LINUX.ORG.RU
Форум — Development  

[СИ] База данных

 


0

0

[СИ] База данных

Язык СИ
ОС UNIX

Хотелось бы написать простую специализированную
базу данных.
Под специализированной понимается:
не универсальная, для конкретного приложения.
Отсюда и ожидаемая простота.

Много чего не понимаю. Вот первая тестовая задача:

Задача 1.

Имеется файл-счетчик count.txt малой длины (100 байт).
и некая программа, время от времени наращивающая
этот счетчик.
Требуется: переделать так, чтобы при мягком сбое (отключение питания)
не потерять счетчик.

Думал - думал и ничего лучше не придумал,
кроме следующего.

Создаю два равнозначных файла-счетчика,
дублирующих друг друга.

count_1.txt
count_2.txt

Формат файла такой
count=4; st_tr=36; ks=123345
где
count=4; -основной счетчик;
st_tr=36; -вспомогательный кольцевой счетчик наращиваний,
например, после 99 следующее число 0;
ks=123345 -контрольная сумма.

Наращивание делать так:

-читаем каждый из этих файлов, проверяем контрольные суммы
и совпадение данных в обоих файлах;

Далее по одной из четырех ветвей

-если все в порядке, то изменяем данные и перезаписываем
эти два файла. Дождать, когда они окажутся на диске. Вот и всё.
-если файлы отличаются, и в одном из них правильная ks,
то восстановить, т. е. скопировать правильный в не правильный,
дождать, когда он
окажется на диске (как проверить - не ведомо), затем
нарастить счетчики в обоих файлах.
-если файлы отличаются, и в каждом правильная ks, лучшим из них
считать тот, у которого больше (по кольцу) вспомогательный
счетчик, сделать восстановление, затем нарастить оба.
-другие варианты считать не подлежащими восстановлению.

В чем я заблуждаюсь?

Кто знает прошу ответить.


★
← Java и течь памяти
[opengl] Отмасштабировать изображение, чтобы оно занимало большую часть экрана →
  1 2 →
Ответ на: комментарий от baverman

А вообще, кончайте тыкать пальцем в небо. Пойдите, что ли, почитайте учебник про теорию баз данных.

ddos3 ★
()
Ответ на: комментарий от ddos3

Товарищ, не горячитесь. Вопрос был совершенно прямой. Повторюсь — есть ли теоретическая невозможность атомарной записи большого объема данных, если имеется _только_ атомарная запись маленькой порции.

На практике, «атомарности» записи страницы хватает даже для обслуживания критичных данных.

baverman ★★★
()
Ответ на: комментарий от baverman

> Кстати, а что трудного в организации какой-угодно по объему транзакции, если есть предположительно атомарный способ записать некоторую порцию данных?

Ну, всё течёт, всё изменяется...

Задача: синхронизировать два 20 Тб хранилища, расстояние 12 км (одномодовое оптоволокно), у тебя есть гарантированная атомарная транзакция 1522 байта. Всё, что требуется — это сказать: «Момент времени XXX — хранилища синхронизированы!» в некотором обозримом будущем.

Предложения по реализации: ???

Neksys ★★★
()
Ответ на: комментарий от Neksys

Предложения по реализации: ???

Никаких. Даже думать не хочу.

Мне кажется человек, который спроектировал систему, был несколько некомпетентен, если понадобилась такая операция.

baverman ★★★
()
Ответ на: комментарий от baverman

> Никаких. Даже думать не хочу.

Вот. А ты спрашиваешь «что трудного в организации какой-угодно по объему транзакции, если есть предположительно атомарный способ записать некоторую порцию данных?»...

Мне кажется человек, который спроектировал систему, был несколько некомпетентен, если понадобилась такая операция.


Да, ладно... Синхронизируют же!

Два хранилища, катастрофоустойчивое решение: зеркалирование рабочего корпоративного хранилища информации на второе такое же (Master-Slave). (1522 байта — размер сетевого пакета)

Neksys ★★★
()
Ответ на: комментарий от Neksys

Видите, как все просто оказалось. Я уж думал, что это живая файловая база данных, для которой неприемлема работа в режиме только для чтения и нет механизма репликации.

baverman ★★★
()
Ответ на: комментарий от baverman

Спасибо всем откликнувшимся.

Может или не может машина гарантировать
атомарность записи сектора?
Это важный вопрос.
Как следует из статьи,
сами SQLite-щики не знают точного ответа.

О блокировке и одновременной записи-чтении
вопрос не ставлю. Тут все в порядке.
Для простоты пока можно считать, что
в тестовой задаче 1 может существовать
только один процесс.

Объясню почему возникла эта задача.
Тут две причины.

1.
Если есть самодельная база данных,
и если нужно сделать транзакцию,
то пишу журнал. Там сохраняю всё, что
нужно чтобы сделать откат.
Об этом, о журнале и откатах написано
в книгах и в статье.
И имея такой журнал бояться нечего.

Но самый журнал - это маленькая специфичная
база данных, подверженная тем же сбоям, что и большая.
Значит надо бы еще вести журнал журнала (поменьше).
Так и есть.
SQLite-щики примерно так и делают и называют это
заголовком журнала.

Наконец еще надо журнал журнала журнала.
А это бы и был бы маленький файл высокой надежности
из задачи 1, только названный контрольным файлом транзакции.
Получается пирамида, в вершине которой
маленький но надежный файл.

2.
Эта задача, будучи решенной, имела бы и
другое самостоятельное применение (не база данных).

По моему, в этой задаче самая суть базы данных.
Всё остальное попроще, попонятнее и тестируемо.

oleg_2 ★
() автор топика
Ответ на: комментарий от oleg_2

Задумайтесь, почему разработчики SQLite вообще начали городить эту подпорку. Не от хорошей же жизни. Условия использования такие драконовские. Десктопная встраиваемая бд. Приложение может упасть, питание может исчезнуть, дешевый винт замусорить сектор.

Если ваша база данных подразумевает такое экстремальное использование, то да, городить велосипед придется. Если нет, то на нет и суда нет. Гарантированное питание спасет от большинства костылей.

baverman ★★★
()
Ответ на: комментарий от oleg_2

> А это бы и был бы маленький файл высокой надежности из задачи 1, только названный контрольным файлом транзакции. Получается пирамида, в вершине которой маленький но надежный файл.

Ну, сделай их три штуки одинаковых (параллельных/дублированных), а не один. Можешь, для надёжности, раскидать их по разным партициям. :)

anonymous
()
Ответ на: комментарий от anonymous

Neksys
о асинхронном бардаке записи-чтения.
Уверяю Вас, что тут всё в порядке.
Мне приходилось иметь дело с данными, доступными
многим, и с блокировками.

ddos3
По атомарности транзакции.
Да. Я понимаю, что с начала и до завершения транзакции
никто не должен вмешиваться в ее ход,
а данные, которые связаны с ней, внешне должны
выглядеть как до транзакции или временно не доступны.
Если до этого дойдет, то, надеюсь, справлюсь.
В предложенной Вами статье есть о блокировках.
Там даже упоминается о проблеме пробиться на запись
когда много читателей.

anonymous
Не понятна последняя фраза
«но пиши их последовательно»
Хорошо бы уточнить.

Спасибо.

oleg_2 ★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 →
← Java и течь памяти
Development
[opengl] Отмасштабировать изображение, чтобы оно занимало большую часть экрана →