Как выбрать сервер под базу данных
В ИТ-инфраструктуре любой компании важное место занимает сервер БД, где хранится и обрабатывается вся корпоративная информация, поэтому неудивительно, что требования к серверу базы данных особенно высоки — оборудование должно удовлетворять стандартам безопасности и отказоустойчивости, а также обладать достаточной производительностью.
Далеко не последнюю роль играет программное обеспечение и сам тип базы данных: именно от этого зависит, насколько быстро и эффективно приложения будут извлекать, обрабатывать и передавать данные. Более того, вся корпоративная информация должна быть защищена, чтобы злоумышленники не смогли получить к ней доступ. К счастью, этого можно достичь с помощью грамотно подобранной системы управления базами данных.
База данных — это место для хранения и систематизации всех данных, тогда как система управления базами данных (СУБД) представляет собой ПО для управления этой базой данных.
На рынке систем управления базами данных представлено свыше 300 инструментов. В сегменте серверного оборудования — еще более широкий выбор. Однако как подобрать оптимальную конфигурацию как «железа», так и программной части?
Типы баз данных: SQL или NoSQL
Когда дело доходит до выбора базы данных, одной из самых больших проблем остается подбор типа структуры данных — SQL (реляционной) и NoSQL (нереляционной). Несмотря на то, что обе они достаточно производительны, между ними есть принципиальные отличия.
Базы данных SQL
Реляционная БД представляет собой набор таблиц с заданными отношениями между друг другом. Для формирования запросов к реляционной базе данных система управления БД оперирует языком структурированных запросов SQL. В сущности это стандартное приложение, которое предоставляет достаточно простой программный интерфейс для взаимодействия с данными.
Базы данных SQL состоят из строк, или по-другому кортежей, и столбцов, или попросту атрибутов. Кортежи в этой таблице имеют идентичные атрибуты.
Преимущества SQL
Реляционная БД подходит для хранения структурированных данных: например, номера телефонов, даты, почтовые адреса. Базы данных SQL — развитая технология: она достаточно документирована, может похвастаться широкой поддержкой и хорошо функционирует со всеми фреймворками и библиотеками. К примерам таких баз данных SQL можно отнести популярные PostgreSQL и MySQL.
Надежность и безопасность — другое ключевое качество реляционных БД. В SQL реализована система разрешений, которая определяет, кому позволено читать и редактировать базу данных. Администратор предоставляет конкретному пользователю права доступа для манипуляции с данными, что не позволяет третьим лицам извлечь важную информацию.
Внедрение реляционной системы управления БД гарантирует защиту от утери и повреждения данных, благодаря соответствию свойствам ACID: атомарности, согласованности, изоляции и долговечности.
- Атомарность символизирует единство любой транзакции (последовательных SQL-операций): таким образом, транзакция может либо провалиться, либо завершиться без ошибок, и если одна операция из этой последовательности приведет к ошибке, вся транзакция целиком завершится неудачей.
- Под согласованностью имеется в виду запись в БД только той информации, которая соответствует всем правилам. Если входные данные не указаны, сервер БД SQL возвращается в исходное состояние до проведения транзакции. Это позволяет исключить повреждения базы данных при проведении транзакции с ошибкой.
- Изоляция подразумевает, что незаконченные транзакции не вносят изменений в систему. Это гарантирует, что все транзакции обрабатываются безопасно и независимо.
- Долговечность означает, что данные сохраняются системой в том числе в случае сбоя транзакции. Благодаря высокому уровню надежности, данные не будут потеряны, даже если система окажется поврежденной.
Соответствие свойствам ACID особенно принципиально для приложений, обрабатывающих финансовые и разного рода другие конфиденциальные личные данные. Благодаря своим положительным сторонам в плане сохранности данных, реляционные БД подходят для реализации финтех-проектов.
Недостатки SQL
Тем не менее, SQL-базы обладают и существенными недостатками:
- Недостаточная гибкость. Реляционные БД неэффективны при работе с неструктурированными данными, в связи с этим они не применимы для аналитики или работы с Big Data.
- Обмениваться информацией между программными компонентами становится тем более затруднено, чем сложнее структура данных. Поэтому в больших компаниях реляционные БД часто используются независимо.
- Базы данных SQL могут функционировать лишь на одном физическом сервере, что приводит к дополнительным тратам на дорогостоящее оборудование при необходимости работы с большим объемом данных.
Ряд таких недостатков заставил разработчиков создавать альтернативы реляционным БД, в результате чего распространение получили базы данных NoSQL.
NoSQL
Базы данных NoSQL, также именуемые нереляционными либо распределенными, являются альтернативным решением. Они могут хранить и работать с неструктурированными данными, как например, с медиа-контентом и различными файлами, тем самым предлагая разработчикам большую гибкость и масштабируемость.
Информацию в NoSQL БД можно изменять на лету, не нанося ущерб имеющимся данным. Также нереляционные базы данных можно распределить на нескольких физических серверах, в связи с чем облегчается процесс масштабирования по сравнению с реляционными БД.
А так как нереляционные БД не полагаются на один сервер базы данных, они демонстрируют большую отказоустойчивость. Это означает, что при выходе из строя одного сервера база данных продолжит функционировать.
Классификация нереляционных БД подразделяет их на 4 вида.
Хранилища «ключ-значение». Наипростейший тип БД NoSQL, который может сохранять исключительно пары ключ-значение. Такой тип хранилища может стать подходящим при требовании к быстрому поиску информации посредством ключа. Amazon DynamoDB и Redis — типичные примеры баз данных «ключ-значение». Однако такой подход не позволяет выполнять большинство операций, доступных в других типах баз данных.
Хранилища документов. Документо-ориентированные БД хранят всю информацию об определенном объекте в едином файле стандарта XML, BSON либо JSON. Документы одного типа можно сгруппировать в коллекции либо списки. Такой подход позволяет девелоперам не переживать о типах данных и отношениях между ними. Благодаря своим свойствам, документо-ориентированные БД могут быть использованы для эффективного прототипирования и анализа данных.
Колоночные СУБД. Работая как со структурированными, так и с неструктурированными данными, колоночная БД подходит для задач, в которых требуется быстрый поиск по значениям столбцов. В БД данного вида любой столбец хранится в качестве логического массива. Колоночные СУБД гарантируют легкую масштабируемость и дублируемость, однако уступают аналогам по производительности.
Графовые базы данных. В графовых БД каждая сущность или узел являются изолированным документом с метаданными произвольного формата. Узлы соединяются ребрами, которые и определяют их отношения. Подобная реализация значительно упрощает визуализацию данных.
Какие факторы учесть при выборе БД
При поиске софта для управления БД необходимо взять в расчет ряд аспектов:
Тип данных. Реляционные БД созданы для хранения и работы со структурированными данными, тогда как NoSQL — лучший выбор для управления неструктурированными данными. Для корректной работы с обеими типами данных, рекомендуется использовать комбинацию из баз данных SQL и NoSQL. Лучше всего для этого подойдут решения на базе NewSQL.
Масштабируемость. С ростом проекта очевидно расширяется и сама база данных. На итоговом выборе БД может сказаться планируемый тип масштабирования, будь то горизонтальный или вертикальный. Базы данных NoSQL с хранением пары ключей и значений больше подходят для горизонтального масштабирования, тогда как реляционные БД — больше для вертикального.
Безопасность. В связи с тем, что в БД хранятся все пользовательские данные, база данных должна быть должным образом защищена. ACID-совместимые реляционные базы данных куда более надежны в этом плане, чем NoSQL БД, в которых на первый план выходят производительность и возможность для масштабирования.
Интегрируемость. Убедитесь, что выбранная для работы СУБД может быть интегрирована с другими инструментами и сервисами в рамках одного проекта. В большинстве случаев недостаточная интегрируемость с другими решениями может ограничить разработку.
Список популярных СУБД
OracleDB. Объектно-реляционная СУБД Oracle Database, разработанная в 70-х годах, остается наиболее популярным и надежным решением для крупных компаний в силу соответствия признанным стандартам безопасности, способности обрабатывать чрезвычайно большие объемы данных и эффективного управления памятью.
MySQL. Одна из наиболее востребованных СУБД с открытым исходным кодом, подходящая для проектов даже начального уровня. Сервер для БД MySQL работает со структурированными данными, обладает подробной и доступной документацией и легко интегрируется с любым приложением.
PostgreSQL. Оптимальное опенсорсное решение для больших проектов ввиду масштабируемости и способности обрабатывать терабайты данных. Безопасность обеспечивается возможностью выстраивания иерархии ролей для редактирования прав пользователей.
MongoDB. Нереляционная БД, в которой информация сохраняется в документах стандарта BSON. В связи с этим информация может без ограничений передаваться между веб-приложениями и отдельными серверами в удобочитаемом формате. MongoDB обладает поддержкой репликации, тем самым являясь легко масштабируемой. MongoDB — подходящее решение для операций с массивными неструктурированными данными.
Более того, вы можете реализовать проект на базе сразу нескольких БД, однако такой подход может иметь и негативные последствия. Разработчики должны принять это решение только после тщательного анализа требований проекта и определения технологического стека продукта.
Конфигурация сервера
Для «среднего» проекта, объем базы данных которого составляет около 100 ГБ, оптимальна средняя конфигурация:
- Высокоскоростные диски, в том числе SAN, с отдельным хранилищем для SQL, вспомогательных данных и временных файлов;
- Высокопроизводительный процессор с числом ядер от 4 до 8;
- От 16 до 64 ГБ оперативной памяти.
Объем оперативной памяти
При необходимости повысить производительность системы, в случае с серверами баз данных решающее значение приобретет возможность просто увеличить объем ОЗУ. Например, удвоение объема оперативной памяти с 16 ГБ до 32 ГБ может сократить время выполнения запроса в два раза.
Для обработки данных предварительно осуществляется соединение сервера с базой данных и загрузка обрабатываемых данных в оперативную память с целью оптимизации производительности: все вычисления таким образом, проходят в режиме реального времени.
Чтобы выяснить, каков «наилучший» объем ОЗУ, сложите размер всех ваших активных баз данных, это и будет тем объемом ОЗУ, который вы потенциально можете использовать, в зависимости от ограничений используемого ПО. Очевидно, что это «лучший сценарий», который не является реалистичным или необходимым для всех компаний.
Кроме того, перед установкой оперативной памяти важно учитывать особенности базы данных и программного обеспечения: в зависимости от версии ПО, СУБД может поддерживать работу только с ограниченным объемом ОЗУ.
Размер хранилища
При выборе размера жестких дисков необходимо учесть в первую очередь потенциал для масштабирования, полагаясь при этом на долговечность накопителей. Если ваша текущая база данных занимает около 100 ГБ с ежегодным приростом в 15 ГБ, следует установить в сервер для БД жесткий диск объемом существенно более 150 ГБ, иначе он заполнится уже через 3 года.
Если есть возможность развернуть сеть хранения данных SAN, то именно ее лучше всего использовать для размещения файлов базы данных. В противном случае в конфигурацию рекомендуется включить 3 отдельных высокоскоростных диска (например, со скоростью вращения шпинделя от 15 тысяч оборотов в минуту) для разных задач:
- Диск 1. Хранилище с базой данных (объем - двойной размер текущей БД);
- Диск 2. Временная база данных (объем - 100 ГБ или меньше);
- Диск 3. Стандартный диск для хранения ОС и программных файлов (объем — 100 ГБ или меньше).
Физическое расположение этих баз данных и задается при установке СУБД.
Процессор
Производительность процессора играет последнюю роль в построении сервера баз данных после определения объема RAM и накопителей. Тем не менее, есть некоторый золотой стандарт для серверных чипов.
Для баз данных небольших компаний будет достаточно производительности 4-8 ядер, тогда как для решения задач более крупных проектов следует ориентироваться на 8 и 16-ядерные процессоры.
