Scénář plakátového potomka pro velká data – potřebujete prosít velké množství dat, abyste získali malý „ nugget“ informací. Také to musí být provedeno v co nejkratším čase, vaše firma na tom závisí. Historicky, při použití tradiční technologie systému správy relačních databází (RDBMS), tento druh scénáře vyžadoval velký tým a investice času a peněz. Většina tradičních RDBMS měří pouze vertikálně, takže musíte stále kupovat větší a větší stroje, abyste zkrátili dobu obratu. Nástup veřejných cloudů a databází NoSQL, jako je MongoDB, zcela narušil způsob, jakým týmy o tomto scénáři uvažují.
Jeden z našich zákazníků k nám nedávno přišel se zajímavým problémem. Pravidelně potřebovali spouštět opravdu složitý dotaz, který skenoval celou jejich datovou sadu. Tento dotaz byl v podstatě skenem sbírky, který se dotkl všech dokumentů ve sbírce a zahrnoval tyto podrobnosti:
- Celková data byla přibližně 100 GB.
- Bezpečnost dat nepředstavovala problém, protože hlavní kopie dat byla umístěna jinde.
- Rychlost dotazu byla extrémně důležitá. Cílem bylo být schopen spustit celý dotaz během 10-15 minut.
- Systém musel být spuštěn pouze tehdy, když je spuštěn dotaz (minimalizujte náklady).
Vzhledem k poslednímu požadavku dávalo smysl provozovat celý systém na veřejném cloudu. Stroje se každý týden zapnou pouze na několik hodin, aby se data aktualizovala a dotaz se spustil. Zákazníkovi již Amazon EC2 vyhovoval, a tak bylo rozhodnuto prototypovat systém v AWS.
Nejlepší konfigurací k dosažení tohoto cíle bylo „sharded“ nasazení MongoDB. Zde je konfigurace, na které jsme se dohodli:
- 3 fragmenty – každý fragment má samostatnou instanci (r3.xlarge) s 30 GB RAM
- 1 konfigurační server
- 1 směrovač shard (m3.xlarge) s 15 GB paměti RAM
Několik věcí, které bychom měli upozornit na naše volby:
-
Samostatná vs. sada replik
Bezpečnost dat zde není důležitým požadavkem, protože kmenová data jsou uložena v samostatném systému. Proto jsme šli se samostatnými servery namísto sady replik, abychom ušetřili náklady.
-
3 konfigurační servery vs 1 konfigurační server
stejný důvod jako výše. Bezpečnost dat není důležitá otázka. V typickém produkčním prostředí bychom použili tři konfigurační servery.
Skutečná krása této konfigurace spočívá v tom, že díky sdílené konfiguraci je téměř celých 100 GB dat uloženo kompletně v paměti. Takže v podstatě to, co spouštíte, je skenování „v paměti“. Tím se dramaticky zkrátila doba běhu dotazu z několika hodin na méně než 10 minut. Použití veřejného cloudu také dramaticky snížilo kapitálové investice, protože za stroje platíte pouze tehdy, když běží.
Toto je poměrně dramatická změna v tom, jak týmy tento scénář za poslední desetiletí zvládaly. Pokud tedy podnikáte v oblasti „hledání jehly v kupce sena“, přemýšlejte o Cloud + NoSQL!
Jako vždy, pokud máte nějaké dotazy, můžete nás kontaktovat na adrese [email protected].