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

Привет!

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

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

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

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

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

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

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

Самая наглядная аналогия реляционным (табличным) базам данных — это крупная классическая библиотека с бумажными книгами.

• Книжные стойки — это таблицы базы данных.

• Книжные полки — это столбцы (атрибуты).

• Конкретные книги — это отдельные записи (строки). 

Всё это имеет строгую логику, структуру и связано между собой. Все литературные произведения поделены по эпохам, странам, жанрам и авторам. При этом в соседней секции хранение книг может быть организовано иначе (это аналог другой базы данных — например, NoSQL или векторной, «заточенной» под ИИ-модели).

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

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

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

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

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

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

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

Начнём с глоссария, а следом к простой аналогии.

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

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

Когда большое приложение работает с данными, ему необходимы инструкции, логика и API. Да, можно хранить данные просто в памяти, как на вашем ПК. Можно даже использовать обычный текстовый файл — например, CSV, JSON или XML. По сути, это тоже хранилище данных, а в простейших сценариях его можно считать примитивной базой данных. Для небольших объёмов информации и однопользовательских приложений этого часто достаточно. Но как только появляются постоянные чтение, запись, обновление данных, несколько пользователей или большие объёмы информации, работать с такими файлами становится неудобно и медленно. СУБД как раз решает эти проблемы, предоставляя быстрый поиск, механизмы параллельного доступа, транзакции и множество других возможностей, например, умеют распределять нагрузку между несколькими серверами, выполнять репликацию, автоматически переключаться на резервные узлы при отказах, работать с десятками терабайт данных и обслуживать сотни тысяч одновременных пользователей.

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

Итого:

• База данных (БД) — это само структурированное хранилище (информация).

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

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

И теперь кратко про систему баз данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выбор конфигурации сервера баз данных

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

Когда определена задача, которую будет решать ваш сервер, можно приступить к конфигурированию. Я очень советую придерживаться принципа “больше — лучше”, но без фанатизма, конечно. Во-первых, невозможно сделать идеальный прогноз на 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 накопителей, что важно учесть при выборе сервера.

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

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

3) Оперативная память (RAM)

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

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

4) Процессор (CPU)

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

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

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

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

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

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

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

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

Характеристики серверов под популярные БД

Дальше мы рассмотрим примерные характеристики серверов под популярные СУБД: Microsoft SQL, MySQL, SQL и PostgreSQL.

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

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

Сервер для Microsoft SQL Server

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

Для установки и запуска Microsoft SQL Server на сервере рекомендуется следующие минимальные характеристики:

• Процессор с тактовой частотой не менее 1,4 ГГц (рекомендуется 2,0 ГГц и выше).

• Оперативная память не менее 1 Гб (рекомендуется 4 Гб и выше).

• Накопитель объёмом не менее 6 Гб для установки SQL Server и дополнительного места для хранения данных.

• Операционная система Windows Server 2012 или выше.

Однако, для обеспечения высокой производительности и надёжности базы данных Microsoft SQL Server рекомендуется использовать сервер с более продвинутыми характеристиками, например:

• Процессор с частотой не менее 2,0 ГГц и не менее 4 ядер (рекомендуется использовать многоядерные процессоры).

• Оперативная память не менее 16 Гб (рекомендуется 32 Гб и выше).

• Наличие RAID-массивов для обеспечения отказоустойчивости и скорости доступа к данным.

• Сетевой интерфейс с высокой пропускной способностью для обеспечения быстрого доступа к базе данных.

• Операционная система Windows Server 2012 или выше, оптимизированная для работы с Microsoft SQL Server.

Кроме того, рекомендуется правильно настроить параметры конфигурации Microsoft SQL Server для достижения наилучшей производительности и надёжности базы данных. Например, можно настроить буферизацию запросов, настройки кэша, оптимизацию запросов и другие параметры, учитывая специфику работы вашей базы данных.

Сервер для MySQL

MySQL — это свободная реляционная база данных, разработанная компанией Oracle. Это одна из самых популярных реляционных СУБД с открытым исходным кодом. Она широко используется во многих приложениях, таких как блоги, интернет-магазины и форумы. Она используется во многих веб-приложениях и сайтах, в том числе в WordPress, Joomla и Drupal.

Для установки и запуска MySQL на сервере рекомендуется следующие минимальные характеристики:

• Процессор с тактовой частотой не менее 1 ГГц (рекомендуется 2 ГГц и выше).

• Оперативная память не менее 1 Гб (рекомендуется 4 Гб и выше).

• Накопитель объёмом не менее 1 Гб для установки MySQL, а для хранения данных рекомендуется использовать дополнительный накопитель или RAID-массивы.

• Операционная система семейства Linux, Windows или macOS.

• Установленный MySQL с необходимыми драйверами и инструментами для работы с базой данных.

Однако, для обеспечения высокой производительности и надёжности базы данных MySQL рекомендуется использовать сервер с более высокими характеристиками, например:

• Процессор с частотой не менее 2 ГГц и не менее 2 ядер (рекомендуется использовать многоядерные процессоры).

• Оперативная память не менее 8 Гб (рекомендуется 16 Гб и выше).

• Наличие RAID-массивов для обеспечения отказоустойчивости и скорости доступа к данным.

• Сетевой интерфейс с высокой пропускной способностью для обеспечения быстрого доступа к базе данных.

• Операционная система семейства Linux, Windows или macOS, оптимизированная для работы с MySQL.

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

Сервер для PostgreSQL

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

Для PostgreSQL рекомендуемые минимальные характеристики сервера зависят от того, какой объем данных будет обрабатываться и сколько пользователей будет иметь доступ к базе данных. 

В целом, для установки PostgreSQL на сервер требуется следующее:

• Процессор с тактовой частотой не менее 1 ГГц (рекомендуется 2 ГГц и выше).

• Оперативная память не менее 1 Гб (рекомендуется 4 Гб и выше).

• Накопитель объёмом не менее 10 Гб (рекомендуется использовать RAID-массивы для обеспечения отказоустойчивости и скорости доступа к данным).

• Операционная система семейства Linux, Windows или macOS.

• Установленный PostgreSQL с необходимыми драйверами и инструментами для работы с базой данных.

Для обеспечения высокой производительности и доступности базы данных PostgreSQL рекомендуется использовать сервер с более высокими характеристиками, например:

• Процессор с частотой не менее 2 ГГц и не менее 2 ядер (рекомендуется использовать многоядерные процессоры).

• Оперативная память не менее 8 Гб (рекомендуется 16 Гб и выше).

• Наличие RAID-массивов для обеспечения отказоустойчивости и скорости доступа к данным.

• Сетевой интерфейс с высокой пропускной способностью для обеспечения быстрого доступа к базе данных.

• Операционная система семейства Linux, Windows или macOS, оптимизированная для работы с PostgreSQL.

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

Характеристики серверов БД по количеству пользователей

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

Фактические требования зависят от конкретной реализации базы данных, количества и типа запросов, ресурсов приложения и других факторов (например, версий ПО).

MySQL

Важно:

• MySQL может быть установлен на разных операционных системах, включая Windows, Linux и MacOS;

• MySQL требует меньше оперативной памяти и процессорных ресурсов, чем SQL Server, но больше, чем некоторые другие СУБД с открытым исходным кодом;

• MySQL обычно хранит данные в файловой системе, что может привести к быстрому заполнению накопителя. Поэтому для MySQL также рекомендуется использовать RAID-массивы для обеспечения надёжности и доступности данных;

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

• Чтобы подобрать оптимальный сервер под вашу задачу, обращайтесь к менеджерам Servermall. Сделают всё в лучшем виде — быстро и бесплатно.

Microsoft SQL Server

Важно:

• Microsoft SQL Server требует много оперативной памяти и процессорных ресурсов для обработки больших объемов данных и нагрузки от многопользовательских приложений;

• Microsoft SQL Server предоставляет функции высокой доступности и отказоустойчивости, включая кластеризацию серверов и репликацию данных;

• Microsoft SQL Server требует много дискового пространства для хранения данных. Рекомендуется использовать RAID-массивы для обеспечения надежности и доступности данных;

• Microsoft SQL Server поддерживает множество функций для управления данными, таких как полнотекстовый поиск, географические данные и хранимые процедуры;

• Чтобы подобрать оптимальный сервер под вашу задачу, обращайтесь к менеджерам СЕРВЕР МОЛЛ. Сделают всё в лучшем виде — быстро и бесплатно.

PostgreSQL

Важно:

• PostgreSQL может быть установлен на разных операционных системах, включая Windows, Linux и MacOS;

• PostgreSQL требует много оперативной памяти и процессорных ресурсов для обработки больших объемов данных и многопользовательской нагрузки;

• PostgreSQL предоставляет мощные функции для управления данными, такие как JSON-хранилище, географические данные и расширяемость через хранимые процедуры;

• PostgreSQL хранит данные в файлах, что может привести к быстрому заполнению накопителя. Поэтому для PostgreSQL также рекомендуется использовать RAID-массивы для обеспечения надежности и доступности данных;

• Чтобы подобрать оптимальный сервер под вашу задачу, обращайтесь к менеджерам СЕРВЕР МОЛЛ. Сделают всё в лучшем виде — быстро и бесплатно.

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

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

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

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

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

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

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

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

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

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

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

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

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

Что в итоге?

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

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

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

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

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