Три формы хранения данных
Большинство баз данных относятся к трём семействам. Вам не нужно запоминать продукты — вам нужно распознавать, какая форма подходит вашей задаче.
| Тип | Примеры | Лучше всего для | Компромиссы |
|---|---|---|---|
| Реляционные () | PostgreSQL, MySQL, SQLite | Структурированные данные со связями; всё, что критично к деньгам или точности | Нужно спроектировать схему заранее; масштабировать запись до очень больших объёмов сложнее |
| Документные / | MongoDB, Firestore, DynamoDB | Гибкие или вложенные данные, быстрые итерации, разнообразные формы записей | Легко создать несогласованные данные; связи и отчётность становятся неудобными |
| Ключ-значение | Redis, Memcached, Cloudflare KV | Кеширование, сессии, счётчики, быстрый поиск по известному ключу | Нет запросов по содержимому; обычно не является источником истины |
Три формы хранят данные по-настоящему по-разному. Представьте их рядом:
РЕЛЯЦИОННАЯ (SQL) ДОКУМЕНТНАЯ (NoSQL) КЛЮЧ-ЗНАЧЕНИЕ
строки + столбцы самодостаточные блобы один ключ → одно знач.
┌────┬───────┬──────┐ ┌──────────────────┐ ┌─────────┬─────────┐
│ id │ email │ name │ │ { │ │ key │ value │
├────┼───────┼──────┤ │ id, email, │ ├─────────┼─────────┤
│ 1 │ a@... │ Ana │ │ name, │ │ session │ "x9f2" │
│ 2 │ b@... │ Bob │ │ posts: [ ... ] │ │ count │ "42" │
└────┴───────┴──────┘ │ } │ └─────────┴─────────┘
таблицы ссылаются └──────────────────┘ внутри не искать —
друг на друга всё вложено только поиск по ключу
Представьте реляционную базу данных как набор электронных таблиц, которые умеют ссылаться друг на друга. Язык, на котором вы с ней разговариваете, — SQL (Structured Query Language — язык структурированных запросов). Хороший выбор по умолчанию для 90% проектов: начните с реляционной базы данных (Postgres). Она зрелая, предсказуемая, обеспечивает структуру и справляется со связями, которые настоящие приложения неизбежно наращивают. Обращайтесь к документным хранилищам, когда ваши данные действительно бесформенны, а к хранилищам ключ-значение — как к вспомогательному слою (кеширование), а не как к основному хранилищу.
Ловушка, которой стоит избегать, — выбирать по настроению. «NoSQL (базы данных, которые не используют таблицы SQL — они хранят гибкие записи свободной формы) лучше масштабируется» верно лишь для узкого набора задач, до которых большинство приложений никогда не доходят, и даже тогда ценой становится отказ от гарантий согласованности, которые делают данные надёжными. Выбирайте форму, которая соответствует вашим данным, а не ту, что звучит наиболее впечатляюще в видео по системному дизайну. Когда сомневаетесь, реляционная — безопасная ставка: кеш или документное хранилище всегда можно добавить позже, а вот распутывать запутанную модель данных NoSQL мучительно.