Решения NoSQL обычно предназначены для преодоления ограничений масштаба SQL.Эти ограничения масштаба объясняются теоремой CAP .Понимание CAP является ключом к пониманию того, почему системы NoSQL имеют тенденцию отказываться от поддержки ACID.
Итак, позвольте мне объяснить CAP в чисто интуитивном смысле.Во-первых, что означают C, A и P:
Согласованность: с точки зрения внешнего наблюдателя каждая «транзакция» либо полностью завершена, либо полностью откатана.Например, при совершении покупки amazon подтверждение покупки, обновление статуса заказа, сокращение запасов и т. Д. Должны отображаться «синхронно» независимо от внутреннего разделения на подсистемы
Доступность: 100% запросов успешно завершены.
Допуск раздела: любой заданный запрос может быть выполнен, даже если поднабор узлов в системе недоступен.
Что это означает с точки зрения проектирования системы?Какое напряжение определяет CAP?
Для достижения P нам нужны реплики.Много их!Чем больше копий мы храним, тем выше вероятность того, что любой нужный нам фрагмент данных будет доступен, даже если некоторые узлы отключены.Для абсолютного «P» мы должны реплицировать каждый элемент данных на каждый узел в системе.(Очевидно, что в реальной жизни мы идем на компромисс на 2, 3 и т. Д.)
Чтобы достичь А, нам не нужна ни одна точка отказа.Это означает, что конфигурации репликации «первичный / вторичный» или «главный / подчиненный» выходят за пределы окна, так как главный / основной является единственной точкой отказа.Нам нужно использовать несколько основных конфигураций.Для достижения абсолютного «A» любая отдельная реплика должна быть способна обрабатывать операции чтения и записи независимо от других реплик.(на самом деле мы идем на компромисс в отношении асинхронности, очереди, кворумов и т. д.)
Для достижения C нам нужна «единая версия истины» в системе.Это означает, что если я пишу в узел A, а затем сразу же читаю обратно из узла B, узел B должен возвращать актуальное значение.Очевидно, что это не может произойти в действительно распределенной мультимастерной системе.
Итак, каково «правильное» решение проблемы?Детали действительно зависят от ваших требований, но общий подход состоит в том, чтобы ослабить некоторые из ограничений и пойти на компромисс с другими.
Например, для достижения гарантии "полной согласованности записи" в системе сn реплик, число операций чтения + количество операций записи должно быть больше или равно n: r + w> = n.Это легко объяснить на примере: если я храню каждый элемент на 3-х репликах, у меня есть несколько вариантов, чтобы гарантировать согласованность:
A) Я могу записать элемент на все 3 реплики, а затем прочитать из любогоодин из трех, и будьте уверены, что я получаю последнюю версию. B) Я могу записать элемент в одну из реплик, а затем прочитать все 3 реплики и выбрать последний из 3 результатов. C) Я могу написать в 2 из3 реплики и считывание с 2 из 3 реплик, и я гарантирую, что на одной из них будет установлена последняя версия.
Конечно, в приведенном выше правиле предполагается, что ни один узел не вышел из строя.тем временем.Чтобы обеспечить P + C, вам нужно быть еще более параноиком ...
Существует также почти бесконечное количество хаков "реализации" - например, уровень хранилища может завершить вызов, если он не можетзаписывать в минимальный кворум, но может продолжать распространять обновления на дополнительные узлы даже после успешного возвращения.Или это может ослабить семантические гарантии и возложить ответственность за объединение конфликтов версий на бизнес-уровень (это то, что сделали в Amazon Dynamo).
Различные подмножества данных могут иметь разные гарантии (т. Е. Одна точка отказаможет быть в порядке для критических данных или в порядке блокировки вашего запроса на запись, пока минимальное количество реплик записи не успешно записало новую версию)
Шаблоны для решения 90% случая уже существуют, но каждое решение NoSQL применяет их в разных конфигурациях.Шаблоны - это такие вещи, как разбиение (стабильное / на основе хеша или на основе переменной / поиска), избыточность и репликация в кэшах памяти, распределенные алгоритмы, такие как map / проводить.
Когда вы углубляетесь в эти шаблоныБазовые алгоритмы также довольно универсальны: векторы версий, деревья меркля, DHT, протоколы сплетен и т. д.