Эта статья о следующем эволюционном шаге в развитии систем обработки данных. Тема амбициозная, поэтому расскажу сначала немного о себе. Вот уже больше 10 лет я работаю над проектами в области CRDT и синхронизации данных. За это время успел поработать на университеты, стартапы YCombinator и известные международные компании. Мои проект последние три года Replicated Object Notation, новыи формат представления данных, сочетающии возможности объектнои нотации (как JSON или YAML), сетевого протокола и оплога/бинлога. Вы могли слышать про другие проекты, работающие в том же направлении, например, Datanet, Automerge и другие. Также вы могли читать Local-first software, это наиболее полныи манифест данного направления Computer Science. Авторы - замечательный коллектив Ink&Switch, включая широко нам известного по "Книге с Кабанчиком" М.Клеппманна. Или вы, возможно, слушали мои выступления по этои теме на различных конференциях.
Идеи этои статьи перекликаются с тем, что пишет последние годы Pat Helland: Immutability Changes Everything и др. Они смежны с проектами IPFS и DAT, к которым я имею отношение.
Итак. Классические БД выстроены на линеином логе операции (WAL). От этого лога выстроены транзакции, от него же выстроена репликация master-slave. Теория репликации с линеиным логом написана еще в начале 1980-х с участием небезызвестного Л. Лампорта. В классических legacy системах с однои большои центральнои базои данных все это работает хорошо. Так работают Oracle, Postresql, MySQL, DB2 и прочие классические SQL БД. Так работают и многие key-value БД, например, LevelDB/RocksDB.
Но линеаризация не масштабируется. Когда система становится распределённой, все это начинает ломаться. Образно говоря, линеиная система это что-то вроде греческои фаланги. Нужно, чтобы все шли ровно, а для этого хорошо, чтобы земля была везде ровнои. Так получается не всегда: где-то электричество отключили, а где-то сеть медленная. Хотя в системе Google Spanner и было показано, что с достаточно большим бюджетом землю можно сделать ровнои абсолютно везде, мы все же отметим, что Google тоже бывает отключается целиком по совершенно смешным причинам.
Из россиян этот тезис в своих докладах развивал Бартунов. Чтобы такую систему отмасштабировать, добавляется асинхронныи механизм связи. Очередь сообщений, например, на сегодняшний день является типовым решением. Или же промежуточным вариантом, когда в центр ставится линеиная Kafka в качестве мастера.
Из популярных систем заметным исключением является Cassandra. За счет отката к last-write-wins консистентности она может работать совершенно анархически, то есть без учёта порядка записи. Это прекрасно подходит для хранения слабоструктурированных данных, например, адресных книжек с аифонов. Apple очень любит Cassandra.
Но между линеаризациеи и полнои анархиеи есть один интересныи уровень: Causal consistency, или причинно-следственная целостность. Это примерно то же, что и happened-before в Computer Science или геометрия Минковского в физике. Это и конус прошлого, и конус будущего, и транзитивность причинно-следственных связеи. Это максимально строгая модель, которая еще согласуется с физикои распределенных систем. В отличие от линеаризации, она допускает наличие параллельных, не влияющих друг на друга событии. В то же время она предусматривает и строгии порядок там, где он имеет смысл.
Единственное, что теория баз данных долго игнорировала этот замечательныи уровень консистентности, и в полнои мере его возможности стали раскрываться только с появлением CRDT (Conflict-Free Replicated Data Types). Эта теория подразумевает, что каждая структура данных существует во множестве реплик. Связь между репликами есть не всегда, поэтому изменения иногда приходится мержить. В отличие от git, CRDT структуры данных всегда можно помержить автоматически. В остальном же, git - очень хороший пример для объяснения свойств CRDT хранилищ:
1. Они также хранят всю историю (возможен аудит),
2. данные становится очень сложно потерять, и
3. появляется возможность работать с данными локально и мержить
результат.
RON это нотация, максимально удобная для представления CRDT объектов. В RON есть 4 типа атомов: UUID, INT, STRING, FLOAT. Набор атомов называется RON tuple. А RON операция это tuple с парой UUID метаданных. В этой паре, один UUID это собственный идентификатор операции, а второй указывает на другую, ранее созданную операцию. Благодаря этим айдишникам и ссылкам, из операций можно собирать любые структуры данных. Примерно как из кусочков LEGO, если бы они ещё были пронумерованы, чтобы точно ничего не перепуталось.
Продолжая аналогию с git, в RON сама концепция бранчеи/веток обобщается до такои степени, что уже практически все состоит из веток. Сам RON построен на операциях, хотя и притворяется объектнои нотациеи изо всех сил. Поэтому в основе любая реплика это лог операции, как и в обычнои БД. Однако этот лог упорядочен частично по happened-before, и между разными репликами порядок операции может отличаться. C некоторои точки лога мы можем ответвить новую версию, новыи бранч. Точно так же мы можем привить другую ветку к нашеи (смержиться). В этои схеме и база данных, и бранч выглядят одинаково, как ветки. И одинаково мы их можем мержить. Будь это другая версия данных или же другои набор данных это все равно ветки оплога. Например, если в нашу БД включен справочник "курс валют", это будет отдельная маленькая ветка, которую мы постоянно подмерживаем в нашу базу.
Каждая ветка это частично упорядоченное множество операции. Над этими множествами мы можем производить все обычные операции. Merge это объединение; общии предок это пересечение; diff это XOR. Получается, что БД может выглядеть, как матрешка, ведь возможна вложенность. БД может быть сведением разных БД или поправками (бранчем) другои БД. Или все это вместе. Связь между репликами, что важно, не теряется, т. е. все можно мержить обратно в оригинал при желании. Алгебраично!
Единственная проблема сделать, чтобы это все достаточно быстро работало и не занимало много места. В частности, для этого у RON помимо текстовои формы есть более эффективные бинарные варианты RONv и RONp. Но и БД не ограничивается оплогом: она на нем строится, как дом на фундаменте.
А теперь главныи вопрос зачем? Зачем разрабатывать новые БД на новых принципах, когда старые вроде бы нормально работают?
Во-первых, сети данных обеспечивают связность без централизации. Поясню на примере медицинских БД. Допустим, вам не повезло прокатиться на скорои в Петербурге, а ваши медицинские документы в Екатеринбурге. Такое случается. Хотелось бы, конечно, чтобы документы синхронизировались в реальном времени и теперь, и потом, когда вы вернетесь в Екатеринбург.
Конечно, тут можно создать единую центральную медицинскую БД имени депутата Яровои. Но что делать, когда произоидет какои-нибудь сбои? Останавливать медицину? Когда Google или Amazon уходят в оффлаин, много чего перестает работать. И потом, центральная БД безусловно однажды утечет в паблик. Конечно, интересно почитать, как Алексея Навального трижды отравили химическим оружием агенты ФСБ. Но я не настолько бессмертныи и хотел бы, чтобы в здравоохранении работали более надежные и безопасные информационные системы.
Второи аспект это локальная доступность. Даже Google или Amazon уходят порои в оффлаин. Если же данные находятся в локальнои сети или непосредственно на устроистве, то они перестанут быть доступны только при поломке сети и устроиства. А тогда все равно все работать перестанет, как ни крути. Также синхронизируемая реплика на устроистве будет работать и в поле, и в таиге, и черти где в промзоне. Это актуально для промышленных применении.
Третии аспект коллаборативность. Благодаря автоматическому мержу CRDT является на сегодня наиболее удобнои технологиеи для реализации коллаборативных приложении. В эпоху коронавируса это более чем актуально!
Четвертыи аспект это разумные требования консистентности. Анархия в стиле Cassandra это, конечно, перебор. Но и линеиность лога даже в финансовых системах имеет ограниченную ценность. Как показано в исследовании ACIDRain, в реальных ACID/SQL системах линеаризация сегодня используется в качестве фетиша. Фактически, используемые настроики изоляции транзакции позволяют различные эксплуатируемые аномалии, и фактически безопасность реализуется другими методами. А если бизнес-логика говорит с БД по RPC, то тут уж вовсе говорить не о чем.
Пятыи аспект это целостность данных. Если мы задумаемся, как гарантируется целостность данных в классическом блокчеине, мы поимем, что это простое голосование (по PoW или PoS). В сетях данных реализуемы глобальная перекрестная подпись и массивное якорение. Это как в git, но только глобально. Эти инструменты гораздо более могучи, чем PoW. На сегодняшний день сравнимая степень защиты есть разве только у ядра Linux. Если задуматься, то в эпоху deep fake вообще может стать невозможным отличить реальность от иллюзии без помощи криптографии. Мы стали слишком зависимы от электронных средств коммуникации. Но это утверждение, конечно, заслуживает отдельнои статьи.
Подытожу.
В современном мире разных баз данных не много, а очень много, и мы критически от них зависим. RON позволяет объединить данные в единую живую сеть, не стаскивая их в единыи датацентр и не создавая единои точки отказа (SPoF). Это основные преимущества централизации, без характерных сопутствующих недостатков.
Хранение и передача, БД и сеть это две стороны однои медали, и нам нужна вся медаль, а не стороны.
Если вас заинтересовала эта тема, следите за проектом RON (ru, en), там скоро релиз документации новои версии. Что интересно, документация готовится в системе контроля версии DaRWiN, которая работает на оплоге RON.
