Нереляционные БД могут быть подходящим решением, если: • ваше приложение нуждается в крайне низкой латентности; • ваши данные не структурированы или не имеют никаких реляционных связей; • вам нужно лишь сериализовать и десериализовать свои данные (JSON, XML, YAML и т.д.); • вам нужно хранить огромные объемы данных.
Нам нужна система версионирования, способная обнаруживать и улаживать конфликты. Для решения этой проблемы часто применяют методику, известную как векторные часы.
Жесткая согласованность обычно достигается за счет того, что операции чтения/записи принимаются только после подтверждения текущей записи всеми репликами. Это не самый оптимальный подход для высокодоступных систем, так как он может блокировать новые операции. В Dynamo и Cassandra используется отложенная согласованность, и именно эту модель мы рекомендуем для нашего хранилища. Она допускает поступление в систему несогласованных значений, заставляя клиента их прочитать и согласовать.
• Строгая согласованность. Любая операция чтения возвращает значение, соответствующее результату самой последней операции записи. Клиент всегда получает актуальные данные. • Слабая согласованность. Последующие операции чтения могут и не вернуть самое последнее значение. • Согласованность в конечном счете. Это разновидность слабой согласованности. Рано или поздно все обновления распространяются по системе и все реплики становятся согласованными.
сконфигурировать N, W и R для наших задач? Вот несколько возможных вариантов: • если R = 1 и W = N, система оптимизирована для быстрого чтения; • если W = 1 и R = N, система оптимизирована для быстрой записи; • если W + R > N, гарантируется строгая согласованность (обычно N = 3, W = R = 2); • если W + R <= N, строгая согласованность не гарантируется.
• W = кворум записи размера W. Операция записи считается успешной, только если она подтверждена W репликами. • R = кворум чтения размера R. Чтобы операцию записи можно было считать успешной, необходимо дождаться ответа как минимум от R реплик.
