Эффекты согласованности в распределенных (NoSQL) базах данных

Question

Всякий раз, когда я что-то читал о распределенных базах данных NoSQL, они упоминают теорему CAP и что это означает, что в многораздельной системе вы можете иметь полную согласованность, полную доступность или немного того и другого, но никогда не оба полностью.

Что не совсем понятно мне, какой тип последовательности они говорят:

1. ли последовательность в свежести данных, где некоторые клиенты могут получить старые данные, чем другие?
2. Или это согласованность в том смысле, что транзакции могут выполняться только частично, и это может привести к несогласованности данных?

Вторая интерпретация звучит довольно опасно для меня и не совсем приемлема. Первая интерпретация звучит приемлемо, но как вы можете предотвратить, что клиент, который запрашивает набор данных, не будет обслуживаться с частично устаревшими данными и частично свежими данными?

Насколько опасно только частичное согласование и каковы возможные негативные последствия?

Answer 1

Консистенция в распределенных базах данных представляет собой огромную проблему, и это означает оба ваших варианта: устаревшие данные в некоторых местах и ​​частично завершенные транзакции. Я не собираюсь писать эссе об этом, потому что - это огромная проблема, и решения непросты. Однако, вот некоторые ключевые фразы.

Возможная последовательность - это решение, но реализация его звучит как большая работа. Ключом к реализации является Идемпотентные сообщения. Допустим, полная транзакция включает обновление данных на машинах A, B и C. Как вы на самом деле это делаете? Вы начинаете отправлять сообщения по всему месту и продолжать отправлять их, пока не получите подтверждение получения и успешной обработки. Вы можете отправить сообщение в B дважды, потому что B никогда не получал сообщение, или потому, что B ack так и не получил. Если вы отправили его дважды, потому что у вас никогда не было этого, тогда B лучше поступил правильно, когда он снова получит его (что может быть проигнорировать его), и отправьте вам ответ, чтобы вы его не беспокоили.

This is a pretty good article, похоже, и его точка зрения NoSQL. В любой поисковой системе есть множество ссылок о сообщениях Idempotent, поэтому я позволю вам вступить в круги.

Заключительное примечание: Пэт Хелланд, который работал над распределенными базами данных в течение многих лет (в Microsoft и Google среди других мест), в конце концов пришел к выводу, что согласованность для распределенных БД невозможна, и что вы лучше соглашаетесь на Eventual Consistency через Идемпотентные сообщения.