Шард (архитектура базы данных)
 | Эта статья нуждается в дополнительных цитатах для проверки . ( март 2021 г. ) |
Осколок базы данных или просто осколок — это горизонтальный раздел данных в базе данных или поисковой системе . Каждый осколок хранится на отдельном экземпляре сервера базы данных для распределения нагрузки.
Некоторые данные в базе данных остаются во всех сегментах. [а] но некоторые появляются только в одном осколке. Каждый осколок (или сервер) выступает в качестве единственного источника этого подмножества данных. [1]
Архитектура базы данных
[ редактировать ]Горизонтальное секционирование — это принцип проектирования базы данных, при котором строки таблицы базы данных хранятся отдельно, а не разбиваются на столбцы (что и делают нормализация и вертикальное секционирование в разной степени). Каждый раздел является частью сегмента, который, в свою очередь, может располагаться на отдельном сервере базы данных или в физическом месте.
Горизонтальное разделение имеет множество преимуществ. Поскольку таблицы разделены и распределены по нескольким серверам, общее количество строк в каждой таблице в каждой базе данных уменьшается. Это уменьшает размер индекса , что в целом повышает производительность поиска. Осколок базы данных можно разместить на отдельном оборудовании, а несколько сегментов можно разместить на нескольких машинах. Это позволяет распределить базу данных по большому количеству компьютеров, что значительно повышает производительность. Кроме того, если сегмент базы данных основан на некоторой реальной сегментации данных (например, европейские клиенты против американских клиентов), тогда можно легко и автоматически сделать вывод о соответствующем членстве в сегменте и запросить только соответствующий сегмент. [2]
На практике шардинг является сложным процессом. Хотя в течение долгого времени это делалось путем ручного кодирования (особенно там, где строки имеют очевидную группировку, как в примере выше), это часто бывает негибким. Есть желание поддерживать шардинг автоматически, как в плане добавления поддержки кода для него, так и для выявления кандидатов на шардирование отдельно. Согласованное хеширование — это метод, используемый при сегментировании для распределения больших нагрузок между несколькими меньшими службами и серверами. [3]
Если распределенные вычисления используются для разделения нагрузки между несколькими серверами (по соображениям производительности или надежности), также может быть полезен сегментный подход. В 2010-х годах сегментирование производительности , а также более традиционное сегментирование данных стало потенциальным подходом к преодолению проблем производительности и масштабируемости в блокчейнах . [4] [5]
По сравнению с горизонтальным разделением
[ редактировать ]Горизонтальное секционирование разбивает одну или несколько таблиц по строкам, обычно в пределах одного экземпляра схемы и сервера базы данных. Это может дать преимущество за счет уменьшения размера индекса (и, следовательно, усилий по поиску) при условии, что существует какой-то очевидный, надежный, неявный способ определить, в каком разделе будет найдена конкретная строка, без необходимости предварительного поиска по индексу, например классический метод пример ' CustomersEast' и ' CustomersWest' таблицы, где их почтовый индекс уже указывает, где они будут найдены.
Шардинг выходит за рамки этого. Он разбивает проблемные таблицы таким же образом, но делает это по потенциально нескольким экземплярам схемы. Очевидным преимуществом будет то, что поисковую нагрузку для большой секционированной таблицы теперь можно будет разделить между несколькими серверами (логическими или физическими), а не только несколькими индексами на одном логическом сервере.
Разделение сегментов на несколько изолированных экземпляров требует большего, чем простое горизонтальное секционирование. Ожидаемый прирост эффективности был бы потерян, если бы для запроса к базе данных требовалось несколько запрашивать экземпляров только для получения простой таблицы измерений . Таким образом, помимо секционирования, сегментирование разделяет большие секционируемые таблицы между серверами, в то время как меньшие таблицы реплицируются как целые единицы. [ нужны разъяснения ]
Именно поэтому сегментирование связано с архитектурой без общего доступа — после сегментирования каждый сегмент может находиться в совершенно отдельном экземпляре логической схемы/физическом сервере базы данных/ центре обработки данных / континенте . Нет постоянной необходимости сохранять общий доступ (между сегментами) к другим несекционированным таблицам в других сегментах. [ нужна ссылка ]
Это упрощает репликацию между несколькими серверами (простое горизонтальное секционирование этого не делает). Это также полезно для распространения приложений по всему миру, где в противном случае каналы связи между центрами обработки данных были бы узким местом. [ нужна ссылка ]
Также существует потребность в некотором механизме уведомления и репликации между экземплярами схемы, чтобы несекционированные таблицы оставались синхронизированными настолько, насколько того требует приложение. Это сложный выбор в архитектуре сегментированных систем: подходы варьируются от того, чтобы сделать их фактически доступными только для чтения (обновления происходят редко и пакетно), до динамически реплицируемых таблиц (за счет уменьшения некоторых преимуществ распределения от сегментирования) и множества вариантов. между ними. [ нужна ссылка ]
Реализации
[ редактировать ]- Altibase обеспечивает комбинированную (клиентскую и серверную) архитектуру сегментирования, прозрачную для клиентских приложений.
- Apache HBase может сегментировать автоматически. [6]
- Осколки инструментов эластичной базы данных SQL Azure для масштабирования и использования уровня данных приложения. [7]
- ClickHouse , быстрая система управления базами данных OLAP с открытым исходным кодом, шарды.
- Couchbase автоматически и прозрачно разделяет фрагменты.
- Шарды CUBRID начиная с версии 9.0
- Функция разделения данных Db2 (MPP), которая представляет собой разделы базы данных без общего доступа, работающие на отдельных узлах.
- DRDS (служба распределенных реляционных баз данных) Alibaba Cloud выполняет сегментирование базы данных/таблиц, [8] и поддерживает День холостяков . [9]
- Elasticsearch . Осколки корпоративного поискового сервера [10]
- eXtreme Scale — это межпроцессное хранилище данных «ключ-значение» в памяти ( хранилище данных NoSQL ). Он использует сегментирование для достижения масштабируемости процессов как для данных, так и для параллельной обработки в стиле MapReduce . [11]
- Hibernate Shards, но с 2007 года мало развивался. [12] [13]
- Осколки IBM Informix начиная с версии 12.1 xC1 как часть технологии MACH11. В Informix 12.10 xC2 добавлена полная совместимость с драйверами MongoDB, что позволяет сочетать обычные реляционные таблицы с коллекциями NoSQL, сохраняя при этом сегментирование, отказоустойчивость и свойства ACID. [14] [15]
- Осколки Kdb+ начиная с версии 2.0.
- MariaDB Spider — механизм хранения, который поддерживает объединение таблиц, сегментирование таблиц, транзакции XA и источники данных ODBC. Движок MariaDB Spider входит в состав сервера MariaDB, начиная с версии 10.0.4. [16]
- MonetDB с открытым исходным кодом , столбцовое хранилище , в выпуске, выпущенном в июле 2015 года, выполняет сегментирование только для чтения. [17]
- Осколки MongoDB начиная с версии 1.6.
- MySQL Cluster автоматически и прозрачно распределяет недорогие стандартные узлы, позволяя масштабировать запросы на чтение и запись, не требуя внесения изменений в приложение. [18]
- Осколки MySQL Fabric (часть утилит MySQL). [19]
- Осколки базы данных Oracle, начиная с версии 12c Release 2, и в одной строке: сочетание преимуществ сегментирования с хорошо известными возможностями многомодельной базы данных Oracle, готовой к использованию на предприятии. [20]
- База данных Oracle NoSQL имеет автоматическое сегментирование и эластичное онлайн-расширение кластера (добавление дополнительных сегментов).
- Осколки OrientDB начиная с версии 1.7
- Solr . Осколки корпоративного поискового сервера [21]
- ScyllaDB работает сегментированно на каждом ядре сервера на всех серверах кластера.
- Spanner , глобальная распределенная база данных Google, распределяется по нескольким конечным машинам Paxos для масштабирования до «миллионов машин в сотнях центров обработки данных и триллионов строк базы данных». [22]
- SQLAlchemy ORM — преобразователь данных для фрагментов языка программирования Python . [23]
- SQL Server , поскольку SQL Server 2005 сегментируется с помощью сторонних инструментов. [24]
- Teradata позиционирует массивную параллельную систему управления базами данных как « хранилище данных ».
- Vault Криптовалюта использует сегменты, позволяющие значительно сократить объем данных, необходимых пользователям для подключения к сети и проверки транзакций. Это позволяет сети масштабироваться гораздо больше. [25]
- Vitess Система кластеризации баз данных с открытым исходным кодом на основе фрагментов MySQL. Это проект Cloud Native Computing Foundation . [26]
- ShardingSphere относится к системе кластеризации баз данных, обеспечивающей сегментирование данных, распределенные транзакции и управление распределенными базами данных. Это проект Apache Software Foundation (ASF). [27]
Недостатки
[ редактировать ]Сегментирование таблицы базы данных до ее локальной оптимизации приводит к преждевременному усложнению. Шардинг следует использовать только тогда, когда все другие варианты оптимизации не подходят. [ по мнению кого? ] Введенная сложность сегментирования базы данных вызывает следующие потенциальные проблемы: [ нужна ссылка ]
- Сложность SQL . Увеличение количества ошибок, поскольку разработчикам приходится писать более сложный SQL для обработки логики сегментирования.
- Дополнительное программное обеспечение , которое может привести к сбою разделения, балансировки, координации и обеспечения целостности.
- Единая точка отказа . Повреждение одного сегмента из-за проблем с сетью/оборудованием/системой приводит к сбою всей таблицы.
- резервного Сложность сервера . Резервные серверы должны иметь копии множества фрагментов базы данных.
- резервного копирования Сложность . Резервные копии базы данных отдельных сегментов должны быть скоординированы с резервными копиями других сегментов.
- Сложность эксплуатации . Добавление/удаление индексов, добавление/удаление столбцов, изменение схемы становится намного сложнее.
Этимология
[ редактировать ]В контексте базы данных большинство признает, что термин «осколок», скорее всего, произошел от одного из двух источников: компьютерной корпорации , «Система для высокодоступных реплицируемых данных» Американской [28] в котором использовалось избыточное оборудование для облегчения репликации данных (в отличие от горизонтального разделения); или получившая признание критиков MMORPG видеоигра Ultima Online 1997 года , которая установила 8 мировых рекордов Гиннеса и была названа журналом Time одной из 100 величайших видеоигр, созданных всех времен. [29] [30]
Ричард Гэрриотт , создатель Ultima Online , вспоминает, как этот термин был придуман на этапе производства, когда они пытались создать саморегулирующуюся систему виртуальной экологии, посредством которой игроки могли бы использовать новый доступ в Интернет (революционная технология того времени) для взаимодействия и сбора урожая. игровые ресурсы. [30] Хотя во время внутреннего тестирования виртуальная экология функционировала так, как задумано, ее естественный баланс нарушился «почти мгновенно» из-за того, что игроки убивали всех живых существ в игровой зоне быстрее, чем могла сработать система нереста. Производственная группа Гэрриотта попыталась смягчить эту проблему, разделив глобальную базу игроков на отдельные сессии и переписав часть Ultima Online вымышленной связи с концом Ultima I: The First Age of Darkness поражение ее антагониста Мондейна. , к чему также привело к созданию мультивселенной «осколков» . Эта модификация предоставила команде Гэрриота вымышленную основу, необходимую для обоснования создания копий виртуальной среды. Однако резкий рост популярности игры среди критиков также означал, что новая система виртуальной экологии мультивселенной также быстро оказалась перегружена. После нескольких месяцев тестирования команда Гэрриота решила вообще отказаться от этой функции и лишила игру ее функциональности. [30]
Сегодня термин «осколок» относится к развертыванию и использованию резервного оборудования в системах баз данных. [ нужна ссылка ]
См. также
[ редактировать ]Примечания
[ редактировать ]- ^ Обычно «вспомогательные» данные, такие как таблицы измерений.
Ссылки
[ редактировать ]- ^ Садалаге, Прамод Дж.; Фаулер, Мартин (2012). «4: Модели распространения». NoSQL дистиллированная . Пирсон Образование. ISBN 978-0321826626 .
- ^ Рахул Рой (28 июля 2008 г.). «Осколок — проектирование базы данных» .
- ^ Райс, Эрик. «Шардинг для стартапов» .
- ^ Ван, Банда; Ши, Чжицзе Джерри; Никсон, Марк; Хан, Сун (21 октября 2019 г.). «СоК» . Материалы 1-й конференции ACM по достижениям в области финансовых технологий . стр. 41–61. дои : 10.1145/3318041.3355457 . ISBN 9781450367325 . S2CID 204749727 .
- ^ Ю, Минчао; Сахраи, Саид; Никсон, Марк; Хан, Сун (18 июля 2020 г.). «SoK: Шардинг на блокчейне» . Материалы 1-й конференции ACM по достижениям в области финансовых технологий . FC 2020: Финансовая криптография и безопасность данных . стр. 114–134. дои : 10.1145/3318041.3355457 . ISBN 9781450367325 . S2CID 204749727 .
- ^ «Apache HBase – Домашняя страница Apache HBase™» . hbase.apache.org .
- ^ «Представляем предварительную версию Elastic Scale для базы данных SQL Azure» . azure.microsoft.com . 2 октября 2014 г.
- ^ «Справочный центр Alibaba Cloud — Определение облака и объяснение облачных услуг — Alibaba Cloud» . www.alibabacloud.com .
- ^ «Основное внимание уделяется крупномасштабным онлайн-базам данных — Alibaba Cloud» . www.alibabacloud.com .
- ^ «Распределение сегментов индекса | Руководство по Elasticsearch [7.13] | Elastic» . www.elastic.co .
- ^ «Документация IBM» .
- ^ «Осколки гибернации» . 8 февраля 2007 г.
- ^ «Осколки гибернации» . Архивировано из оригинала 16 декабря 2008 г. Проверено 30 марта 2011 г.
- ^ «Новые Grid-запросы для Informix» .
- ^ «Поддержка NoSQL в Informix (хранилище JSON, API Mongo DB)» . 24 сентября 2013 г.
- ^ «Паук» . База знаний MariaDB . Проверено 20 декабря 2022 г.
- ^ «Выпуск MonetDB в июле 2015 г.» . 31 августа 2015 г.
- ^ «Особенности и преимущества кластера MySQL» . 2012-11-23.
- ^ «Краткое руководство по сегментированию MySQL Fabric» .
- ^ «Шардинг Oracle» . Оракул . 24 мая 2018 г. Проверено 10 июля 2021 г.
- ^ «Распределенный поиск — SOLR — Apache Software Foundation» . cwiki.apache.org .
- ^ Корбетт, Джеймс С; Дин, Джеффри; Эпштейн, Майкл; Файкс, Эндрю; Фрост, Кристофер; Фурман, Джей-Джей; Гемават, Санджай; Губарев Андрей; Хейзер, Кристофер; Хохшильд, Питер; Се, Уилсон; Кантак, Себастьян; Коган, Евгений; Ли, Хонги; Ллойд, Александр; Мельник, Сергей; Мваура, Дэвид; Нэгл, Дэвид; Куинлан, Шон; Рао, Раджеш; Ролиг, Линдси; Сайто, Ясуси; Шиманьяк, Михал; Тейлор, Кристофер; Ван, Рут; Вудфорд, Дейл. «Spanner: глобально распределенная база данных Google» (PDF) . Материалы ОСДИ 2012 . Проверено 24 февраля 2014 г.
- ^ "sqlalchemy/sqlalchemy" . 9 июля 2021 г. — через GitHub.
- ^ «Параметры секционирования и сегментирования для SQL Server и SQL Azure» . infoq.com .
- ^ «Быстрая и эффективная криптовалюта» . Новости МТИ . 24 января 2019 года . Проверено 30 января 2019 г.
- ^ "скорость" . скорость.io .
- ^ «ШардингСфера» . shardingsphere.apache.org .
- ^ Сарин, ДеВитт и Розенберг, Обзор SHARD: система для высокодоступных реплицируемых данных , Технический отчет CCA-88-01, Компьютерная корпорация Америки, май 1988 г.
- ^ Костер, Раф (8 января 2009 г.). «Шардинг базы данных» исходил от UO?» . Сайт Рафа Костера . Проверено 17 января 2015 г.
- ^ Перейти обратно: а б с «Ultima Online: Виртуальная экология | Военные истории» . Видео Арс Техника .
