Здравствуйте, gandjustas, Вы писали:

G>Вы пытаетесь получить строгую consistency на базе системы с delayed consistency. Если говорить в терминах acid, то речь идет об Атомарности (A).
В идеале да. Я готов согласиться на меньшее, если user experience при этом гарантированно не пострадает по сравнению с традиционными СУБД. Но пока по моим выкладкам получается, что пострадает.

G>1) Подождать пока consistency наступит. То есть после нажатия "сохранить" держать пользователя "сохраняю" пока не удастся получить от хранилища документ.
Не сработает, если получать подтверждение мы будем от одного узла, а ходить для продолжения работы уже на другой. Но мы могли бы ожидать подтверждения от _всех_ узлов — но для этого нужна поддержка на уровне СУБД, ведь не гулять же вручную по всем активным узлам.

G>2) ... или просто время хранения в кеше выставлять равным удвоенному среднему времени прихода подтверждения.
Ну а для экстремальных случаев мы пролетим мимо среднего.

G>В целом такие проблемы могут быть решены если у вас есть одно-узловая consistency. То есть система в целом eventual consistent, но если все запросы приходят в один и тот же узел, то выполняется требование строгой consistency.
G>Но, как я понимаю elastic search не обладает таким свойством.
Мне кажется, все же обладает — но 1) как гарантировать приход запросов на один и тот же узел (ну я писал уже что на этот счет вроде есть средство)? 2) что если узел отомрет? будет короткий момент нарушения монотонности, как минимум (хотя с этим может и смириться можно) 3) Балансировка нагрузки обламывается. Но по идее это может и пренебрежимо небольшой дискомфорт, я ранее уже упоминал, что принял к сведению такой способ.

G>Третий вариант — отказаться от не-ACID хранилищ для транзакционных задач. Вы по факту потребовали от системы атомарности (A) и долговечности (D) с точки зрения ACID, зачем пытаться решать задачу на системе, которая не дает таких гарантий?
Допустим, что у меня есть и иные требования. Скажем, к возможностям поиска (в случае эластика) или же к легкости горизонтального масштабирования.
И опять же, я могу и снять свои требования к консистентности, если мне объяснят, как без них работать пользователям.

P.S. Кстати атомарность ведь несколько не о том. Атомарность в ACID означает "либо выполнена либо нет", а не то, что все клиенты должны видеть наиболее актуальное состояние БД. А мне в общем-то не важно будет ли изменение распространено на всю БД сразу — мне главное, чтобы для юзера это выглядело так. Или не так — но как-то так чтобы он мог работать нормально без удивления.