Вероятно имеется в виду на база данных, а СУБД? Хвалили redis.
Скорость — это одно, только фанаты Redis как-то не говорят о том, что оно не ACID. Т.е. вот выключат электричество в ДЦ до дампа данных на диск и всё, потеряем данные. Специфическая вещь довольно.
Т.е. вот выключат электричество в ДЦ до дампа данных на диск и всё, потеряем данные.
Данные за 30 секунд? В большинстве случаев это не критично. Да и вероятность, что выключат - стремится к нулю. Раз уж пошла такая пьянка, то и вероятность падения атомной бомбы нужно предусмотреть при проектировании приложения.
Данные за 30 секунд? В большинстве случаев это не критично.
Всё-таки я бы так не говорил. У всех проекты разные и требования разные. Я как-то в основном сталкивался с такими проектами, в которых за кривые или потерянные данные могут и нехило наказать.
В общем ладно, выбирать ТСу по специфике решаемой задачи. :-)
В свое время искал, и пришел к выводу, что все популярные базы медленные на update. Быстрые только всякая экзотика. Но: можно заменить update insert-ом, а это уже быстро много где, например в том же постгресе.
Where обрабатывается как обычный select. Если там по индексу поиск, то ничего не тормозит. Дальше затык уже в io, это хорошо видно если отключить fsync, скорость сразу увеличивается. У меня не получилось на моем железе более 50 update в секунду при поиске по pk.
Как мне гарантированно сохранить данные в этом 30 секундном (или в другом, который задаётся вручную) промежутке между последним дампом данных на диск и выключением питания сервера? (Redis.)
да может быть очень кстати, я просто написал какие запросы используются в реляционке. Главное - если данные пришли на апдейт, они должны было 100% на диске. Пару секунд потери обновлений при краше - некритично, но 30 - дофига.
Осиляторы Оракла говорят что он вообще трансформируется базу данных любого назначения путем применения опытного DBA. Думаю это часто правда, но не всегда. Я сам не могу похвастаться что умею ним пользоваться.
Правду мы никогда не узнаем, проприетарные БД нельзя бенчмаркать согласно их лицензиям. Точнее можно дома, но публиковать нельзя. Наколенные бенчмарки обычно лажа, даже когда профессиональные не полностью торт.
Еще один вариант ответа: LDAP, в варианте openldap еще и репликация из коробки (она, как я понял, вообще в протоколе зашита), как у других - не знаю. openldap в далеком 2004 году на дохлом говне мамонта рвал с места в карьер
ACID, к указанному, имеет крайне далекое отношение.
В вашем случае для гарантии нужно использовать журналируемую NoSQL, которая вовсе не обязана быть ACID полной, вместо on-memory NoSQL аля упомянутый Redis.