Lo scenario figlio poster per i big data:è necessario setacciare una grande quantità di dati per estrarre un minuscolo " pepita” di informazioni. Inoltre, deve essere fatto nel minor tempo possibile, la tua attività dipende da questo. Storicamente, utilizzando la tradizionale tecnologia del sistema di gestione di database relazionali (RDBMS), questo tipo di scenario richiedeva un team numeroso e un investimento di tempo e denaro. La maggior parte degli RDBMS tradizionali si ridimensiona solo verticalmente, quindi devi continuare ad acquistare macchine sempre più grandi per ridurre i tempi di consegna. L'avvento dei cloud pubblici e dei database NoSQL come MongoDB ha completamente sconvolto il modo in cui i team pensano a questo scenario.
Uno dei nostri clienti si è rivolto di recente a noi con un problema interessante. Periodicamente avevano bisogno di eseguire una query davvero complessa che scansionasse l'intero set di dati. Questa query era praticamente una scansione di una raccolta che riguardava tutti i documenti della raccolta e includeva questi dettagli:
- I dati totali erano di circa 100 GB.
- La sicurezza dei dati non è stata un problema poiché la copia master dei dati risiedeva altrove.
- La velocità delle query era estremamente importante. L'obiettivo era riuscire a eseguire l'intera query entro 10-15 minuti.
- Il sistema doveva essere attivo solo quando la query è in esecuzione (ridurre al minimo i costi).
A causa dell'ultimo requisito, aveva senso eseguire l'intero sistema su un cloud pubblico. Le macchine vengono accese solo per poche ore ogni settimana per l'aggiornamento dei dati e l'esecuzione della query. Il cliente era già a suo agio con Amazon EC2, quindi è stata presa la decisione di prototipare il sistema in AWS.
La configurazione migliore per raggiungere questo obiettivo è stata un'implementazione "sharded" di MongoDB. Ecco la configurazione su cui ci siamo stabiliti:
- 3 shard:ogni shard ha un'istanza standalone (r3.xlarge) con 30 GB di RAM
- 1 server di configurazione
- 1 router shard (m3.xlarge) con 15 GB di RAM
Un paio di cose da sottolineare sulle nostre scelte:
-
Set standalone vs. Replica
La sicurezza dei dati non è un requisito importante in questo caso poiché i dati di base sono memorizzati in un sistema separato. Quindi abbiamo optato per server standalone invece di un set di repliche per risparmiare sui costi.
-
3 server di configurazione contro 1 server di configurazione
un motivo come sopra. La sicurezza dei dati non è una questione importante. In un tipico ambiente di produzione avremmo optato per tre server di configurazione.
La vera bellezza di questa configurazione è che, a causa della configurazione partizionata, quasi tutti i 100 GB di dati vengono archiviati completamente in memoria. Quindi, essenzialmente ciò che stai eseguendo è una scansione "in memoria". Ciò ha ridotto drasticamente il tempo di esecuzione della query da poche ore a meno di 10 minuti. L'uso del cloud pubblico ha anche ridotto drasticamente l'investimento di capitale poiché paghi solo per le macchine quando sono in funzione.
Questo è un cambiamento abbastanza drammatico nel modo in cui i team hanno gestito questo scenario nell'ultimo decennio. Quindi, se ti occupi di "trovare un ago in un pagliaio", pensa a Cloud + NoSQL!
Come sempre, se hai domande puoi contattarci all'indirizzo [email protected].
