Индекс диапазона блоков или BRIN — это метод индексации базы данных . Они предназначены для повышения производительности с чрезвычайно большими [i] таблицами.
Индексы BRIN обеспечивают те же преимущества, что и горизонтальное разбиение или сегментирование , но без необходимости явного объявления разделов. [1]
BRIN применим к индексу в большой таблице, где значение ключа индекса легко сортируется и оценивается с помощью функции MinMax. [ii]
BRIN были первоначально предложены Альваро Эррерой из 2ndQuadrant в 2013 году как «индексы Minmax». [2] Реализации до сих пор тесно связаны с внутренней реализацией и методами хранения для таблиц базы данных. Это делает их эффективными, но ограничивает их определенными поставщиками. До сих пор PostgreSQL является единственным поставщиком, который объявил о живом продукте с этой конкретной функцией в PostgreSQL 9.5. [3] [4] Другие поставщики описали некоторые похожие функции, [2] включая Oracle , [5] [6] Netezza «карты зон», [7] Infobright «пакеты данных», [8] MonetDB [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 Smart Scanning, [6] заключается в использовании этого типа индекса с приложениями Big Data или хранилищами данных , где известно, что почти вся таблица не имеет отношения к интересующему диапазону. 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 эффективен.
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 впервые появилась в 2013 году. [2] BRIN появился в версии 9.5 PostgreSQL в начале 2016 года. [15] [23]
{{cite web}}: Отсутствует или пусто |url=( помощь ){{cite web}}: Отсутствует или пусто |url=( помощь )