История изменений

Вдогонку, про каузальную консистентность (СС).

Проблема со всеми уровнями консистентности ниже snapshot в том, что потребитель информации не может определить, на сколько она корректна в момент чтения. Тут можно придумать эвристику типа «читаем в цикле несколько раз в экспонециальным увеличением таймаута, если значения не равны», но это всего лишь эвристика.

Можно пробовать эскалировать принятие решения о корректности данных на пользователя и полагаться на его гибкость и достаточность контекста для принятия надежного решения, но это тоже... такое... В одном из моих прошлых проектов пользователи сильно жаловались, когда видели некорректные результаты на дашборде, возникавшие из-за того, что над Druid публиковал сегменты одного датасета асинхронно по мере их фактического появления. И пришлось переделать так, чтобы он эти все сегменты публиковал одномоментно (типа, read committed).

Фактически, применимость EC/СС определяется тем, возможно ли делегирование клиенту принятия решения о корректности данных. Кодить такие вещи ручными эвристиками? Я — пас. Переносить это на пользователей? Тут нужен тщательный анализ на этапе дизайна приложения. Во многих случаях — да, но что это будет стоить? Овербукнутый полет может дорого обойтись в плане репутации. Овербукнутый item на Амазоне — ну зарефандили и всё. Временная неконсистентность данных на дашбордах на NYSE — и опа, потери на миллиарды фантиков из-за паники. Кого-то точно наденут на швабру по самую перекладину.

Что касается CC, я сейчас не уверен, но вроде как она делается на асинхронной репликации, т.е. её можно поднять на любой СУБД с поддержкой асинхронного мультимастера, плюс, возможно, какие-то расширения. Единственное, что она годится только для относительно небольших операционных БД, так как каждый участник (датацентр) должен иметь полную копию данных.

Вдогонку, про каузальную консистентность (СС).

Проблема со всеми уровнями консистентности ниже snapshot в том, что потребитель информации не может определить, на сколько она корректна в момент чтения. Тут можно придумать эвристику типа «читаем в цикле несколько раз в экспонециальным увеличением таймаута, если значения не равны», но это всего лишь эвристика.

Можно пробовать эскалировать принятие решения о корректности данных на пользователя и полагаться на его гибкость и достаточность контекста для принятия надежного решения, но это тоже... такое... В одном из моих прошлых проектов пользователи сильно жаловались, когда видели некорректные результаты на дашборде, возникавшие из-за того, что над Druid публиковал сегменты одного датасета асинхронно по мере их фактического появления. И пришлось переделать так, чтобы он эти все сегменты публиковал одномоментно (типа, read committed).

Фактически, применимость EC/СС определяется тем, возможно ли делегирование клиенту принятия решения о корректности данных. Кодить такие вещи ручными эвристиками? Я — пас. Переносить это на пользователей? Тут нужен тщательный анализ на этапе дизайна приложения. Во многих случаях — да, но что это будет стоить? Овербукнутый полет может дорого обойтись в плане репутации. Овербукнутый item на Амазоне — ну зарефандили и всё.

Что касается CC, я сейчас не уверен, но вроде как она делается на асинхронной репликации, т.е. её можно поднять на любой СУБД с поддержкой асинхронного мультимастера, плюс, возможно, какие-то расширения. Единственное, что она годится только для относительно небольших операционных БД, так как каждый участник (датацентр) должен иметь полную копию данных.