Shard (архитектура базы данных) - Shard (database architecture)

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

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

Архитектура базы данных

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

У подхода с горизонтальным разбиением есть множество преимуществ. Поскольку таблицы разделены и распределены по нескольким серверам, общее количество строк в каждой таблице в каждой базе данных уменьшается. Это снижает индекс size, что обычно повышает производительность поиска. Осколок базы данных можно разместить на отдельном оборудовании, а несколько осколков можно разместить на нескольких машинах. Это позволяет распределить базу данных по большому количеству машин, значительно улучшая производительность. Кроме того, если сегмент базы данных основан на некоторой реальной сегментации данных (например, европейские клиенты против американских клиентов), тогда может быть возможно легко и автоматически вывести соответствующее членство в сегменте и запросить только соответствующий сегмент.[2]

К недостаткам можно отнести:

Основной раздел: Недостатки

  • Более сильная зависимость от взаимодействия между серверами[нужна цитата ]
  • Увеличенная задержка при запросе, особенно когда нужно искать более одного шарда.[нужна цитата ]
  • Данные или индексы часто сегментируются только одним способом, поэтому одни поиски являются оптимальными, а другие - медленными или невозможными.[требуется разъяснение ]
  • Проблемы с согласованностью и долговечностью из-за более сложных режимов отказа набора серверов, которые часто приводят к тому, что системы не дают никаких гарантий относительно согласованности или надежности между сегментами.[нужна цитата ]

На практике шардинг сложен. Хотя это долгое время делалось вручную (особенно там, где строки имеют очевидную группировку, как в приведенном выше примере), это часто негибко. Существует желание поддерживать автоматическое сегментирование, как с точки зрения добавления поддержки кода для него, так и для определения кандидатов для отдельного сегментирования. Последовательное хеширование - это метод, используемый в сегментировании для распределения больших нагрузок на несколько небольших сервисов и серверов.[3]

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

Осколки по сравнению с горизонтальным разделением

Горизонтальное разделение разбивает одну или несколько таблиц по строкам, обычно в пределах Один экземпляр схема и сервер базы данных. Это может дать преимущество за счет уменьшения размера индекса (и, следовательно, усилий по поиску), при условии, что существует некоторый очевидный, надежный, неявный способ определить, в каком разделе будет найдена конкретная строка, без необходимости предварительного поиска по индексу, например, классический пример "КлиентыВосток' и 'КлиентыЗапад'столы, где их почтовый индекс уже указывает, где они будут найдены.

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

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

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

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

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

Известные реализации

  • Altibase: обеспечивает комбинированную (на стороне клиента и на стороне сервера) архитектуру сегментирования, прозрачную для клиентских приложений.
  • Apache HBase: HBase обеспечивает автоматическое шардирование.[4]
  • Инструменты эластичной базы данных Azure SQL Database: позволяют масштабировать уровень данных приложения с помощью стандартных отраслевых методов сегментирования.[5]
  • ClickHouse: ClickHouse - это быстрая система управления базами данных OLAP с открытым исходным кодом, включающая сегментирование.
  • Диван: обеспечивает автоматическое прозрачное сегментирование, а также высокую производительность.
  • Кубрид: позволяет шардинг с версии 9.0
  • DRDS (служба распределенных реляционных баз данных) Облако Alibaba: включает сегментирование базы данных / таблицы,[6] и поддерживает День холостяков.[7]
  • Elasticsearch: поисковый сервер предприятия предоставляет возможности сегментирования.[8]
  • Экстремальный масштаб: межпроцессное хранилище данных ключей / значений в памяти (различные NoSQL хранилище данных). Он использует сегментирование для достижения масштабируемости между процессами как для данных, так и для Уменьшение карты -стиль параллельной обработки.[9]
  • Спящий режим Shards: предоставляет осколки, хотя с 2007 года активность была незначительной.[10][11]
  • IBM Informix: IBM разрешил сегментирование Informix начиная с версии 12.1 xC1 как часть технологии MACH11. В Informix 12.10 xC2 добавлена ​​полная совместимость с драйверами MongoDB, что позволяет сочетать обычные реляционные таблицы с коллекциями NoSQL, при этом сохраняя свойства сегментирования, переключения при отказе и ACID.[12][13]
  • Kdb +: позволяет шардинг начиная с версии 2.0.
  • MonetDB: открытый исходный код колонна-магазин MonetDB разрешает сегментирование только для чтения в версии от июля 2015 г.[14]
  • MongoDB: позволяет шардинг с версии 1.6.
  • Кластер MySQL: Auto-Sharding: база данных автоматически и прозрачно разделяется между недорогими товарными узлами, что позволяет горизонтально масштабировать запросы чтения и записи, не требуя изменений в приложении.[15]
  • MySQL Fabric (часть утилит MySQL) включает возможность сегментирования.[16]
  • Oracle Sharding: представлена ​​в качестве новой функции в Oracle Database 12c Release 2 и в одном пакете: сочетание преимуществ сегментирования с хорошо известными возможностями готовой к работе многомодельной Oracle Database.[17]
  • База данных Oracle NoSQL: имеет автоматическое сегментирование и эластичное онлайн-расширение кластера (добавление дополнительных сегментов).
  • OrientDB: позволяет шардинг с версии 1.7
  • Solr поисковый сервер предприятия: предоставляет возможности сегментирования.[18]
  • Гаечный ключ: Глобальная распределенная база данных Google, разбивает данные на несколько Паксос конечные автоматы для масштабирования до «миллионов машин в сотнях центров обработки данных и триллионах строк базы данных».[19]
  • SQLAlchemy ORM: средство отображения данных для языка программирования Python, обеспечивающее возможности сегментирования.[20]
  • DWH Терадаты: массивная параллельная база данных.
  • Хранилище: A криптовалюта это резко сокращает объем данных, необходимых пользователям для подключения к сети и проверки транзакций. Это приводит к гораздо более масштабируемой сети. Разработано исследователями Массачусетского технологического института. Шардинг играет ключевую роль в его функционировании.[21]
  • Vitess: система кластеризации баз данных с открытым исходным кодом, которая может горизонтально масштабировать MySQL. Витесс Фонд облачных вычислений проект.[22]

Недостатки

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

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

Эти исторические сложности самостоятельного сегментирования решались независимыми поставщиками программного обеспечения, которые обеспечивали автоматическое сегментирование.

Этимология

В контексте базы данных большинство понимает, что термин «сегмент», скорее всего, происходит от одного из двух источников: Компьютерная корпорация Америки "Система для высокодоступных реплицированных данных",[23] которые использовали избыточное оборудование для облегчения передачи данных репликация (в отличие от горизонтального разделения); или получивший признание критиков 1997 MMORPG видео игра Ultima Online который установил 8 Книга Рекордов Гиннесса и был обозначен Время как одна из 100 величайших видеоигр всех времен.[24][25]

Ричард Гэрриотт, создатель Ultima Online, вспоминает термин, придуманный на этапе производства, когда они пытались создать саморегулирующуюся виртуальную экологическую систему, с помощью которой игроки могут использовать новый доступ в Интернет (революционная технология в то время) для взаимодействия и сбора внутриигровых ресурсов.[26] Хотя виртуальная экология функционировала, как и предполагалось во время внутреннего тестирования, ее естественный баланс нарушился «почти мгновенно» из-за того, что игроки убивали всех живых животных в игровой зоне быстрее, чем могла работать система нереста. Производственная группа Гэрриотта попыталась смягчить эту проблему, разделив глобальную базу игроков на отдельные сессии и переписав часть Ultima Onlineс вымышленная связь с концом Ultima I: Первая Эпоха Тьмы, где поражение своего антагониста Mondain также привел к созданию мультивселенная «черепки». Эта модификация предоставила команде Гэрриота вымышленную основу, необходимую для оправдания создания копий виртуальной среды. Тем не менее, резкий рост игры до одобрения критиков также означал, что новая система виртуальной экологии мультивселенной также была быстро подавлена. После нескольких месяцев тестирования команда Гэрриотта решила полностью отказаться от этой функции и лишила игру ее функциональности.

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

Смотрите также

Примечания

  1. ^ Обычно «вспомогательные» данные, такие как таблицы размеров

Рекомендации

  1. ^ Sadalage, Pramod J .; Фаулер, Мартин (2012). «4: Модели распределения». NoSQL Distilled. ISBN  0321826620.
  2. ^ Рахул Рой (28 июля 2008 г.). «Осколок - Дизайн базы данных».
  3. ^ Райс, Эрик. «Шардинг для стартапов».
  4. ^ "Apache HBase Sharding".
  5. ^ «Представляем предварительную версию Elastic Scale для базы данных SQL Azure».
  6. ^ https://www.alibabacloud.com/help/doc-detail/29659.htm?spm=a2c63.l28256.a3.1.4eb21d9a8lUMTW
  7. ^ https://www.alibabacloud.com/product/drds
  8. ^ «Распределение части индекса».
  9. ^ http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r1/index.jsp?topic=%2Fcom.ibm.websphere.extremescale.over.doc%2
  10. ^ "Осколки гибернации". 2007-02-08.
  11. ^ "Осколки гибернации".
  12. ^ «Новые грид-запросы для Informix».
  13. ^ «Поддержка NoSQL в Informix».
  14. ^ «Выпущен MonetDB за июль 2015 г.». 31 августа 2015 г.
  15. ^ «Возможности и преимущества MySQL Cluster». 2012-11-23.
  16. ^ «Краткое руководство по шардированию MySQL Fabric».
  17. ^ http://www.oracle.com/technetwork/database/database-technologies/sharding/overview/index.html
  18. ^ «Распределенный поиск».
  19. ^ Корбетт, Джеймс С; Дин, Джеффри; Эпштейн, Майкл; Фике, Андрей; Фрост, Кристофер; Фурман, JJ; Гемават, Санджай; Губарев Андрей; Хайзер, Кристофер; Хохшильд, Питер; Шей, Уилсон; Кантак, Себастьян; Коган, Евгений; Ли, Хунъи; Ллойд, Александр; Мельник, Сергей; Мваура, Дэвид; Нэгл, Дэвид; Куинлан, Шон; Рао, Раджеш; Ролиг, Линдси; Сайто, Ясуши; Шиманиак, Михал; Тейлор, Кристофер; Ван, Рут; Вудфорд, Дейл. "Spanner: глобально распределенная база данных Google" (PDF). Материалы OSDI 2012. Google. Получено 24 февраля 2014.
  20. ^ «Базовый пример использования API-интерфейса SQLAlchemy Sharding».
  21. ^ «Более быстрая и эффективная криптовалюта». Новости MIT. Получено 2019-01-30.
  22. ^ "Витесс".
  23. ^ Зарин, ДеВитт и Розенбург, Обзор SHARD: система высокодоступных реплицированных данных, Технический отчет CCA-88-01, Computer Corporation of America, май 1988 г.
  24. ^ Костер, Раф (2008-01-08). "Шардинг базы данных" пришел от UO? ". Веб-сайт Рафа Костера. Получено 2015-01-17.
  25. ^ "Ultima Online: Виртуальная экология | Военные истории". Видео Ars Technica. Получено 2020-06-04.
  26. ^ ""Военные истории Ultima Online: Виртуальная экология"".

внешняя ссылка