Mongodb vs Cassandra para agregar, buscar y analizar muchos registros

Question

Estoy trabajando en un proyecto que registra la agregación y el análisis como parte de un proyecto más grande. No sé qué base de datos elegir para manejar estos registros. Últimamente voy y vienen entre MongoDB y Cassandra, pero estoy seguro de que hay otros que también se ajustan a mis necesidades. ¿Cuál debería elegir y por qué?

Todo esto es muy al principio en este momento, pero aquí son los requisitos hasta ahora:

• registros están en el formato syslog
• consultas son en su mayoría en una pequeña cadena que ahora está en el mensaje , pero lo conseguiré en un campo separado. Y también habrá filtros basados ​​en la fecha, la gravedad o la etiqueta. Muy rara vez, la gente simplemente busca una cadena aleatoria dentro del mensaje.
• análisis por hora de algunas de las entradas del registro
• mantener a los registros de un período de tiempo configurable
• vendrán más, estoy seguro :) Es por eso que estoy pensando NoSQL es más apropiado, porque podemos cambiar el esquema

Estamos esperando hacer crecer la base de datos a algunos TB de datos (y ~ 50K insertos por segundo), por lo que la fragmentación es una necesidad. Las consultas no son tan frecuentes, ya que son utilizadas principalmente por los desarrolladores del proyecto más grande. Pero un resultado debe ser devuelto en unos segundos.

En este momento, el almacenamiento es común (y lento) para todas las máquinas. Por lo tanto, para la escalabilidad, supongo que necesitamos hacer un mejor uso de la memoria y el subprocesamiento múltiple para que la fragmentación tenga sentido.

Las ideas básicas que obtuve hasta ahora son que MongoDB tiene más funciones, como resultados de clasificación o regex, y es más fácil configurar una configuración decente, mientras que Cassandra parece más escalable (simplemente agregando servidores), y también tiene una algunas características interesantes, como poner un TTL en los datos.

Answer 1

MongoDB suena como un buen ajuste para sus requisitos. He aquí por qué:

• índices: ya que desea ejecutar consultas ocasionales, es agradable no tener que mantenerlos en su aplicación o tener una aplicación de búsqueda por separado (Lucene).
• escalas bien (soporte incorporado sharding, replicación)
• escrituras son asíncronas (por defecto, usted podría hacer que Synchr.), Es decir sin bloqueo, y rápido. Es posible que pierda algunos en ciertos escenarios de falla, pero para registros y análisis, no haría la diferencia.
• API de consulta bastante poderosa (no como relacional, sin uniones, pero mejor que todas las demás tiendas clave-valor nosql, y suena más poderoso que lo que ofrece Cassandra).

Incluso puede encontrar una configuración adecuada para tenerlo en una configuración no fragmentada. Por ejemplo, de forma predeterminada se sincroniza en el disco cada 60 segundos, lo que significa que 60 segundos de escrituras se amortiguarán, lo que reduce el IO. Lo probé en medio terabyte de datos en una sola máquina y las consultas de un solo campo indexado se ejecutan en cca 100-200ms.

Answer 2

Las áreas de almacenamiento de datos escasamente columnares como Apache Cassandra son excelentes para agregar datos de series de tiempo.Vea los artículos siguientes ejemplos:

• Basic time series with Cassandra
• 4 Months with Cassandra
• Understanding the Cassandra data model

Answer 3

Dado que el sistema será una aplicación de alto rendimiento de escritura que recomendaría Cassandra.

He reunido una descripción de alto nivel de las diferencias entre MongoDB y Cassandra aquí - https://scalegrid.io/blog/cassandra-vs-mongodb/