Mongodb vs Cassandra per l'aggregazione, la ricerca e l'analisi di molti registri

Question

Sto lavorando a un progetto che registra l'aggregazione e l'analisi come parte di un progetto più grande. Non so quale database scegliere per gestire questi registri. Ultimamente sto andando avanti e indietro tra MongoDB e Cassandra, ma sono sicuro che ce ne sono altri che si adattano anche ai miei bisogni. Quale dovrei scegliere e perché?

Il tutto è abbastanza all'inizio il momento, ma qui sono i requisiti finora:

• log sono in formato syslog
• query sono per lo più su una piccola stringa che ora è nel messaggio , ma lo otterrò in un campo separato. E ci saranno anche filtri basati su data, gravità o tag. Molto raramente, le persone cercano solo una stringa casuale all'interno del messaggio.
• analisi ogni ora da alcune delle voci di registro
• tenere i registri di un periodo di tempo configurabile
• più arriverà, sono sicuro :) Ecco perché sto pensando NoSQL è più appropriato, perché possiamo cambia lo schema.

Ci si aspetta di far crescere il database per alcuni TB di dati (e ~ 50K di inserzioni al secondo), quindi la condivisione è un must. Le query non sono così frequenti, perché sono utilizzate principalmente dagli sviluppatori del progetto più grande. Ma un risultato deve essere restituito in pochi secondi.

Al momento, lo spazio di archiviazione è comune (e lento) per tutte le macchine. Quindi, per la scalabilità, suppongo che dobbiamo fare il miglior uso della memoria e del multithreading, in modo che la sharding abbia senso.

Le idee di base ho ottenuto finora è che MongoDB ha più funzioni, come espressione regolare o l'ordinamento dei risultati, ed è più facile installazione per una configurazione decente, mentre Cassandra sembra più scalabile (da server semplicemente aggiungendo), e ha anche un alcune caratteristiche pulite, come mettere un TTL sui dati.

Answer 1

MongoDB suona come una buona misura per le vostre esigenze. Ecco perché:

• indici: dal momento che si desidera eseguire query occasionali, è opportuno non doverli mantenere nella propria app o avere un'app di ricerca separata (Lucene).
• bilanciato (supporto sharding incorporato, replica)
• le scritture sono asincrone (per impostazione predefinita, è possibile renderle sincrone), ovvero non bloccanti e veloci. Potresti perdere alcuni in determinati scenari di errore, ma per i log e l'analisi non farebbe differenza.
• API di query abbastanza potente (non come relazionale, nessun join, ma meglio di tutti gli altri negozi di valori chiave nosql, e suona più potente di quello che offre Cassandra).

Si potrebbe anche trovare una configurazione adeguata per averlo in una configurazione non-sharded. Ad esempio, per impostazione predefinita si sincronizza su disco ogni 60 secondi, il che significa che verranno bufferizzati 60 secondi di scritture riducendo quindi l'IO. L'ho provato su un mezzo terabyte di dati su una singola macchina e una singola query di campo indicizzata eseguita in cca 100-200ms.

Answer 2

I datastore scarsamente colonnari come Apache Cassandra sono eccellenti per aggregare i dati delle serie temporali.Vedere i seguenti articoli per gli esempi:

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

Answer 3

Dato che il sistema sarà un'applicazione elevato throughput di scrittura mi sento di raccomandare Cassandra.

ho messo insieme una panoramica di alto livello delle differenze tra MongoDB e Cassandra qui - https://scalegrid.io/blog/cassandra-vs-mongodb/