Масштабируемость базы данных

Масштабируемость базы данных — это способность базы данных обрабатывать меняющиеся требования путем добавления или удаления ресурсов. Базы данных используют множество методов для решения этой проблемы. ^[1]

История

Первоначальная история масштабируемости баз данных заключалась в предоставлении услуг на компьютерах все меньшего размера. Первые системы управления базами данных, такие как IMS, работали на мейнфреймах . появилось второе поколение, включающее Ingres , Informix , Sybase , RDB и Oracle На миникомпьютерах . Третье поколение, включая dBase и Oracle (снова), работало на персональных компьютерах. ^[2]

В тот же период внимание было обращено на обработку большего количества данных и более требовательных рабочих нагрузок. Одной из ключевых инноваций в программном обеспечении в конце 1980-х годов было снижение детализации блокировки обновлений с таблиц и дисковых блоков до отдельных строк. Это устранило критическое узкое место масштабируемости, поскольку более грубые блокировки могли задерживать доступ к строкам, даже если они не участвовали напрямую в транзакции. Более ранние системы были совершенно нечувствительны к увеличению ресурсов. ^[3]

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

Гораздо более существенное изменение заключалось в разрешении распределенным транзакциям влиять на данные, хранящиеся на отдельных компьютерах, с использованием протокола двухфазной фиксации , устанавливающего архитектуру без общего доступа . ^[4]

Еще позже Oracle представила архитектуру общего доступа , которая обеспечивала полную функциональность многосерверных кластеров. ^[5]

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

В начале двадцать первого века системы NoSQL получили преимущество над реляционными базами данных для некоторых рабочих нагрузок. Мотивация заключалась в еще большей масштабируемости и поддержке документов и других «нереляционных» типов данных. Часто приносились в жертву строгие протоколы согласованности ACID, которые всегда гарантировали идеальную согласованность в пользу конечной согласованности , которая гарантировала, что все узлы в конечном итоге будут возвращать самые последние данные. Некоторые даже допускали потерю транзакций, пока система могла обрабатывать достаточное количество запросов. ^[7] Наиболее известной ранней системой была BigTable / MapReduce от Google , разработанная в 2004 году. Она обеспечивала почти линейную масштабируемость для нескольких ферм серверов за счет таких функций, как многострочные транзакции и соединения. ^[8]

первая NewSQL система — H-Store . В 2007 году была разработана Системы NewSQL пытаются объединить масштабируемость NoSQL с транзакциями ACID и интерфейсами SQL. ^[9]

Размеры

базы данных Масштабируемость имеет три основных измерения: объем данных, объем запросов и размер запросов. Запросы бывают разных размеров: транзакции обычно затрагивают небольшие объемы данных, но могут достигать тысяч в секунду; Аналитических запросов обычно меньше, но они могут получить доступ к большему количеству данных. Связанное с этим понятие — эластичность — способность системы прозрачно добавлять и уменьшать мощность для удовлетворения меняющихся рабочих нагрузок. ^[10]

Вертикальный

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

Горизонтальный

Горизонтальное масштабирование базы данных предполагает добавление большего количества серверов для работы с одной рабочей нагрузкой. Большинство горизонтально масштабируемых систем имеют функциональные компромиссы. Если приложению требуется больше функциональности, предпочтительнее может быть миграция на вертикально масштабируемую систему. ^[10]

Техники

Аппаратное обеспечение

Базы данных работают на индивидуальном оборудовании различной мощности: от умных часов до суперкомпьютеров и нескольких прозрачно реконфигурируемых серверных ферм. ^[2] Базы данных также масштабировались вертикально для работы на 64-битных микропроцессорах , многоядерных процессорах и больших мультипроцессорах SMP с использованием многопоточных реализаций.

Разногласия

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

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

Еще одно потенциальное узкое место может возникнуть в некоторых системах, когда множество запросов пытаются одновременно получить доступ к одним и тем же данным. Например, в OLTP-системах многие транзакции могут одновременно пытаться вставить данные в одну и ту же таблицу. В системе без общего доступа в любой момент все такие вставки обрабатываются одним сервером, который управляет этим разделом ( шардом ) таблицы, возможно, перегружая его, в то время как остальная часть системы мало чем занимается. Многие такие таблицы используют в качестве первичного ключа порядковый номер, который увеличивается с каждой новой вставленной строкой. Индекс для этого ключа также может испытывать конфликты (перегрев) при обработке этих вставок. Одним из решений этой проблемы является изменение местами цифр первичного ключа . Это распределяет вставки как в таблицу, так и в ключ по нескольким частям базы данных. ^[12]

Разделение

Базовый метод — разбиение больших таблиц на несколько разделов на основе диапазонов значений ключевого поля. Например, данные за каждый год можно хранить на отдельном диске или на отдельном компьютере. Секционирование снимает ограничения на размеры одной таблицы.

Репликация

Реплицированные базы данных хранят копии таблиц или баз данных на нескольких компьютерах. Этот метод масштабирования особенно удобен для редко или никогда не обновляемых данных, таких как история транзакций или налоговые таблицы. ^[6]

Кластерные компьютеры

Для масштабирования за пределы одного компьютера используются различные подходы. HP Enterprise от NonStop SQL использует архитектуру без общего доступа , в которой ни данные, ни память не используются совместно за пределами границ сервера. Координатор направляет запросы к базе данных на правильный сервер. Эта архитектура обеспечивает почти линейную масштабируемость.

Широко поддерживаемый стандарт X/Open XA использует глобальный монитор транзакций для координации распределенных транзакций между полуавтономными XA-совместимыми транзакционными ресурсами.

Oracle RAC использует другую модель для достижения масштабируемости, основанную на «общедоступной» архитектуре. Этот подход включает подход с общим диском , который позволяет нескольким компьютерам получать доступ к любому диску в кластере. Сетевые хранилища (NAS) и сети хранения данных (SAN) в сочетании с локальными сетями и технологией Fibre Channel позволяют реализовать такие конфигурации. Этот подход включает в себя «общий» логический кеш, в котором данные, кэшированные в памяти на сервере, становятся доступными другим серверам, не требуя от них повторного чтения данных с диска. Каждая страница перемещается с сервера на сервер для удовлетворения запросов. Обновления обычно происходят очень быстро, поэтому «популярную» страницу можно обновить несколькими транзакциями с небольшой задержкой. Утверждается, что этот подход поддерживает кластеры, содержащие до 100 серверов. ^[13]

ограничения Некоторые исследователи ставят под сомнение присущие системам управления реляционными базами данных . GigaSpaces , например, утверждает, что космическая архитектура необходима для достижения производительности и масштабируемости. Base One демонстрирует исключительную масштабируемость в рамках основной технологии реляционных баз данных. ^[14]

См. также

Ссылки

^ Бонди, Андре Б. (2000). Характеристики масштабируемости и их влияние на производительность . Материалы второго международного семинара по программному обеспечению и производительности – WOSP '00. п. 195. дои : 10.1145/350391.350432 . ISBN 158113195X .
^ Jump up to: ^а ^б Чопра, Раджив (2010). Система управления базами данных (СУБД). Практический подход . Издательство С. Чанд. п. 33. ISBN 9788121932455 .
^ Jump up to: ^а ^б «Блокировки строк и блокировки таблиц в Oracle» . www.dba-oracle.com . Проверено 11 апреля 2019 г.
^ «Преимущества архитектуры без общего доступа для действительно бесперебойных обновлений» . Solidfire.com. 17 сентября 2014 г. Архивировано из оригинала 24 апреля 2015 г. Проверено 21 апреля 2015 г.
^ «Руководство по администрированию и развертыванию кластеров реальных приложений» . docs.oracle.com . Проверено 11 апреля 2019 г.
^ Jump up to: ^а ^б «Букварь по репликации баз данных» . www.brianstorti.com . Проверено 11 апреля 2019 г.
^ Мартин Заплетал (11 июня 2015 г.). «Анализ больших объемов данных на Typesafe Reactive Platform» . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ «Обзор Cloud Bigtable | Документация Cloud Bigtable» . Гугл облако . Проверено 11 апреля 2019 г.
^ Аслетт, Мэтью (2011). «Как поставщики баз данных отреагируют на NoSQL и NewSQL?» (PDF) . 451 Group (опубликовано 4 апреля 2011 г.) . Проверено 6 июля 2012 г.
^ Jump up to: ^а ^б ^с Брэнсон, Тони (6 декабря 2016 г.). «Два основных подхода к масштабируемости баз данных» . Журнал Инфобезопасность . Проверено 11 апреля 2019 г.
^ «Clojure — Ссылки и транзакции» . Clojure.org . Проверено 12 апреля 2019 г.
^ «Введение в реверс ключевых индексов: Часть I» . Блог Oracle Ричарда Фута . 14 января 2008 г. Проверено 13 апреля 2019 г.
^ «кластеризация» (PDF) . Oracle.com . Проверено 7 ноября 2012 г.
^ База Один (2007). «Масштабируемость баз данных: развенчание мифов об ограничениях архитектуры, ориентированной на базы данных» . Проверено 23 мая 2007 г.

Внешние ссылки

[1] Бонди, Андре Б. (2000). Характеристики масштабируемости и их влияние на производительность . Материалы второго международного семинара по программному обеспечению и производительности – WOSP '00. п. 195. дои : 10.1145/350391.350432 . ISBN 158113195X .

[:12-2] Jump up to: ^а ^б Чопра, Раджив (2010). Система управления базами данных (СУБД). Практический подход . Издательство С. Чанд. п. 33. ISBN 9788121932455 .

[:22-3] Jump up to: ^а ^б «Блокировки строк и блокировки таблиц в Oracle» . www.dba-oracle.com . Проверено 11 апреля 2019 г.

[4] «Преимущества архитектуры без общего доступа для действительно бесперебойных обновлений» . Solidfire.com. 17 сентября 2014 г. Архивировано из оригинала 24 апреля 2015 г. Проверено 21 апреля 2015 г.

[5] «Руководство по администрированию и развертыванию кластеров реальных приложений» . docs.oracle.com . Проверено 11 апреля 2019 г.

[:32-6] Jump up to: ^а ^б «Букварь по репликации баз данных» . www.brianstorti.com . Проверено 11 апреля 2019 г.

[7] Мартин Заплетал (11 июня 2015 г.). «Анализ больших объемов данных на Typesafe Reactive Platform» . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[8] «Обзор Cloud Bigtable | Документация Cloud Bigtable» . Гугл облако . Проверено 11 апреля 2019 г.

[aslett20122-9] Аслетт, Мэтью (2011). «Как поставщики баз данных отреагируют на NoSQL и NewSQL?» (PDF) . 451 Group (опубликовано 4 апреля 2011 г.) . Проверено 6 июля 2012 г.

[:02-10] Jump up to: ^а ^б ^с Брэнсон, Тони (6 декабря 2016 г.). «Два основных подхода к масштабируемости баз данных» . Журнал Инфобезопасность . Проверено 11 апреля 2019 г.

[11] «Clojure — Ссылки и транзакции» . Clojure.org . Проверено 12 апреля 2019 г.

[12] «Введение в реверс ключевых индексов: Часть I» . Блог Oracle Ричарда Фута . 14 января 2008 г. Проверено 13 апреля 2019 г.

[13] «кластеризация» (PDF) . Oracle.com . Проверено 7 ноября 2012 г.

[14] База Один (2007). «Масштабируемость баз данных: развенчание мифов об ограничениях архитектуры, ориентированной на базы данных» . Проверено 23 мая 2007 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]