Здравствуйте, Gattaka, Вы писали:
G>Я вас удивлю, но жесткий диск далеко не единственный способ оставить свои данные в сохранности. Более надежная фишка — сеть. Т.е. вместо того чтобы писать на медленный диск. Вы отправьте инфу по сети 100 нодам. Даже если 90 нод потеряет ее (что невероятно с точки зрения теории вероятности) вы сохраните информацию. Причем на 10 нодах. А не на одном паршивом диске. Скорость при этом небо и земля. Просто неспопоставимы по скорости диск и сеть. Сеть быстрее. И зачем нужен этот ваш ACID?
Ты не представляешь глубину всей глупости, которую написал.
Итак простой пример зачем нужен ACID:
Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить.
И внезапно одновременно два человека в разных кассах покупают билеты на одни и те же места на один и тот же сеанс.
Оба "клиента" пишут в 100 нод, 90 из которых эту инфу теряют. То есть реальная запись происходит в 10 нодах. На обоих клиентах эти 10 нод разные.
В итоге твоя система с легкостью продает два билета на одно место.
Ты получил по шапке за такую архитектуру и начал переделывать. Затребовал "кворум" при записи, чтобы 50%+1 одна нода возвращали что данные записаны. Система стала гораздо тормознее.
А все равно продаются по два билета. Потому что запись идет на 51 одну ноду, но данные читаются из остальных 49. И тут ты понял что тебе нужна атомарность (A из ACID).
Прикрутил affinity, чтобы данные одного сеанса шли на одну ноду. То есть полностью похерил всю "фишку" с сетью, но ладно, у тебя данные в памяти и все быстро, а для "надежности" у тебя все равно запись в несколько узлов\зеркал.
Но билеты все равно по два продаются. Оказывается что между чтением состояния и записью проходит время и параллельные операции могут "одновременно" прочитать что билеты не проданы, а потом записать что проданы.
Оказывается нужны констрейны и согласованность (С в ACID), чтобы такого не было.
Ну ок, собрал свой optimistic locking и WAL поверх NoSQL на каждое место (тормозит шопипец), записал в логику ограничений в "хранимые процедуры". Но все равно фигня происходит, когда параллельно пытаются купить билеты на два места, один клиент покупает 10е и 11е, а второй 11е и 10е.
То два билета на место, то дедлоки возникают. Тут ты понимаешь что тебе нужна независимость транзакций (I в ACID).
Наконец ты прикрутил транзакции поверх NoSQL. Это работает в 10 раз медленнее чем MS SQL, хотя пишется на диск не сразу. Только ноды у тебя падают, и после падения случается, что обращения происходят к ноде, которая часть записей до этого потеряла. И ты опять продаешь несколько билетов на одно место.
Когда тебя увольняют за профнепригодность, ты понимаешь что тебе изначально нужна была долговечность записи (D в ACID).
Я уже писал в одной из тем, что ACID это не прихоть инженеров, а здравый смысл людей. Ты не можешь сделать не ACID систему, если она хранит не-мусор.
Максимум что ты можешь сделать это ослабить требования ACID, там где потребитель не увидит разницы или вынести часть сложностей на другой уровень.
