Как выбрать СУБД для нового проекта

Для чего нужна СУБД

СУБД — это система управления базой данных, то есть сложный программный продукт, назначение которого — создавать базы данных, изменять их, получать из них информацию и контролировать версии.

База данных (БД) — это хранилище данных, которое используется для веб-проекта, программных комплексов разного назначения и т. д. Практически в любом проекте мы сталкиваемся с СУБД, которые служат для самых разных целей: например, в интернет-магазине они позволяют управлять базой данных с товарами, а на портале государственного учреждения — управлять персональными данными граждан.

С СУБД имеют дело самые разные ИТ-специалисты: архитекторы систем, разработчики бэкенд-решений и локальных приложений, администраторы БД, системные аналитики, инженеры DevOps и другие специалисты. Кратко охарактеризуем основные функции СУБД:

создание и хранение данных определенных типов; непосредственное управление БД (создание, изменение и удаление данных); получение необходимых данных из базы с помощью специального запроса (например, на языке SQL); администрирование БД, назначение прав различным типам пользователей, контроль доступа к БД, сохранение конфиденциальности данных; обеспечение безопасного хранения данных и их целостности; обеспечение защиты от потерь и сбоев в работе; выполнение резервного копирования и восстановления данных, отслеживание изменений в БД.

Мы рассказали, для чего нужны СУБД, теперь остановимся на проблеме выбора СУБД для нового проекта.

А надо ли вообще выбирать?

Часто можно наблюдать такую картину, когда архитектор и команда разработчиков вообще не задумываются над выбором СУБД, действуя по принципу «мы всегда работаем на MySQL, эта СУБД бесплатная», «такую СУБД предлагает наш хостинг-провайдер» или «мы всегда на ней проектировали, а новое ПО учить некогда». В результате на этапе разработки, тестирования или даже сдачи в эксплуатацию программного продукта возникают серьезные проблемы с масштабируемостью, быстродействием, совместимостью различного ПО и типов данных и т. д. Это ведет к многочисленным переделкам и доработкам проекта, что в конечном итоге увеличивает стоимость и сроки процесса разработки ПО.

Одним словом, не спешите с выбором СУБД, не связывайтесь навсегда с единственным решением или производителем СУБД. На первом этапе анализа проекта системный аналитик, архитектор, руководитель проекта должны рассмотреть будущую СУБД со всех возможных сторон и учесть:

тип решаемых задач в создаваемом ПО; тип данных, используемых в проекте; перспективы масштабирования приложения; стоимость лицензирования СУБД; сложность поддержки и обслуживания; наличие поддержки, документации и распространенность СУБД; отказоустойчивость и надежность; выбор между облачными и on-premise-решениями и другие факторы.

Так как этих критериев достаточно много, мы решили их сгруппировать и как-то систематизировать, чтобы разработчикам ПО, читающим эту статью, было проще определиться с выбором СУБД.

Критерии выбора СУБД: нефункциональные и функциональные

Вначале остановимся на нефункциональных критериях выбора СУБД:

Вид проекта. Имеется в виду область, где проект будет применяться, и масштабы проекта. К примеру, если у вас частный или учебный проект, можно выбрать бесплатную СУБД (MySQL или аналогичную) либо встраиваемую (OpenEdge, SQLite, Microsoft SQL Server Compact). Встраиваемые СУБД (локальные) встраиваются непосредственно в ПО в качестве отдельного модуля и используются для управления данными только внутри него. Локальная или распределенная СУБД. Необходимо обдумать, как будет работать ваше ПО: локально на компьютере или используя клиент-серверные технологии? А может быть, будут задействованы облачные технологии? Например, локальные СУБД предполагают систему хранения данных на одном сервере, как правило, внутри организации. В случае с распределенными базами данных элементы находятся на различных серверах, в том числе и на облачных. Также может быть использована технология «клиент-сервер»: это означает, что СУБД и базы данных размещены на одном сервере, к которому пользователи обращаются со своими запросами. Доступ к данным можно получить через этот сервер с любой рабочей станции (специального программного обеспечения для этого не нужно). Как пример такого решения можно привести интернет-магазин с его базой данных товаров: покупатели просто обращаются к БД магазина со своих личных компьютеров. В свою очередь, Firebird, MS SQL Server, Oracle и PostgreSQL подходят в качестве клиент-серверных СУБД для работы.

Существует и другой способ организации СУБД — «файл-серверные» СУБД. Здесь базы данных находятся на одном сервере, а СУБД — на каждом устройстве, с которого пользователь отправляет запросы к БД. Примеры использования таких систем можно найти в корпоративных CRM или электронном документообороте компании. Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro активно используются для такого рода решений.

Нагрузка. На этапе проектирования хорошо бы сразу посчитать, какое количество пользователей будет обращаться к БД одновременно. Масштабируемость. При оценке этого параметра необходимо иметь данные по нагрузке на начальном этапе. Но следует учитывать, что бизнес развивается и, естественно, приложение, как и БД, нуждается в масштабировании. Эти вопросы нужно предусмотреть заранее. Отказоустойчивость. Для некоторых серьезных проектов это главный параметр при выборе СУБД (например, в финансовых или государственных проектах, где хранятся данные о транзакциях или персональные данные граждан). Отказоустойчивость — это способность системы сохранить информацию и восстановить работоспособность после сбоя (отключения электричества, поломки, ошибки, вызванной сбоем программы или человеческим фактором). Стоимость СУБД. При оценке этого критерия всё упирается в бюджет проекта. Если он у вас низкий, то стоит присмотреться к решениям Open-source: такие СУБД надежны и пользуются большой популярностью у пользователей, однако поддержку придется осуществлять самостоятельно. Обеспечение информационной безопасности. Если в проекте предстоит работа с чувствительной информацией или персональными данными, финансовыми транзакциями, то следует подумать об обеспечении безопасности в СУБД (сертификаты, шифрование, соответствие нормативным документам и т. д.). Администрирование и поддержка. Некоторые сложные проприетарные СУБД (например, Oracle) требуют квалифицированного специалиста для их администрирования и поддержки. Если бюджет проекта позволяет выделить такого специалиста, то можно выбирать данную СУБД. Если же разрабатывается какое-то простое приложение, лучше остановиться на СУБД, которые просты в поддержке и администрировании. Также необходимо обратить внимание, какую поддержку осуществляет разработчик СУБД, хорошо ли документирован его продукт, есть ли большое сообщество пользователей в Интернете, и т. д.

А сейчас рассмотрим функциональные требования к СУБД.

Тип данных. Для начала необходимо определиться, с какими данными будет происходить работа в проекте. Некоторые СУБД лучше работают с текстом или транзакциями, другие с медиаконтентом, и т. д. Объем данных. Каждая система управления базами данных имеет документацию, в которой прописаны ограничения на объем одного файла, таблицы и т. д. При планировании проекта необходимо рассмотреть, какие объемы данных предполагается хранить в БД (возможно, не все СУБД подойдут по этому параметру). Быстродействие. Здесь необходимо рассмотреть, с какой скоростью обрабатываются данные. Если, к примеру, вам важна быстрота обработки транзакций, то следует обратить внимание на этот параметр. Способ обработки данных. При решении задач обработки данных необходимо придерживаться требований универсальности, оптимальности и параллелизма. Универсальность — это возможность запроса данных с помощью различных технологий. Оптимальность запроса означает удобство метода по извлечению данных из базы. А параллелизм означает, что разные серверы одновременно обращаются в БД за одними и теми же данными.

Необходимо отметить, что СУБД также выбирают по принципу применяемой в ней модели данных. Этот критерий настолько важен, что остановимся на нем подробнее.

Модели данных: основные плюсы и минусы

Существует две популярных моделей данных, на основе которых строятся СУБД — это реляционные и нереляционные (key-value, документная, графовая, колоночная).

Реляционные базы данных. Эта модель используется, когда важны согласованность и высокая нормализация данных. При запросе в такую БД лучше вообще не отвечать клиенту или отвечать чуть дольше обычного, чем ответить неправильно. Реляционные базы данных хороши в обработке небольших транзакций с большой долей вставок, минимальным откликом и возможностью отмены любых изменений, выполняемых в рамках транзакции.

Когда нужно выбирать реляционную СУБД?

Если проектируется система, в которой требуется хранить значительное количество таблиц с различными типами связей между ними (один-к-одному, один-к-многим, многие-ко-многим). Если требуется высокая нормализация данных. Если требуется обрабатывать большое количество коротких транзакций с высокой долей операций на вставку.

В каких случаях не стоит выбирать реляционную СУБД?

Если предполагается хранение неструктурируемых данных, к примеру простых структур вида «ключ-значение». Если есть необходимость частого обновления данных в одних и тех же строках.

Реляционные СУБД управляются с помощью языка запросов SQL. Примерами таких СУБД являются Oracle, Microsoft SQL, PostgreSQL, MySQL.

Так, Oracle Database — это объектно-реляционная клиент-серверная СУБД, одна из первых и наиболее известных. Она платная и достаточно сложная, подходит для крупных проектов с солидным бюджетом и наличием серьезной команды специалистов.

MySQL — бесплатное решение из реляционных СУБД, однако также популярная и надежная СУБД для проектов небольшого и среднего размера. Она легкая и гибкая, довольно простая в использовании и обучении.

Для совсем маленьких проектов можно посоветовать файловую СУБД SQLite: она компактная и встраиваемая, проста в использовании.

Наиболее распространенные примеры задач, где нужно использовать реляционные СУБД, — приложения интернет-банкинга.

Нереляционные базы данных. Объясним на простом примере смысл таких СУБД. Если для проекта критически важно всегда отвечать клиенту хоть как-то, чем не отвечать вовсе, стоит обратить внимание на нереляционные СУБД. Пример подобных проектов — сайты-поисковики. При выборе нереляционной СУБД необходимо исходить из функциональных требований к проекту, видов интеграций в нем, допущений, которые разработчики готовы сделать. Также архитектору и аналитику обязательно нужно обсудить свой выбор с разработчиками, чтобы оценить сложность написания кода и быстродействие данной СУБД.

Существует несколько подвидов нереляционных СУБД. Рассмотрим их подробнее.

СУБД «ключ-значение» (key-value). Достаточно простой вариант, который можно представить в виде таблицы с уникальным ключом и связанным с ним значением, в котором может быть какая угодно информация. Такие СУБД обладают хорошим быстродействием, некоторые могут работать полностью в памяти, задавать срок жизни записи, после истечения которого запись будет удалена. Наиболее известные представители типа key-value — Redis и Memcached. Выбирать подобные СУБД стоит для проектов, где будут использоваться кэширование либо брокеры данных или же разработчики будут иметь дело с очень простыми структурами и необходимо получать к ним очень быстрый доступ. Если же в проекте планируются БД с множеством таблиц и сложными структурами, то не стоит ориентироваться на СУБД этого типа. Документные (документно ориентированные) СУБД — это достаточная популярная разновидность СУБД NoSQL. В таких СУБД основной единицей логической модели данных является документ, то есть структурированный текст с определенным синтаксисом. Данные хранятся в форматах JSON, XML и подобных. Примеры документно ориентированных СУБД: CouchDB, MongoDB, Amazon DocumentDB. Подобные СУБД выбирают, как правило, для задач поиска по каталогу. Например, в MongoDB есть технология быстрого полнотекстового поиска (поиск слов или фраз в текстовых данных). Кроме того, документные СУБД хорошо подойдут в случае хранения структур, включая объекты, списки и словари, особенно в формате JSON. Однако документная СУБД не подойдет для работы с транзакциями и для формирования отчетности. Графовые СУБД. Это достаточно специфические СУБД, предназначенные для работы с графами (с их узлами, свойствами, произвольными отношениями между узлами). Самый наглядный пример их использования — социальные сети. Наиболее распространенные графовые СУБД: Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid. Такие СУБД необходимо выбирать, если ваш проект представляет собой что-то похожее по принципам на социальную сеть. В других случаях графовые СУБД рассматривать не стоит. Колоночные СУБД. Основная идея этих систем — способ хранения данных не по строкам, как это реализовано в реляционных БД, а по колонкам. То есть физически данные хранятся в таблицах. Примеры колоночных СУБД: Google Big Table, Apache HBase, Cassandra. Колоночные СУБД применяются в аналитических системах класса business intelligence и аналитических хранилищах данных (data warehouses), объемы данных могут быть достаточно большими (например, по 300-500 Тбайт). Для проектов с небольшими объемами данных такие СУБД применять не стоит — выигрыша в быстродействии по сравнению с реляционными СУБД получить не удастся.

Выводы

Мы рассмотрели как функциональные, так и нефункциональные критерии выбора СУБД для нового проекта. Подводя итоги, следует подчеркнуть, что, выбирая СУБД, нужно оценить сразу несколько важных факторов, продумать, с какими типами данных необходимо будет работать, как их обрабатывать, какое должно быть быстродействие и т. д. Архитектору и аналитику стоит изучить разные модели данных, используемые в СУБД, и принимать решение на основании чисто рациональных факторов. Не стоит использовать всё время одну и ту же СУБД по принципу «она бесплатная или использовалась ранее». А для крупных проектов возможно использование нескольких различных СУБД.