¿Por qué utilizar una base de datos de columnas para los datos de ticks/barras?

Question

A menudo escucho que bases de datos orientadas a columnas son el mejor método de elección para almacenar datos de series temporales en aplicaciones financieras. Especialmente por parte de quienes venden costosas bases de datos orientadas a columnas.

Sin embargo, a primera vista parece una mala elección. Usted quiere añadir nuevos ticks, o nuevas barras, al final (y necesita hacerlo mucho y rápidamente). Se trata de una operación de fila clásica: se añade a un archivo. En una base de datos de columnas tienes que actualizar tres archivos para un tic (marca de tiempo/precio/tamaño de la operación), o cinco o seis para una barra (marca de fecha, apertura, alta, baja, cierre, volumen). (He dicho 5-6, ya que para los datos de la barra espaciados regularmente supongo que la marca de fecha podría estar implícita a partir del número de fila).

Para la lectura, normalmente no quiero coger sólo una columna; quiero coger toda la barra para poder dibujar un candelabro (por ejemplo). Vale, puede que sólo quiera la columna de cierre, o que sólo quiera la columna de volumen (pero sigo necesitando dos lecturas para obtener también las marcas de fecha en una BD orientada a columnas, ¿no?)

Pero lo que parece aún más importante es que cuando quiero leer datos históricos generalmente quiero coger un subperiodo, y eso se almacenará de forma contigua en la BD orientada a filas.

P1: ¿Existe alguna razón de peso para optar por la orientación a columnas en lugar de la orientación a filas si todo lo que se almacena son ticks comerciales?

P2: ¿Existe alguna razón de peso para optar por la orientación a columnas en lugar de la orientación a filas si todo lo que se almacena son barras OHLCV?

P3: Si cree que no para Q1 y Q2 ¿qué tipo de columnas hay que tener para que las BD orientadas a columnas sean la opción claramente superior?

ACTUALIZACIÓN

Gracias a Chris Aycock por los enlaces a preguntas similares. Algunos de los razonamientos por los que las BD orientadas a columnas son mejores siguen sin tener sentido para mí, pero de la primera parte de https://quant.stackexchange.com/a/949/1587 Creo que la gente puede estar utilizando las bases de datos orientadas a las filas de manera diferente. Así que, a efectos de esta pregunta, por favor, asuma que sólo tengo un símbolo por tabla de base de datos (en lugar de una tabla enorme con una columna "símbolo"). Así que, siguiendo el ejemplo de la respuesta anterior, el almacenamiento en disco en bruto tiene el siguiente aspecto:

09:30:01 | 164.05; 09:30:02 | 164.02; ...

Answer 1

Para Q1 y Q2 yo sugeriría que no se utilice una base de datos de columnas. Las razones son las siguientes:

1. Un acceso de escritura típico para su tipo de datos necesitaría actualizar varios símbolos con marca de tiempo y precio juntos en diferentes tablas. Debido a la alta cardinalidad de sus datos (bajo número de duplicados), las técnicas de compresión en columnas no podrían proporcionar los beneficios de velocidad prometidos.
2. Considere si necesitará uniones en estas grandes tablas cuando las lea más tarde, porque las bases de datos columnares no funcionan bien con las uniones.
3. Para una base de datos de series temporales con un símbolo por tabla, recomendaría utilizar un RDBMS tradicional cuya disposición y consultas se hayan ajustado teniendo en cuenta la máquina disponible y las estimaciones de tamaño/crecimiento de los datos. Un RDBMS convencional moderno con las particiones adecuadas funcionaría bien. Los índices pueden (o no) acelerar los tiempos de lectura, pero sin duda ralentizarán las escrituras.

Respuesta a la pregunta 3: Las bases de datos columnares son buenas para datos de baja cardinalidad, por ejemplo, indicadores de estado - S/N, hombre/mujer, campos de dirección como estado/país, etc. con valores mayoritariamente repetidos a lo largo de la columna. Una interpretación simplista sería que descomponen una tabla por sus campos y registran sus valores únicos en un diccionario, la columna se almacena entonces como una matriz de índices en el diccionario, lo que permite una alta compresión y una mayor velocidad al reducirse la cantidad de datos recuperados/manipulados. Las implementaciones actuales utilizan muchas otras optimizaciones, como la ordenación en caché, etc. Pero la sobrecarga hace que las escrituras sean mucho más lentas que los RDBMS convencionales modernos. Las bases de datos columnares son software especializado y muestran un gran rendimiento sólo para casos específicos, mientras que los RDBMS modernos pueden ser personalizados y ajustados a muchos casos de uso diferentes y proporcionan una ayuda y soporte mucho mejor para lograrlo.

He tenido muy buenos resultados con escrituras rápidas usando Oracle y PostgresQL; y vistas materializadas para lecturas rápidas/informes/análisis. Para las aplicaciones de alto rendimiento, me he beneficiado enormemente de los consejos de DBAs experimentados; recomendaría encarecidamente invertir en ellos en lugar de comprar una nueva y brillante base de datos columnar que me recomendó un consultor.

Answer 2

Como todo, la solución más adecuada depende completamente de su caso concreto. Pero primero creo que confundes un par de conceptos aquí. Una cosa es la rapidez con la que una BD puede recuperar datos/leer. Otra es el almacenamiento de datos en bruto. Y una cuestión totalmente diferente es la analítica, las consultas. Las bases de datos columnares brillan en la lectura y escritura de datos en bruto basados en series temporales. Las bases de datos columnares no son buenas para realizar análisis. Tenga en cuenta que incluso KDB no brilla en la agregación de datos, KDB en sí es sólo un sistema de archivos inteligente con estructuras de índice. Es el lenguaje de consulta incorporado el que añade mucha potencia en términos de capacidades de consulta. Por favor, tenga esto en cuenta.

1) Sí, piense en cómo lee generalmente los datos. Piensa en clave/valor, que es esencialmente de lo que tratan las bases de datos en columnas (Edición: Hay una conexión muy estrecha, no son idénticas). Usted quiere recuperar un punto específico en el tiempo o un marco de tiempo y sus valores asociados. Las bases de datos en columnas son muy rápidas a la hora de gestionar este tipo de solicitudes. Una vez que estos datos están en la memoria, se puede operar con ellos mucho más rápido. 2) Lo mismo: Esencialmente, usted quiere leer las barras de la misma manera que los ticks crudos o cualquier otra serie de tiempo. Quieres adquirir barras desde el lunes a las 9 de la mañana hasta el martes a las 2 de la tarde. ¿Cuál es la diferencia aquí? Usted almacena cada valor en su propia columna. 3) ¿Te refieres a si he respondido "sí" a Q1 y/o Q2? Las columnas son símbolo o símbolo + apertura o lo que hayas elegido. Las claves son la fecha/hora/cuadros...

Recuerde lo que dije al principio: su caso de uso es lo único que importa. Si necesita obtener constantemente precios/barras/... de muchos símbolos diferentes en un momento específico, entonces una base de datos basada en filas es insuperable (siempre que configure el esquema de forma inteligente dentro de un RDBMS). Pero si se extraen datos a lo largo del tiempo de una sola métrica (o 4 métricas como o/h/l/c de barras) entonces una base de datos en columnas es mucho más rápida que un RDBMS. ¿Por qué? Porque la E/S es la operación más costosa y tener que leer sólo las columnas, necesarias, es mucho más rápido que tener que leer filas enteras. Tenga en cuenta que su afirmación de que cada columna se almacena en un archivo diferente es incorrecta.

Yo leería el mismo artículo de la Wiki que has enlazado porque responde a la mayor parte de tu propia pregunta. Además, mira algunas bases de datos estructuradas de código abierto, no SQL, en columnas, para iniciarte en los conceptos.

Pero si me pides que resuma mis puntos en una frase, ahí va: Las bases de datos columnares están optimizadas para operaciones de lectura de datos de tipo serie temporal, mientras que las bases de datos basadas en filas están más optimizadas para operaciones de escritura.

Editar:

Para aclarar, lo que quise decir con "Piensa en clave/valor, que es esencialmente en lo que consisten las bases de datos columnares" es lo siguiente:

He utilizado el término "clave-valor" porque es esencialmente el enfoque de almacenamiento de datos No-SQL más sencillo. El punto es que uno no puede ejecutar consultas sobre los valores, no puede agregar valores o buscar por valores como uno podría en un RDBMS puramente a través de esquemas e índices. Creo que esto (y no soy el único) es lo que diferencia a los RDBMS de las soluciones "No-SQL". Mi punto era que una vez que se entiende este concepto de que las bases de datos No-SQL son generalmente sin esquema, carecen de tablas (generalmente no siempre), y que, y aquí está la similitud clave entre los dbs de valor clave y los de columnas, las consultas se limitan a sólo por las claves, de modo que la DB sabe exactamente en qué nodo se puede ejecutar una consulta. Tenga en cuenta que estoy haciendo la comparación mirando las cosas desde más de 30.000 pies, no una comparación detallada de almacén de valor clave vs. DB columnar. Simplemente creo que una vez que uno entiende el concepto de valor-clave y la forma en que los valores-clave son consultados, entonces encuentro mucho más fácil entender los conceptos de las bases de datos columnares, AUNQUE en la superficie las bases de datos columnares parezcan muy similares a los RDBMS, lo cual no podría estar más lejos de la verdad.