Обзорная лекция про базы данных (2025)

Зачем нужна СУБД?

Пример приложения

Wishlist

Допустим, мы хотим написать приложение wishlist, которое будет хранить список понравившихся товаров.

У нас есть простые операции: просмотр списка, добавление и удаление товаров.

Реализация хранилища

Все данные загружаем в память из файла в JSON.

При изменении данных пишем JSON на диск.

Пример приложения

Недостатки реализации

• Запись не атомарна, можем потерят все данные
• Всегда пишем всё, что не эффективно
• Конкуррентный доступ требует блокировок
• А если не хватит одного хоста по памяти?
• Отказоустойчивость

Для прототипа такое решение может сгодиться, но не более.

Базовые термины

Write Amplification

Отношение размера записываемых данных в СУБД к размеру записываемых данных на диск.
Например, в базу вставили 1 Мб данных, но на диск было записано 2 Мб - write aplification равен 2.

Read amplification

Количество чтений с диска необходимых для выполнения запроса.
Например, если для выполнения запроса нужно выполнить 3 чтения, то read amplification равен 3.

Space Amplification

Отношение размера данных в БД к размеру занимаемому на диске.
Например, размер данных в БД 1Мб, но файлы БД на диске занимают 5Мб - space amplification равен 5.

Физика

Стоимость типовых операций

Работа с данными идёт блоками

Выравнивание блоков

• Размер кэшлинии в DDR5: 32 байта
• Размер страницы памяти: 4096 байт
• Размер сектора диска: 4096 байт
• Размер сетевого пакета: 1500 байт

Последовательная запись всегда быстрее

• Особенности механики
• Prefetch данных

Кэширование чтения

Холодный кэш

Пустой кэш или кэш с устаревшими данными.

Тёплый кеш

Кеш, который содержит данные, которые часто используются.

LRU (Least Recently Used)

Кэш, когда удаляется элемент, который дольше всего не использовался.

Буферизация чтения

Основная идея — данные временно сохраняются в специальном буфере (буфере обмена) перед записью.

Это позволяет накапливать изменения и уменьшать общее количество записи.

Журнал транзакций

Журнал транзакций — специальный журнал, который содержит информацию о всех транзакциях, которые были выполнены в базе данных.

• Можно восстановить данные по журналу
• Данные всегда пишутся в конец (амплификация записи)
• Журнал позволяет передавать изменения на другой хост

Batching

Batching — алгоритм, который позволяет сгруппировать несколько операций в одну пачку.

• Позволяет уменьшить количество записей в журнале
• Уменьшает нагрузку на диск
• Увеличивает скорость записи

Batching

Алгоритм Нейгла

Является средством повышения эффективности работы сетей TCP/IP, позволяющим уменьшить количество пакетов, которые должны быть отправлены по сети.

Пока существует отправленный пакет, для которого отправитель ещё не получил никакого подтверждения о доставке, отправитель должен держать в буфере следующие данные для отправки, до тех пор, пока не наберётся достаточно данных на полный пакет, который можно отправить единожды.

А если не влезаем в память?

Организация данных на диске

Строковая vs Колоночная СУБД

Организация данных на диске

Строковая СУБД

• Более быстрая работа с OTLP-запросами (обработка транзакций)
• Более эффективная запись

Колоночная СУБД

• Более быстрая работа с OLAP-запросами (аналитическая нагрузка)
• Более эффективное сжатие данных

Организация данных на диске

B-Tree+

B-Tree+ – это сбалансированное дерево поиска, в котором каждый узел содержит множество ключей и имеет более двух потомков.

Write amplification

`O(B)`

Read amplification

`O(log_B (N/B))`

Организация данных на диске

LSM-дерево

LSM-дерево – структура данных, предоставляющая быстрый доступ по индексу в условиях частых запросов на вставку.

Write amplification

`O(k*log_k (N/B))`

Read amplification

`O((log^2 (N/B))/log k)`

Организация данных на диске

TOAST (The Oversized Attribute Storage Technique)

• Объекты больше TOAST_TUPLE_THRESHOLD (2Кб) сжимаются;
• Если объект получается больше TOAST_TUPLE_TARGET (2Кб), то он перемещается в отдельное хранилище, где хранится чанками.>

SQL vs NoSQL

SQL vs NoSQL

SELECT * FROM people

db.people.find()

SELECT *
FROM people
WHERE age > 25
LIMIT 10

db.people.find({
  age: { $gt: 25 }
}).limit(10)

EXPLAIN SELECT *
FROM people
WHERE status = "A"

db.people.find({
  status: "A"
}).explain()

INSERT INTO
people (user_id, age, status)
VALUES ("bcd001", 45, "A")

db.people.insertOne({
  user_id: "bcd001",
  age: 45,
  status: "A"
})

UPDATE people
SET age = age + 3
WHERE status = "A"

db.people.updateMany(
  { status: "A" },
  { $inc: { age: 3 }}
)

SQL

SQL обычно подразумевает реляционную модель данных.

• Язык запросов SQL:
  • DML (Data Manipulation Language)
  • DDL (Data Definition Language)
• Отношения (таблицы)
• Констрейнты
• Внешние ключи
• Реляционная алгебра
• Нормализация
• ACID-транзакции

1-ая нормальная форма

Переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов.

1-ая нормальная форма

Переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов.

2-ая нормальная форма

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

2-ая нормальная форма

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

3-я нормальная форма

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

3-я нормальная форма

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

4-ая нормальная форма

Переменная отношения находится в четвёртой нормальной форме, если она находится в третьей нормальной форме и не содержит нетривиальных многозначных зависимостей.

4-ая нормальная форма

Переменная отношения находится в четвёртой нормальной форме, если она находится в третьей нормальной форме и не содержит нетривиальных многозначных зависимостей.

Нормализация

• Нормализованные таблицы обычно обновляются быстрее, чем ненормализованные.
• Когда данные хорошо нормализованы, они либо редко дублируются, либо не дублируются совсем. Так что изменять приходится меньше данных.
• Нормализованные таблицы обычно меньше по размеру, поэтому лучше помещаются в памяти и их производительность выше.
• Из-за отсутствия избыточных данных реже возникает необходимость в запросах с фразами DISTINCT или GROUP BY для извлечения списков значений.
• Нормализованные данные требуют большего количества JOIN-ов для выборки.

Денормализация

Денормализация

Намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.

• Обновление данных триггерах.
• Обновление данных по расписанию.
• Инкрементальное обновление данных.

Выборка данных

Поиграемся с базой данных

Чтобы поиграться можно взять готовые базы даных:

• PostgreSQL Sample Database
• MovieLens

Для импорта данных MovieLens есть скприт: https://github.com/bozaro/presentations/tree/master/scripts/movielens.

Простой запрос на поиск

SELECT * FROM movies WHERE title = 'Titanic';

   id   |  title  | year
--------+---------+------
   1721 | Titanic | 1997
   3404 | Titanic | 1953
 118916 | Titanic | 1996
 181653 | Titanic | 1943
(4 rows)

Простой запрос на поиск

EXPLAIN ANALYZE
SELECT * FROM movies WHERE title = 'Titanic';

                      QUERY PLAN
--------------------------------------------------------
Seq Scan on movies  (cost=0.00..1707.71 rows=1 width=27)
  Filter: (title = 'Titanic'::text)
  Rows Removed by Filter: 86533
Planning Time: 0.077 ms
Execution Time: 7.331 ms

CREATE INDEX idx_movies_title ON movies (title);

EXPLAIN ANALYZE
SELECT * FROM movies WHERE title = 'Titanic';

                                QUERY PLAN
-----------------------------------------------------------------------------
Index Scan using idx_movies_title on movies (cost=0.42..8.44 rows=1 width=27)
  Index Cond: (title = 'Titanic'::text)
Planning Time: 0.325 ms
Execution Time: 0.089 ms

Простой запрос на поиск

Варианты сканирования таблицы

Seq Scan

Последовательное сканирование таблицы.

Index Scan

Сканирование по индексу.

Bitmap Index Scan

По индексу строится битовая карта.

Index Only Scan

Сканирование покрывающего индекса.

Для выбора стратегии планировщик использует ранее собранную статистику.

JOIN-стратегии

MERGE JOIN

Соединение двух отсортированных последовательностей.
Работает быстро и за один проход обоих списков.

HASH JOIN

Меньшее отношение помещается в хэш-таблицу. Затем для каждой строки из большей таблицы выполняется поиск значений, соответствующих условию соединения.
Соединение только по условию эквивалентности.

NESTED LOOP

Соединение вложенными циклами.

Не все индексы одинаково полезны

• Индексы позволяют существенно сократить время выполнения запроса.
• Индексы требуют ресурсов для своей работы (память, запись).
• Для экономии места и записи индекс иногда можно сделать частичным.
• В некоторых СУБД существует понятие кластерного индекса.

Еще пара слов про SQL

SQL - декларативный язык.

Для написания эффективных запросов надо мыслить категориями множеств.

Транзакции

ACID

ACID описывает требования к транзакционной системе, обеспечивающие наиболее надёжную и предсказуемую её работу. Требования ACID были в основном сформулированы в конце 70-х годов Джимом Греем.

• Atomicity — Атомарность
• Consistency — Согласованность
• Isolation — Изолированность
• Durability — Долговечность

Журнал транзакций

Общий алгоритм:

• измения пишутся в журнал транзакций (состояние до и после) и изменяются страницы БД в памяти;
• в журнал транзакций сбрасывается маркер успешного завершения транзакции;
• журнал транзакций сбрасывается на диск;
• данные страниц БД пишутся на диск;
• данные страниц БД сбрасываются на диск.

Приблизительные значения IOPS

Журнал транзакций. Бонус

На базе журнала транзакций так же реализуется ряд дополнительных возможностей:

• Point in time recovery;
• Репликация.

Уровни изолированности транзакций

• Read uncommitted - чтение незафиксированных данных
• Read committed (по-умолчанию) - чтение фиксированных данных
• Repeatable read - повторяемость чтения
• Serializable - упорядочиваемость

Потерянное обновление (Lost Update)

Потерянное обновление происходит в случае перезатирания изменений другой транзакцией до заврешнения транзакции, сделавшей изменения.

UPDATE tbl1 SET f2=f2+20 WHERE f1=1;

UPDATE tbl1 SET f2=f2+25 WHERE f1=1;

«Грязное» чтение (Dirty Read)

Чтение данных, добавленных или изменённых еще не завершенной транзакцией.

SELECT f2 FROM tbl1 WHERE f1=1;
f2
---------
100
(1 row)

UPDATE tbl1 SET f2=200 WHERE f1=1;

SELECT f2 FROM tbl1 WHERE f1=1;
f2
---------
200
(1 row)

ROLLBACK;

Неповторяющееся чтение (Non-Repeatable Read)

При повторном чтении в рамках одной транзакции ранее прочитанные данные оказываются изменёнными.

SELECT f2 FROM tbl1 WHERE f1=1;

UPDATE tbl1 SET f2=f2+1 WHERE f1=1;

COMMIT;

SELECT f2 FROM tbl1 WHERE f1=1;

Чтение "фантомов" (Phantom Reads)

Ситуация, когда при повторном чтении в рамках одной транзакции одна и та же выборка дает разные множества строк.

От неповторяющегося чтения оно отличается тем, что результат повторного обращения к данным изменился не из-за изменения/удаления самих этих данных, а из-за появления новых (фантомных) данных.

SELECT SUM(f2) FROM tbl1;

INSERT INTO tbl1 (f1,f2) VALUES (15,20);

COMMIT;

SELECT SUM(f2) FROM tbl1;

Аномалии сериализации

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

SELECT SUM(value) FROM mytab
WHERE class = 1;
---------
30
(1 row)

SELECT SUM(value) FROM mytab
WHERE class = 2;
---------
300
(1 row)

INSERT INTO mytab (value, class)
VALUES (30, 2)

INSERT INTO mytab (value, class)
VALUES (300, 1)

COMMIT;

COMMIT;

Уровни изолированности транзакций

READ COMMITED

Вариант A

SELECT id, money FROM account WHERE name = 'Romeo';
SELECT id, money FROM account WHERE name = 'Giulietta';
UPDATE account SET money = 500 WHERE id = 13 AND money = 600;
UPDATE account SET money = 200 WHERE id = 42 AND money = 100;
COMMIT;

Вариант B

SELECT id, money FROM account WHERE name = 'Romeo';
COMMIT;
---
SELECT id, money FROM account WHERE name = 'Giulietta';
COMMIT;
---
UPDATE account SET money = 500 WHERE id = 13 AND money = 600;
UPDATE account SET money = 200 WHERE id = 42 AND money = 100;
COMMIT;

Изолированность. Блокировки

Для обеспечения изоляции на данные делают блокировки.

Блокировки могут быть разных уровней:

• Базы
• Таблицы
• Кортежа
• Диапазона индексов

Проблема такого подхода в том, что пишущие транзакции могут заблокировать читающие транзакции.

Изолированность. MVCC

MVCC

MultiVersion Concurrency Control

• Разные пользователи могут одновременно работать с одними и теми же данными;
• Каждый пользователь видит свой изолированный срез данных;
• Изменения, вносимые пользователем, никому не видны до завершения транзации.

UPDATE IN PLACE 1: TABLE

UPDATE IN PLACE 2: SCAN

UPDATE IN PLACE 3: UPDATE

UPDATE IN PLACE 4: UPDATED

UPDATE IN PLACE 5: INSERT

UPDATE IN PLACE 6: DELETE

UPDATE IN PLACE 7

UPDATE IN PLACE 8: REALITY

MVCC 1: TABLE

MVCC 2: UPDATE

MVCC 3: UPDATE IN PROGRESS

MVCC 4: UPDATE IN PROGRESS

MVCC 5: UPDATED

MVCC 6: INSERT

MVCC 7: INSERTED

MVCC 8: DELETE

MVCC 9: DELETED

Проблемы MVCC

• MVCC работает идеально, когда мы пишем номер окончания отранзакции, но мы его заранее не знаем;
• Надо как-то избавляться от "мертвых" кортежей.

Варианты реализации MVCC

Heap (PostgreSQL)

• Все кортежи лежат в общей "куче".
• Мертвые кортежи удаляются в фоне отдельным сборщиком мусора (AUTOVACUUM).
• Фискация и откат транзакции имеют одинаковую стоимость.

Rollback segment (MySQL, Oracle)

• В страницах таблицы лежат только актуальные данные.
• Старые версии хранятся в журнале отката.
• Не требуется сборщик мусора и более эффективное использование дискового пространства.
• Долгий откат транзакции.

Блокировки

test=# BEGIN TRANSACTION
test-# ISOLATION LEVEL REPEATABLE READ;
BEGIN
test=# SELECT balance
test-# FROM accounts WHERE name = 'Alice';
balance
---------
400
(1 row)

test=# UPDATE accounts
test-# SET balance = balance + 100
test-# WHERE name = 'Alice';
UPDATE 1



test=# COMMIT;
COMMIT
            

test=# BEGIN TRANSACTION
test-# ISOLATION LEVEL REPEATABLE READ;
BEGIN
test=# SELECT balance
test-# FROM accounts WHERE name = 'Alice';
balance
---------
400
(1 row)





test=# UPDATE accounts
test-# SET balance = balance + 100
test-# WHERE name = 'Alice';


ERROR:  could not serialize access
        due to concurrent update
            

Блокировки

test=# BEGIN TRANSACTION
test-# ISOLATION LEVEL REPEATABLE READ;
BEGIN
test=# SELECT balance
test-# FROM accounts WHERE name = 'Alice';
balance
---------
500
(1 row)

test=# UPDATE accounts
test-# SET balance = balance + 100
test-# WHERE name = 'Alice';
UPDATE 1



test=# ROLLBACK;
ROLLBACK
            

test=# BEGIN TRANSACTION
test-# ISOLATION LEVEL REPEATABLE READ;
BEGIN
test=# SELECT balance
test-# FROM accounts WHERE name = 'Alice';
balance
---------
500
(1 row)





test=# UPDATE accounts
test-# SET balance = balance + 100
test-# WHERE name = 'Alice';


UPDATE 1
test=# COMMIT;
COMMIT
            

Чем плохи «долгие» транзакции?

• Риск отклонения транзакции: менеджер транзакций может найти несоответствие и отклонить транзакцию.
• Для поддержки множества параллельных снапшотов надо много ресурсов.
• Риск блокировки о соседнюю транзакцию (lock_timeout).

Часть операций/примитивов не тразакционны

• SEQUENCE
• TRUNCATE TABLE
• CREATE INDEX CONCURRENTLY

Двухфазный коммит (Two-phase commit)

Трехфазный коммит (Three-phase commit)

Надёжность

Что может пойти не так?

• Операционная система теряет кэш при потере питания
• Диск теряет кэш при потере питания
• Диск может выйти из строя
• Сервер может выйти из строя
• ДЦ может стать недоступен

Идея: каким-то образом на реплике поддерживать данные в состоянии как на мастере, тогда в случае выхода из строя мастера, можно сделать реплику мастером и продолжить работу.

Варианты взаимодействия

Мастер-слейв

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

Возможен так же вариант, когда данные на подчинённом сервере повторяются с задержкой.

Мастер-мастер

Оба сервера равнозначны и могут обрабатываь запросы как на чтение, так и на изменение данных.

Варианты реализации

Физическая

Передаётся информация о физическом изменении страниц базы данных.

Логическая

Передаётся информация об измененни записей базы данных.

Передача запросов

Передаётся информация о выполненных запросах.

Гарантии репликации

Синхронная

Мастер-сервер не подтверждает транзакцию до того, как реплика не подтвердит получение данных.

Асинхронная

Мастер-сервер не ждёт подтвержения получения данных от реплики.

Majority

Мастер-сервер ждёт подтвержения получения данных от N-реплик.

Семисинхронная (MySQL)

Мастер-сервер не подтверждает транзакцию до того, как "живые" реплики не подтвердят получение данных.

Репликация ⥋ вид кластера

Есть несколько вариантов организации кластера:

Общая память

Кластер представляется как одна система (Single-System Image, SSI), то есть эквивалент операционной системы для кластера в целом.

В результате нет необходимости в модификации существующих приложений — все это осуществляется автоматически, прозрачно для приложений пообно SMP.

Общие диски

Узлы кластера используют единую файловую систему.

Операционная система берет на себя координацию работы с файловой системой и ряд сервисных функций.

Приложение должно явно поддерживать работу в кластере.

Ничего общего

Функции кластера целиком реализуются внутри приложения.

Физическая репликация

Общий принцип:

• Главный сервер записывает изменения данных в журнал транзакций;
• Подчиненный сервер копирует события журнала транзакций;
• Подчиненный сервер воспроизводит изменения из журнала транзакций.

Плюсы:

• Простота и надёжность;
• Подчиненный сервер в точности соответвует мастер-серверу;
• Практически отсутствуют накладные расходы на запись и CPU.

Физическая репликация

Минусы:

• Если данные на мастере были испорченны из-за сбоев RAM, то на подчинённом сервере так же будут испорченные данные;
• На реплике не может быть локальных изменений схемы данных;
• Обновление индексов и VACUUM так же попадают в журнал транзакций, это порождает избыточное сетевое общение;
• Реплика может временно отставать, если на подчинённом сервере выполняется запрос на длительное чтение данных;
• На подчинённом сервере должна быть та же версия PostgreSQL, что и на мастере;
• Не возможна мастер-мастер репликация;
• VACUUM на мастере может удалить еще используемые данные на подчинённом.

Логическая репликация

Плюсы:

• Более компактный обмен данными;
• Если данные на мастере были испорченны из-за сбоев RAM, то репликация остановится;
• На мастере и подчинённом сервере могут быть разные версии СУБД;
• На мастере и подчинённом сервере можно использовать разную схему данных;
• Потенциально возможна мастер-мастер репликация.

Логическая репликация

Минусы:

• Более высокая нагрузка на подчинённый сервер;
• Надо крайне аккуратно работать со схемой данных;
• Нет хорошего решения проблемы репликации DDL-запросов.

Синхронная vs асинхронная репликация?

CAP-теорема

В распределенной системе возможно выбрать только 2 из 3-х свойств:

• Consistency — согласованность. Каждое чтение даст вам самую последнюю запись.
• Availability — доступность. Каждый узел (не упавший) всегда успешно выполняет запросы (на чтение и запись).
• Partition tolerance — устойчивость к распределению. Даже если между узлами нет связи, они продолжают работать независимо друг от друга.

Синхронная vs асинхронная репликация?

CAP-теорема

На самом деле, если у нас больше одного сервера обрабатывающего запросы, то мы уже выбрали P.

Поэтому выбирать можем только между A и C.

• Синхронная репликация - согласованность (CP)
• Асинхронная репликация - доступность (AP)

Что происходит после поломки мастера?

• Ручное переключение мастера
• Автоматическое переключение (failover)

Автоматическое переключение

Необходимо выбрать новый мастер и реплики могут сделать это самостоятельно (RAFT). Для достижения консенсуса требуется `N/2+1` доступных реплик.

Split-brain

• Старый мастер потерял сетевую связанность с остальным кластером
• Был выбран новый мастер
• Часть пользовательских запросов продолжил обрабатывать старый мастер, часть новый
• Имеем два набора возможно противоречивых данных

Fencing

Защитный механизм защищающий от split-brain. Мастер потеряв связанность с остальным кластером, должен через заданное время перестать считать себя мастером.

С другой стороны, возможно он действительно остался один и перестав обрабатывать запросы произошел полный отказ СУБД.

И кто же нас спасёт тогда?

• Внешний координатор
• Живой человек
• Система находящаяся в стороне от кластера и управляющая им

Шардирование

Шардирование

Если данных больше чем может поместиться на одном сервере или недостаточно производительности, то нужно шардировать базу.

Шардирование (шардинг) баз данных

Метод распределения данных между несколькими отдельными частями — шардами. Каждый шард располагается на отдельном сервере или группе серверов, что позволяет выполнять запросы параллельно.

Ключ шардирования

Это столбец (или несколько столбцов) в данных, по которому система определяет, в какой шард попадёт конкретная строка.

Цели шардирования

• Горизонтальное масштабирование при росте данных и числа запросов.
• Сокращение времени отклика за счёт параллельной обработки.
• Повышение доступности — отказ одного шарда не выводит из строя всю систему.

Проблемы шардирования

• Если запрос затрагивает несколько шардов, то MapReduce: выполнить один запрос на всех шардах, после чего аггрегировать ответы.
• Изменение данных на нескольких шардах, это двухфазный коммит

Решардинг

Если данных становится так много, что они не помещаются на имеющиеся шарды, то добавляют еще - это называется решардингом.

Для упрощения этого процесса есть приемы, например, виртуальное шардирование.

Решардинг

• Определяется N бакетов, где N может быть десятки тысяч
• Бакеты распределяются между шардами поровну
• При добавлении нового шарда бакеты перераспределяются
• Требуется отдельный компонент - роутер, который хранит информацию о соответствии бакета физическому шарду

Итоги

Так какую базу данных выбрать?

Универсального ответа нет, надо смотреть на< характер данных и профиль нагрузкиЖ

• Для OLTP-нагрузки, если время доступа не критично и не требуется шардирование я выбираю PostgreSQL
• Если время доступа критично, но сами данные не критичны, то in-memory решение, например, Redis
• Если данных очень много и основной профиль нагрузки на чтение - чтение по ключу - MongoDB

Ссылки

• https://github.com/sirupsen/napkin-math
• https://github.com/mtrempoltsev/yandex_system_design/blob/main/db.md
• https://tikv.org/deep-dive/key-value-engine/b-tree-vs-lsm/
• https://habr.com/ru/companies/vk/articles/740108/
• https://habr.com/ru/companies/vk/articles/436916/
• https://habr.com/ru/articles/181584/

Спасибо за внимание!