Здравствуйте, Slicer [Mirkwood], Вы писали:

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

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

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

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

SM>1) как гарантировать приход запросов на один и тот же узел (ну я писал уже что на этот счет вроде есть средство)?
SM>3) Балансировка нагрузки обламывается. Но по идее это может и пренебрежимо небольшой дискомфорт, я ранее уже упоминал, что принял к сведению такой способ.
Бытрое гугление говорит что у эластика есть так называемые client (Coordinating) ноды, которые как раз и занимают маршрутизацией запросов, чтобы кластер выглядел для клиента единым целым. При этом ноды стейтлесс и их можно масштабировать.

SM>2) что если узел отомрет? будет короткий момент нарушения монотонности, как минимум (хотя с этим может и смириться можно)
Если отомрет в момент записи, то последствия могут быть гораздо хуже, чем просто небольшое прекращение обслуживания.


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


SM>P.S. Кстати атомарность ведь несколько не о том. Атомарность в ACID означает "либо выполнена либо нет", а не то, что все клиенты должны видеть наиболее актуальное состояние БД.
А как тогда понять что операция выполнена? ACID ведь рассматривает СУБД как черный ящик. Насколько я понимаю единственный способ получить состояние системы — сделать запрос. То есть Atomicity — "прочитал то что записал". То же самое в других местах называется Consistency.

SM>А мне в общем-то не важно будет ли изменение распространено на всю БД сразу — мне главное, чтобы для юзера это выглядело так. Или не так — но как-то так чтобы он мог работать нормально без удивления.
Чтобы не вызывало удивления все операции манипуляции с данными должны быть ACID, за исключением редких случаев..