stringtranslate.com

Índice de rango de bloques

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]

Diseño

Estructura del índice del árbol B
Estructura del índice BRIN

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]

Ventajas

Búsqueda y escaneo de índice

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.

Insertar

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]

Creación de índices

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.

Implementación

Dependencia del orden de las mesas

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.

Índices de almacenamiento de Exadata

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]

Desarrollo

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]

PostgreSQL

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]

Véase también

Notas

  1. ^ "Grande" aquí se refiere a la cantidad de filas en una tabla , en lugar del tamaño de los campos o el tamaño general.
  2. ^ 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 sean ordenables .
  3. ^ PostgreSQL tiene un tamaño de fragmento BRIN predeterminado de 128 × 8k páginas, o 1 MB. [3] Oracle las denomina "regiones de almacenamiento" y les da un tamaño predeterminado de 1 MB. [12]
  4. ^ Las columnas de la tabla son apenas más anchas que las columnas indexadas.
  5. ^ Foote [13] describe el índice como un indicador que indica si existen valores nulos. Probablemente se trate de un error tipográfico: Oracle los describe como "índices negativos" en los que "identifican las áreas que definitivamente no contendrán los valores". [5] En tal caso, el indicador se describiría más claramente como indicando " Solo existen valores nulos" o si "existen valores que no sean nulos".

Referencias

  1. ^ abc Mark Wong (10 de octubre de 2014). "Carga de tablas y creación de índices de rango de bloques y árboles B". Proyecto AXLE .
  2. ^ abcde Alvaro Herrera (14 de junio de 2013). "Índices minmax". Pg Hackers .
  3. ^ abcd "Novedades en PostgreSQL 9.5". PostgreSQL .
  4. ^ "Capítulo 62. Índices BRIN". Documentación de PostgreSQL 9.5.0 . 2016.
  5. ^ abcd Arup Nanda (mayo-junio de 2011). "Los análisis inteligentes se unen a los índices de almacenamiento". Oracle Magazine . Oracle .
  6. ^ abc "Descripción de los índices de almacenamiento en Oracle Exadata". 2 de junio de 2015.
  7. ^ "Con Netezza, utilice siempre claves de unión de números enteros para lograr una buena compresión, mapas de zonas y uniones". Netezza. 2010.
  8. ^ "Paquetes de datos". Infobright . Archivado desde el original el 27 de junio de 2009.
  9. ^ "Escaneos cooperativos: uso compartido dinámico del ancho de banda en un DBMS". 2007. págs. 723–734. CiteSeerX 10.1.1.108.2662 . 
  10. ^ "Optimizaciones de Hive con índices, filtros Bloom y estadísticas". Jörn Franke. 2015. Archivado desde el original el 4 de marzo de 2016. Consultado el 24 de mayo de 2016 .
  11. ^ Herrera, Alvaro (7 de noviembre de 2014). «commitdiff - BRIN: Block Range Indexes». git.postgresql.org . Consultado el 3 de octubre de 2017 .
  12. ^ "¿Cuándo se utilizan los índices de almacenamiento de Exadata?". OakTable.net .
  13. ^ abcd Richard Foote (4 de octubre de 2012). "Índices de almacenamiento de Exadata: Parte I".
  14. ^ abc Mark Wong (10 de marzo de 2015). "Presentación sobre el rendimiento de PostgreSQL" (PDF) . pp. 7–10.
  15. ^ abc "Índices de rango de bloques (BRIN) en PostgreSQL 9.5". Python Sweetness . 22 de mayo de 2015.
  16. ^ Petr Jelinek (28 de noviembre de 2014). "Avances en la actualización en línea". Proyecto AXLE .
  17. ^ Mark Wong (10 de octubre de 2014). "Sobrecarga de índice en una tabla en crecimiento". 2Ndquadrant | PostgreSQL .
  18. ^ "Prácticas recomendadas para el almacenamiento de datos en aplicaciones Oracle Sun Database Machine". Oracle. 1094934.1. {{cite web}}: Falta o está vacío |url=( ayuda )
  19. ^ Marc Fielding (20 de julio de 2010). "El secreto mejor guardado de Exadata: índices de almacenamiento".
  20. ^ Kerry Osborne (10 de agosto de 2010). "Oracle Exadata – Índices de almacenamiento".
  21. ^ "Proyecto AXLE (Análisis avanzado para bases de datos europeas extremadamente grandes)". 2014.
  22. ^ "Séptimo Programa Marco de la Unión Europea (FP7/2007-2013) en virtud del acuerdo de subvención n° 318633". {{cite web}}: Falta o está vacío |url=( ayuda )
  23. ^ Alvaro Herrera (7 de noviembre de 2014). "BRIN: Índices de rango de bloques". PostgreSQL . Consultado el 14 de enero de 2016 .