Сегментирование (базы данных)

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

Горизонтальное фрагментирование предоставляет множество преимуществ: разделение и распределение таблиц по нескольким серверам приводит к уменьшению общего количества строк в таблицах, что снижает размер индекса, а значит обычно повышает производительность поиска. Шард может быть размещён на отдельном оборудовании, а набор сегментов распределён по разным машинам, что обеспечивает масштабирование и рост производительности. Если сегментация оформляется согласно реальным признакам данных (например, клиенты из Европы и из Америки), то принадлежность строки к тому или иному сегменту становится очевидной, и запросы можно направлять только к нужному сегменту^[3].

На практике сегментирование — непростая задача. Исторически оно реализовывалось вручную, особенно если строки естественным образом группируются (как в примере с регионами клиентов), однако такой подход негибок. Поэтому развиваются автоматизированные средства поддержки сегментирования, а также инструменты для выделения кандидатов для отдельной сегментации. Одной из техник распределения нагрузки между многочисленными сервисами и серверами служит Согласованное хеширование^[4].

В распределённых системах сегментированный подход полезен для повышения производительности и надёжности. В 2010-х годах сегментирование вычислительных ресурсов, наряду с традиционной сегментацией данных, рассматривается как способ устранения узких мест по производительности и масштабируемости в блокчейн-технологиях^[5][6].

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

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

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

Такой подход роднит сегментирование с концепцией shared-nothing архитектуры: каждый сегмент работает в изолированной логической, физической или географической среде, не требуя общего доступа к несегментированным таблицам других сегментов^[7].

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

Для согласованности несегментированных таблиц требуется механизм оповещения и синхронизации между экземплярами схемы: возможны как полностью статические (read-only или пакетное обновление) решения, так и динамическая репликация, уменьшающая выгоды масштабируемости.

• Altibase реализует комбинированную архитектуру сегментирования (на стороне клиента и на стороне сервера), прозрачную для приложений.
• HBase (Apache) может сегментировать данные автоматически^[8].
• Elastic Database в Azure SQL Database реализует сегментацию для масштабирования уровня данных^[9].
• ClickHouse (OLAP СУБД с открытым исходным кодом) реализует сегментирование.
• Couchbase — сегментирует автоматически и прозрачно.
• CUBRID — поддерживает сегментирование с версии 9.0.
• IBM Db2 Data Partitioning Feature (MPP) — архитектура разделения данных на независимых узлах.
• DRDS (Distributed Relational Database Service) в составе Alibaba Cloud поддерживает горизонтальный и вертикальный шардинг^[10] и обслуживает распродажу «День холостяка»^[11].
• Elasticsearch (поисковый сервер для бизнеса) сегментирует данные^[12].
• IBM WebSphere eXtreme Scale — хранилище пар ключ-значение (NoSQL). Использует сегментирование для распределённой обработки и MapReduce-параллелизации^[13].
• Hibernate поддерживает сегментирование, но развитие прекращено с 2007 года^[14].^[15]
• IBM Informix поддерживает сегментирование с версии 12.1 xC1 (технология MACH11); с версии 12.10 xC2 обеспечена поддержка драйверов MongoDB, возможна работа с реляционными и NoSQL-таблицами, при этом сохраняются сегментирование, отказоустойчивость и свойства ACID^[16].^[17]
• Kdb+ — сегментирует с версии 2.0.
• MariaDB Spider — движок хранения, поддерживающий федерацию таблиц, сегментацию, транзакции XA, источники через ODBC. Встроен с версии MariaDB 10.0.4^[18].
• MonetDB — open-source колонночная СУБД, реализовала только для чтения сегментирование в версии July 2015^[19].
• MongoDB поддерживает сегментирование с версии 1.6.
• MySQL Cluster выполняет сегментирование автоматически и прозрачно на недорогом оборудовании, обеспечивая масштабирование без изменений в приложении^[20].
• MySQL Fabric (утилита MySQL) обеспечивает сегментирование^[21].
• Oracle Database — реализует сегментирование с версии 12c Release 2, сочетающее преимущества сегментирования с корпоративными возможностями Oracle^[22].
• Oracle NoSQL Database — автоматическое сегментирование, эластичное наращивание/уменьшение числа сегментов кластера.
• OrientDB поддерживает сегментирование с версии 1.7.
• Solr (поисковый сервер) — реализует сегментирование^[23].
• ScyllaDB использует сегментирование на каждом ядре сервера и между серверами в кластере.
• Spanner от Google — распределённая на глобальном уровне база данных, сегментирует данные между несколькими машинами Paxos для масштабируемости на миллионы машин по сотням дата-центров и триллионы строк^[24]
• SQLAlchemy ORM, маппер данных для языка Python (язык программирования), поддерживает сегментацию^[25].
• SQL Server, начиная с версии 2005 поддерживает сегментацию с помощью сторонних инструментов^[26].
• Teradata — высокомасштабируемая СУБД для хранилищ данных.
• Vault — криптовалюта, где сегментирование значительно уменьшает объём данных, необходимый пользователям для участия в сети и верификации транзакций, что расширяет масштабируемость^[27].
• Vitess — система кластеризации MySQL с открытым исходным кодом, поддерживающая сегментацию; относится к проектам Cloud Native Computing Foundation^[28].
• ShardingSphere — система кластеризации СУБД с сегментированием данных, распределёнными транзакциями и управлением СУБД; проект Apache Software Foundation^[29].

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

• Сложность SQL. Разработчики сталкиваются с необходимостью писать более сложные запросы для корректной обработки логики сегментирования, что увеличивает шанс возникновения ошибок.
• Дополнительное ПО. Системы для разделения, балансировки, координации и обеспечения целостности могут допускать сбои.
• Единая точка отказа. Повреждение одного сегмента из-за сбоев сети, оборудования или системного уровня приводит к отказу всей таблицы.
• Сложность резервного копирования и восстановления. Необходимо согласовывать копирование каждого сегмента с остальными.
• Операционная сложность. Изменение индексов, столбцов и схемы усложняется при масштабировании по сегментам.

В информатике термин «шард» (сегмент) возможно восходит к двум источникам: разработка Computer Corporation of America — «A System for Highly Available Replicated Data»^[30] (где использовалось резервное оборудование для репликации данных), либо к вышедшей в 1997 году массовой многопользовательской игре Ultima Online, получившей восемь рекордов Гиннеса и включённой журналом Time в число ста величайших видеоигр^[31].

Ричард Гарриотт, создатель Ultima Online, вспоминал момент появления термина при попытке реализовать в игре саморегулирующуюся виртуальную экологию, которую игроки должны были изменять в процессе сбора ресурсов благодаря возможностям интернета. Изначально система работала при тестировании, однако при доступе к игре игроки мгновенно уничтожали всю фауну быстрее, чем она успевала появляться. Чтобы снизить нагрузку, команда разделила базу пользователей на отдельные сессии, а в сюжетную линию вписали концепцию осколков (shards) как следствие победы над антагонистом Мондейном в игре Ultima I, обосновав тем самым создание копий игрового мира. Повышение популярности быстро перегрузило виртуальную экологию вновь, и спустя несколько месяцев команда отказалась от этой функции, убрав её из игры.

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