Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>8 авг 2022</li>

3 <li>0</li>

4 </ul>Когда вы начинаете работу над новым проектом, важно понять, по каким критериям выбирать базы данных и какие вообще есть решения.

5 Иллюстрация: rawpixel.com / Graphue / Freepik / nadine shaabana / Unsplash / Дима Руденок для Skillbox Media

6 Онлайн-журнал для тех, кто влюблён в код и информационные технологии. Пишем для айтишников и об айтишниках.

7 Системный архитектор с опытом в разработке полного цикла более 10 лет. Обладает практическими навыками построения масштабируемых сервисов и аналитических систем. А также большим опытом в области обработки изображений, анализа и прогнозирования временных рядов.

8 Существует много различных семейств баз данных, которые различаются структурой хранения, обработки и индексации данных. От основных пользовательских сценариев зависит, какая модель лучше подойдёт в том или ином случае. Иногда вполне оправданно использовать сразу несколько различных баз данных, копируя одни и те же данные несколько раз.

9 Вот наиболее важные критерии для выбора базы данных:

10 <ul><li>какие данные в ней должны храниться,</li>

11 <li>каким будет объём данных,</li>

12 <li>какого рода запросы будут выполняться при обращении к базе данных.</li>

13 </ul>Реляционные базы данных - самые распространённые. Вот лишь самые популярные из них: Oracle, Microsoft SQL Server, PostgreSQL, MySQL. Такие базы данных обеспечивают построчное хранение данных в таблицах, что подразумевает строгую структуру данных. А ещё подразумевается, что за одно обращение к базе вы будете запрашивать относительно небольшое количество записей.

14 Такие решения, как правило, довольно хорошо работают, если общий объём ваших данных не превышает нескольких терабайт (конечно, при наличии подходящей инфраструктуры), что в целом делает их подходящими для большинства проектов - особенно на начальном этапе разработки.

15 Реляционные базы данных стоит выбирать, если вам важны следующие характеристики:

16 <ul><li>транзакционность;</li>

17 <li>частые изменения данных;</li>

18 <li>поиск по индексам;</li>

19 <li>запросы небольшого количества записей за раз;</li>

20 <li>объём данных не превышает нескольких терабайт.</li>

21 </ul>Выбор конкретной реляционной базы данных зависит от дополнительных требований к безопасности, поддержке и других факторов. Например, в банковской сфере предпочитают использовать Oracle и Microsoft SQL Server. Однако это платные решения - а открытая и бесплатная PostgreSQL тоже показывает очень хорошую производительность, активно развивается и распространяется по свободной лицензии. Если у вас совсем небольшой проект, можно использовать любую реляционную БД.

22 Альтернативой для реляционных баз данных являются NoSQL-базы. Это могут быть документоориентированные графовые базы данных или key-value-хранилища.

23 Документоориентированные базы (например, MongoDB, Amazon DocumentDB, CouchDB и другие) хранят данные сразу готовыми "документами", а не в таблицах и строках - как реляционные БД. Этот способ хранения подходит, когда структура данных может изменяться или ваши основные сценарии использования подразумевают загрузку составной структуры. Документоориентированные базы очень близки к формату ресурсов, которыми обмениваются клиент и сервер, что упрощает подготовку данных для передачи по сети.

24 В статьях и книгах в качестве типового примера работы таких БД часто приводят сценарий загрузки страницы пользователя в социальной сети. В этом случае у человека есть основные данные: Ф. И. О., дата рождения, пол - и дополнительная информация, которая может включать в себя несколько элементов и требовать разной структуры. Например, места учёбы, проживания, работы.

25 Как известно, у одного человека может быть много мест учёбы или проживания, а адреса в разных странах могут состоять из разных сущностей. В России это область → город → улица → дом, а во Франции - провинция → регион → город → улица → дом. Да, такие структуры можно собирать и на реляционных БД, однако в этом случае придётся выполнить несколько дополнительных запросов, чтобы собрать всю информацию о человеке и отрисовать его страницу.

26 Документоориентированные базы данных позволяют хранить подобную информацию о пользователе целиком, в одном месте и получать её одним запросом.

27 При этом документоориентированные базы данных поддерживают возможность использования ссылок на другие записи в базе - а это позволяет приблизиться к реляционной модели. Кстати, реляционные модели тоже двигаются в сторону поддержки составных структур данных - таких как JSON - и позволяют выполнять поиск по содержимому "сложного, составного" поля.

28 Таким образом, главное преимущество документоориентированных баз данных - возможность хранения данных без строгого ограничения по структуре.

29 Key-value-хранилища (Redis, Aerospike, DynamoDB и другие) хранят данные в виде хеш-таблицы. В такой модели у каждой записи есть только один индекс. При этом нет строгого ограничения на структуру значения. Как правило, такие базы данных изменяют данные по принципу логов, то есть всегда дописывают значения в конец, а удаление выполняется при помощи добавления специальной записи. Key-value-хранилища хорошо служат в качестве кэша, очереди или логирования.

30 Графовые базы данных хранят все данные в виде узлов и связей между ними. Этот подход может ускорять запросы в некоторых случаях и применяется в рекомендательных движках и приложениях, связанных с геопозиционированием. Так что, если вы делаете подобное приложение, возможно, вам стоит обратить внимание на графовые хранилища. Хотя надо признать - это специфические решения.

31 Для аналитических систем, которые предполагают работу с огромными объёмами данных - в десятки терабайт, а то и несколько петабайт, - существует отдельный класс хранилищ, которые хранят данные в колонкоориентированной модели.

32 В отличие от реляционной модели данных, где последовательно хранится вся строка таблицы, или документоориентированной модели, где последовательно хранится весь документ, здесь последовательно хранятся значения одной колонки, и подразумевается, что в одной и той же позиции каждой колонки хранятся значения, относящиеся к одной строке. Такая модель позволяет эффективно сжимать данные и строить над ними различные агрегаты: сумма, среднее, количество и другие.

33 OLAP-системы позволяют добавлять данные непрерывным потоком или загружать порциями - а вот удалять или изменять их обычно не разрешают. Их главная задача - позволить аналитикам и менеджменту компаний анализировать данные. Следовательно, они должны хранить историю событий, в то время как остальные БД подразумевают хранение лишь текущего состояния каждой сущности. Обычно OLAP-хранилища поддерживают синтаксис SQL-запросов, поскольку он хорошо подходит для аналитических задач.

34 Большинство решений в этой области - например, Vertica, Teradata, BigQuery - стоят довольно дорого. Однако есть и решения с открытым исходным кодом, такие как ClickHouse, Apache Druid и другие.

35 Как правило, в большинстве проектов достаточно реляционных баз данных, среди которых можно выбрать подходящие бесплатные решения. Однако под некоторые специфические сценарии использования лучше подходит документоориентированная модель хранения данных.

36 Конечно, стоит учитывать, что сейчас многие реляционные базы данных поддерживают возможность хранения данных в формате JSON или XML, что в какой-то степени позволяет им конкурировать с документоориентированной моделью.

37 Если же ваш проект вырос до такого размера, когда этих решений недостаточно, имеет смысл добавлять key-value-хранилища в качестве кэша или искать другую гибридную модель управления данными.

38 А вот если вам необходимо построить систему аналитики с обработкой огромных объёмов данных, то, скорее всего, вам придётся рассматривать хранилища из категории OLAP. К ним относятся колонкоориентированные хранилища или хранилища категории семейства столбцов, такие как HBase или Google Cloud Bigtable.

39 <a>Научитесь: SQL для анализа данных Узнать больше</a>