Re[3]: Eventual consistency
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.07.18 20:03
Оценка:
Здравствуйте, 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, за исключением редких случаев..
Re[3]: Eventual consistency
От: Cyberax Марс  
Дата: 12.07.18 05:22
Оценка: 10 (2)
Здравствуйте, Slicer [Mirkwood], Вы писали:

C>>Я не очень понимаю зачем такое вообще нужно. Почему нельзя использовать обычную БД, если требуется read-after-write целостность?

SM>Разумный вопрос. Но он распадается на два, постараюсь кратко ответить.
SM>* Если "обычные" это полностью консистентные, то я отвечу так. Хотелось научиться применять eventual consistency решения, потому что в будущем, чувствуется, мне все чаще будут встречаться задачи такого рода
Я работаю с eventual consistency, но чисто по необходимости. Они требуют особой организации данных для того, чтобы можно было более-менее нормально этим пользоваться.

Я не пользовался ES, так что могу рассказать как я делал бы в случае абстрактного клиента в вакууме. В данном примере, я бы организовал данные так:
1) Каждый клиент получает непрозрачный "контекст соединения" — блоб данных в несколько сотен байт, кодирующий нужное состояние.
2) Этот контекст указывается при всех операциях, в которых важна read-after-write целостность.
3) Контекст является короткоживущим объектом, и каждая операция может вернуть новый контекст. Клиент обязан в этом случае для будущих операций использовать этот новый контекст.

Базу документов делим на shard'ы, привязывая определённые серверы к определённым shard'ам. Каждый shard внутри хранит монотонно увеличивающийся счётчик изменений. Соответственно, при операции записи возвращается контекст, который укажет на ожидаемые счётчики для затронутых shard'ов. При чтении эти значения будут использоваться для того, чтобы подтвердить, что реплика полностью обновилась до нужного уровня.
Sapienti sat!
Re[4]: Eventual consistency
От: Sharov Россия  
Дата: 12.07.18 08:44
Оценка:
Здравствуйте, Cyberax, Вы писали:


C> Соответственно, при операции записи возвращается контекст, который укажет на ожидаемые счётчики для затронутых shard'ов. При чтении эти значения будут использоваться для того, чтобы подтвердить, что реплика полностью обновилась до нужного уровня.


Что значит "ожидаемые счётчики для затронутых shard'ов"? Откуда я их узнаю при записи, кто мне их отдаст? Нода, которая знает о своих соседях или как?
Кодом людям нужно помогать!
Re[5]: Eventual consistency
От: Cyberax Марс  
Дата: 12.07.18 19:20
Оценка:
Здравствуйте, Sharov, Вы писали:

C>> Соответственно, при операции записи возвращается контекст, который укажет на ожидаемые счётчики для затронутых shard'ов. При чтении эти значения будут использоваться для того, чтобы подтвердить, что реплика полностью обновилась до нужного уровня.

S>Что значит "ожидаемые счётчики для затронутых shard'ов"? Откуда я их узнаю при записи, кто мне их отдаст? Нода, которая знает о своих соседях или как?
Ну так при записи выдаётся новый контекст, который будет кодировать их состояние.
Sapienti sat!
Re[6]: Eventual consistency
От: Sharov Россия  
Дата: 13.07.18 09:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

S>>Что значит "ожидаемые счётчики для затронутых shard'ов"? Откуда я их узнаю при записи, кто мне их отдаст? Нода, которая знает о своих соседях или как?

C>Ну так при записи выдаётся новый контекст, который будет кодировать их состояние.

А как новый контекст узнает о затронутых шардах, если он возвращается в ответ на запись (на одном из шародов?) ?
Кодом людям нужно помогать!
Re[7]: Eventual consistency
От: Cyberax Марс  
Дата: 13.07.18 18:55
Оценка:
Здравствуйте, Sharov, Вы писали:

C>>Ну так при записи выдаётся новый контекст, который будет кодировать их состояние.

S>А как новый контекст узнает о затронутых шардах, если он возвращается в ответ на запись (на одном из шародов?) ?
При запросе на запись указываем контекст и каждый раз получаем в ответ новый. Обработчик запроса, очевидно, знает на каких шардах оно исполняется.

По сути, контекст гарантирует нам соблюдение причинности.
Sapienti sat!
Re[8]: Eventual consistency
От: Sharov Россия  
Дата: 14.07.18 21:19
Оценка:
Здравствуйте, Cyberax, Вы писали:


C>Обработчик запроса, очевидно, знает на каких шардах оно исполняется.


А вот это мне не ясно. Мы пишем в базу на одном конкретном шарде и не знаем на каких шардах будет реплика.
Как мы можем вернуть инф-ию о шардах? Или мы ждем, когда ответит большинство и возвращаем контекст?
Т.е. что-то типа гоняем paxos на каждую запись, чтобы знать шарды или как ?
Кодом людям нужно помогать!
Re[4]: Eventual consistency
От: Slicer [Mirkwood] Россия https://ru.linkedin.com/in/maksim-gumerov-039a701b
Дата: 15.07.18 03:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Базу документов делим на shard'ы, привязывая определённые серверы к определённым shard'ам. Каждый shard внутри хранит монотонно увеличивающийся счётчик изменений. Соответственно, при операции записи возвращается контекст, который укажет на ожидаемые счётчики для затронутых shard'ов. При чтении эти значения будут использоваться для того, чтобы подтвердить, что реплика полностью обновилась до нужного уровня.

Ага, так и в одной статейке какого-то из директоров было. Я это назвал "глобальный номер версии" (потому что если у каждого шарда счетчик будет совсем независимый, то до какого-то шарда могло дойти только одно из двух изменений, а до другого — только другое, и получится что у каждого версия увеличилась на 1 — но реально данные на них разные; так что думаю номер должен быть все же каким-то образом сквозным, по кр мере на первый взгляд).

Но вот в том и фишка что БД должна такую нумерацию (в том числе при общении с клиентами) поддерживать сама.

Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Re[9]: Eventual consistency
От: Cyberax Марс  
Дата: 16.07.18 00:15
Оценка: 6 (1)
Здравствуйте, Sharov, Вы писали:

C>>Обработчик запроса, очевидно, знает на каких шардах оно исполняется.

S>А вот это мне не ясно. Мы пишем в базу на одном конкретном шарде и не знаем на каких шардах будет реплика.
Обычно запрос посылается сервису, который имеет карту шардов и сам разбирается куда надо перенаправлять запись.

S>Как мы можем вернуть инф-ию о шардах? Или мы ждем, когда ответит большинство и возвращаем контекст?

Нет, здесь не надо никакого консенсуса.
Sapienti sat!
Re[5]: Eventual consistency
От: Cyberax Марс  
Дата: 16.07.18 00:22
Оценка:
Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Ага, так и в одной статейке какого-то из директоров было. Я это назвал "глобальный номер версии" (потому что если у каждого шарда счетчик будет совсем независимый, то до какого-то шарда могло дойти только одно из двух изменений, а до другого — только другое, и получится что у каждого версия увеличилась на 1 — но реально данные на них разные; так что думаю номер должен быть все же каким-то образом сквозным, по кр мере на первый взгляд).

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

SM>Но вот в том и фишка что БД должна такую нумерацию (в том числе при общении с клиентами) поддерживать сама.

Глобальный ID — это узкое место, так как все записи будут синхронизироваться на нём.
Sapienti sat!
Re[10]: Eventual consistency
От: Sharov Россия  
Дата: 17.07.18 09:13
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Обычно запрос посылается сервису, который имеет карту шардов и сам разбирается куда надо перенаправлять запись.


А можно про это подробнее почитать, ссылки и т.д.? Значит этот сервис будет заниматься консенсусом, хотя бы будет отслеживть кто живой.
В любом случае, запись, после которой вернется новый контекст с шардами, будет, кмк, крайне долгой. Ну или этот сервис будет давать не 100% инф-ию, т.е. некоторые шарды
из его карты могут отвалиться.
Кодом людям нужно помогать!
Re[11]: Eventual consistency
От: Cyberax Марс  
Дата: 17.07.18 19:23
Оценка:
Здравствуйте, Sharov, Вы писали:

C>>Обычно запрос посылается сервису, который имеет карту шардов и сам разбирается куда надо перенаправлять запись.

S>А можно про это подробнее почитать, ссылки и т.д.? Значит этот сервис будет заниматься консенсусом, хотя бы будет отслеживть кто живой.
Да, сервис-маршрутизатор должен знать какие хранилища отвечают за определённые диапазоны ключей (шарды). Но обычно это очень небольшой и достаточно статичный объём информации.

S>В любом случае, запись, после которой вернется новый контекст с шардами, будет, кмк, крайне долгой. Ну или этот сервис будет давать не 100% инф-ию, т.е. некоторые шарды

Почему запись будет долгой? Маршрутизатор принимает команду "запихать значение A по ключу B и значение С по ключу D", разбрасывает их на соответствующие шарды (скажем, "L" и "N") и ждёт их ответа, возможно с таймаутом. Потом возвращает результат (возможно, что частичный) клиенту.

Так как в задаче не требуется транзакционная целостнось или гарантии идемпотентности, то больше ничего и не надо.
Sapienti sat!
Re[2]: Eventual consistency
От: Aquilaware  
Дата: 02.08.19 01:19
Оценка:
Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Тут наверно можно в некоторых системах управлять affinity между идентификатором сессии/логином юзера и номером инстанса эластика (ну или вообще БД) который хранит primary shard. То есть запросы указанного id от указанного пользователя будут всегда ходить на один и тот же шард. Может и так кто-то делает?


Делает. Работает классно. Вероятность того что нагнется инстанс маленькая, поэтому сессия пользователся почти всегда работает с тем инстансом, с которым она была начата. Проблем нет.
Re[2]: Eventual consistency
От: vsb Казахстан  
Дата: 02.08.19 06:17
Оценка:
Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>>2) Аналогично п.1, но еще подлее. Пользователь то видит в списке созданную сущность, то не видит — вплоть до того что например он открывает редактор созданной сущности, вносит изменения туда, а при попытке сохранить получает ошибку из-за того, что сущности якобы нет (потому что опять сходил не на тот шард).


SM>Тут наверно можно в некоторых системах управлять affinity между идентификатором сессии/логином юзера и номером инстанса эластика (ну или вообще БД) который хранит primary shard. То есть запросы указанного id от указанного пользователя будут всегда ходить на один и тот же шард.


ИМХО это самое разумное. Я бы так пытался сделать по возможности.

SM> С другой стороны это во-первых ставит под удар балансировку нагрузки


Почему? Может балансировка будет менее равномерной, но вряд ли прям под улар.

SM> а во-вторых опять-таки шард же может и отвалиться и тогда вероятность не увидеть свои изменения опять появляется (ну или может банально не успеть обновиться, если он не входит в кворум по репликации).


Ну значит будет какой-то процент запросов иметь "глюки". Можно для таких случаев сделать автоматический retry, пока на новом узле, куда вас переназначили, не появится эта запись.
Re: Eventual consistency
От: Ночной Смотрящий Россия  
Дата: 02.08.19 12:43
Оценка:
Здравствуйте, Slicer [Mirkwood], Вы писали:

Обычно по ID документа вполне однозначно вычисляется имя шарда-источника. Поэтому если на своем шарде ты дока не нашел, то просто идешь к источнику. В распределенных БД такое, как правило, обеспечивается автоматически.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[3]: Eventual consistency
От: baxton_ulf США  
Дата: 05.11.19 02:11
Оценка:
Здравствуйте, Slicer [Mirkwood], Вы писали:


SM>А обновить список на клиенте сразу — это ведь тоже не так просто. Как предлагаешь к этому подойти? Вот мне нужна 10-ая страница списка документов с сервера — потому что сейчас мы ее просматриваем — как мне понять на клиенте, попадет в нее добавленный только что документ или нет?


как отсортируешь список на такую страницу и попадет


SM>... сделает рефреш и попадет на тот шард где данных нет, то в списке их опять не будет =)


погоди, редактируемый обьект всегда в одном и том же шарде, нет?
и читается он всегда с прайм ноды. если прайм нода в дауне (деплоймент или сломалась) то читается со следующей реплики.
никто не заставляет читать только с одной реплики это только для очень highly available систем, но там в жертву приносится консистенси. читай с нескольких реплик и пиши сразу на несколько. сравни результат чтения и верни последнюю версию. если версии разьехались (в результате кучи обновлений во время падений хостов) то решай как все обьединить или возвращай все версии — пусть клиент сам решает как быть
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.