Масштабируемость базы данных — это способность базы данных справляться с изменяющимися требованиями путем добавления/удаления ресурсов. Базы данных используют множество методов, чтобы справляться. [1]
Первоначальная история масштабируемости баз данных заключалась в предоставлении услуг на все меньших компьютерах. Первые системы управления базами данных, такие как IMS, работали на мэйнфреймах . Второе поколение, включая Ingres , Informix , Sybase , RDB и Oracle , появилось на миникомпьютерах . Третье поколение, включая dBase и Oracle (снова), работало на персональных компьютерах. [2]
В тот же период внимание переключилось на обработку большего количества данных и более требовательных рабочих нагрузок. Одним из ключевых нововведений в программном обеспечении в конце 1980-х годов было снижение гранулярности блокировки обновления из таблиц и дисковых блоков в отдельные строки. Это устранило критическое узкое место масштабируемости, поскольку более грубые блокировки могли задержать доступ к строкам, даже если они не были напрямую вовлечены в транзакцию. Более ранние системы были совершенно нечувствительны к увеличению ресурсов. [3]
После того, как ограничения программного обеспечения были устранены, внимание переключилось на аппаратное обеспечение. Инновации произошли во многих областях. Первой была поддержка многопроцессорных компьютеров . Это включало в себя разрешение нескольким процессорам обрабатывать запросы к базе данных одновременно, не блокируя друг друга. Это переросло в поддержку многоядерных процессоров .
Гораздо более существенное изменение заключалось в том, что распределенным транзакциям было разрешено влиять на данные, хранящиеся на отдельных компьютерах, используя двухфазный протокол фиксации, устанавливая архитектуру без общего доступа . [4]
Еще позже Oracle представила архитектуру «всеобщего доступа» , которая обеспечивала полную функциональность на многосерверных кластерах. [5]
Еще одним нововведением стало хранение копий таблиц на нескольких компьютерах ( репликация базы данных ), что повысило как доступность (обработка могла продолжаться на копии, даже если основная система была недоступна), так и масштабируемость, особенно для запросов/анализа, поскольку запросы могли быть направлены на копию, если основная достигла своей емкости. [6]
В начале двадцать первого века системы NoSQL получили преимущество перед реляционными базами данных для некоторых рабочих нагрузок. Мотивациями были еще большая масштабируемость и поддержка документов и других «нереляционных» типов данных. Часто жертвовали строгими протоколами согласованности ACID, которые гарантировали идеальную согласованность в любое время в пользу окончательной согласованности , которая гарантировала, что все узлы в конечном итоге вернут последние данные. Некоторые даже допускали иногда потерю транзакций, пока система могла обрабатывать достаточно много запросов. [7] Самой выдающейся ранней системой была BigTable / MapReduce от Google , разработанная в 2004 году. Она достигла почти линейной масштабируемости на нескольких фермах серверов за счет таких функций, как многострочные транзакции и объединения. [8]
В 2007 году была разработана первая система NewSQL , H-Store . Системы NewSQL пытаются объединить масштабируемость NoSQL с транзакциями ACID и интерфейсами SQL. [9]
Масштабируемость базы данных имеет три основных измерения: объем данных, объем запросов и размер запросов. Запросы бывают разных размеров: транзакции обычно затрагивают небольшие объемы данных, но могут приближаться к тысячам в секунду; аналитические запросы, как правило, меньше, но могут получать доступ к большему количеству данных. Связанная концепция — эластичность , способность системы прозрачно добавлять и вычитать емкость для удовлетворения изменяющихся рабочих нагрузок. [10]
Вертикальное масштабирование базы данных подразумевает, что система базы данных может полностью использовать максимально сконфигурированные системы, включая, как правило, многопроцессорные системы с большой памятью и огромной емкостью хранения. Такие системы относительно просты в администрировании, но могут предлагать ограниченную доступность. Однако любой отдельный компьютер имеет максимальную конфигурацию. Если рабочие нагрузки выходят за пределы этого предела, выбор заключается либо в миграции на другую, еще большую систему, либо в перепроектировании системы для достижения горизонтальной масштабируемости. [10]
Горизонтальное масштабирование базы данных подразумевает добавление большего количества серверов для работы над одной рабочей нагрузкой. Большинство горизонтально масштабируемых систем имеют компромиссы функциональности. Если приложению требуется больше функциональности, миграция на вертикально масштабируемую систему может быть предпочтительнее. [10]
Базы данных работают на индивидуальном оборудовании, мощность которого варьируется от умных часов до суперкомпьютеров и нескольких прозрачно реконфигурируемых серверных ферм. [2] Базы данных также масштабируются вертикально для работы на 64-битных микропроцессорах , многоядерных ЦП и больших многопроцессорных процессорах с многопоточной обработкой данных , используя многопоточные реализации.
Полное использование конфигурации оборудования требует различных методов блокировки, начиная от блокировки всей базы данных и целых таблиц, блоков диска и отдельных строк таблицы. Соответствующая гранулярность блокировки зависит от рабочей нагрузки. Чем меньше заблокированный объект, тем меньше вероятность того, что запросы к базе данных будут блокировать друг друга, пока оборудование простаивает. Обычно блокировки строк необходимы для поддержки приложений обработки транзакций большого объема за счет накладных расходов на обработку для управления большим количеством блокировок. [3]
Кроме того, некоторые системы гарантируют, что запрос видит согласованное по времени представление базы данных, блокируя данные, которые проверяет запрос, чтобы предотвратить изменение обновления, останавливая работу. В качестве альтернативы, некоторые базы данных используют согласованность чтения нескольких версий, чтобы избежать (блокировки) блокировок чтения, при этом по-прежнему предоставляя согласованные результаты запроса. [11]
Другое потенциальное узкое место может возникнуть в некоторых системах, когда много запросов пытаются получить доступ к одним и тем же данным одновременно. Например, в системах OLTP много транзакций могут пытаться вставить данные в одну и ту же таблицу одновременно. В системе без общего доступа в любой момент времени все такие вставки обрабатываются одним сервером, который управляет этим разделом ( шардом ) таблицы, возможно, перегружая его, в то время как остальная часть системы мало что делает. Многие такие таблицы используют порядковый номер в качестве своего первичного ключа, который увеличивается для каждой новой вставленной строки. Индекс для этого ключа также может испытывать конкуренцию (перегрев) при обработке этих вставок. Одним из решений этой проблемы является изменение порядка цифр первичного ключа . Это распределяет вставки как в таблицу, так и в ключ по нескольким частям базы данных. [12]
Базовый метод — разбить большие таблицы на несколько разделов на основе диапазонов значений в ключевом поле. Например, данные за каждый год могут храниться на отдельном диске или на отдельном компьютере. Разделение снимает ограничения на размеры одной таблицы.
Реплицированные базы данных поддерживают копии таблиц или баз данных на нескольких компьютерах. Этот метод масштабирования особенно удобен для редко или никогда не обновляемых данных, таких как история транзакций или налоговые таблицы. [6]
Для масштабирования за пределы одного компьютера используются различные подходы. NonStop SQL от HP Enterprise использует архитектуру «ничего общего» , в которой ни данные, ни память не используются совместно на границах сервера. Координатор направляет запросы к базе данных на нужный сервер. Эта архитектура обеспечивает почти линейную масштабируемость.
Широко поддерживаемый стандарт X/Open XA использует глобальный монитор транзакций для координации распределенных транзакций среди полуавтономных транзакционных ресурсов, совместимых с XA.
Oracle RAC использует другую модель для достижения масштабируемости, основанную на архитектуре «общего доступа ко всему». Этот подход включает подход общего диска , который позволяет нескольким компьютерам получать доступ к любому диску в кластере. Сетевое хранилище (NAS) и сети хранения данных (SAN) в сочетании с локальными сетями и технологией Fibre Channel позволяют реализовать такие конфигурации. Подход включает «общий» логический кэш, в котором данные, которые были кэшированы в памяти на сервере, становятся доступными для других серверов без необходимости повторного считывания данных с диска. Каждая страница перемещается с сервера на сервер для удовлетворения запросов. Обновления обычно происходят очень быстро, так что «популярная» страница может быть обновлена несколькими транзакциями с небольшой задержкой. Утверждается, что этот подход поддерживает кластеры, содержащие до 100 серверов. [13]
Некоторые исследователи подвергают сомнению неотъемлемые ограничения систем управления реляционными базами данных . Например, GigaSpaces утверждает, что для достижения производительности и масштабируемости требуется архитектура на основе пространства . Base One приводит доводы в пользу экстремальной масштабируемости в рамках основной технологии реляционных баз данных. [14]
{{cite journal}}: Цитировать журнал требует |journal=( помощь )