Сравнил жигуль с броневиком. Скажи какую задачу решаешь. Сколько данных будешь хранить, какое количество запросов будет, нужна ли транзакционность, надежность, репликации ... ?
вот ведь блин..даже на сайт Oracle пошёл посмотреть - как и какое подмножество SQL они зацепили к key-value базе. Оказалось всё проще - их «SQL интерфейс BDB» просто другая база (с другой моделью) сделанная поверх. Обычный SQLite, c парой фирменных вкусных примочек.
sqlite работает на небольших объемах данных. И опять же, как в sqlite принято бороться с порчей базы при segfault'е/некорректном завершении приложения/выдергивании шнура питания ... ? Какой-нибудь более человеческий способ кроме dump'а уцелевшей части базы уже изобрели?
В общем, мне в такой базе было бы стремно хранить что-то кроме настроек приложения или данных, которые не жалко потерять.
Нормально sqlite работает. sqlite работает при непараллельном доступе к БД и с относительно простыми запросами (т.к. оптимизатор запросов там относительно простой).
И опять же, как в sqlite принято бороться с порчей базы при segfault'е/некорректном завершении приложения/выдергивании шнура питания ... ? Какой-нибудь более человеческий способ кроме dump'а уцелевшей части базы уже изобрели?
В sqlite вполне используется журналирование ровно для этой цели.
И опять же, как в sqlite принято бороться с порчей базы при segfault'е/некорректном завершении приложения/выдергивании шнура питания ... ? Какой-нибудь более человеческий способ кроме dump'а уцелевшей части базы уже изобрели?
В sqlite вполне используется журналирование ровно для этой цели.
Если включить synchronous=full, то sqlite работает очень медленно. А если не включать, то ... много раз получал покаррапченную БД путем выдергивания питания.
ога, bdb в режиме мастер-слейв репликации на трех машинках с включенной опцией DB_TXN_NOSYNC рулит нипадеццки. во-первых, всё летает, а во-вторых, надежно и без потерь данных.