Три формы хранения данных
Большинство баз данных относятся к трём семействам. Вам не нужно запоминать продукты — вам нужно распознавать, какая форма подходит вашей задаче.
| Тип | Примеры | Лучше всего для | Компромиссы |
|---|---|---|---|
| Реляционные (SQL) | PostgreSQL, MySQL, SQLite | Структурированные данные со связями; всё, что критично к деньгам или точности | Нужно спроектировать схему заранее; масштабировать запись до очень больших объёмов сложнее |
| Документные / NoSQL | MongoDB, Firestore, DynamoDB | Гибкие или вложенные данные, быстрые итерации, разнообразные формы записей | Легко создать несогласованные данные; связи и отчётность становятся неудобными |
| Ключ-значение | Redis, Memcached, Cloudflare KV | Кеширование, сессии, счётчики, быстрый поиск по известному ключу | Нет запросов по содержимому; обычно не является источником истины |
Хороший выбор по умолчанию для 90% проектов: начните с реляционной базы данных (Postgres). Она зрелая, предсказуемая, обеспечивает структуру и справляется со связями, которые настоящие приложения неизбежно наращивают. Обращайтесь к документным хранилищам, когда ваши данные действительно бесформенны, а к хранилищам ключ-значение — как к вспомогательному слою (кеширование), а не как к основному хранилищу.
Ловушка, которой стоит избегать, — выбирать по настроению. «NoSQL лучше масштабируется» верно лишь для узкого набора задач, до которых большинство приложений никогда не доходят, и даже тогда ценой становится отказ от гарантий согласованности, которые делают данные надёжными. Выбирайте форму, которая соответствует вашим данным, а не ту, что звучит наиболее впечатляюще в видео по системному дизайну. Когда сомневаетесь, реляционная — безопасная ставка: кеш или документное хранилище всегда можно добавить позже, а вот распутывать запутанную модель данных NoSQL мучительно.