Учебник для понимания разделения базы данных

Опубликовано: 2022-11-05

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

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

Что такое разделение базы данных?

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

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

Иллюстрация, объясняющая сегментирование базы данных. — Пример шардинга. (Источник изображения: Analytics Vidhya)

Реализовать шардинг можно двумя способами — горизонтально и вертикально. Горизонтальное сегментирование делит таблицу на основе строк, а вертикальное сегментирование делит таблицы на основе столбцов.

В этом плане шардинг похож на партиционирование, которое делит большие таблицы на более мелкие.

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

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

Преимущества разделения базы данных

Ниже приведены некоторые преимущества сегментирования базы данных.

Улучшенное горизонтальное масштабирование

Вы можете масштабировать базу данных вертикально или горизонтально. Вертикальное масштабирование означает добавление к серверу дополнительных центральных процессоров (ЦП) и оперативной памяти (ОЗУ) для повышения производительности. Вертикальное масштабирование — полезное решение для небольших и средних баз данных. Однако по мере роста ваших данных вертикальное масштабирование становится невозможным. К одному серверу можно добавить только ограниченную мощность.

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

Более быстрое время ответа на запрос

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

Повышенная надежность в аварийных ситуациях

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

Недостатки шардинга

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

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

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

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

Шардинг архитектуры

Вы можете реализовать шардинг, используя три архитектуры:

Шардинг на основе ключей
Разделение на основе диапазона
Шардинг на основе каталогов

Выбранная вами архитектура зависит от вашего варианта использования.

Разделение на основе ключей

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

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

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

Разделение на основе диапазона

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

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

Например, вы можете использовать значение идентификатора пользователя в пользовательской базе данных в качестве ключа сегментирования. Вы можете хранить пользователей с идентификаторами от 0 до 2000 в одном сегменте, от 2000 до 4000 — в другом и так далее.

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

Разделение на основе каталогов

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

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

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

Разделение базы данных с помощью Kinsta

Большинство современных механизмов баз данных обеспечивают поддержку сегментирования базы данных. Одним из таких механизмов баз данных является MariaDB, коммерчески поддерживаемая версия MySQL. Это высокопроизводительная система баз данных с открытым исходным кодом, принятая такими компаниями, как IBM, GitHub и Wikimedia. Он также является частью стека высокопроизводительных серверов Kinsta.

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

Резюме

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

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

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