Всем привет! Это Алексей Рыбак, основатель R&D-центра Devhands. Мы занимаемся образованием экспертного уровня, внимательно следим за краткосрочными и долгосрочными трендами в индустрии, поэтому предлагаем вашему вниманию очень интересную на наш взгляд ретроспективную статью Константина Ратвина, преподавателя МФТИ и сотрудника СMA Small Systems AB (системы дистанционного банковского обслуживания). Статья посвящена истории развития СУБД, а именно взлету и закату (будем аккуратны, предположительно закату) СУБД нестрогой консистентности (eventually-consistent). В конце этой публикации приведен комментарий к статье Константина Осипова, сооснователя компании Picodata и управляющего директора Группы Arenadata по исследованиям и разработке.
Введение. ACID и BASE: Два пути развития СУБД
В начале 2010-х в профессиональном сообществе разработчиков и архитекторов распределенных систем широко обсуждалась идея, что мир баз данных вступает в новую эру. На фоне успехов крупных интернет-сервисов термин BASE начал использоваться как противопоставление классическому ACID. Хайп вокруг NoSQL, CAP-теоремы и масштабируемых систем породил лозунги вроде «SQL умер», «ACID — для банков, а мы делаем веб», «eventual consistency — это нормально».
Однако спустя полтора десятилетия крупные облачные и корпоративные платформы по-прежнему говорят языком транзакций, изолированных операций и строгой согласованности.
Что же произошло? Была ли «битва ACID и BASE» реальным технологическим разломом или лишь отражала ограничения своего времени?
В этой статье мы разберём, как возникли ACID и BASE, почему BASE быстро стал популярен и что на самом деле означает тезис «победил ACID» в 2020-е годы.
ACID-транзакции как инженерный стандарт
Свойства ACID (Atomicity, Consistency, Isolation, Durability) сформировались в 1970–1980-х на фоне развития транзакционных СУБД для банков и других крупных информационных систем.
Каноничным теоретическим трудом по ACID является книга Transaction Processing: Concepts and Techniques (1993) под авторством Джима Грея (Jim Gray, USA) и Андреаса Ройтера (Andreas Reuter, Germany). В ней под аббревиатурой ACID понимается:
Atomicity: транзакция либо выполняется целиком, либо не выполняется вообще. Это свойство обеспечивается механизмом отката (rollback).
Consistency: транзакция переводит систему из одного согласованного состояния в другое при условии, что прикладная логика корректно описывает инварианты.
Isolation: одновременные транзакции не мешают друг другу, эффект как минимум эквивалентен некоторому последовательному порядку. Это свойство также известно как сериализуемость (serializability).
Durability: зафиксированные изменения не теряются при сбоях. Механизм обеспечения — это журнал транзакций (log) и протокол Write-Ahead Logging (WAL).
ACID-транзакции отвечали на ключевую потребность своего времени в предсказуемой и корректной работе с данными в условиях параллельного доступа и сбоев. Они предлагали формальные механизмы согласованности и восстановления, позволяя системе сохранять логическую целостность даже тогда, когда что-то шло не по плану.
Главная ценность ACID заключалась в том, что вся сложность управления конкурентными операциями и ошибками переносилась из прикладного кода внутрь СУБД. Разработчику не нужно было вручную «склеивать» состояния, отслеживать частично выполненные операции или думать о восстановлении после сбоев — база данных брала эту ответственность на себя и гарантировала корректный результат.
Именно на таких системах десятилетиями работали банки, фондовые биржи и корпоративные расчётные комплексы — тяжёлые, монолитные и внушающие доверие цифровые машины, для которых непредсказуемость данных была недопустимой роскошью. Соответствие ACID стало признаком «нормальной» базы данных, а системы без транзакционных гарантий рассматривались как нишевые или вспомогательные.
Однако к концу 1990-х этот мир начал «трещать по швам». Интернет привёл с собой глобальное распределение, ненадёжные сети и требования к постоянной доступности, при которых классические предпосылки централизованных транзакционных СУБД всё чаще переставали работать. В этих условиях возник запрос на новые архитектуры и переосмысление привычных гарантий работы с данными.
CAP-теорема. Формализация новых вызовов
В 2000 году на симпозиуме PODC Эрик Брюер выступил с докладом “Towards Robust Distributed Systems”. Он сформулировал CAP-теорему:
«В распределённой системе при наличии сетевых разделений невозможно одновременно гарантировать и строгую согласованность, и доступность»
На тот момент CAP была скорее инженерной интуицией, чем строгим результатом, и требовала формального обоснования. Этот вызов был подхвачен научным сообществом.
Вскоре Seth Gilbert и Nancy Lynch (Massachusetts Institute of Technology) обосновали формальную строгость CAP-теоремы в своем труде “Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services” (2002), в котором
вводится формальная модель распределённой системы;
строго определяется, что такое Consistency (строгая согласованность), Availability (доступность) и Partition tolerance (устойчивость к разделениям).
доказывается, что в условиях partition действительно невозможно одновременно обеспечить оба свойства.
CAP-теорема вывела дискуссию о распределённых системах на новый уровень, легализовав инженерные компромиссы, которые уже существовали на практике. Она дала язык, позволяющий утверждать, что отказ от строгой согласованности — это не инженерная слабость, а следствие фундаментальных ограничений распределённых систем.
Однако в публичном поле CAP быстро свели к удобному лозунгу:
«В распределённых системах нужно выбирать между согласованностью и доступностью».
Именно здесь началось упрощение. CAP утверждает, что в присутствии сетевых разделений система вынуждена жертвовать либо согласованностью, либо доступностью. Но в популярном пересказе этот нюанс исчез. Теорема, описывающая аварийные режимы работы, стала восприниматься как универсальный архитектурный приговор.
Эта интерпретация оказалась чрезвычайно удобной. Она хорошо ложилась в доклады и статьи и подкреплялась публичными успехами Amazon, Google и Facebook — масштабируемыми сервисами, демонстрировавшими высокую доступность, глобальное распределение и способность продолжать работу даже при отказах отдельных узлов. На этом фоне постепенно сформировалось устойчивое ощущение, что при глобальном масштабировании строгой согласованностью неизбежно приходится жертвовать.
Позднее сам Эрик Брюер неоднократно уточнял и критиковал такое прочтение CAP, подчёркивая, что согласованность и доступность не являются бинарным выбором и зависят от конкретных условий работы системы.
Тем не менее начали появляться практические системы, сознательно спроектированные вокруг приоритета доступности и устойчивости к отказам. Одной из первых и наиболее влиятельных стала Dynamo — внутренняя система Amazon, наглядно показавшая, как практические инженерные решения позднее были осмыслены через призму CAP.
Dynamo: практическая причина отказаться от транзакции
CAP-теорема дала язык для описания компромиссов, которые начали активно реализовываться в распределённых системах. В 2007 году Amazon опубликовала статью Dynamo: Amazon’s Highly Available Key-value Store, описывающую внутреннюю систему хранения данных с приоритетом высокой доступности и масштабируемости.
Отказ от транзакций и строгой согласованности в Dynamo был осознанным инженерным компромиссом, а не идеологическим противопоставлением ACID. Система разрабатывалась для конкретных сервисов Amazon, прежде всего для корзины покупок, пользовательских сессий, настроек и вспомогательных метаданных, где кратковременная неконсистентность считалась допустимой ценой за устойчивость к отказам и непрерывную работу.
Опыт Dynamo показал, что
eventual consistency может быть допустимой;
расхождения между репликами – это осознанный компромисс;
бизнес иногда готов платить логической сложностью ради SLA.
Именно после Dynamo идея «ослабленных гарантий» стала массово восприниматься как нормальная инженерная практика.
Необходимо было создать новую теоретическую базу для описания распределенных систем. Появился термин NoSQL, под которым объединялись ключ-значение, документо-ориентированные, column-family и графовые базы данных. Параллельно возникла модель BASE как контраст к ACID.
NoSQL и рождение BASE
Буквально на следующий год после представления публике Динамо, в 2008-м, Дэном Притчеттом (Dan Pritchett, eBay, USA) был введён Термин BASE (BASE: An Acid Alternative. ACM Queue, 2008). Он опирается на популярную интерпретацию CAP-теоремы и расшифровывается так:
Basically Available — система стремится быть доступной для операций в любой момент;
Soft State — состояние может временно быть «мягким», т.е. различные реплики расходятся;
Eventual Consistency — если обновления прекратились, со временем все реплики сойдутся к одному значению.
BASE задумывался как антитеза ACID, то есть как простой и запоминающийся язык для описания систем вроде Dynamo. Его риторика была намеренно жёсткой: доступность и масштабируемость объявлялись базовыми свойствами, тогда как строгая согласованность сознательно отодвигалась на второй план. В результате BASE быстро перестал восприниматься как частный инженерный компромисс и начал трактоваться как альтернативная философия проектирования СУБД.
Этот подход оказался созвучен системам, столкнувшимся с новыми условиями эксплуатации, при которых
данные растут на порядок;
требования к задержкам находятся в диапазоне десятков миллисекунд;
пользователи распределены глобально;
вертикальное масштабирование перестало работать.
В то же время разработчиками предпринимались попытки обойти ограничения «классических» СУБД. Наиболее популярной идеей стало горизонтальное масштабирование, однако оно сопровождалось высокой инженерной сложностью: потребностью в распределённых транзакциях, проблемами с глобальными ограничениями, репликационной задержкой, hot-spots и переносом логики согласованности в приложение.
На этом фоне NoSQL-решения с философией BASE казались «глотком свежего воздуха», поскольку предлагали
простой ключ-значение интерфейс;
линейное масштабирование по числу узлов;
возможность записывать данные даже при частичных сбоях.
По сути, индустрия делала утилитарный выбор: лучше временно «грязные», но всегда доступные данные, чем строгие транзакции с высокой латентностью и риском отказов. В условиях быстро растущих интернет-сервисов именно доступность и масштабируемость воспринимались как ключевые бизнес-ценности. В этом контексте BASE оказался удобным политическим маркером эпохи NoSQL. Его риторика звучала почти как лозунг.
BASE чётко отделял «старый мир» транзакционных СУБД от «нового мира» распределённых веб-систем.
Важно подчеркнуть, что в тот момент BASE действительно работал. Это была не теоретическая конструкция и не маркетинговая абстракция: за ним стояли конкретные, успешно эксплуатируемые системы, доказавшие жизнеспособность такого выбора на практике.
Amazon Dynamo и ее наследники
Хотя оригинальный Dynamo был внутренней системой Amazon, его архитектура стала матрицей для целого семейства баз данных.
Cassandra: промышленная реализация BASE-подхода
Apache Cassandra (изначально Facebook, затем Apache) – один из самых ярких примеров успеха BASE.
Ее особенности:
использование модели eventual consistency с настраиваемыми уровнями согласованности;
архитектурная ориентированность на availability и partition tolerance;
способность линейно масштабироваться.
Cassandra позволяла переживать отказ узлов без даунтайма и обслуживать огромные объёмы данных с предсказуемой задержкой. В начале 2010-х Cassandra активно использовалась в Facebook (Inbox Search), Netflix, eBay.
Riak: распределённая система, опередившая свой рынок
Riak – key-value БД, вдохновлённая Dynamo, активно продвигалась как воплощение BASE и сочетала в себе
eventual consistency;
quorum-based операции;
высокую доступность;
Erlang и fault tolerance.
В начале 2010-х Riak быстро завоевала внимание инженерного сообщества как одна из наиболее последовательно реализованных распределённых key-value СУБД. Проект имел активное open-source-сообщество, использовался в ряде стартапов и инфраструктурных проектов и ценился за прозрачную реализацию принципов Dynamo и BASE без скрытых компромиссов. Riak часто приводили в пример как «честную распределённую систему», поведение которой при отказах было предсказуемым и соответствовало заявленной модели согласованности. В период своего наибольшего распространения Riak использовалась в инфраструктурных и веб-проектах ряда крупных компаний, включая Comcast, Best Buy, AT&T, Rovio и Wikia.
При этом в работе системы обнаружился ряд проблем:
сложность reasoning о данных;
конфликты версий;
высокая когнитивная нагрузка на разработчиков.
К сожалению, коммерческая компания Basho обанкротилась в 2017 году.
Riak часто приводят как пример системы, которая была концептуально правильной для эпохи BASE, но оказалась слишком сложной для массового бизнеса.
MongoDB: BASE в мягкой, удобной форме
MongoDB начала 2010-х – это не чистый BASE в духе Dynamo, но в ней
не было транзакций;
была реализована eventual consistency при репликации;
приоритет отдавался простоте и скорости разработки.
Этот подход оказался востребованным на практике – MongoDB быстро стала популярным выбором для веб-приложений и стартапов, а к началу 2010-х широко использовалась как в небольших проектах, так и во внутренних сервисах крупных компаний. Простота модели данных, гибкая схема и активное сообщество сделали её одной из самых массовых NoSQL-СУБД своего времени.
Примерами удачных внедрений MongoDB того периода можно назвать проекты The New York Times, где система использовалась для обработки и хранения контента, метаданных и архивных данных. В MTV Networks применялась для хранения пользовательских данных и контента в веб-проектах. SourceForge, в свою очередь, использовал ее для хранения метаданных проектов, логов и вспомогательной информации.
Однако по мере распространения BASE-систем упрощ��нное прочтение их идей начало работать против самих инженеров. Eventual consistency всё чаще воспринималась как разрешение игнорировать вопросы корректности данных, что на практике приводило к архитектурным и эксплуатационным проблемам.
Проблемы неправильной интерпретации BASE и eventual consistency
На практике BASE часто переводили в крайне упрощённую доктрину:
«Согласованность не важна, пользователи переживут».
Но eventual consistency — это не просто временная «грязь» в данных. Это:
сложные сценарии конфликтов при записи;
неочевидные гонки при чтении/записи;
зависимость поведения от редких сетевых и временных аномалий.
Во многих проектах эти «побочные эффекты» недооценивались. Результат — трудноуловимые баги, которые проявлялись только под нагрузкой или при отказах.
Исследователи и практики начали публично фиксировать подобные аномалии. Так обзор Eventually Consistent: Not What You Were Expecting? (ACM Queue, 2013) указывает, что в слабосогласованных хранилищах торговых систем возможны эффекты, когда один и тот же товар оказывается продан двум покупателям одновременно, или элементы оказываются потерянными из корзины — классические примеры рассинхронизации реплик и overselling / lost cart при распределённых обновлениях данных.
Теоретические работы также подчёркивают, что в системах с eventual consistency разные реплики могут возвращать разные версии данных, и это поведение вовсе не является «случайной ошибкой», а вытекает из фундаментальных свойств модели. Например, формализация eventual consistency показывает, что слабые модели допускают состояние, в котором разные реплики отражают несогласованные состояния системы, что приводит к сложностям в reasoning о корректности [Formalizing eventual consistency (Burckhardt et al., 2013)].
Напрашивался вывод:
BASE — это не «новый стандарт», а осознанный компромисс для конкретных классов задач.
BASE прекрасен, пока речь идёт о
социальных сетях;
телеметрии;
стриминге;
аналитическом логировании.
Но он крайне опасен, когда разговор идёт о
деньгах;
бронированиях;
учёте остатков;
критичных пользовательских данных.
Туманные формулировки BASE («мягкое состояние», «когда-нибудь сойдётся») стали выглядеть слишком грубыми. Они скорее мешали разработке систем, чем помогали. «Сильные стороны» BASE перестали восприниматься таковыми.
Технологический перелом: масштабируемый ACID
К началу 2010-х годов стали появляться системы, показавшие, что строгие ACID-гарантии могут сочетаться с горизонтальным масштабированием. Первой публично описанной системой, доказавшей это на практике, стала Google Spanner.
Google Spanner и внешняя согласованность
В 2012 году компания Google опубликовала статью «Spanner: Google’s Globally-Distributed Database» (OSDI 2012). Она показала, что возможно построить глобально распределённую мультиверсионную СУБД с внешней (строгой) согласованностью транзакций и автоматическим шардингом.
Технически это обеспечивалось сочетанием
механизма мультиверсионности (MVCC);
распределённого консенсуса (Paxos);
глобального синхронизированного времени (TrueTime API).
Google Spanner был не отказом от BASE, а логичным итогом накопленного опыта. Он показал, что при достаточной инфраструктуре строгая согласованность может быть дешевле, чем последствия логических ошибок, не опровергая CAP и не отменяя распределённость.
Эра NewSQL: переосмысление распределённых СУБД
По мере появления систем, сочетающих горизонтальное масштабирование со строгими транзакционными гарантиями, стало очевидно, что термин NoSQL перестал адекватно описывать происходящее. Новые решения больше не отказывались от транзакций и SQL-интерфейса, а напротив возвращали их в распределённый контекст. Для обозначения этого сдвига был введён термин NewSQL, подчёркивающий преемственность с классическими реляционными СУБД при принципиально иной архитектуре.
Следом появились общедоступные системы, реализующие этот подход на практике: CockroachDB, TiDB, YugabyteDB, YDB, а также распределённые расширения и надстройки для PostgreSQL и других традиционных СУБД. Они предлагали:
горизонтальное масштабирование;
транзакции с сильной или близкой к сильной согласованностью;
совместимость с SQL и существующими инструментами.
Возникает закономерный вопрос: означает ли это, что CAP-теорема оказалась ложной, несмотря на свою математическую доказанность? Нет. NewSQL-системы не опровергают CAP, а демонстрируют, что при достаточной инфраструктурной поддержке и точном контроле над отказами можно существенно сузить область, в которой приходится делать жёсткий выбор между согласованностью и доступностью. Иными словами, CAP остаётся верной, но перестаёт быть оправданием грубых архитектурных компромиссов.
Что же с проектами на BASE?
В качестве примеров идеологии BASE были упомянуты СУБД Cassanda, MongoDB и Riak. Riak к настоящему моменту фактически вышла из активного развития и массовой эксплуатации, тогда как Cassandra и MongoDB продолжают широко использоваться в промышленной среде.
Инженеры MongoDB четко отследили меняющийся тренд и совершили переход от BASE к ACID:
сначала single-document atomicity,
затем multi-document transactions (внедрены в 2018)
и наконец усиление гарантий согласованности.
Разработчики Cassanda немного припозднились, но уже сейчас
активно развивают lightweight transactions (LWT, Paxos),
расширяют транзакционные возможности для отдельных операций,
развивают проект децентрализованных транзакций на основе протокола ACCORD
Облачные провайдеры (AWS, GCP, Azure и др.) в свою очередь добавили:
транзакции в ранее нетранзакционные сервисы;
возможность выбора уровня согласованности (strong / eventual / bounded staleness);
автоматическое управление репликацией и шардингом.
Так подход ACID «спустился» с уровня банков и мейнфреймов до уровня массовых облачных сервисов.
Что значит «победил ACID»?
После десятилетия экспериментов с NoSQL, BASE и ослабленными моделями согласованности стало ясно, что разговор о «победе ACID» не сводится к простому противопоставлению концепций. Речь не идёт о том, что BASE оказался ошибкой, а ACID — единственно возможным путём развития СУБД. Под «победой» здесь следует понимать смену инженерных приоритетов, произошедшую по мере накопления практического опыта эксплуатации распределённых систем.
В современных архитектурах транзакционные гарантии всё чаще рассматриваются как инженерный дефолт. При проектировании новых хранилищ сначала обсуждают уровни согласованности и изоляции, и лишь затем — способы масштабирования и распределения нагрузки. Корректность и предсказуемость данных снова стали отправной точкой архитектурных решений, а не опциональным свойством, которым можно пожертвовать ради доступности.
На этом фоне BASE утратил статус универсальной философии и превратился в частный инженерный приём. Ослабленные модели согласованности по-прежнему активно применяются, но точечно — в кэшах, телеметрии, логировании и вспомогательных подсистемах. Вместо противопоставления «ACID vs BASE» язык обсуждения сместился к более точным вопросам: какие гарантии действительно нужны, сколько стоит их обеспечение и какие аномалии допустимы в конкретном доменном контексте.
Выводы
BASE не был ошибкой, но и не стал универсальной альтернативой ACID. Он сыграл роль необходимого этапа, позволив индустрии освоить горизонтальное масштабирование и получить практический опыт работы с распределёнными системами в условиях слабой согласованности.
Язык BASE устарел быстрее, чем стоявшие за ним инженерные идеи. Грубые формулировки вроде «eventual consistency» и «soft state» оказались слишком неточными для описания реальных гарантий и аномалий, с которыми сталкиваются современные системы и бизнес-процессы.
ACID эволюционировал, а не «вернулся». Распределённые СУБД нового поколения показали, что строгие транзакционные гарантии могут сочетаться с масштабируемостью и глобальным распределением при достаточном уровне инфраструктуры и инженерной зрелости.
Современный выбор — не между ACID и BASE, а между конкретными гарантиями и их стоимостью. Строгая согласованность стала инженерным дефолтом для критичных данных, тогда как ослабленные модели применяются точечно и осознанно, там, где их последствия понятны и приемлемы.
ACID «победил» не потому, что BASE был плох, а потому что за прошедшие 15-20 лет индустрия научилась масштабировать строгие гарантии, сохранив их ключевое достоинство – формальную и проверяемую корректность данных. Без BASE этого бы не произошло.
Временная шкала: как менялось внимание к ACID и BASE
Таблица 1. От ACID к BASE и снова ACID
Период | Ключевое событие | Что реально произошло | Связь с ACID / BASE |
1976–1983 | Работы Джима Грея по транзакциям | Формализация свойств корректной транзакционной обработки | Заложены основы ACID |
1990-е | Коммерческие СУБД | ACID становится стандартом де-факто | ACID = «нормальная БД» |
2000 | CAP-теорема (Brewer) | Теоретическое ограничение распределённых систем | Предпосылка будущих компромиссов |
2002 | Формальное доказательство CAP | CAP закрепляет��я как строгая теорема | Часто (ошибочно) трактуется как анти-ACID |
2007 | Amazon Dynamo | Практический отказ от транзакций ради availability | Реальный прообраз BASE-подхода |
2008 | BASE (Pritchett, ACM Queue) | BASE вводится как инженерная философия | Публицистическое противопоставление ACID |
2009–2012 | NoSQL-хайп | Лозунги «SQL умер», «ACID не масштабируется» | BASE воспринимается как альтернатива ACID |
2012 | Google Spanner | Глобально распределённый ACID | Миф о немасштабируемости ACID разрушен |
2015–2020 | NewSQL/DistibutedSQL | CockroachDB, TiDB, YugabyteDB, YDB распределённые транзакции поверх классических СУБД | ACID становится распределённым |
2020-е | Современный статус-кво | ACID — дефолт, BASE — частный случай | Конец противостояния ACID vs BASE |
Комментирует Константин Осипов, сооснователь компании Picodata (Picodata - распределенная PostgreSQL-совместимая СУБД) и управляющий директор Группы Arenadata по исследованиям и разработке.
Я согласен с мнением, что строгая консистентность выигрывает рынок. Но, помимо сложности для пользователей, о которой говорит автор статьи, я вижу и другие причины для этого:
Значительно улучшилась инфраструктура, аварии между дата-центрами реже, стало больше резервных линков, а на смены HDD дискам пришли SSD,
Стало понятно, что на практике не нужно одну СУБД проектировать как строго CP или AP - можно комбинировать подходы для различных функций СУБД.
CAP теорема бинарна, а на практике выбор значительно шире. Например, словарь данных и топология кластера могут управляться строго консистентными, кворумными алгоритмами, в то время как данные могут быть eventually consistent. Состав кворума можно динамически менять, в качестве ответной реакции на аварию (если мы видим что узел мёртв - выводим его из состава кластера проактивно). Или мы можем комбинировать кворумный алгоритм при наличии кворума и подход bully - когда при потере кворума лидером остаётся primary дата-центр, и он сохраняет доступность на запись, при этом bully включается исключительно в момент аварий, а не при “обычной” записи данных.
Дэниэл Абади, профессор, посвятивший много внимания распределенным системам, сформулировал гипотезу о том, что строгая консистентность не влияет на throughput, а влияет только на latency. Да и кросс-континентальный latency, например США-Австралия планомерно приближался всё это время к своему теоретическому минимуму в 120-150 миллисекунд, достаточных для большинства пользователей.
Интересно, что в статье упомянута DynamoDB, одна из первых eventual consistency систем. DynamoDB радикально поменялась за последние 10 лет: на смену LSM деревьям, лежащим в основе большинства eventually-consistent СУБД, пришли Б-деревья из классических транзакционных СУБД. Репликация запросов координатором, также использующаяся в eventually consistent СУБД сменилась на репликацию журнала (помните walsender в PostgreSQL?), появились сначала single-partition, а потом и multi-partition транзакции. Интересно, при этом, что даже авторы DynamoDB видимо не верили что multi-partition транзакции будут востребованы между различными availability zones, и сначала сделали поддержку только в пределах одной availability zone. Думаю такая трансформация в основной облачной СУБД Amazon очень красноречиво говорит о победе транзакционных систем. Отдельный интерес вызывает аспект смены LSM хранилища на B-tree: eventually-consistent СУБД создавались для append-only сценариев, не предусматривающих частых чтений. Для таких сценариев как раз очень хорошо подходит LSM дерево. А вот в транзакционных системах немало "скрытых" чтений: например, при вставке данных необходимо проверить ограничения целостности, а для этого надо прочитать предыдущее значение. И вот как раз для таких сценариев лучше подходят B-деревья. В общем, замена говорящая сама за себя.
Ирония этой истории для разработчиков в том, что несмотря на крутой поворот на уровне одной СУБД проектировать строго консистентные приложения не стало проще. А связано это с тем, что самих СУБД в среднестатистическом проекте стало значительно больше - Kafka, Redis, PostgreSQL, Cassandra - сегодня стандартный джентльменский набор. А вот за консистентность данных распределенных по нескольким СУБД уже отвечает сам разработчик. Так что результат не гарантирован просто выбором СУБД. Необходимо продумать сценарии отказа на уровне приложения, написать интеграционные тесты, иначе спроектировать прикладной код. Так что, вполне возможность, что целостность и консистентность данных в прикладных решениях осталась на прежнем уровне )
Спасибо что дочитали статью! Если вам интересны темы больших распределенных систем, обратите внимание на каналы авторов: Константин Ратвин (@databasethinking), Константин Осипов (@rabid_transit), Алексей Рыбак (@alexeyrybak).
