Tiendas de columnas: Comparación de bases de datos basadas en columnas

Question

Realmente he estado luchando para convertir SQL Server en algo que, francamente, nunca será. Necesito un motor de base de datos para mi trabajo analítico. El DB debe ser rápido y NO necesita todo el registro y otros gastos generales encontrados en las bases de datos típicas (SQL Server, Oracle, DB2, etc.)

Ayer escuché Michael Stonebraker speak at the Money:Tech conference y seguí pensando, "No estoy realmente loco. ¡HAY una mejor manera! " Habla sobre el uso de column stores en lugar de bases de datos orientadas a filas. Fui a la página de Wikipedia para column stores y veo algunos proyectos de código abierto (que me gustan) y algunos proyectos comerciales/de código abierto (que no entiendo del todo).

Mi pregunta es esta: en un entorno analítico aplicado, ¿cómo difieren los diferentes DB basados ​​en columnas? ¿Cómo debería estar pensando en ellos? ¿Alguien tiene experiencia práctica con sistemas basados ​​en múltiples columnas? ¿Puedo aprovechar mi experiencia SQL con estos DB o tendré que aprender un nuevo idioma?

En última instancia voy a tirar datos a R para su análisis.

EDIT: Me pidieron una aclaración sobre qué es exactamente lo que estoy tratando de hacer. Por lo tanto, aquí hay un ejemplo de lo que me gustaría hacer: Cree una tabla que tenga 4 millones de filas y 20 columnas (5 valores débiles, 15 datos). Cree 5 tablas de agregación que calculen max, min y average para cada uno de los hechos. Une esas 5 agregaciones a la mesa de inicio. Ahora calcule la desviación porcentual de la media, la desviación porcentual de min y la desviación porcentual del máximo para cada fila y agréguelo a la tabla original. Los datos de esta tabla no reciben nuevas filas cada día, se reemplaza TOTALMENTE y el proceso se repite. El cielo no lo permita si el proceso debe detenerse. Y los registros ... ohhhhh, los registros! :)

Answer 1

La respuesta corta es que para los datos analíticos, un almacén de columnas tenderá a ser más rápido, con menos ajustes necesarios.

Una tienda de filas, la arquitectura de base de datos tradicional, es buena para insertar pequeños números de filas, actualizar las filas en su lugar y consultar un pequeño número de filas. En una tienda de fila, estas operaciones se pueden realizar con una o dos E/S de bloques de disco.

Las bases de datos analíticas normalmente cargan miles de registros a la vez; a veces, como en tu caso, vuelven a cargar todo. Tienden a desnormalizarse, por lo que tienen muchas columnas. Y en el momento de la consulta, a menudo leen una gran proporción de las filas en la tabla, pero solo algunas de estas columnas. Entonces, tiene sentido desde un punto de vista de E/S almacenar los valores de la misma columna juntos.

Resulta que esto le da a la base de datos una gran oportunidad para hacer la compresión de valores. Por ejemplo, si una columna de cadena tiene una longitud promedio de 20 bytes pero solo tiene 25 valores distintos, la base de datos puede comprimirse a aproximadamente 5 bits por valor. Las bases de datos de las tiendas de columnas a menudo pueden operar sin descomprimir los datos.

menudo en informática no es un I/O en comparación con compensación de tiempo de CPU, pero en las tiendas de las columnas de las mejoras de E/S a menudo mejoran la localidad de referencia, reducen la actividad de paginación caché, y permiten mayores factores de compresión, por lo que las ganancias de la CPU también .

Las bases de datos de almacén de columnas también tienden a tener otras características analíticas como índices de mapa de bits (otro caso donde una mejor organización permite una mejor compresión, reduce las E/S y permite algoritmos que son más eficientes en la CPU), particiones y materializadas puntos de vista.

El otro factor es si usar una base de datos masivamente paralela (MMP). Hay bases de datos de tienda de columnas y almacenes de filas MMP. Las bases de datos de MMP pueden escalar hasta cientos o miles de nodos, y le permiten almacenar enormes cantidades de datos, pero a veces tienen compromisos como una noción más débil de transacciones o un lenguaje de consulta que no es bastante SQL.

Le recomiendo que pruebe LucidDB. (Descargo de responsabilidad: me comprometo con LucidDB.) Es una base de datos de almacén de columnas de código abierto, optimizada para aplicaciones analíticas, y también tiene otras características, como índices de mapa de bits. Actualmente solo se ejecuta en un nodo, pero utiliza varios núcleos de forma efectiva y puede manejar volúmenes razonables de datos sin mucho esfuerzo.

Answer 2

Parece un cambio de implementación (matriz 2-D en orden de columna mayor, en lugar de orden de fila mayor), en lugar de un cambio de interfaz.

Piense en el patrón de "estrategia", en lugar de ser un cambio de paradigma completo. Por supuesto, nunca he usado estos productos, por lo que de hecho pueden forzar un cambio de paradigma en tu garganta. Sin embargo, no sé por qué.

Answer 3

Podríamos ayudarle mejor a tomar una decisión informada si describiera [1] su objetivo específico y [2] los problemas que tiene con SQL Server.

Answer 4

Tengo un poco de experiencia con la edición de la comunidad de Infobright --- column-or. db, basado en mysql.

Pro:

• puede utilizar interfaces con MySQL/drivers ODBC de MySQL, de R también
• consultas lo suficientemente rápido en grandes trozos de selección de datos (debido a KnowledgeGrid paquetes de datos &)
• muy rápido cargador de datos nativo y conectores para ETL (talend, kettle)
• optimizado exactamente esas operaciones lo que yo (y creo que la mayoría de nosotros) usamos (selección por niveles de factor, unir etc)
• opción especial "búsqueda" para variables de factor R almacenamiento optimizados;) (ok, las variables char/varchar con número relativamente pequeño niveles número/filas)
• FOSS
• pagado opción de soporte
• ?

Contras:

• ninguna operación de inserción/actualización de edición de la comunidad (¿todavía?), Carga de datos sólo a través de conectores de cargador de datos/ETL nativos
• sin apoyo oficial UTF-8 (intercalación/ordenar etc.), planificado para el q3 2009
• sin funciones en las consultas globales fe seleccione mes (fecha) desde ...) aún, planeado para julio (?) 2009, pero debido al almacenamiento de columna, prefiero simplemente crear columnas de fecha para cada nivel de agregación (número de semana, mes, ...) Necesito
• no se puede instalar en el servidor mysql existente como motor de almacenamiento (debido a su propio optimizador, si entendí correctamente), pero puede instalar Infobright & mysql en diferentes puertos si necesita
• ?

Currículum: Buena solución FOSS para tareas analíticas diarias, y, creo que, sus tareas también.

Answer 5

4 millones de filas por 20 columnas por 8 bytes para un doble es de 640 mb. Siguiendo la regla general de que R crea tres copias temporales para cada objeto, obtenemos aproximadamente 2 gb. Eso no es mucho para el estándar de hoy.

Así que esto debería poderse hacer en la memoria en una máquina adecuada de 64 bits con una cantidad de ram "decente" (digamos 8 gb o más). Instalar Ubuntu o Debian (posiblemente en la versión del servidor) se puede hacer en unos minutos.

Answer 6

Aquí están mis 2 centavos: el servidor SQL no escala bien. Intentamos usar el servidor SQL para almacenar datos financieros en tiempo real (es decir, los tics de precios vienen en 100 símbolos). Funcionó perfectamente durante las primeras 2 semanas, luego fue más y más lento a medida que el tamaño de la base de datos aumentó, y finalmente se detuvo, demasiado lento para insertar cada precio tal como se recibió. Intentamos solucionarlo moviendo datos de la base de datos activa al almacenamiento fuera de línea todas las noches, pero finalmente el proyecto fue abandonado porque simplemente no funcionaba.

En pocas palabras: si está planeando almacenar una gran cantidad de datos (> 1GB), necesita algo que se adapte correctamente, y eso probablemente signifique una base de datos de columnas.