Какви бази данни има

По пътя към описа КВЕРИ забавя крачка пред тъмна секция на хранилището. Зад стъклото е регистърът на архивите от стара Земя, които не преживяха Големия срив: кеш-възлите угаснаха първи, документните хранилища стигнаха като накъсани фрагменти, аналитичните клъстери мълчат на цели сектори. А релационната снимка на «Kotomarket» оцеля изцяло — с всичките си връзки.

Не само релационни

За «Kotomarket» особено удобни са ни релационните БД: купувачите, поръчките и стоките естествено лягат в таблици с връзки. Именно на тях е посветен курсът. Но в индустрията — както през 2024-та, така и сега — се срещат и други подходи:

• ключ-стойност (Redis) — много бърз формат «ключ → стойност», когато трябва моментално да извадиш прост запис;
• документно ориентирани (MongoDB) — съхраняват гъвкави JSON документи, чиято структура може да се различава от запис до запис;
• колонни (ClickHouse) — силни в аналитиката, когато трябва бързо да се смятат показатели по огромни обеми данни.

Повечето популярни СУБД за продуктова разработка остават релационни: PostgreSQL, MySQL, Oracle, MS SQL. Усвоиш ли SQL тук — ще можеш уверено да четеш данни в съвсем различни компании.

КВЕРИ: На всеки архив — своята работа: на едни скорост, на други гъвкавост, на трети аналитика. На нас с теб ни провървя: падна ни се онзи, в който всичко е свързано с всичко.

Not only relational

For Kotomarket, relational databases suit us especially well: buyers, orders, and products fall naturally into tables with links between them. That’s what this course is about. But across the industry — in 2024 just as today — you’ll meet other approaches too:

• key-value (Redis) — a blazingly fast "key → value" format for when you need to grab a simple record instantly;
• document-oriented (MongoDB) — stores flexible JSON documents whose structure can differ from record to record;
• columnar (ClickHouse) — strong at analytics, when you need to crunch metrics over enormous volumes of data fast.

Most of the popular DBMSs for product development stay relational: PostgreSQL, MySQL, Oracle, MS SQL. Master SQL here and you’ll be able to read data confidently at very different companies.

QUERY: Each archive has its own job: one prizes speed, another flexibility, a third analytics. You and I got lucky: we inherited the one where everything is connected to everything.

Регистър на семействата: подреждане по рафтове

Регистърът зад стъклото е повод да разгледаме семействата бази данни сериозно: «какви БД има и кога коя да вземеш» е един от най-честите въпроси на интервюта. Ще минем през пет семейства подред и за всяко — по една схема: начин на съхранение, силни и слаби страни, продукти и кога да го избереш.

Релационни БД: строга схема и връзки

Начин на съхранение: редове в таблици с предварително обявена схема — всяка колона има тип, между таблиците действат връзки по ключове и СУБД сама пази целостта: поръчка от несъществуващ купувач няма как да се запише. Промените се изпълняват като транзакции с гаранции ACID — «поръчка + отписване на наличност» или се записват заедно, или изобщо не се записват.

• Силни страни: изразителен SQL (филтри, съединения на таблици, агрегати), цялост на ниво база, транзакции.
• Слаби: схемата трябва да се обмисли предварително и да се мигрира при промени; хоризонталното мащабиране на много сървъри е по-трудно, отколкото при NoSQL семействата.
• Продукти: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Кога да го избереш: потребители, поръчки, пари, склад — навсякъде, където данните са свързани и грешка при запис е недопустима. За нов продукт това е изборът по подразбиране.

Бази ключ-стойност: речник на максимална скорост

Начин на съхранение: един гигантски речник «ключ → стойност», най-често в оперативната памет. Нито таблици, нито връзки: сложи по ключ — извади по ключ за части от милисекундата.

-- Это не SQL, это команды Redis
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Силни страни: скорост, простота, лесно мащабиране.
• Слаби: заявки само по точен ключ — въпросът «намери всички сесии на купувачи от Москва» не може да се зададе на този формат; вътрешността на стойността е непрозрачна за базата.
• Продукти: Redis, Memcached, Amazon DynamoDB.
• Кога да го избереш: кеш, сесии, броячи, опашки, класации — горещи данни до основната база, а не вместо нея.

Документни БД: гъвкав JSON

Начин на съхранение: записите са JSON документи, групирани в колекции. Схемата не се обявява предварително: смарт часовникът има поле «време на работа на батерията», суитшъртът — «размерна таблица», и двата документа спокойно лежат в една колекция. Вложените структури се пазят направо вътре в документа, без отделни таблици.

• Силни страни: гъвкава структура, документът се чете изцяло с едно обръщение, удобно за каталози с разнородни атрибути и за бързи прототипи.
• Слаби: връзките между документите са грижа на приложението, пълноценен JOIN почти няма; без дисциплина колекцията се превръща в зоопарк от несъвместими формати.
• Продукти: MongoDB, Couchbase, Firestore.
• Кога да го избереш: съдържание, каталози със силно различаващи се полета, профили и настройки.

Границата между семействата, между другото, е размита: PostgreSQL умее да съхранява документи в колона от тип jsonb и да строи индекси по тях — често това покрива «документната» нужда без втора база:

-- Пример вне нашего снимка: attrs — столбец типа jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Колонни БД: аналитика по милиарди редове

Начин на съхранение: стойностите лежат не по редове, а по колони: всички цени — една до друга, всички дати — една до друга. Заявката «среден чек по месеци» чете от диска само две колони вместо цялата таблица, а еднотипните стойности се компресират чудесно. Оттам и скоростта при агрегати.

-- Любимый жанр колоночной базы (диалект ClickHouse: toYYYYMM — его функция)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Силни страни: агрегати и сканиране на милиарди редове, силна компресия.
• Слаби: точкови обновявания и изтривания са скъпи; да прочетеш един ред изцяло е по-бавно, отколкото в редова база; транзакционно натоварване — за такова те не са предназначени.
• Продукти: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Кога да го избереш: аналитика, отчети, събития, логове, метрики — обикновено до «бойната» релационна база.

Тук и два термина, които обичат на интервюта: OLTP (online transaction processing — много кратки операции по запис и четене, светът на PostgreSQL) и OLAP (online analytical processing — тежки аналитични четения по цялата история, светът на ClickHouse). Продуктът пише в OLTP база, аналитиката чете OLAP копие.

И последно семейство — графови БД

Когато връзките са по-важни от самите записи — «приятели на приятели», маршрути за доставка, вериги от препоръки — взимат графови БД (Neo4j, Memgraph). Данните в тях са възли (това са записите) и ребра (това са връзките между записите); обхождането на връзки с произволна дълбочина е родна операция. В релационна база такова обхождане е стълба от съединения на таблици, която с дълбочината натежава.

Мини-гайд: как да избереш база за проекта

1. Започни от въпросите, а не от данните. Какви заявки ще задава продуктът: точкови «по ключ», свързани «кой какво е купил», аналитични «колко за месец»?
2. По подразбиране — релационна. Свързани данни плюс цена на грешката (поръчки, плащания, наличности) — това е PostgreSQL. Най-безопасният старт за почти всеки продукт.
3. Специализираните бази — за конкретна задача, а не «за всеки случай». Притискат горещите четения — добави кеш на Redis. Пораснала е аналитиката — реплицирай събитията в ClickHouse. Дива вариативност на полетата — първо jsonb в PostgreSQL, и едва когато той не стигне — документна база.
4. Смятай цената на втората база. Всяка нова СУБД е синхронизация на данни, бекъпи, мониторинг и още една технология, която екипът да поддържа.