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

Автор Фёдор Понин

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

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

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

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

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

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

  • создание и хранение данных определенных типов;

  • непосредственное управление БД (создание, изменение и удаление данных);

  • получение необходимых данных из базы с помощью специального запроса (например, на языке SQL);

  • администрирование БД, назначение прав различным типам пользователей, контроль доступа к БД, сохранение конфиденциальности данных;

  • обеспечение безопасного хранения данных и их целостности;

  • обеспечение защиты от потерь и сбоев в работе;

  • выполнение резервного копирования и восстановления данных, отслеживание изменений в БД.

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

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

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

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

  • тип решаемых задач в создаваемом ПО;

  • тип данных, используемых в проекте;

  • перспективы масштабирования приложения;

  • стоимость лицензирования СУБД;

  • сложность поддержки и обслуживания;

  • наличие поддержки, документации и распространенность СУБД;

  • отказоустойчивость и надежность;

  • выбор между облачными и on-premise-решениями и другие факторы.

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

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

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

    1. Вид проекта. Имеется в виду область, где проект будет применяться, и масштабы проекта. К примеру, если у вас частный или учебный проект, можно выбрать бесплатную СУБД (MySQL или аналогичную) либо встраиваемую (OpenEdge, SQLite, Microsoft SQL Server Compact). Встраиваемые СУБД (локальные) встраиваются непосредственно в ПО в качестве отдельного модуля и используются для управления данными только внутри него.

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

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

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

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

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

  • Стоимость СУБД. При оценке этого критерия всё упирается в бюджет проекта. Если он у вас низкий, то стоит присмотреться к решениям Open-source: такие СУБД надежны и пользуются большой популярностью у пользователей, однако поддержку придется осуществлять самостоятельно.

  • Обеспечение информационной безопасности. Если в проекте предстоит работа с чувствительной информацией или персональными данными, финансовыми транзакциями, то следует подумать об обеспечении безопасности в СУБД (сертификаты, шифрование, соответствие нормативным документам и т. д.).

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

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

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

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

    3. Быстродействие. Здесь необходимо рассмотреть, с какой скоростью обрабатываются данные. Если, к примеру, вам важна быстрота обработки транзакций, то следует обратить внимание на этот параметр.

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

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

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

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

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

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

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

  • Если требуется высокая нормализация данных.

  • Если требуется обрабатывать большое количество коротких транзакций с высокой долей операций на вставку.

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

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

  • Если есть необходимость частого обновления данных в одних и тех же строках.

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

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

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

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

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

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

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

    1. СУБД «ключ-значение» (key-value). Достаточно простой вариант, который можно представить в виде таблицы с уникальным ключом и связанным с ним значением, в котором может быть какая угодно информация. Такие СУБД обладают хорошим быстродействием, некоторые могут работать полностью в памяти, задавать срок жизни записи, после истечения которого запись будет удалена. Наиболее известные представители типа key-value — Redis и Memcached. Выбирать подобные СУБД стоит для проектов, где будут использоваться кэширование либо брокеры данных или же разработчики будут иметь дело с очень простыми структурами и необходимо получать к ним очень быстрый доступ. Если же в проекте планируются БД с множеством таблиц и сложными структурами, то не стоит ориентироваться на СУБД этого типа.

    2. Документные (документно ориентированные) СУБД — это достаточная популярная разновидность СУБД NoSQL. В таких СУБД основной единицей логической модели данных является документ, то есть структурированный текст с определенным синтаксисом. Данные хранятся в форматах JSON, XML и подобных. Примеры документно ориентированных СУБД: CouchDB, MongoDB, Amazon DocumentDB. Подобные СУБД выбирают, как правило, для задач поиска по каталогу. Например, в MongoDB есть технология быстрого полнотекстового поиска (поиск слов или фраз в текстовых данных). Кроме того, документные СУБД хорошо подойдут в случае хранения структур, включая объекты, списки и словари, особенно в формате JSON. Однако документная СУБД не подойдет для работы с транзакциями и для формирования отчетности.

    3. Графовые СУБД. Это достаточно специфические СУБД, предназначенные для работы с графами (с их узлами, свойствами, произвольными отношениями между узлами). Самый наглядный пример их использования — социальные сети. Наиболее распространенные графовые СУБД: Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid. Такие СУБД необходимо выбирать, если ваш проект представляет собой что-то похожее по принципам на социальную сеть. В других случаях графовые СУБД рассматривать не стоит.

    4. Колоночные СУБД. Основная идея этих систем — способ хранения данных не по строкам, как это реализовано в реляционных БД, а по колонкам. То есть физически данные хранятся в таблицах. Примеры колоночных СУБД: Google Big Table, Apache HBase, Cassandra. Колоночные СУБД применяются в аналитических системах класса business intelligence и аналитических хранилищах данных (data warehouses), объемы данных могут быть достаточно большими (например, по 300-500 Тбайт). Для проектов с небольшими объемами данных такие СУБД применять не стоит — выигрыша в быстродействии по сравнению с реляционными СУБД получить не удастся.

    Выводы

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

    Источник

    Технологии не стоят на месте: изобретение и поиск продвинутых решений, переосмысление старого и замена новым – залог востребованности на рынке. Лучше всех себя на этом поприще показывает китайская компания Xiaomi.
    Понравилась статья? Поделиться с друзьями:
    Xiaomi-profi.ru
    Добавить комментарий

    ;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: