Как работает разделение данных в распределенных базах данных SQL

задняя часть база данных SQL Программа перевода самородков

Как работает разделение данных в распределенных базах данных SQL

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

Что такое шардинг данных?

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

Рисунок 1. Вертикальная и горизонтальная сегментация (Источник: Medium)

Зачем разбивать базу данных?

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

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

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

Подводные камни ручного шардинга

Для приложений с большими объемами данных полностью автоматизированное развертывание в сегментах, включающее построение таблиц и балансировку нагрузки, даст огромные преимущества. К сожалению, монолитные базы данных, такие как Oracle, PostgreSQL и MySQL, и даже некоторые более новые распределенные базы данных SQL, такие как Amazon Aurora, не поддерживают автоматическое сегментирование. Это означает, что если вы хотите продолжать использовать эти базы данных, вам придется выполнять сегментирование вручную на уровне приложения. Это сильно усложняет разработку. Чтобы знать, как распределяются ваши данные, вашему приложению нужен дополнительный набор кода сегментирования и нужно знать, откуда пришли данные. Вам также необходимо решить, какой метод сегментирования использовать, сколько сегментов вам в конечном итоге понадобится и сколько узлов вам нужно. Как только ваш бизнес изменится, метод сегментирования и первичный ключ сегментирования также должны измениться.

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

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

Часто используемая архитектура автоматического сегментирования

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

Шардинг на основе хэша

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

Рисунок 2. Сегментирование на основе хэша (источник: документация MongoDB)

сегментирование на основе диапазона

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

Рисунок 3. Сегментирование на основе диапазона

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

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

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

Шардинг по географическому признаку

При сегментировании на основе местоположения данные сегментируются в соответствии с персонализированными столбцами (значения в столбцах связаны с географическим положением), а разные сегменты назначаются соответствующим регионам. Например, с кластером, развернутым в США, Великобритании и Европе, мы можем разместить сегменты в соответствующем месте в соответствии с GDPR (Общий регламент защиты данных) на основе значения столбца Country_Code в таблице пользователей.

Шардинг в БД YugaByte

YugaByte DB — это высокопроизводительная распределенная база данных SQL с автоматическим сегментированием и высокой эластичностью, разработанная Google Spanner. В настоящее время он поддерживает сегментирование на основе хэшей по умолчанию. Это активно обновляемый проект, и позже в этом году будут добавлены функции сегментирования на основе географических данных и диапазонов. Каждый сегмент данных в БД YugaByte называется подтаблицей (таблеткой), и они размещаются на соответствующем сервере подтаблиц.

Шардинг на основе хэша

Для сегментирования на основе хэша таблица размещается в хеш-пространстве от 0x0000 до 0xFFFF (всего в диапазоне 2 байт), которое содержит около 64 КБ подтаблиц в очень больших наборах данных или кластерах. Давайте взглянем на таблицу с 16 сегментированными подтаблицами на рисунке 4. Здесь для размещения сегмента используется целое хеш-пространство размером 2 байта, которое разделено на 16 частей, каждая из которых соответствует подтаблице.

Рисунок 4: Шардинг на основе хэшей в YugaByte DB

В операциях чтения и записи первичные ключи первыми преобразуются во внутренние ключи и соответствующие им хэш-значения. Это делается путем сбора данных из доступных подтаблиц. (Рисунок 5)

Рисунок 5: Выбор подтаблицы для использования в Yugabyte DB

Например, как показано на рис. 6, теперь вы хотите вставить данные с ключом k и значением v в таблицу. Сначала будет вычислено хэш-значение на основе значения k ключа, а затем база данных будет запрашивать соответствующую подтаблицу и сервер подтаблиц. Наконец, запрос будет передан непосредственно на соответствующий сервер для обработки.

Рисунок 6: Сохранение значения k в базе данных YugaByte

сегментирование на основе диапазона

Таблицы SQL могут устанавливать автоинкремент и автодекремент в первом столбце первичного ключа. Это позволяет хранить данные в одном сегменте (т. е. в дочерней таблице) в предварительно выбранном порядке. В настоящее время команда проекта разрабатываетДинамическое разделение подтаблиц(на основе различных критериев, таких как границы области и нагрузки), иРасширенный синтаксис SQLэти функции.

Суммировать

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

Следующий шаг?

Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории