¿Qué hace que las bases de datos en columnas sean adecuadas para la ciencia de datos?
Respuestas:
Una base de datos orientada a columnas (= almacén de datos columnar) almacena los datos de una tabla columna por columna en el disco, mientras que una base de datos orientada a filas almacena los datos de una tabla fila por fila.
Hay dos ventajas principales de usar una base de datos orientada a columnas en comparación con una base de datos orientada a filas. La primera ventaja se relaciona con la cantidad de datos que uno necesita leer en caso de que realicemos una operación con solo algunas características. Considere una consulta simple:
SELECT correlation(feature2, feature5)
FROM records
Un ejecutor tradicional leería toda la tabla (es decir, todas las características):
En cambio, utilizando nuestro enfoque basado en columnas, solo tenemos que leer las columnas que están interesadas en:
La segunda ventaja, que también es muy importante para grandes bases de datos, es que el almacenamiento basado en columnas permite una mejor compresión, ya que los datos en una columna específica son homogéneos que en todas las columnas.
El principal inconveniente de un enfoque orientado a columnas es que manipular (buscar, actualizar o eliminar) una fila completa es ineficiente. Sin embargo, la situación rara vez debería ocurrir en las bases de datos para análisis ("almacenamiento"), lo que significa que la mayoría de las operaciones son de solo lectura, rara vez leen muchos atributos en la misma tabla y las escrituras son solo anexos.
Algunos RDMS ofrecen una opción de motor de almacenamiento orientado a columnas. Por ejemplo, PostgreSQL no tiene nativamente ninguna opción para almacenar tablas en forma de columnas, pero Greenplum ha creado una fuente de código cerrado (DBMS2, 2009). Curiosamente, Greenplum también está detrás de la biblioteca de código abierto para análisis escalables en la base de datos, MADlib (Hellerstein et al., 2012), lo cual no es una coincidencia. Más recientemente, CitusDB, una startup que trabaja en una base de datos analítica de alta velocidad, lanzó su propia extensión de tienda columnar de código abierto para PostgreSQL, CSTORE (Miller, 2014). El sistema de Google para el aprendizaje automático a gran escala Sibyl también utiliza el formato de datos orientado a columnas (Chandra et al., 2010). Esta tendencia refleja el creciente interés en torno al almacenamiento orientado a columnas para análisis a gran escala. Stonebraker y col. (2005) discuten más a fondo las ventajas del DBMS orientado a columnas.
Dos casos de uso concretos: ¿cómo se almacenan la mayoría de los conjuntos de datos para el aprendizaje automático a gran escala?
(la mayor parte de la respuesta proviene del Apéndice C de: BeatDB: un enfoque de extremo a extremo para revelar saliencias de conjuntos de datos de señales masivas. Franck Dernoncourt, SM, tesis, Departamento de MIT de EECS )
Depende de lo que hagas.
Las tiendas de columnas tienen dos beneficios clave:
- se pueden omitir columnas enteras
- la compresión de longitud de ejecución funciona mejor en columnas (para ciertos tipos de datos; en particular con pocos valores distintos)
Sin embargo, también tienen inconvenientes:
- muchos algoritmos necesitarán todas las columnas y solo grabarán a la vez (por ejemplo, k-medias) o incluso pueden necesitar calcular una matriz de distancia por pares
- las técnicas de compresión solo funcionan bien en tipos y factores de datos dispersos, pero no en datos continuos de doble valor
- Los agregados en las tiendas de columnas son caros, por lo que no es ideal para transmitir / cambiar datos
El almacenamiento en columnas es realmente popular para OLAP, también conocido como "análisis estúpido" (Michael Stonebraker) y, por supuesto, para el preprocesamiento donde puede estar interesado en descartar columnas enteras (pero primero necesitaría tener datos estructurados; no almacene JSON en columnas) formato). Porque el diseño en columnas es realmente bueno para, por ejemplo, contar cuántas manzanas ha vendido la semana pasada.
Para gran parte de los casos de uso científicos / ciencia de datos, las bases de datos de matriz parecen ser el camino a seguir (además, por supuesto, datos de entrada no estructurados). Por ejemplo, SciDB y RasDaMan.
En muchos casos (por ejemplo, aprendizaje profundo), las matrices y las matrices son los tipos de datos que necesita, no las columnas. MapReduce, etc. todavía puede ser útil en el preprocesamiento, por supuesto. Tal vez incluso datos de columna (pero la base de datos de matriz generalmente también admite una compresión similar a una columna).
No he usado una base de datos columnar, pero he usado un formato de archivo columnar de código abierto llamado Parquet, y creo que los beneficios son probablemente los mismos: procesamiento de datos más rápido cuando solo necesita consultar un pequeño subconjunto de un archivo grande número de columnas. Tuve una consulta ejecutándose en aproximadamente 50 terabytes de archivos Avro (un formato de archivo orientado a filas) con 673 columnas que tomaron aproximadamente una hora y media en un clúster Hadoop de 140 nodos. Con Parquet, la misma consulta tardó unos 22 minutos porque solo necesitaba 5 columnas.
Si tuviera una pequeña cantidad de columnas o estuviera utilizando una gran proporción de sus columnas, no creo que una base de datos columnar haga una gran diferencia en comparación con una orientada a filas porque todavía tendría que escanear básicamente todos sus datos. Creo que las bases de datos en columnas almacenan columnas por separado, mientras que las bases de datos orientadas a filas almacenan filas por separado. Su consulta será más rápida cada vez que pueda leer menos datos del disco.
Este enlace explica más detalles.
Nota: Esta es mi pregunta, y estoy realmente agradecido por las maravillosas respuestas aquí, que me ayudaron a comprender el concepto.
Entonces, explicaría el concepto de la manera que he entendido:
Generalmente, los datos en las bases de datos se almacenan en la memoria en los siguientes formatos:
Considere este dato:
X1 X2
1 0.7091409 -1.4061361
2 -1.1334614 -0.1973846
3 2.3343391 -0.4385071
En una tienda basada en filas relacionales, se almacena así:
1, 0.7091409, -1.4061361, 2, -1.1334614, -0.1973846, 3, 2.3343391, -0.4385071
en forma de filas.
En la tienda columnar, se almacenaría así:
1, 2, 3, 0.7091409 ,-1.1334614, 2.3343391, -1.4061361, -0.1973846, -0.4385071
en forma de columnas.
¿Entonces, qué significa esto?
Esto significa que la inserción (y actualización) y las eliminaciones son rápidas en el almacén de columnas basado en filas, ya que es solo la eliminación de los últimos valores o los primeros valores. Sin embargo, no es el caso en las tiendas de columnas, ya que el valor en cada tienda de bloques debe eliminarse.
Sin embargo, cuando existe la necesidad de agregados y operaciones de columnas, los almacenes de columnas tienen una ventaja sobre sus contrapartes basadas en filas, ya que se almacenan en columnas y, como resultado, acceder a columnas individuales es muy fácil.