Шардинг с помощью хэш-партиционирования

1 ВВЕДЕНИЕ

С началом XXI века требования к веб-приложениям значительно возросли. Технологии Web 2.0 сделали веб-приложения гораздо более привлекательными благодаря улучшению их интерактивности. Появился целый ряд новых приложений: например, социальные сети, приложения для обмена мультимедиа и онлайн-офисные пакеты. Эти новые приложения привлекли огромное количество пользователей, многие из которых перешли с локальных приложений на онлайн-приложения. Одновременно многие компании разработали приложения на основе SOA, упрощающие интеграцию между различными системами и расширяющие повторное использование функций через сервисы. В этом сценарии были разработаны новые функции интеграции, и приложения начали обмениваться большими объемами данных.

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

Системы баз данных могут масштабироваться как вертикально, так и горизонтально. Вертикальное масштабирование подразумевает использование более мощных машин, большего количества процессоров, дискового пространства и памяти. Вертикальное масштабирование сервера баз данных не всегда возможно из-за высокой стоимости приобретения всех этих ресурсов, а также физических и практических ограничений. Альтернативой является вертикальное масштабирование системы баз данных, которое заключается в объединении нескольких небольших машин в кластер (Сэдэлидж и Фаулер, 2013). Для увеличения емкости кластера по запросу добавляется стандартное оборудование. Относительно новая, но быстро получившая распространение технология облачных вычислений сделала необходимую инфраструктуру для горизонтального масштабирования систем более доступной.

После того, как база данных будет иметь необходимую инфраструктуру для работы в большом кластере, необходимо выбрать модель распределения, основанную на требованиях приложения. Приложению может потребоваться масштабируемость чтения, записи или и то, и другое. По сути, существует две модели распределения: репликация и шардинг. Первая модель копирует одни и те же данные на несколько узлов, а вторая размещает разные данные на разных узлах (Sadalage and Fowler, 2013). Оба подхода ортогональны и могут использоваться совместно.

В данной статье рассматриваются модели распределения шардинга баз данных, в частности, метод, известный как хэш-партиционирование. Целью данной работы является каталогизация в формате шаблона масштабируемости баз данных (Database Scalability Pattern) наилучшей практики, заключающейся в шардинге данных между узлами кластера баз данных с использованием техники хэш-партиционирования для оптимальной балансировки нагрузки между серверами баз данных. Этот шаблон позволяет избежать создания «горячих точек», то есть областей данных, в которых операции чтения и записи сосредоточены в одном узле или группе узлов. Этот метод шардинга встроен в некоторые NoSQL-базы данных, такие как AmazonDB (DeCandia et al., 2007) и MongoDB (Boicea et al., 2012), а также в фреймворки ORM для реляционных баз данных, например, EclipseLink (Kalotra and Kaur, 2014) и Hibernate Shards (Wu and Yin, 2010). Наш главный вклад заключается в том, чтобы сделать общедоступной сопоставление сценария и его решения, помогая разработчикам определять, когда следует применять хэш-разбиение в сегментированных кластерах вместо других методов сегментирования.

Остальная часть статьи структурирована следующим образом. В разделе 2 представлена ​​предыстория, а в разделе 3 обсуждаются основные работы, связанные с данной темой. В разделе 4 модель описана с использованием формата, предложенного Хопе и Б. Вульфом (Hohpe and B.Woolf, 2003), который используется для обозначения подразделов модели. Наконец, в разделе 5 представлены выводы и дальнейшие исследования.

2 ИСТОРИЯ

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

В работе Элмасри и Навате (Elmasri and Navathe, 2011) распределенные системы баз данных определяются как совокупность нескольких логически взаимосвязанных баз данных, распределенных по компьютерной сети, а распределенная система управления базами данных (РСУБД) — как программная система, которая управляет распределенной базой данных, делая распределение прозрачным для пользователя. В этой архитектуре отсутствуют общие аппаратные ресурсы, и узлы могут иметь разные аппаратные конфигурации. Параллельные системы управления базами данных объединяют несколько меньших машин для достижения той же пропускной способности, что и одна большая машина, часто с большей масштабируемостью и надежностью, чем однопроцессорная система управления базами данных (Connolly and Begg, 2005). Однако несколько процессоров используют либо общую память (дисковое хранилище и основную память), либо только дисковую память (в этом случае каждый процессор имеет свою собственную основную память).

Многие поставщики баз данных предлагают решения для масштабирования, основанные на подходе с общим диском, например, Oracle RAC (Abramson et al., 2009). Такие решения связывают несколько серверов высокоскоростной сетью, но у них всё равно есть ограничивающее устройство. Они используют общее устройство хранения данных, которое является узким местом системы. В параллельной архитектуре без общего доступа процессоры взаимодействуют через высокоскоростную сеть, и у каждого из них есть своя основная и вторичная память. Такой тип архитектуры требует симметрии узлов и однородности, но в полностью распределённой базе данных однородность системы не требуется. Для достижения настоящей горизонтальной масштабируемости необходимо использовать архитектуру полностью распределённой системы баз данных.

2.1 Модели распределения

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

2.1.1 Репликация

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

2.1.2 Шардинг

Шардинг — это способ горизонтального масштабирования базы данных посредством горизонтальной фрагментации. Горизонтальный фрагмент отношения (таблицы) представляет собой подмножество кортежей в этом отношении. Кортежи, принадлежащие горизонтальному фрагменту, определяются условием для одного или нескольких атрибутов отношения (Elmasri and Navathe, 2011). Часто используется только один атрибут. То есть горизонтальная масштабируемость поддерживается размещением различных частей данных на разных серверах кластера. Цель состоит в том, чтобы разные клиенты взаимодействовали с разными узлами сервера. Следовательно, нагрузка равномерно распределяется между серверами. Шардинг особенно ценен для производительности, поскольку он может повысить производительность как чтения, так и записи. Репликация может значительно повысить производительность чтения, но малоэффективна для приложений, выполняющих несколько операций записи. Шардинг обеспечивает горизонтальное масштабирование этих операций.

2.1.3 Стратегии разбиения (партицирования)

Существует четыре различных стратегии разбиения данных в кластере: циклическое разбиение, разбиение по диапазону, разбиение по списку и разбиение по хэшу (DeWitt and Gray, 1992). Простейшей стратегией разбиения является циклическое разбиение, при котором строки таблицы распределяются между узлами циклически (рис. 1a).

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

Списочная стратегия аналогична стратегии разбиения по диапазону. В первой разбиение имеет список значений, назначенных по одному. Раздел выбирается для сохранения строки, если значение ключа разбиения равно одному из значений, определённых в списке (рис. 1c). В последнем случае сопоставление значений ключа разбиения с соответствующими узлами осуществляется на основе результата хэш-функции. Значение ключа разбиения используется в качестве параметра хэш-функции, а результат определяет место размещения данных (рис. 1d).

3 СОПУТСТВУЮЩИЕ РАБОТЫ

Каталог шаблонов проектирования программного обеспечения был впервые описан Гаммой и др. (Gamma et al., 1994), пионером в области компьютерных наук. Впоследствии Фаулер и др. (Fowler et al., 2002) и Хопе и Б. Вульф (Hohpe and B.Woolf, 2003) выявили и опубликовали архитектурные шаблоны проектирования программного обеспечения.

Шумахер и др. (Shumacher et al., 2006) представляют в формате шаблонов набор передовых практик для повышения безопасности приложений на разных уровнях. Хафиз (Hafiz, 2006) описывает четыре шаблона проектирования, применимых к проектированию систем анонимности и которые могут быть использованы для защиты конфиденциальных данных. Шумахер (Shumacher, 2003) представляет подход к извлечению шаблонов безопасности из стандартов безопасности и представляет два шаблона для анонимности и конфиденциальности. Штраух и др. (Strauch et al., 2012) описывают четыре шаблона, обеспечивающих конфиденциальность данных в облаке.

Авторы (Eessaar, 2008) предлагают подход к проектированию и реализации баз данных на основе шаблонов, который способствует использованию шаблонов в качестве основы для генерации кода. Кроме того, они представляют программную систему, которая генерирует код на основе шаблонов проектирования баз данных. Однако в их работе не перечислены шаблоны проектирования баз данных, на которых основан предлагаемый инструмент, и не упоминаются шаблоны проектирования, относящиеся к распределенным системам баз данных.

Таблица 2. Распространенные ключи хэширования разбиения и их эффективность

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

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

Паллман (Паллман, 2011) представляет набор шаблонов, реализованных в облачной платформе Microsoft Azure, и описывает пять шаблонов хранения данных, которые могут быть использованы для хранения данных, ориентированных на записи. В статье (Го, 2014) шаблон «Ключ раздела» описывает распределение данных в Azure на высоком уровне, не определяя стратегию, используемую для фактического разделения данных. Шаблон, описанный в нашей статье, фокусируется на стратегии, используемой для распределения данных, и не ориентирован на платформу какого-либо поставщика.

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

Стоунбрейкер и Кэттел (Stonebraker and Cattell, 2011) предлагают десять правил для достижения масштабируемости в хранилищах данных, обрабатывающих простые операции. В ходе обсуждения этих правил авторы указывают на важные недостатки шардинга данных в конкретных ситуациях. Наблюдения Стоунбрейкера и Кэттела (Stonebraker and Cattell, 2011) сыграли важную роль в построении шаблона, представленного в данной работе.

В дополнение к четырём шаблонам конфиденциальности, Штраух и др. (Strauch et al., 2012) также предлагают два шаблона, связанных с горизонтальной масштабируемостью уровня доступа к данным приложения: «Локальный прокси-сервер базы данных» и «Локальный маршрутизатор на основе шардинга». Шаблон «Локальный маршрутизатор на основе шардинга» предполагает расширение уровня доступа к данным за счёт добавления маршрутизатора, отвечающего за распределение запросов на чтение и запись между серверами баз данных. Каждый сервер баз данных в кластере хранит часть данных, разделенных с использованием той или иной техники шардинга. Тем не менее, этот шаблон не предполагает какой-либо конкретной стратегии шардинга данных. Его можно использовать в качестве дополнения к предлагаемому нами шаблону для реализации стратегии чтения и записи после внедрения описанного здесь шаблона.

4 Шардинг с помощью хэш-партиционирования

Целью паттерна масштабирования базы данных «Шардирование по хэш-партиционированию» является максимально равномерное распределение функциональной группы между узлами кластера с использованием метода шардинга. Желаемым результатом является равномерное распределение нагрузки, генерируемой клиентскими запросами, между серверами баз данных.

4.1 Контекст

Методы масштабирования используются для повышения производительности систем баз данных. Архитектура «ведущий/ведомый» обеспечивает масштабируемость по чтению, но не слишком полезна для приложений с высокой интенсивностью записи. Для достижения общей масштабируемости чтения и записи следует использовать метод шардинга. Однако системы без общего доступа масштабируются только в том случае, если объекты данных распределены по узлам системы таким образом, чтобы обеспечить балансировку нагрузки (Stonebraker и Cattell, 2011).

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

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

4.2 Задача

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

4.3 Силы

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

Избыточный трафик может возникать в системах баз данных, где размещение данных не было тщательно выбрано разработчиком (Zilio et al., 1994). При использовании стратегии шардинга по круговой схеме данные распределяются без учёта их атрибутов. Реестры, которые обычно агрегируются для формирования результата запроса, могут быть разбросаны по узлам, что приводит к увеличению трафика данных.

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

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

4.4 Решение

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

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

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

4.5 Результаты

Размещение данных крайне важно в параллельных системах баз данных, не требующих совместного использования ресурсов. Оно должно обеспечивать параллелизм и минимизировать коммуникационные издержки (Zilio et al., 1994). Системы, агрегирующие необходимую информацию только в одном реестре, лучше всего подходят для такого подхода, поскольку он минимизирует сетевой трафик. Поэтому важно максимально избегать многошардных операций, включая запросы, направленные на несколько шардов, а также многошардных обновлений, требующих свойств ACID (Stonebraker and Cattell, 2011). Таким образом, шардирование данных между узлами кластера лучше всего подходит для приложений, не требующих соединений между таблицами базы данных.

Если хеш-партиционирование необходимо полностью реализовать на уровне доступа к данным приложения, необходимо выбрать алгоритм и хеш-функцию для реализации метода хеш-партиционирования. Например, MD5 (Rivest, 1992) может быть реализацией хеш-функции, а алгоритм Consistent Hashing (Karger et al., 1997) может использоваться для распределения и поиска данных в кластере. Инструменты, реализующие этот шаблон, такие как некоторые хранилища данных NoSQL, изначально поддерживающие шардинг, и некоторые фреймворки персистентности, уже имеют реализованный алгоритм.

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

4.6 Дальше

Облачные хранилища данных предоставляют необходимую инфраструктуру для масштабирования с меньшими затратами и упрощенным управлением. Однако большинство облачных реляционных баз данных не реализуют шаблон шардинга по хэш-партиционированию. Более того, они не поддерживают шардинг изначально. В таких случаях функциональность хранилища данных может быть расширена путем реализации шаблона на уровне доступа к данным приложения. Штраух и др. (Strauch et al., 2012) описывают шаблон «Локальный маршрутизатор на основе шардинга», который дополняет шаблон, описанный в этой статье. Шаблон «Локальный маршрутизатор на основе шардинга» предлагает дополнительный уровень, развернутый в облаке, отвечающий за реализацию шардинга в облачных хранилищах данных, которые изначально не поддерживают шардинг. Шаблон «Локальный маршрутизатор на основе шардинга» не предполагает какой-либо стратегии шардинга.

4.7 Сайдбары

Существуют хранилища данных NoSQL, такие как MongoDB (Liu et al., 2012) и DynamoDB (DeCandia et al., 2007), которые реализуют шаблон Sharding by Hash Partitioning. Эти хранилища данных можно использовать, если шаблон доступа приложения не требует соединений между различными таблицами и требует масштабируемости, обеспечиваемой шардингом данных, и балансировки рабочей нагрузки, обеспечиваемой хэш-партиционированием. То есть, если приложение выиграет от шаблона Sharding by Hash Partitioning и не нуждается в ограничениях отношений, предлагаемых реляционными базами данных, можно использовать упомянутые хранилища данных. В статье (DeCandia et al., 2007) описывается алгоритм хэш-партиционирования, используемый DynamoDB. Он является разновидностью алгоритма Consistent Hashing (Karger et al., 1997) и может быть использован в качестве справочного материала для реализации шаблона Sharding by Hash Partitioning при разработке фреймворка или на уровне доступа к данным приложения.

Реляционные базы данных поддерживают шардинг в архитектуре без совместного использования ресурсов (really nothing shared Architecture), но те, которые поддерживают, как правило, сложнее в обслуживании. Если приложению требуется шардировать данные с помощью хэш-партиционирования, но используемая реляционная база данных не предоставляет такую ​​возможность, можно использовать фреймворк, реализующий шаблон шардинга по хэш-ключу. EclipseLink реализует политику шардинга данных по хэш-ключу и может предоставлять эту возможность реляционным базам данных, не поддерживающим шардинг. В качестве альтернативы, его можно использовать, если разработчики не знают, как настроить базы данных с поддержкой шардинга.

В локальных приложениях, хранящих данные в облаке, если шаблон шардинга по хэш-партиционированию должен быть реализован на уровне доступа к данным, это должно быть сделано на стороне облака, чтобы избежать сетевых задержек при запросе более чем к одному узлу (Strauch et al., 2012).

4.8 Пример

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

Со временем таблица становится очень большой. ИТ-специалисты решают распределить данные таблицы по узлам кластера для повышения производительности и масштабируемости. Создаётся кластер, состоящий из трёх серверов баз данных. В первой попытке таблица секционируется хронологически, то есть настраивается секционирование по диапазону, основанное на дате транзакции. Сервер A хранит самые старые транзакции, а сервер C — самые последние (рисунок 2). Такая схема секционирования создаёт «горячие точки». Все новые реестры журналов транзакций хранятся на сервере C, и большинство клиентов банка просматривают свои последние транзакции, которые также хранятся на сервере C.

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

5 ВЫВОДЫ

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

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

Литература

1. Абрамсон И., Эбби М., Кори М. Дж., Малчер М. Oracle Database 11g. Руководство для начинающих [Oracle Database 11g. A Beginner’s Guide]. Oracle Press, 2009.
2. Адлер Б. Создание масштабируемых приложений в облаке. Референсная архитектура и лучшие практики [Building scalable applications in the cloud. Reference architecture and best practices]. 2011.
3. Бойча А., Радулеску Ф., Агапин Л. И. Сравнение MongoDB и Oracle [Mongodb vs oracle – database comparison] // Proceedings of the 2012 Third International Conference on Emerging Intelligent Data and Web Technologies. 2012. С. 330–335.
4. Коннолли Т. М., Бегг К. Е. Системы баз данных. Практический подход к проектированию, реализации и управлению [DATABASE SYSTEMS. A Practical Approach to Design, Implementation, and Management]. 4-е изд. Addison-Wesley, 2005.
5. Декандиа Дж., Хасторун Д., Джампани М. и др. Dynamo: высокодоступное хранилище типа ключ-значение от Amazon [Dynamo: amazon’s highly available key-value store] // Proceedings of Twenty-first ACM SIGOPS Symposium on Operating Systems Principles (SOSP ’07). Нью-Йорк : ACM, 2007. С. 205–220.
6. ДеВитт Д., Грей Дж. Параллельные системы баз данных: будущее высокопроизводительных СУБД [Parallel database systems: The future of high performance database systems] // Communications of the ACM. 1992. Т. 35, № 6. С. 85–98.
7. Эссаар Э. Проектирование и реализация баз данных на основе паттернов [On pattern-based database design and implementation] // Proceedings of the 2008 International Conference on Software Engineering Research, Management and Applications. 2008. С. 235–242.
8. Элмасри Р., Навате Ш. Б. Основы систем баз данных [Fundamentals of Database Systems]. 6-е изд. Addison-Wesley, 2011.
9. Фелинг К., Лейманн Ф., Реттер Р. и др. Язык архитектурных паттернов облачных приложений [An architectural pattern language of cloud-based applications] // Proceedings of the 18th Conference on Pattern Languages of Programs (PLoP ’11). Нью-Йорк : ACM, 2011. № 2. С. 1–11.
10. Фаулер М., Райс Д., Фёммель М. и др. Паттерны корпоративных приложений [Patterns of Enterprise Application Architecture]. Addison-Wesley, 2002.
11. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приёмы объектно-ориентированного проектирования. Паттерны проектирования [Design Patterns. Elements of Reusable Object-Oriented Software]. 1-е изд. Addison-Wesley, 1994.
12. Го Дж. Проектирование масштабируемой стратегии партиционирования для Azure Table Storage [Designing a scalable partitioning strategy for azure table storage] : электронный ресурс. Microsoft Docs, 2014. URL: http://msdn.microsoft.com/en-us/library/azure/hh508997.aspx (дата обращения: 20.10.2025).
13. Хафиз М. Коллекция паттернов обеспечения конфиденциальности [A collection of privacy design patterns] // Proceedings of the 2006 Conference on Pattern Languages of Programs (PLoP ’06). Нью-Йорк : ACM, 2006. № 7. С. 1–7.
14. Хопе Г., Вулф Б. Паттерны интеграции корпоративных приложений [Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions]. 1-е изд. Addison-Wesley, 2003.
15. Калотра М., Каур К. Анализ производительности повторно используемых программных систем [Performance analysis of reusable software systems] // 2014 5th International Conference on Confluence The Next Generation Information Technology Summit. 2014. С. 773–778.
16. Каргер Д., Леман Э., Лейтон Т. и др. Согласованное хеширование и случайные деревья: распределённые протоколы кэширования для устранения горячих точек во Всемирной паутине [Consistent hashing and random trees: Distributed caching protocols for relieving hot spots on the world wide web] // Proceedings of the Twenty-ninth Annual ACM Symposium on Theory of Computing (STOC ’97). Нью-Йорк : ACM, 1997. С. 654–663.
17. Лю Ю., Ван Ю., Цзинь Ю. Исследование улучшения автоматического шардирования MongoDB в облачной среде [Research on the improvement of mongodb auto-sharding in cloud environment] // Proceedings of the 7th International Conference on Computer Science and Education. 2012. С. 851–854.
18. Паллманн Д. Паттерны проектирования Windows Azure [Windows azure design patterns] : электронный ресурс. 2011. URL: http://neudesic.blob.core.windows.net/webpatterns/index.html (дата обращения: 20.10.2025).
19. Ривест Р. Алгоритм хеш-суммы сообщения MD5 [The md5 message-digest algorithm]. IETF RFC 1321, 1992.
20. Садалаге П. Дж., Фаулер М. NoSQL вкратце. Краткое руководство по миру полиглотной персистентности [NoSQL Distilled. A Brief Guide to the Emerging World of Polyglot Persistence]. 1-е изд. Addison-Wesley, 2013.
21. Шумахер М. Паттерны безопасности и стандарты безопасности — с избранными паттернами анонимности и конфиденциальности [Security patterns and security standards – with selected security patterns for anonymity and privacy] // European Conference on Pattern Languages of Programs. 2003.
22. Шумахер М., Фернандес-Бульони Э., Хайбертсон Д. и др. Паттерны безопасности: интеграция безопасности и системной инженерии [Security Patterns: Integrating Security and Systems Engineering]. Wiley, 2006.
23. Стоунбрейкер М., Каттелл Р. 10 правил масштабируемой производительности в хранилищах «простых операций» [10 rules for scalable performance in ‘simple operation’ datastores] // Communications of the ACM. 2011. Т. 54, № 6. С. 72–80.
24. Штраух С., Андрикопулос В., Брайтенбюхер У. и др. Нефункциональные паттерны слоя данных для облачных приложений [Non-functional data layer patterns for cloud applications] // 2012 IEEE 4th International Conference on Cloud Computing Technology and Science. 2012. С. 601–605.
25. Ву П., Инь К. Исследование применения технологии персистентности на основе Hibernate [Application research on a persistent technique based on hibernate] // International Conference on Computer Design and Applications. 2010. Т. 1. С. 629–631.
26. Зилио Д. К., Джингран А., Падманабхан С. Выбор ключа партиционирования для параллельной СУБД типа shared-nothing [Partitioning key selection for a shared-nothing parallel database system] : технический отчёт. IBM Research Division, Yorktown Heights, NY, 1994.