Het onderliggende scenario voor big data - je moet een grote hoeveelheid gegevens doorzoeken om een kleine " klompje" aan informatie. Het moet ook in de kortst mogelijke tijd worden gedaan, uw bedrijf hangt ervan af. Historisch gezien vereiste dit soort scenario's, met behulp van traditionele relationele databasebeheersysteem (RDBMS)-technologie een groot team en een investering van tijd en geld. De meeste traditionele RDBMS'en schalen alleen verticaal, dus u moet steeds grotere machines kopen om uw doorlooptijd te verkorten. De komst van openbare clouds en NoSQL-databases zoals MongoDB heeft de manier waarop teams over dit scenario denken volledig verstoord.
Een van onze klanten kwam onlangs bij ons met een interessant probleem. Ze moesten af en toe een echt complexe query uitvoeren die hun hele dataset scande. Deze zoekopdracht was zo'n beetje een collectiescan die elk document in de collectie aanraakte, en bevatte de volgende details:
- Totale gegevens waren ongeveer 100 GB.
- Gegevensveiligheid was geen probleem aangezien de hoofdkopie van de gegevens zich ergens anders bevond.
- De querysnelheid was uiterst belangrijk. Het doel was om de hele query binnen 10-15 minuten uit te voeren.
- Het systeem hoefde alleen actief te zijn wanneer de zoekopdracht wordt uitgevoerd (kosten minimaliseren).
Vanwege de laatste vereiste was het logisch om het hele systeem op een openbare cloud te draaien. De machines worden slechts een paar uur per week ingeschakeld om de gegevens te updaten en de query uit te voeren. De klant was al vertrouwd met Amazon EC2, dus werd besloten om het systeem in AWS te prototypen.
De beste configuratie om dit doel te bereiken, was een MongoDB-implementatie met 'shard'. Dit is de configuratie die we hebben gekozen:
- 3 shards – elke shard heeft een zelfstandige instantie (r3.xlarge) met 30 GB RAM
- 1 configuratieserver
- 1 shardrouter (m3.xlarge) met 15 GB RAM
Een paar dingen om op te wijzen over onze keuzes:
-
Standalone vs. replicaset
Dataveiligheid is hierbij geen belangrijke eis, aangezien de stamgegevens in een apart systeem worden opgeslagen. Daarom gingen we voor standalone servers in plaats van een replicaset om kosten te besparen.
-
3 configuratieservers versus 1 configuratieserver
een reden zoals hierboven. Gegevensveiligheid is geen belangrijk punt. In een typische productieomgeving zouden we met drie configuratieservers zijn gegaan.
Het echte mooie van deze configuratie is dat dankzij de shard-configuratie bijna de volledige 100 GB aan gegevens volledig in het geheugen wordt opgeslagen. Dus in wezen is wat u uitvoert een "in-memory" scan. Dit verminderde de uitvoeringstijd van de query drastisch van enkele uren tot minder dan 10 minuten. Het gebruik van de openbare cloud heeft ook de kapitaalinvestering drastisch verminderd, aangezien u alleen voor de machines betaalt wanneer ze draaien.
Dit is een vrij dramatische verandering in de manier waarop teams dit scenario het afgelopen decennium hebben aangepakt. Dus als u zich bezighoudt met het vinden van een speld in een hooiberg, denk dan aan Cloud + NoSQL!
Zoals altijd, als je vragen hebt, kun je ons bereiken op [email protected].