Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 37
Хорошая статья
в присутствии сетевых разделений система вынуждена жертвовать либо согласованностью, либо доступностью
Что значит "разделений"? В присутствии любой сети между БД, даже если сеть сейчас работает. То есть этот момент закладывается уже при проектировании.
Ничего не понял. Зачем так много слов? Хоть бы алгоритмы кворума расписали.
Если несколько баз, разделенных сетью то варианты:
Ждём ответа всех
Ждём ответа кворума
Ждём ответа хоть кого-то одного
Полная согласованность 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, мол раз все равно может упасть, давайте хотя бы будем работать, но по мне лучше предсказуемая ошибка "сервис временно недоступен", чем непредсказуемый мусор в базе, который всплывет через месяц
тогда получается если нужна согласованность и есть проблемы с сетью, то объявленная консистентной транзакция должна упасть. если консистентность не требуется, то при проблемах с сетью допускается несогласованность
Ну да, так и есть. Это вообще называется двухфазный комит, и он существует уже лет 30 как в разных в субд
это вы про всякие суровые вещи типа db2 и oracle?
если я правильно помню там не было масштабирования на уровне самой базы данных, это кажется нужно было еще сверху application layer писать свой, который уже с отдельными базами работал, а в new sql получается примерно тоже самое что было 30 лет назад но без этого дополнительного application layer, его теперь в саму бд засунули.
нет еще в 2000- лохматом году у mssql субд был Failover Clustering с полным acid и и двухфазными коммитами внутри субд, без всяких application layer
а в постгрес двухфазный комит подвезли в 8-й версии
Add two-phase commit (Heikki Linnakangas, Alvaro, Tom)
Two-phase commit allows transactions to be "prepared" on several computers, and once all computers have successfully prepared their transactions (none failed), all transactions can be committed. Even if a machine crashes after a prepare, the prepared transaction can be committed after the machine is restarted. New syntax includes PREPARE TRANSACTION and COMMIT/ROLLBACK PREPARED. A new system view pg_prepared_xacts has also been added.
так это вы же про HA cluster говорите, а не горизонтальное масштабирование.
То что я писал выше про application layer похоже скорее на clickhouse timescale. Если я правильно помню, то там вы определяете ключ партицирования и разные партиции лежат на разных физических нодах + копии на других нодах для избыточности. И когда вы делаете join, он либо делается долго и дорого, все данные со всех нод сливаются на одну и она делает join. Либо же если у вас все партицировано правильно, и все данные которые нужно для джойна лежат на одной ноде, каждая нода делает join, а потом результаты этих джойнов мержаться и отдаются клиенту. Кстати не уверен что timescale такое умеет, а вот clickhouse точно умеет. Но это так нормально повышает сложность разработки, нужно сразу, при дизайне схемы думать что с чем будет джоиниться. Насколько я понимаю 30 лет назад что-то такое было у db2 и oracle, но не как часть db, а как отдельная надстройка.
Жаль что в статье лишь вскользь прошли мимо того что 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 СУБД — всё?