Un índice de rango de bloques o BRIN es una técnica de indexación de bases de datos . Están destinados a mejorar el rendimiento con tablas [i] extremadamente grandes .
Los índices BRIN proporcionan beneficios similares a la partición o fragmentación horizontal, pero sin necesidad de declarar particiones explícitamente. [1]
Un BRIN es aplicable a un índice en una tabla que es grande y donde el valor de la clave del índice se clasifica y evalúa fácilmente con una función MinMax . [ii]
Los BRIN fueron propuestos originalmente por Álvaro Herrera de 2ndQuadrant en 2013 como 'índices Minmax'. [2] Hasta ahora, las implementaciones están estrechamente relacionadas con la implementación interna y las técnicas de almacenamiento de las tablas de la base de datos. Esto los hace eficientes, pero los limita a proveedores particulares. Hasta ahora, PostgreSQL es el único proveedor que ha anunciado un producto en vivo con esta característica específica, en PostgreSQL 9.5. [3] [4] Otros proveedores han descrito algunas características similares, [2] incluyendo Oracle , [5] [6] 'mapas de zona' de Netezza , [7] 'paquetes de datos' de Infobright , [8] MonetDB [9]y Apache Hive con ORC / Parquet. [10]
Diseño
BRIN funciona "resumiendo" grandes bloques de datos en una forma compacta, que se puede probar de manera eficiente para excluir muchos de ellos de una consulta de base de datos, desde el principio. Estas pruebas excluyen un gran bloque de datos para cada comparación. Al reducir el volumen de datos tan pronto, tanto al representar bloques grandes como pequeñas tuplas como al eliminar muchos bloques, BRIN reduce sustancialmente la cantidad de datos detallados que debe examinar el nodo de la base de datos fila por fila. [11]
El almacenamiento de datos en grandes bases de datos está dividido en capas y fragmentado, con el almacenamiento de la tabla organizado en "bloques". Cada bloque contiene quizás 1 MB en cada fragmento [iii] [13] y se recuperan solicitando bloques específicos de una capa de almacenamiento basada en disco. BRIN son una capa de resumen en memoria ligera por encima de esto: cada tupla en el índice resume un bloque en cuanto al rango de los datos contenidos en él: sus valores mínimo y máximo, y si el bloque contiene datos no nulos para la columna ( s) de interés. [14]
A diferencia de un índice tradicional que ubica las regiones de la tabla que contienen valores de interés, BRIN actúa como "índices negativos", [5] mostrando los bloques que definitivamente no son de interés y por lo tanto no necesitan procesarse más.
Algunos puntos de referencia simples sugieren una mejora de cinco veces en el rendimiento de búsqueda con un escaneo de índice, en comparación con la tabla no indexada. [3] En comparación con los árboles B, evitan los gastos generales de mantenimiento. [2]
Como los BRIN son tan livianos, pueden guardarse completamente en la memoria, evitando así la sobrecarga del disco durante el escaneo. Puede que no ocurra lo mismo con el árbol B: el árbol B requiere un nodo de árbol por cada aproximadamente N filas en la tabla, donde N es la capacidad de un solo nodo, por lo que el tamaño del índice es grande. Como BRIN solo requiere una tupla para cada bloque (de muchas filas), el índice se vuelve lo suficientemente pequeño como para marcar la diferencia entre el disco y la memoria. Para una tabla 'estrecha' [iv], el volumen del índice del árbol B se aproxima al de la tabla misma; el BRIN puede ser solo del 5 al 15%. [15]
Ventajas
Búsqueda e índice de exploración
Un índice de base de datos grande normalmente utilizaría algoritmos de árbol B. BRIN no siempre es un sustituto del árbol B, es una mejora en el escaneo secuencial de un índice, con ventajas particulares (y potencialmente grandes) cuando el índice cumple condiciones particulares para ser ordenado y para que el objetivo de búsqueda sea un conjunto estrecho de estos valores. En el caso general, con datos aleatorios, el árbol B aún puede ser superior. [3]
Una ventaja particular de la técnica BRIN, compartida con Smart Scanning de Oracle Exadata, [6] está en el uso de este tipo de índice con aplicaciones de Big Data o data warehousing , donde se sabe que casi toda la tabla es irrelevante para el rango. de interés. BRIN permite consultar la tabla en tales casos recuperando únicamente los bloques que pueden contener datos de interés y excluyendo aquellos que están claramente fuera del rango o que no contienen datos para esta columna.
Insertar
Un problema habitual con el procesamiento de tablas grandes es que la recuperación requiere el uso de un índice, pero mantener este índice ralentiza la adición de nuevos registros. Las prácticas típicas han sido agrupar las adiciones y agregarlas como una sola transacción masiva, o eliminar el índice, agregar el lote de nuevos registros y luego volver a crear el índice. Ambos son disruptivos para las operaciones de lectura / escritura simultáneas y pueden no ser posibles en algunas empresas que operan continuamente. [dieciséis]
Con BRIN, la desaceleración por mantener el índice se reduce mucho en comparación con el árbol B. [17] Wong informa que B-tree ralentizó las adiciones a una tabla no indexada de 10GB en un 85%, pero un BRIN comparable solo tuvo una sobrecarga del 11%. [1]
Creación de índice
BRIN se puede crear para datos extremadamente grandes donde el árbol B requeriría particiones horizontales. [14]
Crear el BRIN también es mucho más rápido que para un árbol B, en un 80%. [1] Esto sería una mejora útil para refactorizar las aplicaciones de bases de datos existentes que usan el enfoque de eliminar-agregar-reindexar, sin requerir cambios de código.
Implementación
Dependencia del pedido de mesa
Se pueden definir varios BRIN para diferentes columnas en una sola tabla. Sin embargo, existen restricciones.
Los BRIN solo son eficientes si el orden de los valores clave sigue la organización de los bloques en la capa de almacenamiento. [13] [15] En el caso más simple, esto podría requerir el orden físico de la tabla, que a menudo es el orden de creación de las filas dentro de ella, para que coincida con el orden de la clave. Cuando esta clave es una fecha de creación, puede ser un requisito trivial. [14] : 9
Si los datos son verdaderamente aleatorios, o si hay mucha rotación de los valores clave en una base de datos 'caliente', las suposiciones subyacentes a BRIN pueden fallar. Todos los bloques contienen entradas "de interés" y muy pocos pueden ser excluidos desde el principio por el filtro de rango BRIN.
En la mayoría de los casos, BRIN está restringido a un solo índice por tabla. Se pueden definir varios BRIN, pero es probable que solo uno tenga un pedido adecuado. Si dos (o más) índices tienen un comportamiento de ordenación similar, puede ser posible y útil definir varios BRIN en la misma tabla. Un ejemplo obvio es donde tanto la fecha de creación como la columna record_id aumentan monótonamente con la secuencia de creación del registro. En otros casos, el valor de la clave puede no ser monótono, pero siempre que haya una agrupación fuerte dentro del orden físico del registro, BRIN es efectivo.
Índices de almacenamiento de Exadata
BRIN tiene algunas similitudes con los " índices de almacenamiento " de Oracle Exadata . [2] [5] [18] Exadata tiene el fuerte concepto de una 'capa de almacenamiento' en su pila de arquitectura. Los datos de la tabla se guardan en bloques o 'celdas de almacenamiento' en los servidores de almacenamiento. Estas celdas de almacenamiento son opacas para el servidor de almacenamiento y se devuelven al motor de la base de datos a pedido, por su identificador. Previamente, los nodos de la base de datos deben solicitar todas las celdas de almacenamiento para poder escanearlas. [6]
Storage Indexes proporciona la poda de datos en esta capa: indica de manera eficiente las secciones que no son de mayor interés. [13] [v] [19] El índice de almacenamiento se carga en la memoria del servidor de almacenamiento, de modo que cuando se emite una solicitud de celdas, se puede predicar con valores de búsqueda. Estos se comparan con el índice de almacenamiento y luego solo las celdas relevantes deben devolverse al nodo de la base de datos.
Las ventajas de rendimiento con un índice de almacenamiento son más evidentes cuando la columna indexada contiene muchos valores nulos . Se obtienen enormes ventajas de rendimiento al escanear datos escasos . [20]
Desarrollo
El desarrollo de PostgreSQL se llevó a cabo como parte del proyecto AXLE (Análisis avanzado para bases de datos europeas extremadamente grandes) [21]. Este trabajo fue parcialmente financiado por el Séptimo Programa Marco de la Unión Europea (FP7 / 2007-2013). [22]
PostgreSQL
La implementación de PostgreSQL fue evidente por primera vez en 2013. [2] BRIN apareció en la versión 9.5 de PostgreSQL a principios de 2016. [15] [23]
Ver también
- Fragmentación
Notas
- ^ 'Grande' aquí se refiere al número de filas en una tabla , en lugar de los tamaños de campo o el tamaño total.
- ^ Una función que evalúa de manera eficiente una gran cantidad de elementos de datos y devuelve sus valores mínimo y máximo. Los conceptos de "mínimo" y "máximo" son amplios y pueden aplicarse a cualquier tipo de datos, o sus combinaciones, que se puedan ordenar .
- ^ PostgreSQL tiene un tamaño de fragmento BRIN predeterminado de 128 × 8k páginas, o 1 MB. [3] Oracle denomina estas "regiones de almacenamiento" y les da un tamaño predeterminado de 1 MB. [12]
- ^ Las columnas de la tabla son apenas más anchas que las columnas indexadas.
- ^ Foote [13] describe el Índice como sosteniendo "una bandera para indicar si existen Nulos". Probablemente se trate de un error tipográfico: Oracle los describe como "índices negativos" donde "identifican las áreas que definitivamente no contendrán los valores" [5] En tal caso, la bandera se describiría más claramente como " Solo nulos exist "o si"existen no nulos ".
Referencias
- ^ a b c Mark Wong (10 de octubre de 2014). "Carga de tablas y creación de índices de rango de bloque y árbol B" . Proyecto AXLE .
- ^ a b c d e Álvaro Herrera (14 de junio de 2013). "Índices Minmax" . Pg Hackers .
- ^ a b c d "Novedades de PostgreSQL 9.5" . PostgreSQL .
- ^ "Capítulo 62. Índices BRIN" . Documentación de PostgreSQL 9.5.0 . 2016.
- ^ a b c d Arup Nanda (mayo-junio de 2011). "Los análisis inteligentes cumplen con los índices de almacenamiento" . Revista Oracle . Oracle .
- ^ a b c "Comprensión de los índices de almacenamiento en Oracle Exadata" .
- ^ "Con Netezza, utilice siempre claves de combinación de enteros para una buena compresión, mapas de zona y combinaciones" . Netezza. 2010.
- ^ "Paquetes de datos" . Infobright . Archivado desde el original el 27 de junio de 2009.
- ^ "Exploraciones cooperativas: compartir ancho de banda dinámico en un DBMS". MonetDB. 2007. CiteSeerX 10.1.1.108.2662 . Cite journal requiere
|journal=
( ayuda ) - ^ "Optimizaciones de Hive con índices, filtros Bloom y estadísticas" . Jörn Franke. 2015.
- ^ Herrera, Alvaro (7 de noviembre de 2014). "commitdiff - BRIN: índices de rango de bloque" . git.postgresql.org . Consultado el 3 de octubre de 2017 .
- ^ "¿Cuándo se utilizan los índices de almacenamiento de Exadata?" . OakTable.net .
- ^ a b c d Richard Foote (4 de octubre de 2012). "Índices de almacenamiento de Exadata - Parte I" .
- ^ a b c Mark Wong (10 de marzo de 2015). "Presentación de rendimiento de PostgreSQL" (PDF) . págs. 7-10.
- ^ a b c "Índices de rango de bloque (BRIN) en PostgreSQL 9.5" . Dulzura de pitón . 22 de mayo de 2015.
- ^ Petr Jelinek (28 de noviembre de 2014). "Progreso en la actualización en línea" . Proyecto AXLE .
- ^ Mark Wong (10 de octubre de 2014). "Índice de gastos generales en una mesa en crecimiento" .
- ^ "Mejores prácticas de aplicación de máquina de base de datos Oracle Sun para almacenamiento de datos". Oráculo. 1094934.1. Falta o vacío
|url=
( ayuda ) - ^ Marc Fielding (20 de julio de 2010). "El secreto mejor guardado de Exadata: índices de almacenamiento" .
- ^ Kerry Osborne (10 de agosto de 2010). "Oracle Exadata - Índices de almacenamiento" .
- ^ "Proyecto AXLE (Advanced Analytics for Extremely Large European Databases)" . 2014.
- ^ "Séptimo Programa Marco de la Unión Europea (FP7 / 2007-2013) bajo acuerdo de subvención n ° 318633". Falta o vacío
|url=
( ayuda ) - ^ Álvaro Herrera (7 de noviembre de 2014). "BRIN: Índices de rango de bloque" . PostgreSQL . Consultado el 14 de enero de 2016 .