Не знаю как сформулировать заголовок понятнее.
Мне нужна база данных, которая не будет ломаться в условиях некорректного завершения работы. Конкретно мне нужно что бы эта БД работала на моём одноплатнике, который в любой момент может быть выключен простым выдергиванием из розетки. Не страшно, если не выполнится текущая операция, главное что бы база не повредилась.
UPD. Попробую все, что тут предложили, кроме записи в файл, тк записей в таблицах предполагается довольно много, как и операций поиска по ним. Через некоторое время напишу на чём остановился и отмечу рабочие варианты решением.
Егор Казанцев, а чем смущает? И там не только KV, а еще и сеты, хеши, массивы, очереди , счетчики..ttl... или без «транзакций» и вторичных ключей - солнышко в копеечку? Я вас научу, это просто. Спрашивайте. Я без sql живу уже лет 10-15, и волосы только шелковистее. Хотя могу и в sql, которым еще лет 10 занимался. Могу сказать, sql также ненадежен, как и nosql.
Егор Казанцев Вы реально не представляете насколько быстрее разработка на nosql!Тем более, для web! Одни счетчики и pub/sub вас на SQL замучают, не говоря уже про TTL. Эти базы как раз и заточены. чтобы уйти от колонок и полей, а перейти к работе с объектами в виде счетчиков, документов, агрегаций и прочего, что и представляет 90% реальных данных.
И asm, уж простите, никто вас не заставляет пользовать. Как пример, вместо того, чтобы хранить 5-7 таблиц с полями какого нибудь форума вопрос-ответ - у вас всего две-три хеш-таблицы с нормальными полями.
Просто поменять парадигму использования данных.
Вообще-то, все современные СУБД именно под это и заточены. В идеале - надо, чтобы данные располагались не в файловой системе, а в неотформатированном разделе, а то не все файловые системы выдерживают отключение питания.
насколько мне известно, достаточно популярная СУБД Postgresql использует файловую систему посредством драйвера ОС, и как следствие в момент когда буфер еще не был записан системой на диск а БД уже "подумала" что журнал на диск записан , могут быть потери зафиксированных данных.
Нормально написанные СУБД - требуют от операционки (от др-ра файловой системы и от др-ра диска) не врать на тему записи. Т.е. команда запись на диск - даётся с опциями "сообщить о завершении операции только когда она реально завершена".
Простой
