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

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

* Если "обычные" это полностью консистентные, то я отвечу так. Хотелось научиться применять eventual consistency решения, потому что в будущем, чувствуется, мне все чаще будут встречаться задачи такого рода, где масштабируемости или отказоустойчивости или производительности или возможностей (взять тот же эффективный поиск подстрок, например) классических СУБД будет не хватать, особенно с учетом пожеланий заказчиков по бюджету. А еще хотелось научиться конкретно эластик применять — пусть даже в сочетании с классической БД.

* На самом деле я готов отказаться именно от требования такого уровня целостности, если мне предложат другой подходящий К примеру, я готов до какой-то степени не сразу увидеть внесенные изменения, но хочется хотя бы, раз их увидев, в дальнейшем не получить на свой запрос более ранний вариант данных, где их еще нет. Не иметь возможности вносить корректировки в только что созданную запись (или в ту которую только что показал поиск) — мне кажется странным и для конечного пользователя неприемлемым. Я с удовольствием послушаю, если кто-то мне объяснит, почему это ОК — от этого моя жизнь только проще станет Или если мне скажут что по идее производительность кластера БД должна быть настолько велика, а отваливания узлов настолько редки, что с проблемами столкнется лишь один пользователь в неделю из сотни тысяч, а такое в большинстве систем можно и игнорировать.

Slicer