Comments 32
Хорошая статья
в присутствии сетевых разделений система вынуждена жертвовать либо согласованностью, либо доступностью
Что значит "разделений"? В присутствии любой сети между БД, даже если сеть сейчас работает. То есть этот момент закладывается уже при проектировании.
Ничего не понял. Зачем так много слов? Хоть бы алгоритмы кворума расписали.
Если несколько баз, разделенных сетью то варианты:
Ждём ответа всех
Ждём ответа кворума
Ждём ответа хоть кого-то одного
Полная согласованность acid только в первом случае. 3й похож на base. 2й пытается играть с вероятностями, подходя к почти 100% оценке согласованности
Ничего не понял. Зачем так много слов?
Потому что LLM.
Ребят, это такой вид спорта теперь на хабре? Да, статья ретроспективная и поэтому длинная; статья не ставит целью "разжевать" базу тем, кто не в теме. Но обвинять в LLM-генерации -- имейте совесть, на крайняк не поленитесь и загоните текст в LLM чтобы оценить вероятность генерации.
Это реинкарнация «первыйнах» со времен удаффкома. Но там это было органично, а сейчас больше на болезненное самоутверждение смахивает.
загоните текст в LLM чтобы оценить вероятность генерации
Вероятность генерации 75%.
Но вы верите детекторам LLM на базе LLM? :)
Ладно, может вы просто графоман и любите длинно писать о том, о чём можно написать коротко и без канцеляризма.
Обвинять Рыбака в LLM такое себе. Он сам умеет генерить тексты почище ИИ, я за 20+ лет знакомства не раз в этом убеждался :)
ACID хоронят половину того времени которые я занимаю программированием. Ни куда ты не денишься от транзакций, если тебе нужно гарантировать констстентность сложных структур данных, над которыми могут производится комплексные манипуляции. А при разпрелеленнвх системах вопрос только в том какой алгоритм кворума ты выберешь.
столько боролись - "лишь бы не ACID", а в результате всё равно пришли к ACID
Юзаем в проде FoundationDB в котором распределённый ACID, и он прекрасно держит большие нагрузки со вполне вменяемым latency. Но там важно, чтобы конфликтов в транзпкциях было поменьше и кластер с базой был рядом с подами, а то все преимущества скушают сетевые задержки.
Использую в проде base на максимаклках
А конкретно - гипер базу aka crusDb
https://habr.com/ru/articles/956154/
Без кворума
Без транзакций
Но быстро надёжно, доступно
статья хороша, но вот самая суть вопроса осталась не оч понятной::
"можно существенно сузить область, в которой приходится делать жёсткий выбор между согласованностью и доступностью."
что блин это значит
upd:
а вроде понял.
это значит что если нет проблем с сетью, то наблюдается и согласованность и доступность, а вот если проблемы с сетью появляются, тогда что-то одно теряется.
и вся суть статьи:
CAP неправильно поняли и сделали eventual consistency постоянным режимом, хотя она должна включаться только при сетевых сбоях, а не при нормальной работе системы.
Странно, что нейронка не в курсе, что C в ACID и в CAP - это совсем разные consistency. Сколько раз уже это разжевывали…
Да, согласованность, или даже линеаризуемость, и консистентность из acid - это разные вещи. Но это вообще не меняет ни смысла статьи, ни ценности. И кстати нейронка-то как раз в курсе. И на всякий случай -- вместо того чтобы включать неуместный поучающий тон -- можно взять текст статьи, загнать его в LLM, и оценить вероятность написания текста нейронкой. Оставлю это упражнение в качестве домашнего задания (спойлер: будет очень низкая вероятность написания нейронкой, chatgpt 5.2 thinking даст ниже 10%).
сделали eventual consistency постоянным режимом, хотя она должна включаться только при сетевых сбоях,
А проблема в том, что ты ДО начала транзакции должен знать - нужна ли её консистентность или нет, ждем ли подтвержение кворума для коммита или нет? А сетевые сбои они такие - непредсказуемые.
Забавно что непредсказуемость сбоев обычно используют как аргумент в пользу base, мол раз все равно может упасть, давайте хотя бы будем работать, но по мне лучше предсказуемая ошибка "сервис временно недоступен", чем непредсказуемый мусор в базе, который всплывет через месяц
тогда получается если нужна согласованность и есть проблемы с сетью, то объявленная консистентной транзакция должна упасть. если консистентность не требуется, то при проблемах с сетью допускается несогласованность
Жаль что в статье лишь вскользь прошли мимо того что consistency в ACID и в CAP это вообще про разные вещи: в ACID это про инварианты бизнес-логики (баланс не меньше нуля), а в CAP - про линеаризуемость (все видят одно и то же состояние системы). Но суть верна: индустрия наигралась в "со временем сойдется". Когда у тебя реплики начинают отдавать разные версии реальности, даже самая быстрая БД превращается в генератор случайных чисел, который невозможно дебажить
Обычно write сторону делают согласованной, а read делают eventual. И не будет ситуации когда один заказ уходит двум людям.
Наверное, имеется в виду что аналитическая часть может быть безболезненно eventual.
Но не вся read такая. И вообще, для разделения нужен CQRS
Не увидел в статье про аналитическую часть. Рассматриваются СУБД безотносительно к шаблонам и практикам типа cqrs и делается вывод о превосходстве acid это непонятно.
Что значит не вся read такая? Я пишу как масштабировать мы при помощи base стандартный подход в использовании eventual read.
Есть два сценария: RW и чистый R. Вот в первом случае понижать гарантии есть риск собрать бинго. Если смотрим на чистый R, то тут уже можно обменивать гарантии на что-то другое. В частности, можно читать чуть неконсистентные данные в моменте чтения, но в следующий момент все будет ок.
Как студент 4 курса скажу, что эта статья хорошо дополняет то, что сейчас обычно читают на курсах субд. Не тех, где изучение БД= изучение SQL, а тех которые погружают в мир разнообразия баз данных. Обычно рассказывается хронология SQL, NoSQL, NewSQL и даже все перечисленные технологии и подходы, но нет времени на такие подробности. А как мне кажется это хорошо расширяет кругозор и особенно раскрывает тему eventually-consistent
Первая половина статьи очень хорошая, а вот вторая на поминает оправдания "это не мы плохие и опростоволосилась, что просто нам не повезло" или "Парень к успеху шел, но но повезло не фортануло". Да и фразы типа "не вернулся, а переродился" заставили улыбнуться.
В общем статья интересная, только я чувствуется, что у автора произошёл перелом видения мира, и морально он его до конца не прошёл.
А мне статья понравилась, спасибо
Eventually-consistent СУБД — всё?