Как и обычные системы управления базами данных, системы управления распределенными базами данных также хранят данные. Тем не менее, единственный момент заключается в том, что они распределяют и реплицируют данные на нескольких машинах, пытаясь удовлетворить аспекты доступности, надежности, производительности крупных организаций, нормативных требований и требований к масштабированию.
Таким образом, распределенная база данных делает две вещи:
- Распределение: размещение разделов данных на разных машинах.
- Репликация: размещение копий данных на разных машинах.
Конечная цель состоит в том, чтобы обеспечить ту же функциональность и транзакционную семантику, что и РСУБД с распределенными функциями. Но суровая реальность такова, что есть уступки с точки зрения функциональности, семантики транзакций и производительности.
Обратите внимание, что сегмент — это горизонтальный раздел данных в базе данных.
Распределенные базы данных сталкиваются с тремя серьезными проблемами:
- Как распространять данные
- Как получить доступ к распределенным данным
- Как выполнять транзакции с распределенными данными
В этой статье в основном речь пойдет о первой проблеме распространения данных.
А) Распределение диапазонов:
В этом типе таблицы секционируются по ключу распределения, который обычно является частью первичного ключа. Кроме того, каждый из осколков содержит диапазон значений.
Это можно понять на следующем примере — представьте себе таблицу EMPLOYEE, распределенную по трем серверным машинам, где на первой машине мы храним всех сотрудников с именами, начинающимися с буквы в диапазоне A-J, а на других устройствах с K-T, а затем U-Z, как показано на диаграмме ниже.
Допустим, в компанию приходит сотрудник по имени Самуэль. Его запись будет храниться во втором шарде второго узла.
Этот метод работает только для простых (буквенно-цифровых данных). Для хранения сложных данных нам необходимо использовать другие методы распределения данных.
Б) Распределение хэша:
Этот тип предназначен для хранения модуля хеш-значения или диапазона хеш-значений в каждом сегменте.
- Хранить хеш-значение — ужасная идея, так как шард может быстро заполниться, и нам нужно будет разделить данные на несколько серверов.
- Хранение диапазона хеш-значений лучше, поскольку осколки могут не заполняться так быстро, как при предыдущем способе распределения хэшей.
Продолжая наш предыдущий пример: рассмотрение хэш-функции
#storing into 3 nodes h(x) = (2(x) + 5) % 6 #where x = employee_id
Давайте рассмотрим первый employee_id как 100. Хэш-функция возвращает значение: (2*100 + 5) % 6 => 205 % 6 => 1. Таким образом, запись сохраняется во втором сегменте первого узла (при условии, что узлы 0 по модулю, т. е. когда h(x) возвращает 0 (первый узел — первый осколок), 1 (первый узел — второй осколок) и когда он возвращает 2 (второй узел — первый осколок) и так далее.
#storing into 3 nodes h(x) = (2(x) + 5) % 30 #where x = employee_id
Расширение этого для хранения диапазона хеш-значений: хеш-функция на этот раз возвращает (2*100+5) % 30 => 205 % 30 => 25. Таким образом, запись сохраняется в третьем узле (поскольку первый будет иметь диапазон значений от 0 до 9, второй сегмент от 10 до 19 и третий сегмент от 20 до 29).
Как бы очевидно это ни казалось, второй метод сочетает в себе методы диапазона и простого распределения хэшей.
В) Ребалансировка:
Всякий раз, когда появляется точка распространения данных, желательно поддерживать примерно одинаковый объем данных в каждом шарде. Для этого можно использовать стратегию ребалансировки. Он может обеспечить эффективность двумя способами: либо перемещением сегментов, либо разделением сегментов для лучшего распределения данных по сегментам.
Это довольно просто понять, как показано на рисунках ниже.
D) Распределение по совместному размещению:
Этот тип стратегии распределения данных основан на идее, что некоторые таблицы имеют общие атрибуты. Предположим, что общий атрибут связан с ключом распределения. В этом случае мы можем хранить разные таблицы распределенным образом, таким образом, если мы выполним соединение между этими таблицами, используя этот атрибут. Таким образом, мы минимизируем взаимодействие между таблицами из разных узлов.
Как видно из изображения выше, эта стратегия хранит сотрудников и их менеджеров (при условии, что у них есть общие атрибуты — один и тот же отдел, один этаж, одна и та же лаборатория и т. д.) в одних и тех же узлах для быстрого доступа с использованием внешнего ключа менеджера от сотрудника. стол.
E) Распределение справочной таблицы:
Как и в предыдущей стратегии, распределенные соединения могут повысить производительность за счет репликации небольших таблиц (таблиц с меньшим количеством записей или наиболее часто используемых таблиц), которые позволяют выполнять быстрые соединения с использованием внешних ключей.
Используя наш текущий пример, давайте рассмотрим две таблицы: сотрудников и отделов. Учитывая, что таблица отделов маленькая, отделов всего три (почти застойные, редко модифицируемые), она реплицируется и хранится во всех шардах сотрудников.
Таблица сотрудников имеет ссылку внешнего ключа на таблицу отделов, поэтому объединение их с помощью этой стратегии полезно.
Подводя итог, можно использовать одну или несколько стратегий распределения данных для практики распределения данных по нескольким серверам для достижения эффективности, производительности, доступности и надежности.
Также существуют некоторые другие формы распределения данных, отличные от описанных выше, например случайное распределение (при котором данные распределяются между узлами и осколками случайным образом) или пространственное распределение (при котором расположение данных в осколках имеет особое значение) и т. д.
Спасибо за чтение! Подписывайтесь и делитесь со всеми в вашем сообществе, и не забывайте ставить лайки и комментировать. Подпишитесь на мою страницу на Medium, Ришика Гупта.
