Usuario:Anayanci lop/Sistema gestor de base de datos orientado a columnas V2

De Wikipedia, la enciclopedia libre

Un sistema gestor de base de datos orientado a columnas (o sistema de administración de base de datos columnar) es un sistema gestor de la base de datos (SGBD) que almacena tablas de datos por columnas en lugar de por fila. Los usos prácticos de un almacen de columna versus un almacen de filas difiere un poco en el mundo de los SGBD relacionales. Ambas bases de datos, columnar y de filas, pueden utilizar un lenguaje de consultas de bases de datos tradicionales como SQL para cargar datos y realizar consultas. Ambas bases de datos, de filas y columnares, pueden convertirse en la columna vertebral de un sistema para servir datos a herramientas comunes de extracción, transformación y carga (ETL) y de visualización de datos. Sin embargo, almacenando datos en columnas en lugar de en filas, la base de datos puede acceder de forma más precisa a los datos que necesita para responder a una consulta en vez de escanear y descartar datos no deseados en filas. El rendimiento de consultas incrementa para ciertas cargas de trabajo.

Descripción[editar]

Contexto[editar]

Un sistema de administración de bases de datos relacional proporciona datos que representan una tabla bidimensional, de columnas y filas. Por ejemplo, una base de datos podría tener esta tabla:

RowId EmpId Apellido Nombre Salario
001 10 Smith Joe 60000
002 12 Jones Mary 80000
003 11 Johnson Cathy 94000
004 22 Jones Bob 55000

Esta tabla sencilla 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 estén serializados de una forma u otra.

Las operaciones más costosas que involucran a los discos duros son las búsquedas. Para mejorar el rendimiento global, los datos relacionados deberían ser almacenados en una forma que minimice el número de búsquedas. Esto está conocido como cercanía de referencias, y el concepto básico aparece en un número de contextos diferentes. Los discos duros están organizados en una serie de sectores de una medida fija, típicamente suficiente para almacenar varias filas de la tabla. Organizando los datos de la table de manera que las filas quepan dentro de estos sectores, y agrupando filas relacionadas en sectores secuenciales, el número de sectores que necesitan ser leídos o buscados es minimizado en muchos casos, junto con el número de búsquedas.

Un estudio de Pinnecke et al. cubre técnicas para hibridación de columna-/fila cuando a partir de 2017.[1]​

Sistemas orientados a filas[editar]

Un método común de 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;

Cuando el dato es insertado en la tabla, le es asignado un ID (identificador) interno, el rowid que es utilizado internamente en el sistema para referirse al dato. En este caso los registros tienen rowids secuenciales independientes del empid asignado al usuario. En este ejemplo, el SGBD utiliza enteros cortos para almacenar rowids. En la práctica, normalmente se utilizan números más grandes, de 64-bits o de 128-bits.

Los sistemas basados en filas son diseñados para retornar datos eficientemente para una fila entera, o registro, en tan pocas operaciones como sea posible. Esto encaja con el caso de uso común donde el sistema está intentando recuperar información sobre un objeto particular, por ejemplo la información de contacto de un usuario en un rolodex sistema, o la información de un producto para un sistema de compra en línea. Almacenando los datos del registro en un solo sector del disco, junto con registros relacionados, el sistema puede recuperar registros rápidamente con un mínimo de operaciones de disco.

Los sistemas basados en fila no son eficaces al realizar operaciones sobre conjuntos amplios en la tabla completa, al contrario de cuando las hace para un número pequeño de registros concretos. Por ejemplo, para encontrar todos los registros en la tabla del ejemplo con salarios entre 40,000 y 50,000, el SGBD tendría que escanear completamente toda la tabla en busca de registros que cumplan ese criterio. Aunque la tabla del ejemplo anterior probablemente cabe en un único sector de disco, una tabla con unos cuantos centenares de filas no lo hará, y se necesitarán múltiples operaciones de disco múltiple para recuperar los datos y examinarlos.

Para mejorar el rendimiento de estos tipos de operaciones (las cuales son muy comunes, y generalmente son la razón de utilizar un SGBD) la mayoría de los SGBDs soporta el uso de índices de base de datos, los cuales almacenan todos los valores de un conjunto de columnas junto con punteros al rowid que regresan a la tabla original. Un índice en la columna de salario se vería algo así: 

55000:004; 
60000:001;
80000:002;
94000:003;

Ya que los índices almacenan sólo piezas solas de datos, en vez de filas enteras, los índices son generalmente mucho más pequeños que las tablas de almacenamiento principales. Escaneando este conjunto más pequeño de datos se reduce el número de operaciones de disco. Si el índice es utilizado intensivamente, puede reducir dramáticamente el tiempo para realizar operaciones comunes. Sin embargo, mantener índices añade sobrecarga al sistema, especialmente cuando se escriben nuevos datos a la base de datos. Los registros no sólo necesitan ser almacenados en la tabla principal, sino que todos los índices ligados también tienen que ser actualizados.

La principal razón de por qué los índices mejoran dramáticamente el rendimiento en grandes conjuntos de datos es porque los índices de bases de datos en una o más columnas están ordenados típicamente por valor, lo que hace muy rápidas las operaciones de consultas de rangos (como el ejemplo anterior "encontrar todos los registros con salarios entre 40,000 y 50,000"), ya que se tiene una complejidad de tiempo más baja.

Un número de bases de datos orientadas a filas están diseñadas para caber enteramente en la RAM, una base de datos en memoria. Estos sistemas no dependen de operaciones de disco, y tienen tiempo de acceso igual que al conjunto de datos completo. Esto reduce la necesidad de índices, ya que requiere la misma cantidad de operaciones para escanear completamente los datos originales, que para escaneo de índice completo para propósitos de una agregación típica. Tales sistemas pueden ser, por tanto, más sencillos y más pequeños, pero sólo pueden manejar bases de datos que caben en memoria.

Sistemas orientados a columnas[editar]

Una base de datos orientada a columnas serializa juntos todos los valores de una columna, luego los valores de la columna siguiente, y así consecutivamente. Para nuestra tabla de ejemplo, el dato sería almacenado de este modo: 

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 encaja más cercanamente a la estructura de índice en un sistema basado en filas. Esto puede causar confusión, lo que puede llevar a la creencia equivocada de que un almacen orientado a columnas "es realmente solo" un almacen orientado a filas con un índice en cada columna. Sin embargo, es el mapeo de los datos lo que difiere dramáticamente. En una sistema orientado a filas indexado, la llave primaria es el rowid que es mapeado a partir de los datos indexados. En un sistema orientado a columnas, la llave primaria es el dato, el cual es mapeado a partir de los rowids.[2]​ Esto puede parecer sutil, pero la diferencia puede ser vista en esta modificación común a el mismo almacen donde los dos elementos "Jones" son comprimidos en un solo elemento con dos rowids: 

…;Smith:001;Jones:002,004;Johnson:003;…

Si un sistema orientado a columnas será más eficaz, o no, en la operación depende en gran medida de la carga de trabajo a ser automatizada. Las operaciones que recuperan todos los datos para un objeto dado (la fila entera) son más lentas. Un sistema basado en filas puede recuperar la fila en una sola lectura de disco, mientras que en un sistema columnar se requieren numerosas operaciones de disco para recuperar los datos de múltiples columnas. Aun así, estas operaciones de fila entera son generalmente raras. En la mayoría de los casos, sólo un subconjunto limitado de datos es recuperado. En una aplicación rolodex, por ejemplo, recuperar el nombre y apellido de muchas filas para construir una lista de contactos es mucho más común que leer todos los datos para una única 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 columna han demostrado excelente desempeño en el mundo real a pesar de muchas desventajas teóricas.[3]​

El particionamiento, la indexación, el cacheo, las vistas, los cubos OLAP, y los sistemas transaccionales tales como "write-ahead logging" o el control de concurrencia mediante versiones múltiples, todo esto afecta dramáticamente la organización física de cualquier sistema. Dicho esto, los sistemas RDBMS enfocados en procesamiento de transacciones en línea (OLTP) son más orientados a filas, mientras que los sistemas centrados en procesamiento analítico en línea (OLAP) son un equilibrio orientación a filas y a columnas.

Beneficios[editar]

Las comparaciones entre bases de datos orientadas a filas y orientadas a columnas típicamente se enfocan en la eficiencia de acceso al disco duro para una carga de trabajo dada, ya que el tiempo de búsqueda es increíblemente largo comparado a los otros cuellos de botella en computadoras. Por ejemplo, un típico disco duro Serial ATA (SATA) tiene un tiempo de búsqueda promedio de entre 16 y 22 milisegundos, mientras que el acceso DRAM en un procesador Intel Core i7 toma en promedio 60 nanosegundos, casi 400,000 veces más rápido.[4]​[5]​ Claramente, el acceso a disco es un cuello de botella importante en el manejo de grandes cantidades de datos. Las bases de datos columnares impulsan el rendimiento al reducir la cantidad de datos que necesitan ser leídos del disco, debido a que comprime eficientemente los datos columnares similares, y a que lee sólo los datos necesarios para responder a una consulta.

En la práctica, las bases de datos columnares son muy convenientes para cargas de trabajo tipo OLAP (por ej., almacenes de datos) las cuales típicamente involucran consultas altamente complejas sobre todos los datos (posiblemente petabytes). Sin embargo, se requiere algo de trabajo para escribir datos en una base de datos columnar. Las transacciones (INSERT's) tienen que ser separadas en columnas y comprimidas cuando son almacenadas, haciéndolas menos convenientes para cargas de trabajo OLTP. Las bases de datos orientadas a filas son muy convenientes para cargas de trabajo tipo OLTP las cuales están mayoritariamente cargadas de transacciones interactivas. Por ejemplo, la recuperación de todos los datos de una única fila es más eficiente cuando esos datos están localizados en una única ubicación (minimizando búsquedas en disco), como lo es en arquitecturas orientadas a filas. Sin embargo, los sistemas orientados a columnas han sido desarrollados como híbridos capaces de ambas operaciones, OLTP y OLAP. Algunas de las restricciones OLTP, enfrentadas por los sistemas orientados a columnas, son mediadas utilizando (entre otras cualidades) almacenamiento de datos en memoria.[6]​ Los sistemas orientados a columnas adecuados para roles OLAP y OLTP reducen de manera efectiva la huella de datos total al remover la necesidad de sistemas separados.[7]​

Compresión[editar]

Dato de columna es de tipo uniforme; por tanto, hay algunas oportunidades para optimizaciones de medida del almacenamiento disponibles en columna-dato orientado que no es disponible en fila-dato orientado. Por ejemplo, muchos esquemas de compresión modernos populares, como LZW o carrera-la longitud que codifica, uso de marca de la semejanza de dato adyacente para comprimir. Valores desaparecidos y repitió valores, comunes en dato clínico, puede ser representado por un dos-mordió marcador.[8]​ Mientras las mismas técnicas pueden ser utilizadas encima fila-dato orientado, una implementación típica conseguirá menos resultados eficaces.[9]​

Para mejorar compresión, ordenando las filas pueden también ayuda. Por ejemplo, utilizando bitmap índices, ordenando puede mejorar compresión por un orden de magnitud.[10]​ A maximize los beneficios de compresión del orden lexicográfico con respetar para correr-la longitud que codifica, es más para utilizar abajo-cardinality columnas como las primeras llaves de clase.[11]​ Por ejemplo, dado una mesa con sexo de columnas, edad, nombre, sea más para ordenar primero en el sexo de valor (cardinality de dos), entonces edad (cardinality de <150), entonces nombre.

La compresión columnar consigue una reducción en espacio de disco a expensas de eficacia de retrieval. La compresión adyacente más grande consiguió, el más difícil aleatorio-el acceso puede devenir, cuando el dato podría necesitar ser uncompressed para ser leído. Por tanto, columna-orientó las arquitecturas son a veces enriquecidas por los mecanismos adicionales apuntaron en minimizar la necesidad para acceder a dato comprimido.[12]​

Historia[editar]

Tiendas de columna o transposed los archivos han sido implementados de los días tempranos de desarrollo de SGBD. TAXIR Era la primera aplicación de una columna-sistema de almacenamiento de base de datos orientado con centrar encima información-retrieval en biología en 1969.[13]​ Dato clínico de registros pacientes con muchos más atributos que podría ser analizado estuvo procesado en 1975 y después de que por un tiempo-sistema de base de datos orientada (TODS).[8]​ Canadá de estadística implementó el sistema RÁPIDO en 1976 y utilizó él para procesar y retrieval del Censo canadiense de Población y Albergando así como muchos otras aplicaciones estadísticas.[14]​ RÁPIDO estuvo compartido con otras organizaciones estadísticas durante el mundiales y utilizó ampliamente en el @1980s. Continúe ser utilizado por Canadá de Estadísticas hasta el @1990s.

Otra columna-la base de datos orientada era SCSS[15]​.[16]​[17]​

Columna más tardía-paquetes de base de datos orientada incluyeron:

Desde entonces aproximadamente 2004 ha habido código abierto adicional e implementaciones comerciales. MonetDB Estuvo liberado bajo una licencia de fuente abierta encima septiembre 30, 2004, siguió estrechamente por el ahora difunto C-Tienda.[18]​[19]​

C-la tienda era un proyecto universitario que finalmente, con miembro de equipo Michael Stonebraker quedándose encima, dirigido a Vertica, el cual él co-fundado en 2005.[20]​

El MonetDB-relacionó X100 proyecto evolucionado a VectorWise.[21]​[22]​ Druid Es una columna-el dato orientado almacena aquello era abierto-sourced en tardío 2012 y ahora utilizado por organizaciones numerosas.[23]​

SGBD Relacional clásico puede utilizar columna-orientó estrategias por mezclar fila-orientado y columna-orientó mesas. A pesar de la complejidad de SGBD, esta aproximación ha probado para ser valioso de los años 2010 para presentar. Por ejemplo en 2014 Citusdata columna introducida-orientó mesas para PostgreSQL[24]​ y McObject añadió soporte para almacenamiento columnar con su liberación de eXtremeDB Edición Financiera en 2012 cuál era entonces utilizado para establecer un estándar nuevo de rendimiento para el independientemente auditado STAC-M3 benchmark.[25]​[26]​

Vea también[editar]

Referencias[editar]

  1. ↑ . IEEE 33rd International Conference on Data Engineering (ICDE). 2017. doi:10.1109/ICDE.2017.237. 
  2. ↑ Daniel Abadi (31 July 2008). «Debunking Another Myth: Column-Stores vs. Vertical Partitioning». The Database Column. Archivado desde el original el December 4, 2008. 
  3. ↑ Stavros Harizopoulos. «Column-Oriented Database Systems». VLDB 2009 Tutorial. 
  4. ↑ Masiero, Manuel (January 8, 2013). «Western Digital's 4 TB WD4001FAEX Review: Back In Black». Tom's Hardware. 
  5. ↑ Levinthal, Dr David (2009). «Performance Analysis Guide for Intel® Core™ i7 Processor and Intel® Xeon™ 5500 processors». Intel. Consultado el 10 de noviembre de 2017. 
  6. ↑ «Compacting Transactional Data in Hybrid OLTP&OLAP Databases». Consultado el August 1, 2017. 
  7. ↑ «A Common Database Approach for OLTP and OLAP Using an In-Memory Column Database». Consultado el August 1, 2017. 
  8. ↑ a b Stephen Weyl; James F. Fries; Gio Wiederhold; Frank Germano (1975). «A Modular Self-describing Clinical Database System». Computers in Biomedical Research 8 (3): 279-293. doi:10.1016/0010-4809(75)90045-2. 
  9. ↑ D. J. Abadi; S. R. Madden; N. Hachem (2008). Column-stores vs. row-stores: how different are they really?. pp. 967-980. 
  10. ↑ Daniel Lemire, Owen Kaser, Kamel Aouiche, "Sorting improves word-aligned bitmap indexes", Data & Knowledge Engineering, Volume 69, Issue 1 (2010), pp. 3-28.
  11. ↑ Daniel Lemire and Owen Kaser, Reordering Columns for Smaller Indexes, Information Sciences 181 (12), 2011
  12. ↑ . Proceedings of the 34th VLDB Conference. 2008 [2016-05-07 2016-05-07] |url= incorrecta (ayuda) |urlarchivo= sin título (ayuda). Archivado desde el original|urlarchivo= requiere |url= (ayuda) el https://web.archive.org/web/20160507160356/http://www.vldb.org/pvldb/1/1454174.pdf. 
  13. ↑ George F. Estabrook; Robert C. Brill (November 1969). «The theory of the TAXIR accessioner». Mathematical Biosciences 5 (3–4): 327-340. doi:10.1016/0025-5564(69)90050-9. 
  14. ↑ «A DBMS for large statistical databases». acm.org. 1979. pp. 319-327. 
  15. ↑ already on the market by September 1977
  16. ↑ SCSS: A User's Guide to the SPSS Conversational Statistical System. 1980. ISBN 978-0070465336. 
  17. ↑ «SCSS from SPSS, Inc». September 26, 1977. p. 28. 
  18. ↑ «A short history about us». monetdb.org. 
  19. ↑ «C-Store». mit.edu. 
  20. ↑ «The Vertica Analytic Database: C-Store 7 Years Later" (PDF)». VLDB.org. August 28, 2012. 
  21. ↑ Marcin Zukowski; Peter Boncz (20 de mayo de 2012). From x100 to vectorwise: opportunities, challenges and things most researchers do not think about. ACM. pp. 861-862. ISBN 978-1-4503-1247-9. doi:10.1145/2213836.2213967. 
  22. ↑ D. Inkster; M. Zukowski; P.A. Boncz (September 20, 2011). «Integration of VectorWise with Ingres». ACM SIGMOD Record 40 (3): 45. doi:10.1145/2070736.2070747. 
  23. ↑ «Druid». druid.io. 
  24. ↑ https://github.com/citusdata/cstore_fdw/graphs/contributors
  25. ↑ Saujani, Sandeep (19 June 2012). «McObject eXtremeDB Financial Edition In-Memory DBMS Breaks Through Capital Markets’ Data Management Bottleneck». bobs guide. 
  26. ↑ STAC Benchmark Council, Leadership (3 November 2012). «McObject eXtremeDB 5.0 Financial Edition with Kove XPD L2 Storage System, Dell PowerEdge R910 Server and Mellanox ConnectX-2 and MIS5025Q QDR InfiniBand Switch». STAC. 

Enlaces externos[editar]

[[Categoría:Bases de datos por tipo]] [[Categoría:Modelos de bases de datos]] [[Categoría:Sistemas de gestión de bases de datos]] [[Categoría:Wikipedia:Páginas con traducciones sin revisar]]

Obtenido de «https://es.wikipedia.org/w/index.php?title=Usuario:Anayanci_lop/Sistema_gestor_de_base_de_datos_orientado_a_columnas_V2&oldid=127075814»