Affischbarnscenariot för big data – du måste sålla igenom en stor mängd data för att extrahera en liten ” klumpa” av information. Det måste också göras på så kort tid som möjligt, ditt företag är beroende av det. Historiskt sett krävde denna typ av scenario ett stort team och en investering av tid och pengar med traditionell RDBMS-teknik (Relational Database Management System). De flesta traditionella RDBMS skalar endast vertikalt, så du måste fortsätta köpa större och större maskiner för att minska din handläggningstid. Tillkomsten av offentliga moln och NoSQL-databaser som MongoDB har fullständigt stört hur team tänker kring detta scenario.
En av våra kunder kom nyligen till oss med ett intressant problem. De behövde med jämna mellanrum köra en riktigt komplex fråga som skannade hela deras datamängd. Den här frågan var i stort sett en samlingsskanning som berörde alla dokument i samlingen och inkluderade dessa detaljer:
- Total data var cirka 100 GB.
- Datasäkerhet var inget problem eftersom huvudkopian av data fanns någon annanstans.
- Frågehastigheten var extremt viktig. Målet var att kunna köra hela frågan inom 10-15 minuter.
- Systemet behövde bara vara uppe när frågan körs (minimera kostnaden).
På grund av det sista kravet var det vettigt att köra hela systemet på ett offentligt moln. Maskinerna slås på bara några timmar varje vecka för att data ska uppdateras och frågan ska köras. Kunden var redan bekväm med Amazon EC2, så beslutet togs att prototypa systemet i AWS.
Den bästa konfigurationen för att uppnå detta mål var en "delad" MongoDB-implementering. Här är konfigurationen vi bestämde oss för:
- 3 shards – varje shard har en fristående instans (r3.xlarge) med 30 GB RAM
- 1 konfigurationsserver
- 1 shard router (m3.xlarge) med 15 GB RAM
Ett par saker att påpeka om våra val:
-
Fristående vs. Replica Set
Datasäkerhet är inte ett viktigt krav här eftersom masterdata lagras i ett separat system. Därför valde vi fristående servrar istället för en replikuppsättning för att spara kostnader.
-
3 konfigurationsservrar vs 1 konfigurationsserver
ame anledning som ovan. Datasäkerhet är ingen viktig fråga. I en typisk produktionsmiljö skulle vi ha gått med tre konfigurationsservrar.
Det verkliga skönheten med denna konfiguration är att på grund av den sönderdelade konfigurationen lagras nästan hela 100 GB data helt i minnet. Så det du kör är i huvudsak en "in-memory"-skanning. Detta minskade dramatiskt söktiden för frågan från några timmar till mindre än 10 minuter. Användningen av det offentliga molnet minskade också kapitalinvesteringen dramatiskt eftersom du bara betalar för maskinerna när de är igång.
Detta är en ganska dramatisk förändring av hur team har hanterat detta scenario under det senaste decenniet. Så, om du är i "hitta en nål i en höstack", tänk på Cloud + NoSQL!
Som alltid, om du har några frågor kan du nå oss på [email protected].