Das Vorzeige-Szenario für Big Data – Sie müssen eine große Datenmenge sichten, um ein winziges „ Nugget“ an Informationen. Außerdem muss es so schnell wie möglich erledigt werden, Ihr Unternehmen hängt davon ab. In der Vergangenheit erforderte diese Art von Szenario unter Verwendung traditioneller relationaler Datenbankverwaltungssystem-Technologie (RDBMS) ein großes Team und eine Investition von Zeit und Geld. Die meisten herkömmlichen RDBMS skalieren nur vertikal, sodass Sie immer größere Maschinen kaufen müssen, um Ihre Bearbeitungszeit zu verkürzen. Das Aufkommen von Public Clouds und NoSQL-Datenbanken wie MongoDB hat die Art und Weise, wie Teams über dieses Szenario denken, völlig verändert.
Einer unserer Kunden kam kürzlich mit einem interessanten Problem zu uns. Sie mussten regelmäßig eine wirklich komplexe Abfrage ausführen, die ihren gesamten Datensatz durchsuchte. Diese Abfrage war so ziemlich ein Sammlungsscan, der jedes Dokument in der Sammlung berührte und diese Details enthielt:
- Die Gesamtdatenmenge betrug etwa 100 GB.
- Die Datensicherheit war kein Problem, da sich die Masterkopie der Daten woanders befand.
- Die Abfragegeschwindigkeit war extrem wichtig. Das Ziel war, die gesamte Abfrage innerhalb von 10–15 Minuten ausführen zu können.
- Das System musste nur aktiv sein, wenn die Abfrage ausgeführt wurde (Minimierung der Kosten).
Aufgrund der letzten Anforderung war es sinnvoll, das gesamte System in einer Public Cloud zu betreiben. Die Maschinen werden jede Woche nur für wenige Stunden eingeschaltet, damit die Daten aktualisiert und die Abfrage ausgeführt werden kann. Der Kunde war bereits mit Amazon EC2 vertraut, daher wurde die Entscheidung getroffen, das System in AWS zu prototypisieren.
Die beste Konfiguration, um dieses Ziel zu erreichen, war eine „geteilte“ MongoDB-Bereitstellung. Hier ist die Konfiguration, für die wir uns entschieden haben:
- 3 Shards – jeder Shard hat eine eigenständige Instanz (r3.xlarge) mit 30 GB RAM
- 1 Konfigurationsserver
- 1 Shard-Router (m3.xlarge) mit 15 GB RAM
Ein paar Dinge, auf die wir bei unseren Entscheidungen hinweisen sollten:
-
Eigenständig vs. Replica-Set
Datensicherheit ist hier keine wichtige Anforderung, da die Stammdaten in einem separaten System gespeichert werden. Daher haben wir uns für eigenständige Server anstelle eines Replikats entschieden, um Kosten zu sparen.
-
3 Konfigurationsserver vs. 1 Konfigurationsserver
gleichen Grund wie oben. Datensicherheit ist kein wichtiges Thema. In einer typischen Produktionsumgebung wären wir mit drei Konfigurationsservern gegangen.
Das wirklich Schöne an dieser Konfiguration ist, dass aufgrund der Sharding-Konfiguration fast die gesamten 100 GB an Daten vollständig im Arbeitsspeicher gespeichert werden. Was Sie also im Wesentlichen ausführen, ist ein „In-Memory“-Scan. Dadurch wurde die Laufzeit der Abfrage drastisch von wenigen Stunden auf weniger als 10 Minuten reduziert. Die Nutzung der Public Cloud hat auch die Kapitalinvestition drastisch reduziert, da Sie nur für die Maschinen bezahlen, wenn sie laufen.
Dies ist eine ziemlich dramatische Änderung im Umgang der Teams mit diesem Szenario in den letzten zehn Jahren. Wenn Sie also im Geschäft „die Nadel im Heuhaufen finden“ tätig sind, denken Sie an Cloud + NoSQL!
Wenn Sie Fragen haben, können Sie uns wie immer unter [email protected] erreichen.
