Привет, хабр!
Меня зовут Кирилл, и на протяжении последних двух лет я мечтал научиться проходить System Design интервью. Но только недавно взялся за дело всерьёз.
Изучив различные хранилища данных, я наконец-то смог систематизировать свои знания. И хочу поделиться этой структурой с вами, чтобы рассказать, какие бывают хранилища данных и в каких случаях их лучше всего использовать.
SQL базы данных
Когда каждый из нас начинает изучать программирование, он учит циклы, операторы ветвления, и когда дело доходит до баз данных, мы изучаем SQL и реляционные СУБД (RDBMS). PostgreSQL, MS SQL Server, MySQL — это всё они, наши старые добрые реляционные базы данных.
SQL-хранилища относятся к классу систем OLTP (Online Transactional Processing — обработка транзакций в реальном времени). Такие базы данных идеально подходят для операций, требующих строгой консистентности и транзакционности: банковские системы, платформы для бронирования билетов, интернет-магазины (учёт заказов, профили пользователей) и так далее. Они гарантируют нам ACID (Atomicity — атомарность транзакций; Consistency — консистентность транзакций, что транзакция применяется полность; Isolation — изоляцию транзакций; Durability — долговечность, что применённая транзакция не отменится транзакций).
Если у вас небольшое приложение с невысокой нагрузкой и небольшим количеством данных, то просто используйте SQL-хранилище и не парьтесь. Это надёжное, проверенное временем решение.
Но как только возникает большое количество данных, то ваша классическая SQL-база может не выдержать. Классические реляционные базы данных в роде PostgreSQL плохо масштабируется горизонтально, потому что изначально не проектировались для этого. Именно в такие моменты и и приходят на помощь другие классы хранилищ, например NoSQL.
NoSQL
Для определённых задач запросы в SQL-хранилища могут требовать слишком много времени или ресурсов. Например, поиск всех друзей друзей в социальной сети превращается в дорогостоящий рекурсивный JOIN. Для таких специфичных кейсов и были придуманы NoSQL-решения.
NoSQL (Not Only SQL) — это широкий класс систем управления базами данных, которые не являются реляционными. Они, как правило, оптимизированы под конкретные типы нагрузки или для решения специфичных задач: могут бесконечно масштабироваться горизонтально или хорошо выполнять определённые типы запросов (быстрый поиск по предложениям, быстрый поиск в связей), или быть специально спроектированы для хранения данных определённого типа (например, документов).
Давайте разберёмся в их многообразии.
Key-Value хранилища и кэши
Key-Value хранилища — тип нереляционной базы данных, которая хранит данные в виде пар «ключ — значение». Некоторые хранилища типа ключ-значние часто используются в качестве кэша.
Кэш — это высокоскоростное хранилище, которое держит данные в оперативной памяти (RAM) для максимально быстрого доступа к ним. Его основная задача — быстро возвращать значение по ключу, что активно применяется, когда нужно оптимизировать доступ к более медленной, основной базе данных.
Например, чтобы ускорить получение информации о популярном посте на Хабре, можно сохранить уже готовую HTML-страницу или JSON с данными этого поста в кэше по ключу (ID поста). При следующем запросе мы мгновенно достанем его из кэша по ключу, не нагружая основную базу данных. Самые распространённые кэши — это Redis и Memcached.
Redis хранит данные в оперативной памяти, но при этом обеспечивает персистентность (сохранность данных после перезагрузки) за счёт двух механизмов: снэпшотов (RDB), когда он периодически сохраняет всё состояние на диск, или AOF (Append-Only File), когда он логгирует на диск каждую операцию записи. Эти механизмы работают независимо и могут использоваться по отдельности или вместе для обеспечения разной степени надёжности и удобства восстановления данных.
Примеры использования кэша:
Кэширование результатов часто выполняемых запросов к базе данных для ускорения доступа к данным.
Хранение сессий пользователей в веб-приложениях для уменьшения нагрузки на основную базу данных.
Wide-Columnlar
А что делать, если нам нужно очень-очень много писать? Например, сообщения в онлайн-мессенджере или данные с IoT-устройств? Тут обычная реляционная база данных не справится с нагрузкой на запись.
Здесь на помощь подходит вид хранилища под названием "широкие колонки" (Wide-Column). Самым популярным представителем является Cassandra. Форк Cassandra также активно используется для реализации ленты новостей и сообщений в социальной сети Одноклассники.
Cassandra строится на основе LSM-дерева (Log-structured merge-tree). Если просто, все операции записи сначала попадают в быструю структуру в памяти (Memtable), а з��тем асинхронно сбрасываются на диск в виде неизменяемых файлов (SSTables). Это делает запись невероятно быстрой, так как нет необходимости искать нужную ячейку на диске и перезаписывать её. Чтение может быть медленнее, но для write-heavy (когда запись происходит чаще, чем чтение) нагрузок это идеальное решение.
Ключевой особенностью Cassandra является её линейная масштабируемость: чтобы увеличить мощность, нужно просто добавить новые узлы в кластер. Данные автоматически шардируются (распределяются) между узлами кластера на основе хеша от Partition Key.
Примеры использования Wide-Columnlar (широких колонок):
Хранение постов пользователей в социальных сетях, и их распространение для миллионов пользователей с преимущественно записью.
Обработка данных с IoT-устройств, генерирующих большие объёмы данных в реальном времени.
Columlar
Колоночные базы данных — это хранилища, которые физически хранят данные по колонкам, а не по строкам. Самый известный представитель — ClickHouse от Яндекса.
В отличие от традиционных БД, где все значения одной строки (например, ID, Имя, Фамилия, Возраст) лежат на диске рядом, в колоночных базах рядом лежат все значения одной колонки (все ID, затем все Имена, все Фамилии). Это даёт два преимущества:
Фантастическое сжатие данных, так как данные одного типа (например, числа) сжимаются гораздо лучше, чем разнородные.
Высокая скорость аналитических запросов. Например, если вам нужно посчитать средний возраст пользователей (
SELECT AVG(age) FROM users), база прочитает с диска только одну колонкуage, а не всю таблицу.
Колоночные базы данных — это идеальный представитель OLAP-систем — Online Analytical Processing — аналитическая обработка данных в реальном времени, где скорость анализа огромных объемов данных критична.
Например, используя ключ сортировки ORDER BY в ClickHouse можно указать в каком физическом порядке данные будут лежать на диске. Это важно, потому что на основе этого ключа автоматически строится первичный индекс, который будет использоваться при поиске или фильтрации.
Примеры использования колоночных баз данных:
Аналитика продаж в ритейле, где требуется агрегирование данных по большим объёмам транзакций.
Логирование и анализ системных событий в крупных распределённых системах.
Документные базы данных
Документные базы данных — это вид NoSQL-хранилищ, которые хранят данные в виде документов, обычно в формате JSON или его бинарном аналоге BSON. Самый популярный представитель — это MongoDB.
Внутреннее устройство выглядит так: каждый документ — это самодостаточная структура со своими полями и значениями (обычно JSON-объект), которая может иметь вложенные документы и массивы. Это очень удобно для программистов, так как структура документа в базе часто напрямую соответствует объекту в коде. Данные хранятся в коллекциях (аналог таблиц в реляционных базах данных). Для быстрого поиска MongoDB позволяет создавать индексы по любым полям документа, даже по вложенным. Это избавляет от необходимости делать JOIN и позволяет быстро получать всю связанную информацию одним запросом.
Примеры использования документных БД:
Хранение профилей пользователей в социальных сетях со сложной и изменяемой структурой данных.
Управление конфигурациями устройств, где каждый документ может представлять собой конфигурацию конкретного устройства.
Графовые базы данных
Графовая база данных — это система, созданная для хранения данных в виде графа, состоящего из вершин (узлов) и рёбер (связей).
Тут же возникает вопрос: а зачем? В каком случае она может понадобиться? А я вам скажу: она нужна в одном простом случае — когда нужно быстро и эффективно работать со связями между сущностями.
Например, при проектировании социальной сети в графовой базе данных вы можете хранить информацию о друзьях или подписках на группы. Запрос вида «найти всех друзей моих друзей, которые живут в Москве» выполнится в графовой базе данных разы быстрее, чем в SQL. Самый известный представитель графовых БД — это Neo4j.
Под капотом графовые базы данных хранят узлы и рёбра как основные сущности. Вместо того чтобы вычислять связи через JOIN-операции, они хранят прямые указатели от одной вершины к другой (через списки смежности). Благодаря этому обход графа — это просто переход по указателям в памяти или на диске, что невероятно быстро. Примеры использования графовых БД:
Моделирование и анализ социальных графов для выявления сообществ и рекомендаций.
Обнаружение мошеннических схем в финансовых транзакциях путём анализа связей между участниками.
Поисковые движки
Инвертированный индекс — это структура данных, которая хранит отображение из контента (например, слов) в его расположение в документе или наборе документов. Соответственно, базы данных, которые строятся на этом принципе, — это поисковые движки.
Самый известный представитель — ElasticSearch. Без баз данных на основе инвертированных индексов просто невозможно построить ни один современный поиск по тексту, логам или каталогу товаров.
Внутренне такие хранилища строятся следующим образом: для каждого слова (терма) в документе создаётся запись в индексе, которая указывает на все документы, где это слово встречается. Когда вы делаете поисковый запрос, движок мгновенно находит все документы по нужным словам, а затем ранжирует их по релевантности. Примеры использования инвертированных индексов:
Реализация полнотекстового поиска по каталогу товаров в интернет-магазине.
Анализ логов серверов для выявления аномалий и ошибок.
Time Series Database
TSDB (Time Series Database) — это специализированное хранилище, заточенное под данные, где временная метка — главный ключ. Хотя они часто ассоциируются с метриками серверов, их применение гораздо шире: любые потоки событий или измерений, строго привязанных ко времени, от финансовых котировок до действий пользователей в приложении. Самый распространённый представитель TSDB — InfluxDB.
Внутреннее устройство TSDB оптимизировано для работы с временными рядами. Данные физически группируются и сжимаются по времени. Используются специальные алгоритмы сжатия, которые отлично работают на монотонно растущих временных метках и значениях. Это позволяет эффективно хранить огромные объёмы данных и очень быстро выполнять запросы по временным диапазонам.
Примеры использования БД временных рядов:
Хранение данных о финансовых тиках на бирже.
Хранение метрик мониторинга.
NewSQL
NewSQL — это класс современных распределённых реляционных баз данных, которые стремятся объединить лучшее из двух миров: горизонтальную масштабируемость NoSQL-систем с полными ACID-гарантиями традиционных SQL-баз. По сути, это попытка преодолеть главный недостаток классических реляционных СУБД: сложность масштабирования без потери транзакций и строгой консистентности.
Под капотом NewSQL-системы используют различные подходы к распределенной обработке. Но все они делят данные на сегменты (шарды), которые распределяются по кластеру и реплицируются на несколько узлов для обеспечения отказоустойчивости. Это ключевая особенность NewSQL баз данных. Такой вид хранилищ используется для высоконагруженных систем, которые требуют и строгой консистентности, и горизонтального масштабирования.
Самые известные представители NewSQL — это YDB (Yandex Database) и CockroachDB.
NewSQL является мощным инструментом для очень специфичных задач, когда нужны транзакции для больших данных и возможность горизонтального масштабирования. Но для большинства проектов проверенные PostgreSQL, MySQL остаются проще, дешевле и надежнее. Это не замена, а специализированное решение для тех, кт�� "перерос" классические БД.
Примеры использования NewSQL:
Высоконагруженные маркетплейсы (e-com платформы), требующие строгой консистентности и масштабируемости.
Финансовые системы, обрабатывающие большое количество транзакций в реальном времени.
Смежные технологии и системы хранения
Есть отдельные инструменты, которые не всегда являются базами данных в классическом понимании, но используются для хранения или обработки данных.
Системы обработки больших данных
Есть отдельные фреймворки, предназначенные для распределённой обработки огромных объёмов данных (петабайты данных). К таким системам относятся Hadoop (с его файловой системой HDFS), Spark и YTsaurus. Они не являются базами данных для вашего приложения, а скорее платформой для batch или stream-обработки данных в аналитических целях.
Примеры использования систем обработки больших данных:
Анализ данных о поведении пользователей в крупных онлайн-сервисах для улучшения пользовательского опыта.
Обработка спутниковых данных для мониторинга климатических изменений.
S3 (Object Storage)
Объектное хранилище (S3 — Simple Storage Service) — это сервис для хранения файлов (объектов) в виде неструктурированных данных. Ключевое отличие от файловой системы в том, что у него плоская структура. Вы обращаетесь к объекту по уникальному ключу. S3 обеспечивает высочайшую надёжность, масштабируемость и низкую стоимость хранения. Идеально подходит для бэкапов, медиаконтента (видео, фото), статических данных сайта.
Примеры использовани�� S3:
Хранение бэкапов данных для обеспечения их надёжности и доступности.
Хранение медиафайлов (видео, фото) для использования в контент-менеджменте.
CDN (Content Delivery Network)
CDN — это географически распределённая сеть серверов, которая кэширует контент (картинки, видео, статику) как можно ближе к конечным пользователям. Это не хранилище в прямом смысле, а слой доставки, который кардинально снижает задержку при загрузке контента для пользователей из разных уголков мира.
Примеры использования CDN:
Распределение статического контента (изображения, стили CSS, JavaScript-файлы) для ускорения загрузки веб-сайтов.
Доставка видеопотоков пользователям по всему миру с минимальной задержкой.
Некоторые кейсы
Также я написал небольшую подборку кейсов, которая позволит разобрать ещё больше примеров, какой тип хранилища лучше использовать и их преимущества.
Решаемая задача | Требуемое хранилище | Объяснение, почему выбрано хранилище |
Хранение профилей пользователей в социальной сети с сложной и изменяемой структурой данных | Документная БД (MongoDB) | Гибкость и возможность хранения сложных структур данных |
Запись данных с IoT-устройств, генерирующих большие объёмы данных в реальном времени | Wide-Columnlar (Cassandra) | Высокая пропускная способность на запись и горизонтальное масштабирование |
Аналитика продаж в ритейле, где требуется агрегирование данных по большим объёмам транзакций | Колоночная БД (ClickHouse) | Быстрая скорость аналитических запросов и эффективное сжатие данных |
Реализация полнотекстового поиска по каталогу товаров в интернет-магазине | Поисковый движок (Elasticsearch) | Быстрый поиск по ключевым словам и релевантность результатов |
Хранение метрик мониторинга серверов | TSDB (Prometheus) | Оптимизация для работы с временными рядами и эффективное хранение данных |
Обработка большого количества транзакций в реальном времени в финансовой системе | NewSQL (YDB) | Строгая консистентность и горизонтальное масштабирование |
Анализ данных о поведении пользователей в крупных онлайн-сервисах | Системы обработки больших данных (Apache Hadoop) | Распределённая обработка огромных объёмов данных |
Хранение бэкапов данных для обеспечения их надёжности и доступности | S3 (Object Storage) | Высочайшая надёжность, масштабируемость и низкая стоимость хранения |
Распределение статического контента (изображения, стили CSS, JavaScript-файлы) для ускорения загрузки веб-сайтов | CDN (Content Delivery Network) | Снижение задержки при загрузке контента для пользователей из разных уголков мира |
Моделирование и анализ социальных графов для выявления сообществ и рекомендаций | Графовая БД (Neo4j) | Эффективная работа со связями между сущностями и быстрый обход графа |
Саммари
В статье мы разобрали:
различные типы хранилищ данных, включая SQL, Key-Value, Wide-Column, Columnar, документные, графовые, поисковые движки, TSDB, NewSQL;
особенности и преимущества каждого типа хранилища;
примеры использования различных хранилищ в реальных сценариях;
смежные технологии и системы хранения, такие как системы обработки больших данных, S3 и CDN.
Помните главное: идеального хранилища "на все случаи жизни" не существует. Каждое решение — это компромисс. Выбирая базу, вы всегда будете жертвовать чем-то одним ради чего-то другого. Поэтому спросите себя: что для вашей задачи критичнее? Скорость чтения или записи? Данные будут чаще читать или писать?
А может, ключевой фактор — это возможность легко масштабироваться горизонтально? Eventual consistency в NoSQL может привести к временным аномалиям в согласованности данных. А транзакции в SQL — к низкой производительности из-за блокировок. Важно правильно пределять приоритеты, и тогда выбор становится яснее.
Спасибо большое за прочтение статьи! И удачи в подготовке к собеседованию!
