Четвертый выпуск получился самым сложным по организации. Поругались до трех раз, переделали претезентацию два раза, форкнули подкаст - надеюсь наши усилия не пропадут даром и вам зайдет.

В этом выпуске мы даже писали код! И даже запускали его!!!

https://www.youtube.com/watch?v=ojtNJX0ik2I

Если когда-то возникал вопрос "Как ConsumerGroup'ы работают в Кафке?" - то вот ответ:

https://www.youtube.com/watch?v=MmLezWRI3Ys

А я, в свое время, чинил конкаррент багу в этом протоколе - https://github.com/apache/kafka/commit/00374c3ddf6c4ecc96f58c6685fd107500b976cd

Сейчас занимаюсь исследованием проектов которые реализуют идеи Amazon Aurora (Cloud Native Postgres) - NeonDB - решение на слуху, пока не понял насколько готовое.

Исходники выглядят неплохо, есть тех.документация, RFC.

Дизайн описан в статье в их блоге - https://neon.tech/blog/architecture-decisions-in-neon

А вот и форкнутый выпуск подкаста - рекомендуется к просмотру!

https://t.me/apacheigniteRus/172

На записи подкаста узнал про существование redbook "Readings in Database Systems".
Сборник того что нужно прочитать по СУБД(время переименовывать канал? 🙂 ).

Стоунбрейкер плохого не посоветует

http://www.redbook.io/pdf/redbook-5th-edition.pdf

У соавторов в CV также есть список пейперов, которые выигрывали награды VLDB и других уважаемых изданий.

Придется изучать

Пятый выпуск!
Мы разогнались и не поместились в 2ч)

Про ARIES можно разговаривать долго.
Приятного просмотра)

https://www.youtube.com/watch?v=GzZGlZk-Qy8

https://www.youtube.com/watch?v=k2ccFXWdBN4 - хороший доклад.

Андрей Фомичев - руководитель YDB рассказывает как у них сделан MVCC для распределенной OLTP СУБД.

Выпуск #6 - второй про Aries, и это не конец! Еще и третья часть будет!

https://youtu.be/xuA37cve074?si=Ep30JqbKWou3ygBB

Рекомендации от Databricks и других умных ребят как строить современное хранилище данных.

Кажется, что все крупные игроки уже так делают, хотя пейперу всего 3 года.

Пейпер легко читается - можно подчерпнуть некторые идеи.

Вот еще что интересного делает наша команда:

https://youtu.be/Z8TJZdTJr9A?si=hwadqBwy70IjmU1n

Продолжаем с классикой - "Calvin: Fast Distributed Transactions
for Partitioned Database Systems":

https://www.cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf

СУБД которая реализована по принципам из статьи - YDB.


TL;DR

The essence of Calvin lies in separating the system into three separate layers of processing:

• The sequencing layer (or “sequencer”) intercepts transactional inputs and places them into a global transactional input
sequence—this sequence will be the order of transactions to
which all replicas will ensure serial equivalence during their
execution. The sequencer therefore also handles the replication and logging of this input sequence.

• The scheduling layer (or “scheduler”) orchestrates transaction execution using a deterministic locking scheme to guarantee equivalence to the serial order specified by the sequencing layer while allowing transactions to be executed concurrently by a pool of transaction execution threads. (Although
they are shown below the scheduler components in Figure 1,
these execution threads conceptually belong to the scheduling layer.)

• The storage layer handles all physical data layout. Calvin
transactions access data using a simple CRUD interface; any
storage engine supporting a similar interface can be plugged
into Calvin fairly easily.

Такой дизайн накладывает ограничение:

All transactions are therefore required to declare their full read/write
sets in advance;

Но есть трюки что бы его почти обойти.

https://www.youtube.com/watch?v=8AR1u5OZIm8 - на HighLoad был доклад с описанием реализации Calvin с точностью до тех примитивов что есть в Яндексе.

https://pdos.csail.mit.edu/6.824/papers/spanner.pdf - еще один, уже классический, подход по реализации консистентности в распределенной СУБД - "Spanner: Google’s Globally-Distributed Database".

Ребята из гугла придумали TrueTime API - он предоставляет время с некоторой точностью и на основе этого спроектировали MVCC который хорошо скейлится.

Еще немного про распределенные траназкции. Отличный доклад с Hydra 2022 - Артем Алиев в немного провокационной и слегка фактически неверной манере обозревает подходы к реализации распределенных транзакций.

Доклад стоит глядеть всем прикладным разработчикам, которые собирают "поменять PG на распределенную базу" - что бы осознать сколько это стоит в усилиях, изучении особенностей и переписывании прикладного кода.

https://www.youtube.com/watch?v=lHeEBBSe208

Выпуск #7 - третий про ARIES. Доразобрали все на что хватило сил.
Тема супер обширная - много чего есть еще разобрать и осознать.

https://www.youtube.com/watch?v=zUIuZQBaasY

Новый выпуск!

#8 - В этот раз решили не брать совсем уж хардкорную тему. Разобрали хороший доклад Стоунбрейкера про принципы работы с данными. Облака, дата центры, безопасность и вот это вот все.

https://www.youtube.com/watch?v=bQ9rTsv6VMM

https://sigmodrecord.org/publications/sigmodRecord/2406/pdfs/04_Surveys_Stonebraker.pdf - обзорная статья от авторитетов индсутрии - Павло и Стоунбрейкера.

Цитата для привлечения внимания. Срывают покровы:

There have been major new ideas in DBMS architectures put forward in the last two decades that reflecting changing application and hardware characteristics. These ideas range from terrific to questionable, and we
discuss them in turn.

Вкратце:

Data Models & Query Languages

* MapReduce dead.
* Hadoop dead.
* Spark & Flink doing well.
* RocksDB ... rocks for embedded use-case.
* Для современной СУБД хорошо бы иметь API хранилища для разработки своего.
* json > xml.
* ACID это хорошо и нужно.
* wide column db are dead.
* text search engines где-то сбоку и без транзакций.
* array db интересные и хорошие но только для своих областей - научные и подобные данные натурально ложатся на модель хранения "массив".
* vector db специальный случай массива - одноразмерный. привлекают самое большое внимание разработчиков и инвесторов сегодня. Много ML use-case'ов.

The key difference between vector and array DBMSs is their query patterns. The former are designed for similarity searches that find records whose vectors have the shortest distance to a given input vector in a highdimensional space.

* graph db - развивают совсем другую модель хранения. От этого другой API запросов. Узкоспециализированные сценарии использования.

SQL:2023 introduced property graph queries (SQL/PGQ) for defining and traversing graphs in a RDBMS

===

A reasonable conclusion from the above section is that non-SQL, non-relational systems are either a niche market or are fast becoming SQL/RM systems

System Architectures

Глава написана хорошо - даже не буду ее конспектировать - рекомендуется к прочтению полностью 🙂

NewSQL vendors also incorrectly anticipated that inmemory DBMS adoption would be larger in the last decade. Flash vendors drove down costs while improving storage densities, bandwidth, and latencies. Higher DRAM costs and the collapse of persistent memory(e.g., Intel Optane) means that SSDs will remain dominant for OLTP DBMSs.

The aftermath of NewSQL is a new crop of distributed, transactional SQL RDBMSs. These include TiDB [141],
CockroachDB [195], PlanetScale [60] (based on the Vitess sharding middleware [80]), and YugabyteDB [86]. The major NoSQL vendors also added transactions to their systems in the last decade despite previously strong
claims that they were unnecessary. Notable DBMSs that made the shift include MongoDB, Cassandra, and DynamoDB. This is of course due to customer requests
that transactions are in fact necessary. Google said this cogently when they discarded eventual consistency in
favor of real transactions with Spanner in 2012 [119].

At the present time, cryptocurrencies (Bitcoin) are the only use case for blockchains. In addition, there
have been attempts to build a usable DBMS on top of blockchains, notably Fluree [25], BigChainDB [12], and ResilientDB [136]. These vendors (incorrectly) promote
the blockchain as providing better security and auditability that are not possible in previous DBMSs.

Ну и в заключение нестареющие мудрости:

* Never underestimate the value of good marketing for bad products.

* Beware of DBMSs from large non-DBMS vendors.

* Do not ignore the out-of-box experience.

* Developers need to query their database directly

* The impact of AI/ML on DBMSs will be significant

Новый выпуск!

#9

Обзор статьи "What Goes Around Comes Around... And Around..." залетел в топы.
Сделали целый выпуск про статью.

Статья авторитетов индустрии и наше ценное мнение на этот счет.
Приятного просмотра:

https://www.youtube.com/watch?v=ibNrVbcAw24

https://www.youtube.com/shorts/qjdV8u-CBf0 база про использование ORM