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

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

Что мне не совсем понятно, так это о какой консистенции они говорят:

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

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

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


nosql database consistency eventual-consistency acid
person Stefan    schedule 12.11.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

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

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

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

person simon at rcl    schedule 12.11.2014
comment
Спасибо, четкий ответ. Однако с практической точки зрения: допустим, вы выбираете существующую СУБД nosql, такую ​​как cassandra, которая предлагает настраиваемую согласованность. Существуют ли какие-либо меры, указывающие на вероятность возникновения проблем согласованности с определенными параметрами? Кроме того, существуют ли какие-либо способы структурирования модели данных таким образом, чтобы с меньшей вероятностью возникали проблемы непротиворечивости? - person Stefan; 12.11.2014
comment
Я не могу ответить, так как я не использую Cassandra (и у меня очень мало опыта работы с NoSQL). Однако, когда вы получаете распределенные базы данных — любого типа, даже если это просто текстовые файлы — у вас рано или поздно возникнут проблемы с согласованностью, поскольку машинам не гарантируется 100% время безотказной работы, сети отключаются на короткие периоды, маршрутизаторы или DNS неправильно настраиваются, и т.д. и т.п. Если у Cassandra нет собственной системы идемпотентного обмена сообщениями, однажды она потеряет согласованность. - person simon at rcl; 12.11.2014
comment
PS Под распределенным я подразумеваю, что ни у одного узла нет всех данных; Я не включаю репликацию БД. - person simon at rcl; 12.11.2014