database - que - Selección de base de datos para una aplicación analítica de escala web

google data transfer

Question

Quiero construir una aplicación web similar a Google-Analytics, en la cual recopilo estadísticas sobre los usuarios finales de mis clientes y les muestro el análisis de mis clientes en base a esa información.

Caracteristicas:

• Alta escalabilidad, maneja volúmenes muy grandes
• Compartimentado: las consultas siempre se ejecutan en los datos de un solo cliente
• Soporte de consultas analíticas (drill-down, slices, etc.)

Debido a la necesidad analítica, estoy considerando utilizar un paquete OLAP / BI, pero no estoy seguro de que sea para esta escala. Base de datos NoSQL? RDBMS simple haría?

Answer 1

Esto es lo que estoy usando en el trabajo en un entorno de producción y funciona como un encanto.

Yo copié tres cosas

PostgreSQL + LucidDB + Mondrian (Más generalmente, todos los componentes de la suite Pentaho BI)

• PostgreSQL : No voy a describir postgresql, RDBMS de fuente abierta realmente sólido te permitirá hacer, sin duda, todo lo que necesites. Lo uso para almacenar mis datos operativos.

• LucidDB : LucidDB es una base de datos de columna de código abierto. Altamente escalable y proporcionará una gran ganancia de tiempo de procesamiento en comparación con PostgreSQL para recuperar una gran cantidad de datos. No está optimizado para el procesamiento de transacciones sino para lecturas intensivas. Esta es mi base de datos de Datawarehouse

• Mondrian : Mondrian es un cubo de código abierto R-OLAP. LucidDB hizo que sea fácil conectar esos dos programas juntos.

Te recomendaría que veas todo el Pentaho BI Suite, vale la pena, es posible que quieras utilizar algunos de sus componentes.

Espero poder ayudar,

Answer 2

Diría que haber implementado el análisis OLAP siempre es bueno y que luego tiene un gran potencial para el análisis sofisticado de datos usando MDX.

• ¿Qué quieres decir con un gran volumen?
• ¿Dónde está la información de usuario de tu cliente?
• ¿Qué tipo de front-end y reportes vas a usar?

Aclamaciones.

Descargo de responsabilidad: Voy a hacer un poco de publicidad para mi propia solución, eche un vistazo a www.icCube.com y póngase en contacto conmigo para obtener más detalles.

Answer 3

Hay dos arquitecturas principales que puede optar por la verdadera escala web:

1. Arquitectura "BI"

• Receptor de eventos (por ejemplo, LWES Journaller ) o alimentador de eventos inmutables (por ejemplo, HDFS )
• Base de datos de Analytics / column-store (por ejemplo, Greenplum , InfiniDB, LucidDB , Infobright )
• Herramienta de informes de inteligencia empresarial (por ejemplo, Microstrategy , Pentaho Business Analytics )

2. Arquitectura "NoSQL"

• (Opcional) Redactor de eventos o feeds de tiendas de eventos inmutables
• Base de datos NoSQL (por ejemplo, Cassandra , Riak, HBase)
• Una interfaz de usuario analítica personalizada (por ejemplo, utilizando D3.js )

La tienda de eventos inmutables o el periodista está ahí porque en la mayoría de los casos desea agrupar sus eventos analíticos y realizar actualizaciones masivas en su base de datos (incluso con algo como HDFS), en lugar de hacer una escritura atómica para cada vista de página, etc.

Para SnowPlow , nuestra plataforma de análisis de código abierto basada en Hadoop y Hive, los registros de eventos se recopilan todos en S3 primero antes de cargarlos en lote en Hive.

Tenga en cuenta que la "arquitectura NoSQL" implicará un poco más de trabajo de desarrollo. Recuerde que con cualquiera de las dos arquitecturas, siempre puede modificar según el cliente si los volúmenes crecen verdaderamente épicos (miles de millones de filas por cliente), porque no hay necesidad (supongo) de realizar análisis de clientes cruzados.