Понимание "P" в "CAP" с DDBMS
В теореме CAP компонент "P" (Partitioning) по существу утверждает, что система работает хорошо, несмотря на физические сетевые разделы.
Я предполагаю, что "C" (согласованность) и "A" (доступность) имеют смысл для меня в контексте DDBMS: при согласованности все клиенты должны иметь согласованное представление данных независимо от того, какой узел БД они обслуживают. А с доступностью все клиенты должны иметь возможность получить ответ от некоторого узла БД на чтение / запись (т. Е. Все узлы никогда не выключаются одновременно).
Но по какой-то причине я задыхаюсь от раздела CAP и его значения, особенно в отношении DDBMS.
С распределенной базой данных у вас по определению есть несколько (кластеризованных) узлов. В зависимости от архитектуры сети и систем, физических устройств и т. Д. У вас могут возникнуть проблемы с производительностью при репликации или обмене данными (полусоединения и т. Д.) Между узлами в любом случае. Так что "P" в CAP- это просто способ повысить производительность в DDBMS; производительность, которая в противном случае была бы затруднена без P-гарантии?
Кроме того, как "P" относится к одному узлу (некластеризованной) БД? Я чувствую, что это совершенно не имеет значения в этом контексте. Заранее спасибо!
2 ответа
Теорема CAP гласит, что в распределенной системе при сбоях не может быть универсальной корректности, доступности и допуска разделов. Корректность означает, что данные, прочитанные с любого узла, не имеют конфликтующих значений на любом другом узле. Доступность означает, что все здоровые узлы могут использоваться клиентами. Допуск разделения означает, что система может быть разбита на подмножества, которые не могут взаимодействовать друг с другом и все еще функционировать.
Скажем, у вас есть 3 машины. Один из них не может связаться с другими, или, другими словами, кластер разделен на 2 раздела. Если система может справиться с этим сценарием, то она терпима к разделу. Однако вы должны отказаться от полной корректности или полной доступности:
Корректность отбрасывания: все узлы остаются активными, но разделенный узел и остальные узлы кластера могут содержать противоречивые данные, иногда известные как разделенный мозг.
Отбрасывание доступности: один из разделов отключается. Это защищает целостность данных, поскольку любое успешное чтение не будет иметь конфликтующего значения где-либо еще.
С точки зрения системы баз данных это означает, что у вас должны быть разные стратегии для решения проблем. База данных, которая не может обработать сбои разделов, означает, что, если какой-либо узел выходит из строя, поведение не определено. База данных, которая жертвует корректностью во время сбоев, вынуждает приложение решать проблемы согласованности при устранении сбоев, но больше узлов может оставаться доступным. База данных, которая отказывается от доступности, позволит логике приложения предположить, что данные всегда согласованы, но в противном случае некоторые исправные узлы будут недоступны во время сбоя.
Насколько я понимаю, CAP заключается в том, что вы не можете надежно иметь все три желаемых атрибута все время и должны выбирать свои приоритеты. Я согласен, что не так просто разобраться с используемой терминологией, но эта статья самого Эрика Брюера хорошо объясняет это. http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
Чтобы ответить на ваш вопрос напрямую, если вы решите разделить данные, то на каком-то уровне вам нужно будет поменять согласованность или доступность. Если вы разделяете данные между A и B, и они теряют связь друг с другом, то вы либо блокируете обновления (-availibity), либо позволяете им обновляться независимо (-consistency)