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 columnas en lugar de por filas. Los beneficios incluyen un acceso más eficiente a los datos cuando solo se consulta un subconjunto de columnas (al eliminar la necesidad de leer columnas que no son relevantes) y más opciones para la compresión de datos. Sin embargo, suelen ser menos eficientes para insertar datos nuevos.
El uso práctico de un almacén de columnas versus un almacén de filas difiere poco en el mundo DBMS relacional . Tanto las bases de datos de columnas como 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 de columnas pueden convertirse en la columna vertebral de un sistema para servir datos para extracción, transformación, carga (ETL) y herramientas comunes.
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 podría tener esta tabla:
Esta tabla simple 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 de 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 están organizados en una serie de bloques de un tamaño fijo, normalmente 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 agrupar las filas relacionadas en bloques secuenciales, en muchos casos se minimiza la cantidad de bloques que deben leerse o buscarse, junto con la cantidad de búsquedas.
Una encuesta realizada por Pinnecke et al. [1] cubre técnicas para la hibridación de columnas/filas a partir de 2017.
Un método común para almacenar una tabla es serializar cada fila de datos, así:
001:10,Smith,Joe,60000;002:12,Jones,María,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, que rowidse utiliza internamente en el sistema para hacer referencia a los datos. En este caso los registros tienen rowids secuenciales independientes del asignado por el usuario empid. En este ejemplo, el DBMS utiliza números enteros cortos para almacenar rowidcorreos electrónicos. En la práctica, normalmente se utilizan números mayores, de 64 o 128 bits.
Los sistemas orientados a filas están diseñados para devolver datos de manera eficiente para una fila o registro completo 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 en el disco.
Los sistemas orientados a filas no son eficientes para realizar operaciones en todo el conjunto de 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 cabe en un solo bloque de disco, una tabla con incluso unos pocos cientos de filas no cabrí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 objetivo 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 rowidpunteros a la base de datos. mesa original. Un índice en la columna de salario se vería así:
55000:004;60000:001;80000:002;94000:003;
Como almacenan solo datos individuales, en lugar de filas enteras, los índices son generalmente mucho más pequeños que los almacenes de la tabla principal. Escanear este conjunto más pequeño de datos reduce la cantidad de operaciones en el disco. Si el índice se utiliza mucho, puede reducir drásticamente el tiempo de las operaciones comunes. Sin embargo, mantener índices añade una sobrecarga 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 grandes conjuntos de datos es que los índices de bases de datos en una o más columnas generalmente se ordenan por valor, lo que hace que las operaciones de consulta de rango (como el ejemplo anterior "buscar todos los registros con salarios entre 40 000 y 50 000") sean muy rápidas. (menor complejidad temporal ).
Varias bases de datos orientadas a filas están diseñadas para caber completamente en la RAM , una base de datos en memoria . Estos sistemas no dependen de las operaciones del disco y tienen acceso en el mismo tiempo 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 que un índice completo para fines de agregación típicos. Por lo tanto, estos sistemas pueden ser más simples y más pequeños, pero sólo pueden gestionar bases de datos que quepan en la memoria.
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:
001:10,002:12,003:11,004:22;001: Smith, 002: Jones, 003: Johnson, 004: Jones,001:Joe,002:María,003:Cathy,004:Bob;001:60000,002:80000,003:94000,004:55000;
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 un almacén orientado a columnas "en realidad es sólo" un almacén de filas con un índice en cada columna. Sin embargo, lo que difiere dramáticamente es el mapeo de los datos. En un sistema orientado a filas, los índices asignan valores de columnas a ID de fila, mientras que en un sistema orientado a columnas, las columnas asignan ID de fila a valores de columna. [2] Esto puede parecer sutil, pero la diferencia se puede ver en esta modificación común en la misma tienda en la que los dos artículos "Jones" anteriores se comprimen en un solo artículo con dos ID de fila:
…;Herrero:001; Jones:002,004 ;Johnson:003;…
El funcionamiento más eficiente de un sistema orientado a columnas depende en gran medida de la carga de trabajo que se automatiza. 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 múltiples columnas de una base de datos en columnas. Sin embargo, estas operaciones de hileras completas son generalmente poco comunes. En la mayoría de los casos, sólo se recupera un subconjunto limitado de datos. En una aplicación rolodex, por ejemplo, recopilar los nombres y apellidos 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 al 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 dramáticamente 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 el procesamiento analítico en línea (OLAP) son un equilibrio entre los orientados a filas y las columnas.
Las comparaciones entre bases de datos orientadas a filas y columnas generalmente se refieren a 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 la 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 big data. Las bases de datos en columnas aumentan el rendimiento al reducir la cantidad de datos que deben leerse del disco, tanto comprimiendo de manera eficiente los datos en columnas similares como leyendo solo los datos necesarios para responder la consulta.
En la práctica, las bases de datos en columnas son adecuadas para cargas de trabajo tipo OLAP (por ejemplo, almacenes de datos ) que normalmente implican consultas muy complejas sobre todos los datos (posiblemente petabytes ). Sin embargo, se debe realizar 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 se encuentran en una sola ubicación (minimizando las búsquedas en el 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 tanto OLTP como OLAP. Algunas de las limitaciones de OLTP a las que se enfrentan estos sistemas orientados a columnas están mediadas mediante (entre otras cualidades) el almacenamiento de datos en memoria . [6] Los sistemas orientados a columnas adecuados para funciones OLAP y OLTP reducen efectivamente la huella total de datos al eliminar la necesidad de sistemas separados. [7]
Los datos de las columnas son de tipo uniforme; por lo tanto, existen algunas oportunidades para optimizar el 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 , utilizan la similitud de datos adyacentes para comprimir. Los valores faltantes y los valores repetidos, comunes en los datos clínicos, se pueden representar mediante un marcador de dos bits. [8] Si bien se pueden utilizar 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, también puede ser útil ordenar filas. Por ejemplo, utilizando índices de mapas 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 utilizar columnas de baja cardinalidad como 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 por edad (cardinalidad <128) y luego por nombre.
La compresión en columnas 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 será 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]
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 registros de pacientes con muchos más atributos de los que podían analizarse se procesaron en 1975 y después por 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 varias otras aplicaciones estadísticas. RAPID se compartió con otras organizaciones estadísticas de todo el mundo y se utilizó ampliamente en la década de 1980. Continuó siendo utilizado por Statistics Canada 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:
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 el ahora desaparecido C-Store . [20]
C-store fue un proyecto universitario que finalmente, con la permanencia del miembro del equipo Michael Stonebraker , condujo a Vertica , que cofundó en 2005. [21] [22]
El proyecto X100 relacionado con MonetDB evolucionó hasta convertirse en 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 lo utilizan 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 los años 2010 hasta la actualidad. 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 rendimiento para el STAC auditado de forma independiente. -Punto de referencia M3. [28]
{{cite book}}: |work=ignorado ( ayuda )