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