Очень большая база данных
( Очень большая база данных изначально написанная очень большая база данных ) или VLDB , [1] — это база данных, содержащая очень большой объем данных, настолько большой, что может потребоваться специализированная методология архитектуры, управления, обработки и обслуживания. [2] [3] [4] [5]
Определение
[ редактировать ]Расплывчатые определения «очень » и «большой» допускают широкую и субъективную интерпретацию, но попытки определить метрику и порог были предприняты. Ранними метриками были размер базы данных в канонической форме посредством нормализации базы данных или время полной операции с базой данных, например резервного копирования . Технологические усовершенствования постоянно меняют то, что считается очень большим . [6] [7]
Одно из определений предполагает, что база данных становится VLDB, когда она «слишком велика, чтобы ее можно было поддерживать в пределах окна возможностей… времени, когда база данных молчит». [8]
Размеры базы данных VLDB
[ редактировать ]Не существует абсолютного количества данных, которые можно было бы привести. Например, нельзя сказать, что любая база данных с объемом данных более 1 ТБ считается VLDB. Этот абсолютный объем данных со временем менялся, поскольку методы компьютерной обработки, хранения и резервного копирования стали лучше справляться с большими объемами данных. [5] Тем не менее, проблемы с VLDB могут начать проявляться при приближении к 1 ТБ. [8] [9] и, скорее всего, появятся при превышении 30 ТБ или около того. [10]
Проблемы ВЛДБ
[ редактировать ]Ключевые области, в которых VLDB могут представлять проблемы, включают настройку, хранение, производительность, обслуживание, администрирование, доступность и ресурсы сервера. [11] : 11
Конфигурация
[ редактировать ]Тщательная настройка баз данных, находящихся в области VLDB, необходима для облегчения или уменьшения проблем, возникающих с базами данных VLDB. [11] : 36–53 [12]
Администрация
[ редактировать ]Сложность управления VLDB может возрастать в геометрической прогрессии для администратора базы данных по мере увеличения размера базы данных. [13]
Доступность и обслуживание
[ редактировать ]При работе с операциями VLDB, связанными с обслуживанием и восстановлением, такими как реорганизация базы данных и копирование файлов, которые были вполне практичны для базы данных, отличной от VLDB, отнимают очень много времени и ресурсов для базы данных VLDB. [14] В частности, обычно невозможно достичь типичного целевого времени восстановления (RTO), максимального ожидаемого времени, в течение которого база данных будет недоступна из-за сбоя, с помощью методов, которые включают копирование файлов с диска или других архивов хранения. [13] Для преодоления этих проблем могут помочь такие методы, как кластеризация, клонированные/реплицированные/резервные базы данных, снимки файлов, снимки хранилища или менеджер резервного копирования, хотя отдельные методы могут иметь ограничения, предостережения, требования к лицензии и инфраструктуре, в то время как некоторые может возникнуть риск потери данных и не достичь целевой точки восстановления (RPO). [15] [16] [13] [17] [18] Для многих систем могут быть приемлемыми только географически удаленные решения. [19]
Резервное копирование и восстановление
[ редактировать ]Лучшей практикой является создание архитектуры резервного копирования и восстановления с учетом общей доступности и непрерывности бизнеса. [20] [21]
Производительность
[ редактировать ]При той же инфраструктуре обычно может наблюдаться снижение производительности, то есть увеличение времени отклика по мере увеличения размера базы данных. При некоторых доступах просто потребуется больше данных для обработки (сканирования), что займет пропорционально больше времени ( линейное время ); в то время как индексы, используемые для доступа к данным, могут немного вырасти в высоту, что, возможно, потребует дополнительного доступа к хранилищу для доступа к данным ( сублинейное время ). [22] Другие последствия могут заключаться в том, что кэширование станет менее эффективным, поскольку можно кэшировать пропорционально меньше данных, и хотя некоторые индексы, такие как B+, автоматически хорошо сохраняются при росте, другие, такие как хеш-таблица, возможно, придется перестроить.
Если увеличение размера базы данных приведет к увеличению количества средств доступа к базе данных, может быть использовано больше серверных и сетевых ресурсов, и риск возникновения конфликтов увеличится. Некоторые решения по восстановлению производительности включают секционирование , кластеризацию , возможно, с сегментированием или использование машины базы данных . [23] : 390 [24]
Разделение
[ редактировать ]Секционирование может помочь в выполнении массовых операций над VLDB, включая резервное копирование и восстановление. [25] массовые перемещения благодаря управлению жизненным циклом информации (ILM), [26] : 3 [27] : 105–118 уменьшение разногласий [27] : 327–329 а также позволяет оптимизировать обработку некоторых запросов. [27] : 215–230
Хранилище
[ редактировать ]Чтобы удовлетворить потребности VLDB, хранилище базы данных должно иметь низкую задержку доступа и конкуренцию , высокую пропускную способность и высокую доступность .
Ресурсы сервера
[ редактировать ]Увеличение размера VLDB может оказать давление на серверные и сетевые ресурсы, а также может возникнуть узкое место, для устранения которого могут потребоваться инвестиции в инфраструктуру. [13] [28]
Отношение к большим данным
[ редактировать ]VLDB — это не то же самое, что большие данные , однако аспект хранения больших данных может включать базу данных VLDB. [2] Тем не менее, некоторые решения для хранения данных, поддерживающие большие данные, с самого начала были разработаны для поддержки больших объемов данных, поэтому администраторы баз данных могут не столкнуться с проблемами VLDB, с которыми могли столкнуться старые версии традиционных СУБД . [29]
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ «Онлайн-документация базы данных Oracle 11g, выпуск 1 (11.1) / Концепции администрирования базы данных» . оракул . 18 очень больших баз данных (VLDB) . Проверено 3 октября 2018 г.
- ^ Jump up to: а б «Очень большая база данных (VLDB)» . Технопедия . Архивировано из оригинала 4 июля 2018 года . Проверено 3 октября 2018 г.
- ^ Гейнс, Р.С. и Р. Гэммилл. Очень большие базы данных: новая область исследований, неофициальный рабочий документ, RAND Corporation
- ^ Журнал обработки данных . Североамериканская издательская компания. 1964. с. 18,58.
- ^ Jump up to: а б Видлейк, Марин (18 сентября 2009 г.). «Что такое VLDB?» . мвидлейк . Архивировано из оригинала 6 октября 2018 года . Проверено 7 октября 2018 г.
- ^ Сидли, Эдгар Х. (1 апреля 1980 г.). Энциклопедия компьютерных наук и технологий: Том 14 - Очень большие системы баз данных с нулевой памятью и марковский источник информации . ЦРК Пресс. стр. 1–18. ISBN 9780824722142 .
- ^ Герритсен, Роб; Морган, Ховард; Зисман, Майкл (июнь 1977 г.). «О некоторых метриках баз данных или что такое очень большая база данных?» . Запись ACM SIGMOD . 9 (1): 50–74. дои : 10.1145/984382.984393 . ISSN 0163-5808 . S2CID 6359244 .
- ^ Jump up to: а б Рэнкинс, Рэй; Дженсен, Пол; Бертуччи, Пол (18 декабря 2002 г.). «21» . Microsoft SQL Server 2000 (2-е изд.). САМС. ISBN 978-0672324673 . Администрирование очень больших баз данных SQL Server.
- ^ «База данных Oracle, выпуск 18 — Руководство по VLDB и секционированию» . Оракул . 1 Введение в очень большие базы данных. Архивировано из оригинала 3 октября 2018 года . Проверено 3 октября 2018 г.
- ^ «Проблема очень большой базы данных: как создать резервную копию и восстановить базы данных объемом 30–100 ТБ» (PDF) . актифио. Архивировано (PDF) из оригинала 19 февраля 2018 г.
- ^ Jump up to: а б Хусейн, Сайед Джаффер (2014). «Настройка и применение лучших практик в очень больших базах данных (VLDB)» (PDF) . Сангам: АЙОУГ. Архивировано (PDF) из оригинала 4 октября 2018 г.
- ^ Чавес, Уорнер (7 января 2015 г.). «10 самых важных вещей, которые необходимо сделать для вашей очень большой базы данных SQL Server» . SQLTURBO . Архивировано из оригинала 13 декабря 2017 года . Проверено 5 октября 2018 г.
- ^ Jump up to: а б с д Фурман, Дмитрий (22 января 2018 г.). Раджеш Сетлем; Майк Вайнер; Сяочэнь Ву (ред.). «SQL Server VLDB в Azure: задачи администратора базы данных стали проще» . MSDN . Архивировано из оригинала 6 октября 2018 года . Проверено 6 октября 2018 г.
- ^ «Специализированные требования к серверам реляционных хранилищ данных» . Ред Брик Системс, Инк . 21 июня 1996 года. Архивировано из оригинала 10 октября 1997 года.
- ^ «Аспекты проектирования кластера» . Краучбейс . Архивировано из оригинала 17 октября 2018 года . Проверено 17 октября 2017 г.
- ^ «Межцентровая репликация (XDCR)» . Краучбейс . Архивировано из оригинала 17 октября 2018 года . Проверено 17 октября 2017 г.
- ^ Чиен, Тим. «Снимки НЕ являются резервными копиями» . Техсеть Oracle . Архивировано из оригинала 7 сентября 2018 года . Проверено 10 октября 2018 г.
- ^ «Использование разделенного зеркала в качестве резервного образа» . Центр знаний IBM . Архивировано из оригинала 9 января 2018 года . Проверено 10 октября 2018 г.
- ^ «Глава 1. Высокая доступность и масштабируемость» . dev.mysql . Архивировано из оригинала 15 декабря 2016 года . Проверено 12 октября 2018 г.
- ^ Брукс, Шарлотта; Люнг, Клем; Мирза, Аслам; Нил, Кертис; Цю, Инь Лэй; Спой, Джон; Вонг, Фрэнсис Т.Х.; Райт, Ян Р. (март 2007 г.). «Глава 1. Определены три сегмента бизнес-решений». Непрерывность бизнеса IBM System Storage: Часть 2. Руководство по решениям . Красные книги IBM. ISBN 978-0738489728 .
- ^ Ахтар, Али Навид; Бухгольц, Джефф; Райан, Майкл; Сетти, Кумар (2012). «Рекомендации по резервному копированию и восстановлению баз данных» . Архивировано из оригинала 29 июня 2018 года . Проверено 12 октября 2012 г.
- ^ Тарик, Овайс (14 июля 2011 г.). «Понимание индексов B+tree и их влияние на производительность» . ovaistariq.net . Архивировано из оригинала 7 февраля 2018 года . Проверено 10 октября 2018 г.
- ^ Шреста, Раджу (2017). Высокая доступность и производительность базы данных в облаке: традиционная репликация «главный-подчиненный» в сравнении с современными решениями на базе кластеров . 7-я Международная конференция по облачным вычислениям и сервисам. Том. 1: БЛИЖЕ. SCITEPRESS – Публикации по науке и технологиям, Lda. дои : 10.5220/0006294604130420 . HDL : 10642/6140 . ISBN 978-989-758-243-1 . Архивировано из оригинала 17 октября 2018 года.
- ^ «Энциклопедия» . Определение: машина базы данных. Архивировано из оригинала 4 июля 2016 года . Проверено 10 октября 2018 г.
- ^ Берлесон, Дональд (26 марта 2015 г.). «Советы по Oracle Backup VLDB» . Берлесон Консалтинг . Архивировано из оригинала 30 июня 2017 года . Проверено 11 октября 2016 г.
- ^ «Разделение Oracle в базе данных Oracle 12c Release 2. Экстремальное управление данными и производительность для каждой системы» (PDF) . Оракул . Март 2017 г. Архивировано (PDF) из оригинала 15 декабря 2017 г. . Проверено 17 октября 2018 г.
- ^ Jump up to: а б с Теске, Томас (8 февраля 2018 г.). Получите максимум от Oracle Partitioning — практическое руководство и справочник (PDF) (выступление). ЦЕРН . Герман Бэр. 40-S2-C01 - Зал Кюри (ЦЕРН): Oracle. Архивировано (PDF) из оригинала 12 октября 2018 г. Проверено 12 октября 2018 г.
{{cite speech}}: CS1 maint: местоположение ( ссылка ) - ^ Стил, Фил; Поггемейер, Лиза; Плетт, Кори (1 августа 2018 г.). «Аспекты производительности серверного оборудования» . Центр ИТ-специалистов Microsoft . Архивировано из оригинала 17 октября 2018 года . Проверено 17 октября 2018 г.
- ^ Ли, Ишань; Манохаран, Сатиамурти (2013). Сравнение производительности баз данных SQL и NoSQL . Тихоокеанская конференция IEEE по коммуникациям, компьютерам и обработке сигналов (PACRIM) 2013 г. IEEE. п. 15. дои : 10.1109/PACRIM.2013.6625441 . ISBN 978-1-4799-1501-9 .
| Основной | |
|---|---|
| Языки | |
| Безопасность | |
| Дизайн |
|
| Программирование | |
| Управление | |
| Списки | |
| См. также | |
