Un índice de rango de bloques o BRIN es una técnica de indexación de bases de datos . Su objetivo es 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 de una tabla que es grande y donde el valor de la clave del índice se ordena 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] Las implementaciones hasta ahora están estrechamente acopladas a las técnicas de implementación y almacenamiento internas para las tablas de la base de datos. Esto las hace eficientes, pero las 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] Netezza 'zone maps', [7] Infobright 'data packs', [8] MonetDB [9] y Apache Hive con ORC/Parquet. [10]
BRIN funciona "resumiendo" grandes bloques de datos en un formato compacto, que puede probarse 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 grandes bloques 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 bases de datos grandes se realiza en capas y fragmentos, y el almacenamiento de tablas se organiza 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 es una capa de resumen liviana en memoria por encima de esto: cada tupla en el índice resume un bloque en cuanto al rango de los datos que contiene: sus valores mínimo y máximo, y si el bloque contiene algún dato no nulo para la(s) columna(s) de interés. [14]
A diferencia de un índice tradicional que localiza 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 ser procesados 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 la sobrecarga de mantenimiento. [2]
Como los BRIN son tan livianos, pueden almacenarse completamente en la memoria, evitando así la sobrecarga del disco durante el escaneo. Puede que no suceda lo mismo con el árbol B: el árbol B requiere un nodo de árbol por cada N filas aproximadamente 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 el 5-15% de ella. [15]
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 del 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 reducido de estos valores. En el caso general, con datos aleatorios, el árbol B puede seguir siendo 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 puedan contener datos de interés y excluyendo aquellos que están claramente fuera del rango o no contienen datos para esta columna.
Un problema habitual en el procesamiento de tablas de gran tamaño es que la recuperación requiere el uso de un índice, pero el mantenimiento de este índice ralentiza la incorporación de nuevos registros. Las prácticas típicas han sido agrupar las incorporaciones y agregarlas como una única transacción masiva, o bien eliminar el índice, agregar el lote de nuevos registros y luego volver a crear el índice. Ambas prácticas interrumpen las operaciones de lectura y escritura simultáneas y pueden no ser posibles en algunas empresas que operan de forma continua. [16]
Con BRIN, la desaceleración del mantenimiento del índice se reduce mucho en comparación con B-tree. [17] Wong informa que B-tree ralentizó las adiciones a una tabla de 10 GB no indexada en un 85%, pero un BRIN comparable solo tuvo una sobrecarga del 11%. [1]
BRIN se puede crear para datos extremadamente grandes donde el árbol B requeriría una partición horizontal. [14]
La creación del BRIN también es mucho más rápida que la de un árbol B, en un 80 %. [1] Esto sería una mejora útil para refactorizar las aplicaciones de bases de datos existentes que utilizan el enfoque de eliminar-agregar-reindexar, sin necesidad de realizar cambios en el código.
Se pueden definir varios BRIN para distintas columnas de una misma tabla. Sin embargo, existen restricciones.
Los BRIN solo son eficientes si el orden de los valores de 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 que el orden físico de la tabla, que a menudo es el orden de creación de las filas dentro de ella, coincida con el orden de la clave. Cuando esta clave es una fecha de creación, ese 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 es posible que el filtro de rango BRIN excluya algunos de ellos al principio.
En la mayoría de los casos, BRIN está restringido a un único índice por tabla. Se pueden definir varios BRIN, pero es probable que solo uno tenga un orden 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 cuando tanto la fecha de creación como la columna record_id aumentan de forma monótona con la secuencia de creación de registros. En otros casos, el valor de la clave puede no ser monótono, pero siempre que exista una agrupación sólida dentro del orden físico del registro, BRIN es eficaz.
BRIN tiene algunas similitudes con los " Índices de almacenamiento " de Oracle Exadata . [2] [5] [18] Exadata tiene el concepto sólido de una "capa de almacenamiento" en su pila de arquitectura. Los datos de las tablas se almacenan 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 base de datos a pedido, por su identificador. Previamente, los nodos de la base de datos debían solicitar todas las celdas de almacenamiento para poder escanearlas. [6]
Los índices de almacenamiento permiten la eliminación de datos en esta capa, lo que indica de manera eficiente las secciones que ya no son de 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 predecir con valores de búsqueda. Estos se comparan con el índice de almacenamiento y luego solo es necesario devolver las celdas relevantes 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 dispersos . [20]
El desarrollo para PostgreSQL se llevó a cabo como parte del proyecto AXLE (Advanced Analytics for Extremely Large European Databases) [21]. Este trabajo fue financiado parcialmente por el Séptimo Programa Marco de la Unión Europea (FP7/2007-2013). [22]
La implementación para PostgreSQL se hizo evidente por primera vez en 2013. [2] BRIN apareció en la versión 9.5 de PostgreSQL a principios de 2016. [15] [23]
{{cite web}}: Falta o está vacío |url=( ayuda ){{cite web}}: Falta o está vacío |url=( ayuda )