¿Qué base de datos elegir (Cassandra, MongoDB,?) Para almacenar y consultar datos de eventos/log/métricas?

Question

En términos de SQL que está almacenando los datos de la siguiente manera:

table events (
    id 
    timestamp 
    dimension1 
    dimension2 
    dimension3 
    etc. 
) 

Todos los valores de dimensión son enteros. Esta tabla se está volviendo muy grande.

Queremos estúpidamente lecturas rápidas para las consultas de este tipo:

SELECT dimension1, dimension2, COUNT(*) 
FROM events 
WHERE dimension8 = 'foo' 
AND dimension9 = 'bar' 
GROUP BY 1, 2 

Queremos escrituras rápidas, y no se preocupan por las transacciones y consistencia. Nos preocupamos por la disponibilidad final y la tolerancia de partición.

Estaba buscando alternativas "NoSQL". ¿Puede Casandra hacer el tipo de consultas que estoy buscando? Esto no es inmediatamente obvio al leer sus documentos ... si puede hacerlo, ¿cuál es su rendimiento para esos tipos de consultas?

También estaba mirando a MongoDB, pero su función de "grupo()" tiene serias limitaciones por lo que pude leer (máximo de 10.000 filas).

¿Tiene experiencia con alguna de estas bases de datos y la recomendaría como solución al problema descrito anteriormente?

¿Hay alguna otra base de datos que deba considerar que pueda hacer este tipo de consultas rápidamente?

Saludos, barreta

Answer 1

también estaba mirando a MongoDB, pero su "grupo()" función tiene severas limitaciones por lo que he podido leer (máximo de 10.000 filas).

Para aclarar, se trata de 10.000 filas devueltas. En su ejemplo, esto funcionará para hasta 10,000 combinaciones de dimension1/dimension2. Si es demasiado grande, también puede usar el Map/Reduce más lento. Tenga en cuenta que si está ejecutando una consulta con más de 10k resultados, puede ser mejor utilizar Map/Reduce y guardar esta información. 10k es un gran resultado de consulta para, de lo contrario, simplemente "tirar".

¿Tiene experiencia con alguna de estas bases de datos y la recomendaría como solución al problema descrito anteriormente?

Muchas personas realmente usan MongoDB para hacer este tipo de resumen "en tiempo real", pero lo hacen usando "contadores" en lugar de "agregación". En lugar de "desplegar" datos detallados, harán una inserción regular y luego incrementarán algunos contadores.

En particular, el uso de los atomic modifiers como $inc & $push de datos de actualización atómicamente en una sola solicitud.

Eche un vistazo a hummingbird para que alguien lo haga en este momento. También hay un sistema de registro de eventos de código abierto respaldado por MongoDB: Graylog2. ServerDensity también hace el registro de eventos del servidor respaldado por MongoDB.

Si lo mira, puede darle un poco de inspiración para los tipos de registro que desea hacer.

Answer 2

"Agrupar por" y "estúpidamente rápido" no van juntos. Esa es solo la naturaleza de esa bestia ...De ahí las limitaciones en la operación grupal de Mongo; Cassandra ni siquiera lo admite de forma nativa (aunque lo hace para las consultas de Hive o Pig a través de Hadoop ... pero esas no están destinadas a ser estúpidamente rápidas).

Sistemas como de Twitter Rainbird (que utiliza Cassandra) que realizan análisis en tiempo real hacen por desnormalización/pre-computación los recuentos: http://www.slideshare.net/kevinweil/rainbird-realtime-analytics-at-twitter-strata-2011

Answer 3

empecé a ir por este camino para un propósito similar (métricas de recolección y presentación de informes), y aquí es donde terminé ...

Obtener los datos es la parte fácil. Sacar los datos es la parte difícil.

Si tiene tiempo y talento, puede aprender y usar una combinación de herramientas de código abierto como se describe aquí: http://kibana.org/infrastructure.html. La lista de piezas:

• Syslog-ng - Syslogd
• Logstash - ducto de registro de gran alcance
• RabbitMQ o Redis - Para los mensajes en cola
• Elasticsearch - almacenamiento de documentos de texto completo y búsqueda
• Grafito - De Orbitz, Graficación en tiempo real escalable
• Statsd - Desde Etsy, cuenta las ocurrencias de campos y envía a grafito
• Graphital - A ruby ​​dae mon para enviar datos de rendimiento de nivel de host al grafito
• Kibana - Un frente de terminar el análisis de registros basado en navegador para Logstash y Elasticsearch

Si usted tiene más dinero que tiempo, considere Splunk. Es caro, pero es una buena opción para muchas situaciones. p.ej. Estoy en una situación en la que el cliente es extremadamente escaso con las personas, pero no les importa gastar dinero, por lo que splunk ha sido una buena opción ya que es más una solución llave en mano que aprender y unir un compuesto de herramientas .