Plakat underordnet scenarie for big data – du skal gennemsøge en stor mængde data for at udtrække en lille “ guldklump” af information. Det skal også gøres på kortest mulig tid, din virksomhed afhænger af det. Historisk set krævede denne form for scenarie et stort team og en investering af tid og penge ved at bruge traditionel RDBMS-teknologi (Relational Database Management System). De fleste traditionelle RDBMS'er skalerer kun lodret, så du skal blive ved med at købe større og større maskiner for at reducere din ekspeditionstid. Fremkomsten af offentlige skyer og NoSQL-databaser som MongoDB har fuldstændig forstyrret, hvordan teams tænker på dette scenarie.
En af vores kunder kom for nylig til os med et interessant problem. De havde med jævne mellemrum brug for at køre en virkelig kompleks forespørgsel, der scannede hele deres datasæt. Denne forespørgsel var stort set en samlingsscanning, der berørte hvert dokument i samlingen og indeholdt disse detaljer:
- Samlede data var omkring 100 GB.
- Datasikkerhed var ikke et problem, da masterkopien af dataene lå et andet sted.
- Forespørgselshastighed var ekstremt vigtig. Målet var at kunne køre hele forespørgslen inden for 10-15 minutter.
- Systemet skulle kun være oppe, når forespørgslen kører (minimer omkostningerne).
På grund af det sidste krav gav det mening at køre hele systemet på en offentlig sky. Maskinerne bliver kun tændt i et par timer hver uge, så dataene bliver opdateret, og forespørgslen kan køre. Kunden var allerede fortrolig med Amazon EC2, så det blev besluttet at prototype systemet i AWS.
Den bedste konfiguration til at nå dette mål var en "sønderdelt" MongoDB-implementering. Her er den konfiguration, vi slog os fast på:
- 3 shards – hvert shard har en selvstændig instans (r3.xlarge) med 30 GB RAM
- 1 konfigurationsserver
- 1 shard router (m3.xlarge) med 15 GB RAM
Et par ting at påpege om vores valg:
-
Fristående vs. Replikasæt
Datasikkerhed er ikke et vigtigt krav her, da stamdata er lagret i et separat system. Derfor valgte vi selvstændige servere i stedet for et replikasæt for at spare omkostninger.
-
3 konfigurationsservere vs 1 konfigurationsserver
ame grund som ovenfor. Datasikkerhed er ikke et vigtigt emne. I et typisk produktionsmiljø ville vi have gået med tre konfigurationsservere.
Den virkelige skønhed ved denne konfiguration er, at på grund af den sønderdelte konfiguration er næsten hele 100 GB data gemt fuldstændigt i hukommelsen. Så i det væsentlige er det, du kører, en "in-memory"-scanning. Dette reducerede kørselstiden for forespørgslen dramatisk fra et par timer til mindre end 10 minutter. Brugen af den offentlige sky reducerede også kapitalinvesteringen dramatisk, da du kun betaler for maskinerne, når de kører.
Dette er en ret dramatisk ændring af, hvordan teams har håndteret dette scenarie i løbet af det sidste årti. Så hvis du er i "at finde en nål i en høstak", så tænk på Cloud + NoSQL!
Som altid, hvis du har spørgsmål, kan du kontakte os på [email protected].