Базы данных: от страницы на диске до триграмм

Что такое база данных и зачем она вообще

Файл на диске - тоже хранилище. Разница в четырёх буквах ACID, в 55 годах теории Кодда и в том, что база переживает выдёргивание шнура из розетки на середине записи.

1. Почему не просто файл03
2. 55 лет: от статьи Кодда до векторных баз04
3. Зоопарк: восемь семейств и что у них внутри05

Как СУБД устроена внутри

Парсер, планировщик, исполнитель, буферный пул, журнал. Что происходит за 200 микросекунд между SELECT и первой строкой ответа - и почему одна и та же строка может существовать в пяти версиях одновременно.

1. Жизнь одного SELECT07
2. Страницы, буферный пул, WAL08
3. MVCC: почему читатели не ждут писателей09
4. Уровни изоляции и аномалии, которые они пропускают10
5. Локи: что блокирует что и как они друг друга убивают11

Индексы: структуры, которые делают базу базой

B-tree с 1970 года не имеет конкурентов для точечного поиска и диапазонов. Но у Postgres ещё пять типов индексов, и каждый решает задачу, на которой B-tree бессилен: JSON, геометрия, полнотекст, «содержит подстроку», таблица на 10 ТБ по времени.

1. B-tree: три чтения на миллиард строк13
2. Шесть типов индексов: когда B-tree не подходит14
3. Порядок колонок решает всё15
4. Почему индекс есть, а планировщик его не берёт16
5. Читаем EXPLAIN (ANALYZE, BUFFERS)17
6. Partial, expression, unique с нюансами18
7. Семь способов сделать индексы бесполезными19

Стратегии соединений

Три алгоритма на всю индустрию: Nested Loop, Hash Join, Merge Join. Планировщик выбирает между ними по статистике, и ошибка в оценке в 100 раз превращает 2 мс в 2 минуты. MySQL 20 лет жил с одним из трёх.

1. Три алгоритма соединения21
2. Как планировщик выбирает и где ошибается22
3. MySQL 20 лет с одним алгоритмом23
4. Джоины, которые тормозят, и как их лечить24

PostgreSQL: слон, который умеет всё

Самая расширяемая СУБД в истории: типы, операторы, индексы и даже планировщик подменяются расширениями. Отсюда PostGIS, TimescaleDB, pgvector, Citus - и pg_trgm, три буквы, ради которых половина проектов не ставит Elasticsearch.

1. Процессы, память, диск26
2. VACUUM: цена MVCC, которую платишь постоянно27
3. Типы данных, которых нет у других28
4. Расширения: одна база вместо пяти сервисов29
5. pg_trgm: магия трёх букв30
6. Триграммы: цифры, лимиты, рецепты31
7. Встроенный Full Text Search: tsvector и tsquery32
8. pgvector: векторный поиск там же, где данные33
9. Репликация и отказоустойчивость34
10. Грабли Postgres, на которые наступают все35

MySQL: дельфин, на котором стоит веб

Facebook, YouTube, Wikipedia, Booking, Uber - все начинали и многие остались на MySQL. Простой, быстрый по PK, с репликацией, которая настраивалась за 5 минут в 2005-м. И с набором тихих сюрпризов, из-за которых половина индустрии перешла на Postgres.

1. Два слоя: сервер и storage engine37
2. Таблица = B+-tree по первичному ключу38
3. Репликация: binlog, GTID, Group Replication39
4. Тихие сюрпризы MySQL40
5. Честное сравнение41
6. Форки и надстройки: MariaDB, Percona, Vitess, TiDB42

ClickHouse: миллиард строк в секунду

Яндекс.Метрика в 2016 открыла движок, который делает GROUP BY по 20 триллионам строк. Секрет - колонки вместо строк, сжатие в 10 раз, векторное исполнение и полный отказ от всего, что мешает: транзакций, точечных UPDATE, честных JOIN.

1. Почему колонки в 100 раз быстрее для аналитики44
2. MergeTree: parts, гранулы, разреженный индекс45
3. Чего ClickHouse не умеет и как с этим жить46
4. Когда ClickHouse, когда Postgres, когда оба47

Oracle, MSSQL, SQLite, DuckDB

Oracle - $50 тысяч за ядро и лучший оптимизатор на планете. SQLite - бесплатно и в каждом телефоне. Между ними MSSQL для корпоративной Windows и DuckDB, который делает аналитику на ноутбуке.

1. Oracle Database: за что платят $47 500 за ядро49
2. Ещё три, которые нельзя не знать50

NoSQL: когда таблицы не подходят

Redis отвечает за 100 микросекунд, Cassandra принимает миллион записей в секунду на 100 нодах, MongoDB хранит документ как есть. Каждая из них отказалась от чего-то, что реляционные базы считают священным - и именно поэтому решает свою задачу.

1. CAP, PACELC и что реально выбирают52
2. Redis: структуры данных по сети за 100 микросекунд53
3. MongoDB: документы, WiredTiger и долгий путь к ACID54
4. LSM-tree против B-tree: две философии записи55
5. Cassandra / ScyllaDB: миллион записей в секунду, ноль лидеров56
6. Графовые, time-series, NewSQL57

Почему Elasticsearch - не база данных

Инвертированный индекс ищет слово среди миллиарда документов за миллисекунды - и не умеет ничего из того, ради чего существуют базы: транзакций, консистентности, целостности. Elastic, Sphinx, Solr, Manticore - это индексы поверх базы, а не вместо неё.

1. Инвертированный индекс: от слова к документам59
2. Elasticsearch / OpenSearch: как устроен кластер60
3. Семь причин, почему Elastic - не источник правды61
4. Sphinx / Manticore, Solr, Meilisearch, Typesense, Tantivy62
5. Где база, а где поисковый движок: матрица решения63
6. Как держать индекс в согласии с базой64

Практика: схема, масштаб, бэкапы, мониторинг

Вещи, которые не пишут в документации, но которые определяют, спишь ты ночью или нет: нормализация без фанатизма, пагинация без OFFSET, партиции вместо DELETE, бэкап, который реально восстанавливается, и пять метрик, на которые надо смотреть.

1. Нормализация и денормализация без религии66
2. Пагинация, батчи, блокировки очередей67
3. Партиционирование и шардирование68
4. Бэкапы: три вида и одно правило69
5. На что смотреть, пока не упало70
6. Все базы на одном слайде71

Одна страница 8 килобайт

Всё, что было выше, сводится к одному вопросу: сколько страниц по 8 КБ нужно прочитать, чтобы ответить на запрос. B-tree - чтобы их было три. Колонки - чтобы они были плотные. MVCC - чтобы читать их, не ожидая никого. WAL - чтобы после выключения света они остались. Планировщик - чтобы угадать, каких страниц меньше. Триграммы - чтобы страницы нашлись даже по обрывку слова.