Индекс диапазона блоков
Индекс диапазона блоков или BRIN — это метод индексации базы данных . Они предназначены для повышения производительности при чрезвычайно больших [я] столы.
Индексы BRIN предоставляют те же преимущества, что и горизонтальное секционирование или сегментирование , но без необходимости явного объявления секций. [1]
BRIN применим к индексу большой таблицы, где значение ключа индекса легко сортируется и оценивается с помощью функции MinMax . [ii]
Первоначально BRIN были предложены Альваро Эррерой из 2ndQuadrant в 2013 году как «индексы Minmax». [2] До сих пор реализации тесно связаны с внутренней реализацией и методами хранения таблиц базы данных. Это делает их эффективными, но ограничивает их использование конкретными поставщиками. На данный момент PostgreSQL — единственный поставщик, анонсировавший действующий продукт с этой специфической функцией — PostgreSQL 9.5. [3] [4] Другие поставщики описали некоторые аналогичные функции, [2] включая Oracle , [5] [6] Netezza «карты зон», [7] Infobright , «Пакеты данных» [8] МонетБД [9] и Apache Hive с ORC/Parquet. [10]
Дизайн
[ редактировать ]
BRIN работает путем «суммирования» больших блоков данных в компактную форму, которую можно эффективно протестировать и исключить многие из них из запроса к базе данных на раннем этапе. Эти тесты исключают большой блок данных для каждого сравнения. Уменьшая объем данных на столь раннем этапе, как путем представления больших блоков в виде небольших кортежей, так и путем исключения многих блоков, BRIN существенно уменьшает объем подробных данных, которые должны быть проверены узлом базы данных построчно. [11]
Хранение данных в больших базах данных является многоуровневым и фрагментированным, при этом хранилище таблиц организовано в «блоки». Каждый блок содержит примерно 1 МБ в каждом фрагменте. [iii] [13] и они извлекаются путем запроса определенных блоков с уровня дискового хранилища. BRIN — это легкий сводный уровень в памяти, расположенный над ним: каждый кортеж в индексе суммирует один блок в зависимости от диапазона содержащихся в нем данных: его минимальные и максимальные значения, а также если блок содержит какие-либо ненулевые данные для столбца ( с) представляет интерес. [14]
В отличие от традиционного индекса, который определяет области таблицы, содержащие интересующие значения, BRIN действует как «отрицательные индексы». [5] показывая блоки, которые заведомо не представляют интереса и поэтому не нуждаются в дальнейшей обработке.
Некоторые простые тесты показывают пятикратное улучшение производительности поиска при сканировании индекса по сравнению с неиндексированной таблицей. [3] По сравнению с B-деревьями они позволяют избежать затрат на обслуживание. [2]
Поскольку BRIN очень легкие, их можно полностью хранить в памяти, что позволяет избежать перегрузки диска во время сканирования. То же самое может быть не так с B-деревом: B-дереву требуется узел дерева для каждых примерно N строк в таблице, где N — емкость одного узла, поэтому размер индекса велик. Поскольку BRIN требует только кортежа для каждого блока (из многих строк), индекс становится достаточно маленьким, чтобы определить разницу между диском и памятью. Для «узкого» стола [iv] объем индекса B-дерева приближается к объему самой таблицы; BRIN может составлять всего 5-15% от него. [15]
Преимущества
[ редактировать ]Поиск и индексное сканирование
[ редактировать ]В индексе большой базы данных обычно используются алгоритмы B-дерева . BRIN не всегда является заменой B-дерева, это усовершенствование последовательного сканирования индекса с особыми (и потенциально большими) преимуществами, когда индекс удовлетворяет определенным условиям упорядочивания и целью поиска является узкий набор эти ценности. В общем случае со случайными данными B-дерево все же может быть лучше. [3]
Особое преимущество метода BRIN, совместное с интеллектуальным сканированием Oracle Exadata, [6] Речь идет об использовании этого типа индекса с большими данными или приложениями хранилищ данных , где известно, что почти вся таблица не имеет отношения к интересующему диапазону. В таких случаях BRIN позволяет запрашивать таблицу, извлекая только те блоки, которые могут содержать интересующие данные, и исключая те, которые явно выходят за пределы диапазона или не содержат данных для этого столбца.
Вставлять
[ редактировать ]Регулярная проблема при обработке больших таблиц заключается в том, что для извлечения требуется использование индекса, но поддержание этого индекса замедляет добавление новых записей. Типичная практика заключалась в группировке дополнений и добавлении их как единой массовой транзакции или в удалении индекса, добавлении пакета новых записей и последующем воссоздании индекса. Оба эти фактора мешают одновременным операциям чтения/записи и могут оказаться невозможными в некоторых непрерывно работающих предприятиях. [16]
С BRIN замедление поддержания индекса значительно меньше по сравнению с B-деревом. [17] Вонг сообщает, что B-дерево замедлило добавление в неиндексированную таблицу размером 10 ГБ на 85%, но сопоставимый BRIN имел накладные расходы всего на 11%. [1]
Создание индекса
[ редактировать ]BRIN может быть создан для очень больших данных, где B-дерево потребует горизонтального секционирования. [14]
Создание BRIN также происходит намного быстрее, чем B-дерева, на 80%. [1] Это было бы полезным улучшением рефакторинга существующих приложений баз данных, использующих подход «отбросить-добавить-переиндексировать», не требуя изменений кода.
Выполнение
[ редактировать ]Зависимость от порядка таблиц
[ редактировать ]Несколько BRIN могут быть определены для разных столбцов в одной таблице. Однако существуют ограничения.
BRIN эффективны только в том случае, если порядок значений ключей соответствует организации блоков на уровне хранения. [13] [15] В простейшем случае это может потребовать физического упорядочения таблицы, которое часто является порядком создания строк в ней, чтобы соответствовать порядку ключа. Если этот ключ является датой создания, это может быть тривиальным требованием. [14] : 9
Если данные действительно случайны или если в «горячей» базе данных происходит сильное изменение ключевых значений, предположения, лежащие в основе BRIN, могут не сработать. Все блоки содержат записи, «представляющие интерес», поэтому лишь немногие из них могут быть исключены на раннем этапе фильтром диапазона BRIN.
В большинстве случаев BRIN ограничивается одним индексом для каждой таблицы. Можно определить несколько BRIN, но, скорее всего, только один из них будет иметь подходящий порядок. Если два (или более) индекса имеют схожее поведение при упорядочении, возможно и полезно определить несколько BRIN в одной таблице. Очевидным примером является случай, когда и дата создания, и столбец Record_id монотонно увеличиваются с последовательностью создания записи. В других случаях значение ключа может не быть монотонным, но при условии, что внутри физического порядка записи все еще существует сильная группировка, BRIN эффективен.
Индексы хранения Exadata
[ редактировать ]BRIN имеет некоторое сходство с » Oracle Exadata « Индексами хранения . [2] [5] [18] В архитектуре Exadata присутствует четкая концепция «уровня хранения». Данные таблицы хранятся в блоках или «ячейках хранения» на серверах хранения. Эти ячейки хранения непрозрачны для сервера хранения и возвращаются в ядро базы данных по запросу по их идентификатору. Ранее узлы базы данных должны были запросить все ячейки хранилища для их сканирования. [6]
Индексы хранения обеспечивают сокращение данных на этом уровне: эффективно указывают разделы, которые больше не представляют интереса. [13] [v] [19] Индекс хранения загружается в память на сервере хранения, поэтому при выдаче запроса на ячейки он может быть основан на значениях поиска. Они сравниваются с индексом хранения, а затем в узел базы данных необходимо вернуть только соответствующие ячейки.
Преимущества производительности при использовании индекса хранения наиболее очевидны, когда индексированный столбец содержит много нулевых значений . Огромный выигрыш в производительности достигается при сканировании разреженных данных . [20]
Разработка
[ редактировать ]Разработка для PostgreSQL осуществлялась в рамках проекта AXLE (Advanced Analytics for Extremely Large European Databases). [21] Эта работа частично финансировалась Седьмой рамочной программой Европейского Союза (FP7/2007-2013). [22]
PostgreSQL
[ редактировать ]Реализация PostgreSQL впервые была очевидна в 2013 году. [2] BRIN появился в версии PostgreSQL 9.5 в начале 2016 года. [15] [23]
См. также
[ редактировать ]Примечания
[ редактировать ]- ^ «Большой» здесь относится к количеству строк в таблице , а не к размерам полей или общему размеру.
- ^ Функция, которая эффективно оценивает большое количество элементов данных и возвращает их минимальное и максимальное значения. Понятия «минимум» и «максимум» являются широкими и могут применяться к любому типу данных или их комбинациям, поддающимся сортировке .
- ^ PostgreSQL имеет размер фрагмента BRIN по умолчанию 128 × 8 КБ страниц или 1 МБ. [3] Oracle называет эти «области хранения» и присваивает им размер по умолчанию 1 МБ. [12]
- ^ Столбцы таблицы едва шире индексированных столбцов.
- ^ Фут [13] описывает индекс как содержащий «флаг, указывающий, существуют ли какие-либо нули». Вероятно, это опечатка: Oracle описывает их как «отрицательные индексы», где «они определяют области, которые определенно не будут содержать значения». [5] В таком случае флаг можно было бы более четко описать как обозначающий либо « Существуют только значения NULL», либо «Существуют любые значения , отличные от NULL».
Ссылки
[ редактировать ]- ^ Jump up to: а б с Марк Вонг (10 октября 2014 г.). «Загрузка таблиц и создание индексов B-дерева и диапазона блоков» . Проект ОСЬ .
- ^ Jump up to: а б с д и Альваро Эррера (14 июня 2013 г.). «Минмакс-индексы» . ПГ Хакеры .
- ^ Jump up to: а б с д «Что нового в PostgreSQL 9.5» . ПостгреСБЛ .
- ^ «Глава 62. Индексы BRIN» . Документация PostgreSQL 9.5.0 . 2016.
- ^ Jump up to: а б с д Аруп Нанда (май – июнь 2011 г.). «Умное сканирование соответствует индексам хранения» . Журнал Оракул . Оракул .
- ^ Jump up to: а б с «Понимание индексов хранения в Oracle Exadata» . 2 июня 2015 г.
- ^ «В Netezza всегда используйте целочисленные ключи соединения для хорошего сжатия, карт зон и соединений» . Нетезза. 2010.
- ^ «Пакеты данных» . Инфобрайт . Архивировано из оригинала 27 июня 2009 г.
- ^ «Совместное сканирование: динамическое разделение полосы пропускания в СУБД». 2007. стр. 723–734. CiteSeerX 10.1.1.108.2662 .
- ^ «Оптимизация улья с помощью индексов, фильтров Блума и статистики» . Йорн Франке. 2015. Архивировано из оригинала 4 марта 2016 г. Проверено 24 мая 2016 г.
- ^ Эррера, Альваро (7 ноября 2014 г.). «commitdiff — BRIN: Индексы диапазона блоков» . git.postgresql.org . Проверено 3 октября 2017 г.
- ^ «Когда используются индексы хранения Exadata?» . OakTable.net .
- ^ Jump up to: а б с д Ричард Фут (4 октября 2012 г.). «Индексы хранения Exadata – Часть I» .
- ^ Jump up to: а б с Марк Вонг (10 марта 2015 г.). «Презентация производительности PostgreSQL» (PDF) . стр. 7–10.
- ^ Jump up to: а б с «Индексы блочного диапазона (BRIN) в PostgreSQL 9.5» . Питонская сладость . 22 мая 2015 г.
- ^ Петр Елинек (28 ноября 2014 г.). «Прогресс в онлайн-обновлении» . Проект ОСЬ .
- ^ Марк Вонг (10 октября 2014 г.). «Накладные расходы на индекс в растущей таблице» . 2-йквадрант | Постгреск .
- ^ «Лучшие практики применения машины базы данных Oracle Sun для хранения данных». Оракул. 1094934.1.
{{cite web}}: Отсутствует или пусто|url=( помощь ) - ^ Марк Филдинг (20 июля 2010 г.). «Самый сокровенный секрет Exadata: индексы хранения» .
- ^ Керри Осборн (10 августа 2010 г.). «Oracle Exadata – индексы хранения» .
- ^ «Проект AXLE (Расширенная аналитика для чрезвычайно больших европейских баз данных)» . 2014.
- ^ «Седьмая рамочная программа Европейского Союза (FP7/2007-2013) в рамках грантового соглашения № 318633».
{{cite web}}: Отсутствует или пусто|url=( помощь ) - ^ Альваро Эррера (07 ноября 2014 г.). «BRIN: Индексы диапазона блоков» . ПостгреСБЛ . Проверено 14 января 2016 г.