Перейти к содержанию

Data Architecture

1. RDBMS (OLTP)

  • Суть — реляционные базы данных для онлайновой транзакционной обработки: таблицы, связи, ACID.
  • Когда использовать — жёсткие требования к консистентности, сложные JOIN’ы, классические CRUD-операции.
  • Плюсы
    • Гарантии ACID
    • Мощный SQL для запросов и аналитики
    • Зрелая экосистема (мониторинг, бэкапы)
  • Минусы
    • Ограничения на масштабирование (горизонтальное сложнее)
    • Сложнее шардировать
  • Примеры технологий PostgreSQL, MySQL, Oracle, Microsoft SQL Server

2. NoSQL

2.1 Key–Value

  • Суть — хранилище пар «ключ ↔ значение», очень быстрое чтение/запись.
  • Когда использовать — сессии, кеши, простой state.
  • Плюсы
    • Экстремальная скорость
    • Лёгкая горизонтальная масштабируемость
  • Минусы
    • Нет запросов «по значению»
    • Нет связей между записями
  • Примеры Redis, Amazon DynamoDB (KV режим), Memcached

2.2 Document

  • Суть — JSON- или BSON-документы, схему можно эволюционировать.
  • Когда использовать — гибкая модель данных, вложенные структуры, быстрые итерации.
  • Плюсы
    • Схема «на лету»
    • Поддержка индексов по полям
  • Минусы
    • Ограниченные транзакции
    • Рост документов → влияние на производительность
  • Примеры MongoDB, Couchbase, Amazon DocumentDB

2.3 Wide-column

  • Суть — таблицы с нефиксированным набором столбцов, хранятся построчно.
  • Когда использовать — телеметрия, time-series at scale, аналитика.
  • Плюсы
    • Хорошо шардируется по ключу строки
    • Хранение «холодных» колонок отдельно
  • Минусы
    • Сложнее модель данных
    • Нет сложных JOIN’ов
  • Примеры Apache Cassandra, HBase, ScyllaDB

3. TimeSeries

  • Суть — оптимизированное хранение метрик и событий с меткой времени.
  • Когда использовать — мониторинг, IoT-датчики, финансовые котировки.
  • Плюсы
    • Компактное хранение временных рядов
    • Функции агрегации по интервалам
  • Минусы
    • Не подходит для произвольных данных
    • Иногда дорогостоящее хранение долгосрочных рядов
  • Примеры InfluxDB, TimescaleDB, Prometheus, OpenTSDB

4. Graph DB

  • Суть — узлы и рёбра, запросы по графовым паттернам.
  • Когда использовать — социальные сети, рекомендательные системы, fraud detection.
  • Плюсы
    • Быстрый traversal по связям
    • Язык запросов для графов (Cypher, Gremlin)
  • Минусы
    • Специализированная модель, менее эффективна для OLTP
    • Требует переобучения запросных паттернов
  • Примеры Neo4j, Amazon Neptune, JanusGraph, TigerGraph

5. Polyglot Persistence

  • Суть — использование разных хранилищ под разные задачи в одной системе.
  • Когда использовать — сложные домены, требующие разных свойств БД.
  • Плюсы
    • Можно выбрать оптимальное хранилище для каждой подсистемы
    • Гибкость в эволюции проекта
  • Минусы
    • Сложнее разработка и поддержка
    • Повышенная операционная нагрузка
  • Примеры сочетаний RDBMS + Redis + Elasticsearch + Kafka (Event Store)

6. Sharding

  • Суть — горизонтальное разбиение данных на сегменты (шарды) по ключу.
  • Когда использовать — очень большие объёмы данных, нагрузка выше возможностей одной ноды.
  • Плюсы
    • Линейное масштабирование
    • Изоляция «горячих» ключей
  • Минусы
    • Сложность перекомпоновки шардов
    • Перенос данных тяжёлый процесс
  • Примеры MongoDB Sharding, PostgreSQL Citus, Vitess

7. Replication

  • Суть — копирование данных между мастером и репликами для отказоустойчивости и масштабирования чтения.
  • Когда использовать — обеспечить RPO/RTO, улучшить read-throughput.
  • Плюсы
    • Высокая доступность
    • Распределение нагрузки на чтение
  • Минусы
    • Задержка репликации → eventual consistency
    • Управление «лидером» + failover
  • Примеры PostgreSQL Streaming Replication, MySQL Group Replication, MongoDB Replica Set

8. Caching

  • Суть — слой быстрого доступа (in-memory или CDN) для сокращения задержек и нагрузки на основную БД.
  • Когда использовать — «горячие» данные, результаты тяжёлых запросов.
  • Плюсы
    • Серьёзное снижение latency и нагрузки
    • Поддержка TTL, eviction-политик
  • Минусы
    • Сложности в консистентности (cache invalidation)
    • Дополнительная инфраструктура
  • Типичные инструменты Redis, Memcached, Varnish, Cloudflare CDN

9. Event Store

  • Суть — хранение всех изменений состояния как последовательности событий.
  • Когда использовать — CQRS, Event Sourcing, аудит, time-travel.
  • Плюсы
    • Полная история изменений
    • Возможность воспроизведения состояния
  • Минусы
    • Сложнее запросить «текущее» состояние без построения проекций
    • Обновление схемы событий требует миграций
  • Примеры EventStoreDB, Apache Kafka (как log), Axon Server

Как применять 1. Определите требования к консистентности, латентности, объёму и аналитике. 2. Выберите основной тип БД (RDBMS vs NoSQL) по критериям ACID vs гибкая схема. 3. Добавьте шардирование/репликацию при необходимости масштабирования и отказоустойчивости. 4. Внедрите кеш для ускорения «горячих» запросов. 5. Рассмотрите event store для сложных доменных логик и аудита. 6. Используйте polyglot — комбинируйте несколько хранилищ под разные задачи.