db.links


Гео и язык канала: Россия, Русский
Категория: Технологии


Ссылки на различные обучающие материалы по базам данных

Связанные каналы

Гео и язык канала
Россия, Русский
Категория
Технологии
Статистика
Фильтр публикаций


https://arxiv.org/pdf/2504.11259

Обзорная статья развития СУБД с большим количеством авторитетов в соавторах.

В том числе дана оценка LLM - можно охарактеризовать как сдержаный оптимизм.


https://synthesis.frccsc.ru/sigmod/rus/index_html.html - Буквально недавно узнал, что в Москве есть "Special Interest Group on Management of Data"

И ребята проводят довольно академические семинары по нашей теме.
Строго рекомендуется к посещению.


Хороший товарищ идет делать stream processing по этому пейперу.

https://static.googleusercontent.com/media/research.google.com/ru//pubs/archive/43864.pdf


Стоунбрейкер с другими уважаемыми людьми померял оверхед на различные способы изоляции пользовательского когда от ядра СУБД - https://vldb.org/cidrdb/papers/2025/p17-zhou.pdf


Результаты можно прочитать по ссылке - мне очень нравится структурированность и ясность описания. Приятно читать.

Есть еще ссылки на бенчи, про которые я не слышал - YCSB, Voter. Видимо, стоит изучить.


Вот цитата из выводов статьи:



We have also shown that relational database systems produce large
estimation errors that quickly grow as the number of joins increases,
and that these errors are usually the reason for bad plans. In contrast to cardinality estimation, the contribution of the cost model to
the overall query performance is limited.

Going forward, we see two main routes for improving the plan
quality in heavily-indexed settings. First, database systems can incorporate more advanced estimation algorithms that have been proposed in the literature. The second route would be to increase the
interaction between the runtime and the query optimizer. We leave
the evaluation of both approaches for future work.


Инновационные предложения состоят в "Напишите более лучшие оптимизаторы" и "Собирайте более лучшую статистику". Спасибо, пойдем работать и делать! Без этих советов мы бы сами об этом никак не догадались 🙂


Прочитал, вроде как, популярный пейпер "How Good Are Query Optimizers, Really?"

Бюось показаться невеждой, но не уловил в чем такой восторг у авторов оптимизаторов.

Возможно, авторы оптимизаторов настолько оторвались от реальности и пользователей СУБД, что выводы

- Оптимизатор работает плохо когда много JOIN'ов.
- Вероятностная статистика работает .... ну вероятностно и часто ошибается.
- Что бы нормально отработали JOIN'ы в сложном запросе их надо прибивать гвоздями с помощью хинтов.

кажутся инновационными и прорывными.

Алле - это все известно буквально с 80-х годов прошлого века 🙂

https://vldb.org/pvldb/vol9/p204-leis.pdf






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






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

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

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


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

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




Продолжаем с классикой - "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;

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




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

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

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







Показано 20 последних публикаций.

336

подписчиков
Статистика канала