Scenariusz potomny plakatu dla dużych zbiorów danych – musisz przesiać dużą ilość danych, aby wyodrębnić maleńki „ bryłka” informacji. Ponadto musi to zostać zrobione w jak najkrótszym czasie, od tego zależy Twoja firma. Historycznie, przy użyciu tradycyjnej technologii systemu zarządzania relacyjnymi bazami danych (RDBMS), tego rodzaju scenariusz wymagał dużego zespołu oraz zainwestowania czasu i pieniędzy. Większość tradycyjnych RDBMS skaluje się tylko w pionie, więc musisz kupować coraz większe maszyny, aby skrócić czas realizacji. Pojawienie się chmur publicznych i baz danych NoSQL, takich jak MongoDB, całkowicie zmieniło sposób myślenia zespołów o tym scenariuszu.
Jeden z naszych klientów zgłosił się niedawno do nas z interesującym problemem. Od czasu do czasu musieli uruchamiać naprawdę złożone zapytania, które skanowały cały ich zestaw danych. To zapytanie było w zasadzie skanem kolekcji, który dotyczył każdego dokumentu w kolekcji i zawierał następujące szczegóły:
- Łączna ilość danych wynosiła około 100 GB.
- Bezpieczeństwo danych nie było problemem, ponieważ główna kopia danych znajdowała się gdzie indziej.
- Szybkość zapytań była niezwykle ważna. Celem było uruchomienie całego zapytania w ciągu 10-15 minut.
- System musiał działać tylko wtedy, gdy zapytanie jest uruchomione (minimalizuj koszt).
Ze względu na ostatnie wymaganie sensowne było uruchomienie całego systemu w chmurze publicznej. Maszyny są włączane tylko na kilka godzin tygodniowo, aby dane zostały zaktualizowane i zapytanie zostało uruchomione. Klient był już zadowolony z Amazon EC2, więc podjęto decyzję o prototypowaniu systemu w AWS.
Najlepszą konfiguracją do osiągnięcia tego celu było „sharded” wdrożenie MongoDB. Oto konfiguracja, na którą się zdecydowaliśmy:
- 3 shardy – każdy shard ma samodzielną instancję (r3.xlarge) z 30 GB pamięci RAM
- 1 serwer konfiguracyjny
- 1 router shard (m3.xlarge) z 15 GB pamięci RAM
Kilka rzeczy, na które należy zwrócić uwagę przy naszych wyborach:
-
Zestaw samodzielny kontra replika
Bezpieczeństwo danych nie jest tutaj ważnym wymogiem, ponieważ dane podstawowe są przechowywane w osobnym systemie. Dlatego zdecydowaliśmy się na samodzielne serwery zamiast zestawu replik, aby zaoszczędzić na kosztach.
-
3 serwery konfiguracyjne kontra 1 serwer konfiguracyjny
z tego powodu jak powyżej. Bezpieczeństwo danych nie jest ważną kwestią. W typowym środowisku produkcyjnym wybralibyśmy trzy serwery konfiguracyjne.
Prawdziwe piękno tej konfiguracji polega na tym, że dzięki konfiguracji podzielonej na fragmenty prawie całe 100 GB danych jest przechowywane całkowicie w pamięci. Zasadniczo to, co uruchamiasz, to skanowanie „w pamięci”. To znacznie skróciło czas wykonywania zapytania z kilku godzin do mniej niż 10 minut. Korzystanie z chmury publicznej znacznie zmniejszyło również inwestycje kapitałowe, ponieważ płacisz za maszyny tylko wtedy, gdy są uruchomione.
Jest to dość dramatyczna zmiana sposobu, w jaki zespoły radzą sobie z tym scenariuszem w ciągu ostatniej dekady. Tak więc, jeśli zajmujesz się „znalezieniem igły w stogu siana”, pomyśl o Cloud + NoSQL!
Jak zawsze, jeśli masz jakiekolwiek pytania, możesz skontaktować się z nami pod adresem [email protected].
