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

Смотрите также: Масштабируемость

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

История

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

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

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

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

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

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

В начале двадцать первого века NoSQL системы получили преимущество перед реляционными базами данных для некоторых рабочих нагрузок. Мотивация заключалась в еще большей масштабируемости и поддержке документов и других «нереляционных» типов данных. Часто жертвовали строгими протоколами согласованности КИСЛОТЫ, которые всегда гарантировали идеальную согласованность в пользу возможная последовательность Это гарантировало, что все узлы в конечном итоге вернут самые свежие данные. Некоторые даже позволяли время от времени терять транзакции, если система могла обрабатывать достаточно много запросов.[7] Самой известной ранней системой была система Google Большой стол /Уменьшение карты, разработанный в 2004 году. Он достиг почти линейной масштабируемости по нескольким серверные фермы за счет таких функций, как многострочные транзакции и объединения.[8]

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

Габаритные размеры

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

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

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

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

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

Методы

Оборудование

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

Спор

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

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

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

Разбиение

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

Репликация

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

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

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

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

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

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

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

использованная литература

  1. ^ Бонди, Андре Б. (2000). Характеристики масштабируемости и их влияние на производительность. Труды второго международного семинара по программному обеспечению и производительности - WOSP '00. п. 195. Дои:10.1145/350391.350432. ISBN  158113195X.
  2. ^ а б Чопра, Раджив (2010). Система управления базами данных (СУБД) Практический подход. С. Чанд Паблишинг. п. 33. ISBN  9788121932455.
  3. ^ а б «Блокировки строк и блокировки таблиц в Oracle». www.dba-oracle.com. Получено 2019-04-11.
  4. ^ «Преимущества архитектуры Shared Nothing для действительно непрерывных обновлений». solidfire.com. 2014-09-17. Архивировано из оригинал на 2015-04-24. Получено 2015-04-21.
  5. ^ «Руководство по администрированию и развертыванию реальных кластеров приложений». docs.oracle.com. Получено 2019-04-11.
  6. ^ а б «Учебник по репликации базы данных». www.brianstorti.com. Получено 2019-04-11.
  7. ^ Мартин Заплетал (11.06.2015). «Анализ больших объемов данных на платформе Typesafe Reactive Platform». Цитировать журнал требует | журнал = (Помогите)
  8. ^ «Обзор Cloud Bigtable | Документация по Cloud Bigtable». Google Cloud. Получено 2019-04-11.
  9. ^ Аслетт, Мэтью (2011). "Как будут реагировать существующие базы данных на NoSQL и NewSQL?" (PDF). 451 Group (опубликовано 04.04.2011). Получено 2012-07-06.
  10. ^ а б c Брэнсон, Тони (2016-12-06). «Два основных подхода к масштабируемости базы данных». Журнал Infosecurity. Получено 2019-04-11.
  11. ^ "Clojure - ссылки и транзакции". clojure.org. Получено 2019-04-12.
  12. ^ «Введение в индексы с обратным ключом: Часть I». Блог Ричарда Фута Oracle. 2008-01-14. Получено 2019-04-13.
  13. ^ "кластеризация" (PDF). Oracle.com. Получено 2012-11-07.
  14. ^ База Один (2007). «Масштабируемость базы данных - развенчание мифов об ограничениях архитектуры, ориентированной на базы данных». Получено Двадцать третье мая, 2007.

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