Un DBMS orientado a columnas o DBMS en columnas es un sistema de gestión de bases de datos (DBMS) que almacena tablas de datos por columna en lugar de por fila. El uso práctico de un almacén de columnas frente a un almacén de filas difiere poco en el mundo DBMS relacional . Tanto las bases de datos de columnas como las de filas pueden utilizar lenguajes de consulta de bases de datos tradicionales como SQL para cargar datos y realizar consultas. Tanto las bases de datos de filas como las de columnas pueden convertirse en la columna vertebral de un sistema para proporcionar datos para extracción, transformación, carga (ETL) y visualización de datos comunes.herramientas. Sin embargo, al almacenar datos en columnas en lugar de filas, la base de datos puede acceder con mayor precisión a los datos que necesita para responder una consulta en lugar de escanear y descartar datos no deseados en filas.
Descripción
Fondo
Un sistema de gestión de bases de datos relacionales proporciona datos que representan una tabla bidimensional, de columnas y filas. Por ejemplo, una base de datos puede tener esta tabla:
RowId | EmpId | Apellido | Nombre propio | Salario |
---|---|---|---|---|
001 | 10 | Herrero | José | 60000 |
002 | 12 | Jones | María | 80000 |
003 | 11 | Johnson | Cathy | 94000 |
004 | 22 | Jones | Beto | 55000 |
Esta sencilla tabla incluye un identificador de empleado (EmpId), campos de nombre (Apellido y Nombre) y un salario (Salario). Este formato bidimensional es una abstracción. En una implementación real, el hardware de almacenamiento requiere que los datos se serialicen en una forma u otra.
Las operaciones más costosas que involucran discos duros son las búsquedas . Para mejorar el rendimiento general, los datos relacionados deben almacenarse de manera que se minimice el número de búsquedas. Esto se conoce como localidad de referencia y el concepto básico aparece en varios contextos diferentes. Los discos duros se organizan en una serie de bloques de un tamaño fijo, por lo general lo suficiente para almacenar varias filas de la tabla. Al organizar los datos de la tabla de modo que las filas quepan dentro de estos bloques y al agrupar las filas relacionadas en bloques secuenciales, en muchos casos se minimiza el número de bloques que deben leerse o buscarse, junto con el número de búsquedas.
Una encuesta de Pinnecke et al. [1] cubre técnicas para la hibridación columna / fila a partir de 2017.
Sistemas orientados a hileras
Un método común para almacenar una tabla es serializar cada fila de datos, así:
001: 10, Smith, Joe, 60000;002: 12, Jones, Mary, 80000;003: 11, Johnson, Cathy, 94000;004: 22, Jones, Bob, 55000;
A medida que se insertan datos en la tabla, se le asigna una ID interna, rowid
que se utiliza internamente en el sistema para hacer referencia a los datos. En este caso, los registros tienen rowid
s secuenciales independientes de los asignados por el usuario empid
. En este ejemplo, el DBMS utiliza números enteros cortos para almacenar correos rowid
electrónicos. En la práctica, normalmente se utilizan números más grandes, de 64 bits o de 128 bits.
Los sistemas orientados a filas están diseñados para devolver datos de manera eficiente para una fila completa, o registro, en la menor cantidad de operaciones posible. Esto coincide con el caso de uso común en el que el sistema intenta recuperar información sobre un objeto en particular, por ejemplo, la información de contacto de un usuario en un sistema rolodex o información de producto para un sistema de compras en línea . Al almacenar los datos del registro en un solo bloque en el disco, junto con los registros relacionados, el sistema puede recuperar registros rápidamente con un mínimo de operaciones de disco.
Los sistemas orientados a filas no son eficientes para realizar operaciones de conjunto en toda la tabla, a diferencia de una pequeña cantidad de registros específicos. Por ejemplo, para encontrar todos los registros en la tabla de ejemplo con salarios entre 40.000 y 50.000, el DBMS tendría que escanear completamente toda la tabla en busca de registros coincidentes. Si bien la tabla de ejemplo que se muestra arriba probablemente encajará en un solo bloque de disco, una tabla con incluso unos pocos cientos de filas no lo haría, y se necesitarían múltiples operaciones de disco para recuperar los datos y examinarlos.
Para mejorar el rendimiento de este tipo de operaciones (que son muy comunes, y generalmente el punto de usar un DBMS), la mayoría de los DBMS admiten el uso de índices de bases de datos , que almacenan todos los valores de un conjunto de columnas junto con rowid
punteros de regreso al mesa original. Un índice en la columna de salario se vería así:
55000: 004; 60000: 001;80000: 002;94000: 003;
Como solo almacenan datos individuales, en lugar de filas enteras, los índices son generalmente mucho más pequeños que las tiendas de la tabla principal. El escaneo de este conjunto más pequeño de datos reduce el número de operaciones del disco. Si el índice se usa mucho, puede reducir drásticamente el tiempo para las operaciones comunes. Sin embargo, el mantenimiento de índices agrega gastos generales al sistema, especialmente cuando se escriben nuevos datos en la base de datos. Los registros no solo deben almacenarse en la tabla principal, sino que también deben actualizarse los índices adjuntos.
La razón principal por la que los índices mejoran drásticamente el rendimiento en conjuntos de datos grandes es que los índices de la base de datos en una o más columnas generalmente se ordenan por valor, lo que hace que las operaciones de consultas de rango (como el ejemplo anterior "encuentre todos los registros con salarios entre 40,000 y 50,000") sean muy rápidos (menor complejidad de tiempo ).
Varias bases de datos orientadas a filas están diseñadas para caber completamente en RAM , una base de datos en memoria . Estos sistemas no dependen de las operaciones del disco y tienen el mismo tiempo de acceso a todo el conjunto de datos. Esto reduce la necesidad de índices, ya que requiere la misma cantidad de operaciones para escanear completamente los datos originales como un índice completo para propósitos típicos de agregación. Por lo tanto, estos sistemas pueden ser más simples y más pequeños, pero solo pueden administrar bases de datos que quepan en la memoria.
Sistemas orientados a columnas
Una base de datos orientada a columnas serializa todos los valores de una columna juntos, luego los valores de la siguiente columna, y así sucesivamente. Para nuestra tabla de ejemplo, los datos se almacenarían de esta manera:
10: 001,12: 002,11: 003,22: 004;Smith: 001, Jones: 002, Johnson: 003, Jones: 004;Joe: 001, Mary: 002, Cathy: 003, Bob: 004;60000: 001,80000: 002,94000: 003,55000: 004;
En este diseño, cualquiera de las columnas se asemeja más a la estructura de un índice en un sistema orientado a filas. Esto puede causar confusión que puede llevar a la creencia errónea de que una tienda orientada a columnas "es realmente" una tienda de filas con un índice en cada columna. Sin embargo, es el mapeo de los datos lo que difiere dramáticamente. En un sistema indexado orientado a filas, la clave principal es el rowid que se asigna a partir de datos indexados. En el sistema orientado a columnas, la clave principal son los datos, que se asignan a partir de filas. [2] Esto puede parecer sutil, pero la diferencia se puede ver en esta modificación común a la misma tienda en la que los dos elementos "Jones", arriba, están comprimidos en un solo elemento con dos filas:
…; Smith: 001; Jones: 002,004 ; Johnson: 003;…
El que un sistema orientado a columnas sea o no más eficiente en funcionamiento depende en gran medida de la carga de trabajo que se automatice. Las operaciones que recuperan todos los datos de un objeto determinado (la fila completa) son más lentas. Un sistema orientado a filas puede recuperar la fila en una sola lectura de disco, mientras que se requieren numerosas operaciones de disco para recopilar datos de varias columnas de una base de datos en columnas. Sin embargo, estas operaciones de fila completa son generalmente raras. En la mayoría de los casos, solo se recupera un subconjunto limitado de datos. En una aplicación de rolodex, por ejemplo, recopilar el nombre y apellido de muchas filas para crear una lista de contactos es mucho más común que leer todos los datos de una sola dirección. Esto es aún más cierto para escribir datos en la base de datos, especialmente si los datos tienden a ser "escasos" con muchas columnas opcionales. Por esta razón, los almacenes de columnas han demostrado un excelente rendimiento en el mundo real a pesar de muchas desventajas teóricas. [3]
El particionamiento , la indexación , el almacenamiento en caché, las vistas, los cubos OLAP y los sistemas transaccionales, como el registro de escritura anticipada o el control de concurrencia de múltiples versiones, afectan drásticamente la organización física de cualquiera de los sistemas. Dicho esto, los sistemas RDBMS centrados en el procesamiento de transacciones en línea (OLTP) están más orientados a filas, mientras que los sistemas centrados en procesamiento analítico en línea (OLAP) tienen un equilibrio entre los orientados a filas y los orientados a columnas.
Beneficios
Las comparaciones entre las bases de datos orientadas a filas y a columnas suelen estar relacionadas con la eficiencia del acceso al disco duro para una carga de trabajo determinada, ya que el tiempo de búsqueda es increíblemente largo en comparación con otros cuellos de botella en las computadoras. Por ejemplo, un disco duro Serial ATA (SATA) típico tiene un tiempo de búsqueda promedio de entre 16 y 22 milisegundos [4], mientras que el acceso a DRAM en un procesador Intel Core i7 tarda en promedio 60 nanosegundos, casi 400.000 veces más rápido. [5] Claramente, el acceso al disco es un cuello de botella importante en el manejo de macrodatos. Las bases de datos en columnas aumentan el rendimiento al reducir la cantidad de datos que deben leerse desde el disco, tanto al comprimir de manera eficiente los datos en columnas similares como al leer solo los datos necesarios para responder la consulta.
En la práctica, las bases de datos en columnas son adecuadas para cargas de trabajo similares a OLAP (por ejemplo, almacenes de datos ) que normalmente implican consultas muy complejas sobre todos los datos (posiblemente petabytes ). Sin embargo, se debe hacer algo de trabajo para escribir datos en una base de datos en columnas. Las transacciones (INSERT) deben separarse en columnas y comprimirse a medida que se almacenan, lo que las hace menos adecuadas para cargas de trabajo OLTP. Las bases de datos orientadas a filas son adecuadas para cargas de trabajo similares a OLTP que están más cargadas de transacciones interactivas. Por ejemplo, recuperar todos los datos de una sola fila es más eficiente cuando esos datos están ubicados en una sola ubicación (minimizando las búsquedas de disco), como en las arquitecturas orientadas a filas. Sin embargo, los sistemas orientados a columnas se han desarrollado como híbridos capaces de realizar operaciones OLTP y OLAP. Algunas de las limitaciones OLTP, enfrentado por tales sistemas en columnas, están mediadas usando (entre otras cualidades) en memoria de almacenamiento de datos. [6] Los sistemas orientados a columnas adecuados para roles OLAP y OLTP reducen efectivamente la huella total de datos al eliminar la necesidad de sistemas separados. [7]
Compresión
Los datos de la columna son de tipo uniforme; por lo tanto, existen algunas oportunidades para optimizaciones de tamaño de almacenamiento disponibles en datos orientados a columnas que no están disponibles en datos orientados a filas. Por ejemplo, muchos esquemas de compresión modernos y populares, como LZW o codificación de longitud de ejecución , hacen uso de la similitud de los datos adyacentes para comprimir. Los valores perdidos y los valores repetidos, comunes en los datos clínicos, se pueden representar mediante un marcador de dos bits. [8] Si bien se pueden usar las mismas técnicas en datos orientados a filas, una implementación típica logrará resultados menos efectivos. [9] [10]
Para mejorar la compresión, ordenar filas también puede ayudar. Por ejemplo, al utilizar índices de mapa de bits , la clasificación puede mejorar la compresión en un orden de magnitud. [11] Para maximizar los beneficios de compresión del orden lexicográfico con respecto a la codificación de longitud de ejecución , es mejor usar columnas de baja cardinalidad como las primeras claves de clasificación. [12] Por ejemplo, dada una tabla con columnas sexo, edad, nombre, sería mejor ordenar primero por el valor sexo (cardinalidad de dos), luego edad (cardinalidad de <128), luego nombre.
La compresión columnar logra una reducción del espacio en disco a expensas de la eficiencia de la recuperación. Cuanto mayor sea la compresión adyacente lograda, más difícil puede resultar el acceso aleatorio, ya que es posible que sea necesario descomprimir los datos para poder leerlos. Por lo tanto, las arquitecturas orientadas a columnas a veces se enriquecen con mecanismos adicionales destinados a minimizar la necesidad de acceso a datos comprimidos. [13]
Historia
Los almacenes de columnas o archivos transpuestos se han implementado desde los primeros días del desarrollo de DBMS. TAXIR fue la primera aplicación de un sistema de almacenamiento de bases de datos orientado a columnas centrado en la recuperación de información en biología [14] en 1969. Los datos clínicos de los registros de pacientes con muchos más atributos de los que podían analizarse se procesaron en 1975 y después de un tiempo. sistema de base de datos orientado (TODS). [8] Statistics Canada implementó el sistema RAPID [15] en 1976 y lo utilizó para procesar y recuperar el Censo Canadiense de Población y Vivienda, así como otras aplicaciones estadísticas. RAPID se compartió con otras organizaciones estadísticas de todo el mundo y se usó ampliamente en la década de 1980. Statistics Canada siguió utilizándolo hasta la década de 1990.
Otra base de datos orientada a columnas fue SCSS. [16] [17] [18]
Los paquetes de bases de datos orientados a columnas posteriores incluyeron:
- 1993: KDB
- 1995: Sybase IQ
Desde aproximadamente 2004 ha habido implementaciones comerciales y de código abierto adicionales. MonetDB fue lanzado bajo una licencia de código abierto el 30 de septiembre de 2004, [19] seguido de cerca por la ahora desaparecida C-Store . [20]
C-store fue un proyecto universitario que eventualmente, con la permanencia del miembro del equipo Michael Stonebraker , llevó a Vertica , que cofundó en 2005. [21] [22]
El proyecto X100 relacionado con MonetDB evolucionó a VectorWise . [23] [24] Druid es un almacén de datos orientado a columnas que fue de código abierto a finales de 2012 y ahora es utilizado por numerosas organizaciones. [25]
El DBMS relacional clásico puede utilizar estrategias orientadas a columnas mezclando tablas orientadas a filas y a columnas. A pesar de la complejidad del DBMS, este enfoque ha demostrado ser valioso desde 2010 hasta el presente. Por ejemplo, en 2014 Citusdata introdujo tablas orientadas a columnas para PostgreSQL [26] y McObject agregó soporte para almacenamiento en columnas con su lanzamiento de eXtremeDB Financial Edition en 2012 [27] que luego se utilizó para establecer un nuevo estándar de desempeño para el STAC auditado de forma independiente -M3 de referencia. [28]
Ver también
- Almacén de datos
- Lista de DBMS orientados a columnas
- AOS y SOA
- RCFile
- BigQuery
Referencias
- ^ Marcus Pinnecke; David Broneske; Gabriel Campero Durand; Gunter Saake (2017). ¿Las bases de datos son adecuadas para cargas de trabajo híbridas en GPU? Perspectiva de un motor de almacenamiento (PDF) . IEEE 33rd International Conference on Data Engineering (ICDE). doi : 10.1109 / ICDE.2017.237 .
- ^ Daniel Abadi; Samuel Madden (31 de julio de 2008). "Desmentir otro mito: Column-Stores frente a particiones verticales" . La columna de la base de datos. Archivado desde el original el 4 de diciembre de 2008.
- ^ Stavros Harizopoulos; Daniel Abadi; Peter Boncz. "Sistemas de bases de datos orientados a columnas" (PDF) . Tutorial de VLDB 2009 . pag. 5.
- ^ Masiero, Manuel (8 de enero de 2013). "Revisión de 4 TB WD4001FAEX de Western Digital: De vuelta en negro" . Hardware de Tom .
- ^ Levinthal, Dr. David (2009). "Guía de análisis de rendimiento para el procesador Intel® Core ™ i7 y los procesadores Intel® Xeon ™ 5500" (PDF) . Intel. pag. 22 . Consultado el 10 de noviembre de 2017 .
- ^ "Compactación de datos transaccionales en bases de datos híbridas OLTP y OLAP" (PDF) . Consultado el 1 de agosto de 2017 .
- ^ "Un enfoque de base de datos común para OLTP y OLAP utilizando una base de datos de columnas en memoria" (PDF) . Consultado el 1 de agosto de 2017 .
- ^ a b Stephen Weyl; James F. Fries; Gio Wiederhold; Frank Germano (1975). "Un sistema modular de base de datos clínica autodescriptiva". Las computadoras en la investigación biomédica . 8 (3): 279-293. doi : 10.1016 / 0010-4809 (75) 90045-2 . PMID 1157469 .
- ^ DJ Abadi; SR Madden; N. Hachem (2008). Tiendas en columna frente a tiendas en fila: ¿en qué se diferencian realmente? . SIGMOD'08 . págs. 967–980.
- ^ Bruno, N (2009). "Enseñar nuevos trucos a un elefante viejo". arXiv : 0909.1758 [ cs.DB ]. Parámetro desconocido
|url=
ignorado ( ayuda ) - ^ Daniel Lemire, Owen Kaser, Kamel Aouiche, "La clasificación mejora los índices de mapa de bits alineados con palabras" , Ingeniería de datos y conocimientos , Volumen 69, Número 1 (2010), págs. 3-28.
- ^ Daniel Lemire y Owen Kaser, Reordenamiento de columnas para índices más pequeños , Ciencias de la información 181 (12), 2011
- ^ Dominik Ślęzak; Jakub Wróblewski; Victoria Eastwood; Piotr Synak (2008). Brighthouse: un almacén de datos analíticos para consultas ad hoc (PDF) . Actas de la 34ª Conferencia de VLDB. Auckland, Nueva Zelanda. Archivado desde el original (PDF) el 7 de mayo de 2016 . Consultado el 4 de mayo de 2009 .
- ^ George F. Estabrook; Robert C. Brill (noviembre de 1969). "La teoría del adherente TAXIR". Biociencias matemáticas . 5 (3–4): 327–340. doi : 10.1016 / 0025-5564 (69) 90050-9 .
- ^ "Un DBMS para grandes bases de datos estadísticos" . acm.org . Vldb '79. 1979. págs. 319–327.
- ^ ya en el mercado en septiembre de 1977
- ^ Nie, Norman H. (1980). SCSS: Guía del usuario del sistema estadístico conversacional SPSS . ISBN 978-0070465336.
- ^ "SCSS de SPSS, Inc" . ComputerWorld . 26 de septiembre de 1977. p. 28.
- ^ "Una breve historia sobre nosotros" . monetdb.org .
- ^ "C-Store" . mit.edu . Archivado desde el original el 21 de marzo de 2012 . Consultado el 22 de enero de 2008 .
- ^ "The Vertica Analytic Database: C-Store 7 Years Later" (PDF) " (PDF) . VLDB.org . 28 de agosto de 2012.
- ^ Charles Babcock (21 de febrero de 2008). "Pionero de la base de datos reconsidera la mejor manera de organizar los datos" . InformationWeek . Consultado el 8 de diciembre de 2018 .
- ^ Marcin Zukowski; Peter Boncz (20 de mayo de 2012). De x100 a vectorwise: oportunidades, desafíos y cosas en las que la mayoría de los investigadores no piensa . Actas de la Conferencia Internacional ACM SIGMOD de 2012 sobre Gestión de Datos . ACM. págs. 861–862. doi : 10.1145 / 2213836.2213967 . ISBN 978-1-4503-1247-9.
- ^ D. Inkster; M. Zukowski; PA Boncz (20 de septiembre de 2011). "Integración de VectorWise con Ingres". Registro ACM SIGMOD . 40 (3): 45. CiteSeerX 10.1.1.297.4985 . doi : 10.1145 / 2070736.2070747 .
- ^ "Druida" . druid.io .
- ^ https://github.com/citusdata/cstore_fdw/graphs/contributors
- ^ Saujani, Sandeep (19 de junio de 2012). "McObject eXtremeDB Financial Edition In-Memory DBMS rompe el cuello de botella de gestión de datos de los mercados de capitales" . guía de bobs .
- ^ STAC Benchmark Council, Leadership (3 de noviembre de 2012). "McObject eXtremeDB 5.0 Financial Edition con Kove XPD L2 Storage System, Dell PowerEdge R910 Server y Mellanox ConnectX-2 y MIS5025Q QDR InfiniBand Switch" . STAC .
enlaces externos
- Distinguir dos tipos principales de almacenes de columnas
- Tutorial de VLDB 2009 - descripción general
- Recorrido por DBMS híbrido orientado a filas de columnas
- Tejiendo relaciones para el rendimiento de la caché : diseño de bloques orientado a columnas
- El diseño e implementación de sistemas modernos de bases de datos orientadas a columnas