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

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

G>>Ты не представляешь глубину всей глупости, которую написал.

CK>фи

G>>Итак простой пример зачем нужен ACID:

G>>Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить.
G>>И внезапно одновременно два человека в разных кассах покупают билеты на одни и те же места на один и тот же сеанс.
G>>Оба "клиента" пишут в 100 нод, 90 из которых эту инфу теряют. То есть реальная запись происходит в 10 нодах. На обоих клиентах эти 10 нод разные.
G>>В итоге твоя система с легкостью продает два билета на одно место.

G>>Ты получил по шапке за такую архитектуру и начал переделывать. Затребовал "кворум" при записи, чтобы 50%+1 одна нода возвращали что данные записаны. Система стала гораздо тормознее.
G>>А все равно продаются по два билета. Потому что запись идет на 51 одну ноду, но данные читаются из остальных 49. И тут ты понял что тебе нужна атомарность (A из ACID).

CK>Есть такая штука, consistent read называется. Система гоняет кворум не только на запись но и на чтение.
И что? Ты или пишешь в те ноды, из которых потом читаешь, или продаешь два билета на место. Про это как раз написано сразу после процитированного тобой блока.


CK>И BTW, у тебя данные будут храниться не на всех нодах а на %replication-factor% нодах (на пяти например), поэтому кворум ты будешь гонять не между всеми нодами а только между пятью.
Тут конечно можно играться кворумом, но надо понимать, что при отвале кворума все стопорится. И нет смысла в твоих 100 нодах если при падении двух из них ты не можешь продавать билеты.