Как выбрать сервер для баз данных

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

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

А остальные — заваривайте чай, кофе и присаживайтесь поудобней :)

Навигация по статье:

• Введение

• Что такое базы данных (БД)

• Что такое система управления базами данных (СУБД)

• Что такое система баз данных

• Зачем нужны БД, СУБД и системы баз данных

• Как выбрать сервер для баз данных

• Как выбрать тип СУБД

1. Реляционные SQL

2. Нереляционные noSQL

• Железо

1. Дисковая подсистема — это главное

2. Сетевые интерфейсы

3. ОЗУ

4. ЦПУ

• Безопасность

• Выводы

Что такое база данных

Информационные технологии во многом базируются на точных науках, а потому большинство терминов имеет единую трактовку. Но как бы мне не хотелось дать общепризнанное определение БД, его нет. А это значит, что самое время обратиться к глоссарию. В нашем случае — к ребятам из Oracle. Это один из крупнейших производителей серверного железа; с 1977 года развивают объектно-реляционную СУБД Oracle Database, последние лет 10 лидируют в этой области. В общем, разбираются :)

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

Хранение информации в базах данных логично, структурировано и решает конкретные задачи.

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

— А где у вас труды Фрейда?
— В какой-то из коробок на полу, там ещё 50 оттенков серого и Гарри Поттер сверху.

Получается, что БД — это большое количество упорядоченной информации, работать с которой нужно по определённым правилам.

Теперь давайте разберёмся с другим важнейшим понятием – с системой управления базами данных (СУБД).

Что такое СУБД

Мне нужна твоя книга, кожаный.

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

Поэтому и базам данных нужна система управления базами данных.

Когда большое приложение работает с данными, ему необходимы инструкции, логика и API. Да, можно хранить данные просто в памяти, как на вашем ПК, но если объём сильно возрастает, то это неэффективно

Итого: СУБД — это программа, которая необходима для создания, управления и другого взаимодействия с БД.

СУБД + базы данных = системы баз данных.

Что такое система баз данных

Чтобы БД и СУБД работали, нужны ресурсы и инфраструктура: помещение, сервер(ы), сисадмины, софт и другое оборудование. Некоторые непрофессионалы объединяют всё это в одно слово — БД.

Не надо так ¯\_(ツ)_/¯

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

Подытожу:

БД — это секции в библиотеке с книгами;

СУБД — это библиотекари;

Система баз данных — это библиотека в целом.

Зачем нужна база данных, СУБД и система баз данных

Когда компания развивается, растёт штат сотрудников и объём данных. Если в классической схеме хранения данных файл лежит там, куда его “положат” до востребования, то в базах данных дополнительно решаются вопросы с структурированием, обработкой, анализом, одновременным доступом и безопасностью информации. Многие процессы автоматизируют, а пользователь даже не знает, как всё устроено. 

В целом, на системах баз данных сейчас работает чуть менее чем всё:

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

• Любые сервисы, сайты и приложения, где нужно регистрировать личный кабинет, так как эти данные должны хранить в безопасности и не смешиваться друг с другом;

• Операционные системы.

Представим ситуацию:

Дюжина архитекторов начала одновременно работать над проектом здания объемом 5 ГБ. Им нужно отредактировать проект, и чтобы изменения отображались в реальном времени у всех сразу, не вызывая противоречий (консолидированная модель здания).

Тут нужна система баз данных с клиент-серверной СУБД. У разработчиков (и не только) есть метод управления ресурсами, который хорошо проиллюстрирует, что получится без использования системы баз данных. Называется он бурёнка COW (Copy-on-Write) — при чтении данных используется оригинал (копия не нужна), но при изменениях создаётся новый экземпляр (snapshot), который не влияет на исходные данные:

Одновременное редактирование по принципу COW.

На практике в работе архитекторов это будет выглядеть так:

1. Архитектор открывает файл проекта с локального диска — теперь его коллеги могут просматривать оригинал, но не изменять его;

2. Архитектор редактирует проект — коллеги не видят изменений в реальном времени, а только изначальную версию файла;

3. Один из коллег также начал вносить изменения в проект — API создаёт новый экземпляр файла, не связанный с оригиналом. Все изменения будут сохраняться в новом файле;

4. Архитектор сохраняет изменения в исходном файле и закрывает его; 

5. Теперь, если коллеги заново откроют проект, они увидят последние изменения;

6. Тот, кто первый откроет файл — будет работать с оригиналом.

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

Более функциональной альтернативой ПК и проекту на локальном диске можно назвать клиент-серверную систему баз данных. Рассмотрим на примере BIM-системы.

В центре у нас сервер (Server), который связывает пользователей, BIM-систему и все данные, создаёт бэкапы, предоставляет и (или) ограничивает доступ к клиентским приложениям и многое другое.

Все 10 архитекторов смогут работать одновременно, не мешая друг другу. Файл проекта один в актуальной версии (на считая бэкапов). Централизованная BIM-модель здания не даст проектировщикам допустить коллизии. В общем — одни плюсы.

Выбираем сервер для баз данных

Большинство компаний уровня SMB приобретают один сервер под систему баз данных — такой подход наиболее экономичен и прост в развёртывании, управлении и обслуживании. А раз сервер один, то и эффективность будет полностью зависеть от него. Неправильное решение скажется на всём бизнесе. Как и в других случаях отталкиваться нужно от задачи. Поскольку ваших задач я не знаю, то и советы будут конкретными настолько, насколько это возможно.

Вопрос 1: Как выбрать тип СУБД?

Основные игроки и их продукты.

Нельзя просто купить сервер, а потом решать, что на нём делать. Для начала нужно определиться, как вы будете использовать данные. Типов БД не меньше полусотни, конкретных решений – ещё больше. Тема настолько обширная, что можно пару жизней ей посвятить :) Для желающих изучить поподробнее оставлю ссылку — материал тоже не исчерпывающий, но много нового оттуда точно узнаете.

А я затрону лишь два самых распространённых класса СУБД:

1. Реляционные, SQL — Structured Query Language.

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

• Плюсы: целостность, сохранность (соответствие требованиям ACID) и структурированность данных, богатый бэкграунд SQL даёт огромные функциональные возможности, не зависит от конкретной СУБД;

• Минусы: сложность, плохая оптимизация в работе с разреженными данными, проблемы с многократными выполнением одинаковых запросов (N+1);

• Примеры: SQLite, MySQL, PostgreSQL, Microsoft SQL Server.

1. Нереляционные, NoSQL — not only SQL.

Как вы уже догадались из названия, здесь нет таблиц, строк и столбцов. В NoSQL данные оптимизируются более тонко, под конкретную задачу, а внутри имеют гибкую нетипизированную схему. Понадобилось добавить в документ или поле рандомные данные? Пожалуйста. Такой подход позволяет эффективнее работать с разреженными данными. Нереляционные БД можно поделить на два типа: сетевые и иерархические.

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

• Минусы: привязка к конкретной СУБД, ограниченность языков запросов и API, в процессе разработки базы данных могут случаться непредвиденные ошибки (так как схема БД не требуется изначально), миграция с одной БД NoSQL на другую БД NoSQL может стать квестом с препятствиями, понадобятся проприетарные инструменты для работы с БД;

• Примеры: MongoDB, CouchDB, GemFire, Cassandra.

Подытожу: Приставка No в NoSQL, а также фундаментальные различия с SQL могут навести вас на мысль, что системные архитекторы терзают себя муками выбора. Но на самом деле эти типы БД решают разные задачи.

SQL — ваш выбор, если вы будете работать со структурированными данным;

NoSQL — ваш выбор, если данные будут неструктурированными.

Вопрос 2: Как выбрать сервер баз данных?

Когда определена задача, которую будет решать ваш сервер, можно приступить к конфигурированию. Я очень советую придерживаться принципа “больше — лучше”, но без фанатизма, конечно. Во-первых, невозможно сделать идеальный прогноз на 5-10 лет, так как бизнес по определению должен непрерывно меняться и подстраиваться под конъюнктуру меняющегося рынка — слишком много переменных. А во-вторых, цена ошибки может быть дороже, чем переплата за дополнительный запас производительности в 20-30%.

Конкретные моменты по конфигурированию сервера:

1) Дисковая подсистема — это главное

В 2014 году количество сайтов перевалило за 1 миллиард, а сегодня их почти 2 миллиарда. Неплохо, да? Как вы уже поняли, вместе с количеством сайтов растёт и объём данных в интернете. Он увеличивается приблизительно на 30% каждый год. Если 2019 года весь интернет весил приблизительно 33 миллиарда ТБ (33 зеттабайта), то по прогнозам IDC к 2025 году эта цифра вырастет до 175 зеттабайт.

Именно это я имел ввиду, когда говорил о “больше — лучше”. На плечах дисковой подсистемы сервера находится скорость, надёжность и эффективность хранения и передачи информации. А нагрузка будет перманентно расти. Поэтому, если мы говорим о сервере баз данных, то дисковая подсистема требует тщательной проработки.

Из чего она состоит (основные моменты):

• Любые виды накопителей — HDD, SSD и другие, на которых хранится информация. От выбора накопителей будет зависеть общий объем хранилища, а также скорость работы с данными.

• Дисковые контроллеры — это могут быть как RAID-контроллеры, так и only JBOD контроллеры. Задача контроллеров — “руководить” всеми дисками сервера, проверять их на существующие и возможные неисправности (битые сектора, износ), организовывать массивы и многое другое. От выбора/наличия контроллера будет зависеть безопасность ваших данных, стабильность системы а также скорость чтения/записи.

• Дисковая корзина — место в сервере, где размещаются диски. Одна и та же модель сервера может комплектоваться разными дисковыми корзинами: под SFF (2.5-дюймовые) и LFF (3.5-дюймовые) диски; корзина под 8 дисков, под 24 и т.д. От выбора корзины будет зависеть, сколько и какой памяти вы сможете установить в сервер.

• Интерфейсы — накопители и дисковые контроллеры “общаются” по шинам и интерфейсам. Наиболее распространённые: SATA, SAS и NVMe. Например, интерфейс SATA даже в последней ревизии 3.5 не может в полной мере раскрыть производительность SSD накопителей, что важно учесть при выборе сервера.

Для максимальной производительности используют NVMe SSD накопители, организованные в RAID-массивы с помощью новых дисковых контроллеров в последних поколениях серверов. А для нетребовательных к скорости чтения данных чаще всего выбирают HDD из-за относительно невысокой стоимости.

2) Сетевые интерфейсы

Интерфейсы и шины дисковой подсистемы важны при внутреннем “общении” сервера, но так как система баз данных может включать в себя целый комплекс устройств, то не менее важны и сетевые интерфейсы. В целом, сетевых возможностей серверов последних поколений более чем достаточно, чтобы решать задачи SMB. Но иногда сетевая карта “из коробки” (2 или 4 гигабитных порта) не справляется. Поэтому исходите от задачи, но 10-гигабитная карта почти наверняка закроет все ваши потребности в обозримом будущем.

3) ОЗУ

Красным выделены планки оперативной памяти, установленные в сервер.

Объем и скорость оперативной памяти будут напрямую влиять на производительность сервера баз данных. Чем современнее поколение сервера и процессора, тем выше они поддерживают скорость ОЗУ. Но объем памяти надо рассчитывать, исходя из архитектуры (вдруг вы планируете виртуальный сервер) и характера нагрузки: количества пользователей, которые будут работать с БД, сколько запросов в секунду получает сервер при рабочей нагрузке, какие дисковые очереди получаются. То есть нужен детальный анализ системы. 

Для максимальной производительности выбирают быструю память, последние поколения серверов, а также серверные базы, в которые можно установить много планок ОЗУ (для масштабирования в будущем). А также анализ всей системы, тесты и ещё раз тесты.

4) ЦПУ

СPU 1 и CPU 2 — это радиаторы для охлаждения 2-ух процессоров в высокоплотном блейд-сервере. 

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

Преимущества Intel Xeon Scalable 3 над 2-ым поколением:

• До 1.46x — среднее повышение производительности;

• До 1.60x — увеличение пропускной способности памяти;

• До 2.66x — увеличение максимального объема памяти;

• До 1.33x — больше PCIe линий на процессор.

Некоторые серверы поддерживают установку сразу нескольких процессоров (2, 4 и т.д.), для решения ресурсоемких задач или для масштабирования в будущем.

Чтобы получить передовую производительность с запасом на будущее, выбирают либо процессоры последних поколений, либо что-то из более высокого ценового сегмента в прошлом поколении.

Информационная безопасность — это головная боль миллионов специалистов, инженеров и системных архитекторов по всему миру. Киберпреступления с каждым годом учащаются, а главная проблема заключается в трилемме безопасности, функциональности и доступности (так называемый парадокс Андерсона):

• Чем безопаснее база данных, тем она менее функциональна и доступна для конечного пользователя;

• Чем функциональнее и доступнее база данных, тем она менее защищена.

Поэтому безопасность базы данных — это во многом компромисс. Но решать его нужно, чтобы не оказаться в неприятной ситуации, как Facebook (Meta) и другие компании, когда личные данные тысяч и миллионов пользователей утекают в сеть. А всё что попадает в сеть, как известно, остаётся там навсегда.

Что ж, безопасность — мера комплексная и организуется сразу на нескольких уровнях:

• Безопасность на физическом уровне 

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

• Ограничение прав и контроль доступа

Чтобы обеспечить максимальную безопасность, нужно выдавать доступ к базе данных только тем пользователям, которым он действительно необходим. При этом права нужно ограничить до минимального набора, необходимого для выполнения задач. Помните парадокс Андерсона? Он самый во всей красе.

• Мониторинг

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

• Шифрование

В эпоху киберпреступлений процветает снифферинг (от англ. sniff “нюхать”) — хищение данных. Поэтому все хранящиеся и передаваемые данные нужно защищать шифрованием. При этом очень важно соблюдать правила по управлению ключами шифрования (Encryption Key Management). Потеряете ключи — потеряете данные.

• Безопасность ПО базы данных

Есть пользователи, которые используют пиратские и (или) неактуальные версии софта. Патчи безопасности выпускают не для того, чтобы замучить сисадмина обновлениями. 

• Безопасность узлов

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

• Безопасность резервных копий

Зачастую все силы по обеспечению безопасности вкладываются в основную систему, но не стоит забывать про резервные копии. Доступ злоумышленников к ним может причинить не меньший вред и ущерб предприятию. 

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

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

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

Выбор железа всегда происходит от задачи. Параметров много, но особое внимание нужно уделить дисковой подсистеме, сетевым параметра, ОЗУ и, разумеется, ЦПУ.

И не забывайте про безопасность — это убережёт вас и ваши данные от многих проблем.