Ponieważ została już przesłana i udzielona odpowiedź, a także przydatna i prawidłowa, nie chcę odwracać uwagi od jej własnej przydatności, ale w rzeczywistości istnieją rzeczy, które należy podnieść, które wykraczają poza krótki komentarz. Rozważ więc to „powiększenie”, które, miejmy nadzieję, jest ważne, ale przede wszystkim stanowi uzupełnienie tego, co zostało już powiedziane.
Prawda jest taka, aby naprawdę rozważyć „sposób, w jaki aplikacja wykorzystuje dane”, a także być świadomym czynników, które wpływają na „środowisko podzielone”, a także proponowane „środowisko kontenerowe”, które na to wpływają.
Sprawa w tle
Ogólne zalecenie praktyczne dotyczące kolokacji mongosprocesu wraz z instancją aplikacji polega na uniknięciu narzutu sieciowego wymaganego do komunikacji aplikacji z tym mongosprocesem. Oczywiście „zalecaną praktyką” jest także określenie liczby mongoswystąpień w ciągu połączenia aplikacji w przypadku, gdy z jakiegoś powodu ten „najbliższy” węzeł nie powinien być dostępny, można wybrać inny, aczkolwiek z możliwym narzutem związanym z kontaktem z zdalny węzeł.
Przypadek „dokera”, o którym wspominasz, wydaje się nieco arbitralny. Chociaż prawdą jest, że jednym z głównych celów kontenerów (a wcześniej czegoś takiego jak więzienia BSD lub nawet chroot) jest ogólnie osiągnięcie pewnego poziomu „izolacji procesu”, nie ma nic złego w prowadzeniu wielu procesów, o ile zrozumieć konsekwencje.
W tym konkretnym przypadku mongosma on być „lekki” i działać jako „dodatkowa funkcja” w procesie aplikacji w taki sposób, że jest to „sparowana” część samej aplikacji. Tak więc obrazy dokerów same w sobie nie mają procesu „inicjowanego”, ale tak naprawdę nie ma nic złego w uruchamianiu kontrolera procesu, takiego jak nadzór (na przykład), jako głównego procesu dla kontenera, który następnie daje punkt kontroli nad procesem ten pojemnik również. Ta sytuacja „sparowanych procesów” jest uzasadnionym przypadkiem, a także dość powszechnym pytaniem o oficjalną dokumentację .
Jeśli wybierzesz tego rodzaju „sparowaną” operację do wdrożenia, to rzeczywiście dotyczy on podstawowego punktu utrzymania mongosinstancji w tym samym połączeniu sieciowym i rzeczywiście „instancji serwera” jak sam serwer aplikacji. Można to również w pewien sposób postrzegać jako przypadek, w którym „cały kontener” miałby zawieść, wówczas sam węzeł byłby po prostu nieprawidłowy. Nie to, że poleciłbym to, i w rzeczywistości prawdopodobnie powinieneś nadal konfigurować połączenia, aby szukać innych mongosinstancji, nawet jeśli są one dostępne tylko przez połączenie sieciowe, które zwiększa opóźnienie.
Wersja specyficzna / specyficzna dla użycia
Teraz, gdy już o tym mowa, druga uwaga sprowadza się do wstępnego rozważenia wspólnej lokalizacji mongosprocesu z aplikacją do celów związanych z opóźnieniem sieci. W wersjach MongoDB wcześniejszych niż 2.6, a zwłaszcza w odniesieniu do operacji, takich jak w ramach agregacji, wtedy było tak, że ruch sieciowy byłby znacznie większy, a następnie po przetworzeniu pracy wykonanej przez mongosproces przetwarzania danych z różnych odłamków . Nie jest tak obecnie, ponieważ znaczną część przetwarzania można teraz wykonać na tych odłamkach przed „destylacją” na „routerze”.
Innym przypadkiem są same wzorce użytkowania aplikacji w odniesieniu do dzielenia na fragmenty. Oznacza to, czy głównym obciążeniem jest „rozdzielanie zapisów” na wiele niezależnych fragmentów, czy też podejście „zbieranie rozproszone” w konsolidacji żądań odczytu. W tych scenariuszach
Testuj, testuj, a następnie testuj ponownie
Zatem końcowy punkt tutaj jest naprawdę oczywisty i sprowadza się do podstawowego konsensusu każdej rozsądnej odpowiedzi na twoje pytanie. Nie jest to nowością dla MongoDB ani żadnego innego rozwiązania pamięci masowej, ale rzeczywiste środowisko wdrażania należy przetestować pod kątem „wzorców użytkowania” tak zbliżonych do rzeczywistej rzeczywistości, jak każde „testowanie jednostkowe” oczekiwanej funkcjonalności z podstawowych komponentów lub ogólne wyniki muszą zostać przetestowane.
Naprawdę nie ma „definitywnego” stwierdzenia, które mówi „skonfiguruj w ten sposób” lub „używaj w ten sposób”, które ma sens poza testowaniem tego, co „faktycznie działa najlepiej” dla wydajności i niezawodności aplikacji zgodnie z oczekiwaniami.
Oczywiście „najlepszym przypadkiem” zawsze będzie nie „tłumienie” mongosinstancji żądaniami z „wielu” źródeł serwerów aplikacji. Ale potem, aby pozwolić im na pewną naturalną „parzystość”, którą można rozdzielić za pomocą dostępnych obciążeń zasobów, na posiadanie co najmniej „puli zasobów”, którą można wybrać, i rzeczywiście idealnie w wielu przypadkach, ale eliminując potrzebę wywołania dodatkowego „koszty transportu sieciowego”.
Taki jest cel, ale najlepiej można „przetestować laboratoryjnie” różne postrzegane konfiguracje, aby znaleźć rozwiązanie „najlepiej dopasowane” do ostatecznego rozwiązania wdrożeniowego.
Zdecydowanie poleciłbym również „bezpłatne” (jak w piwie) kursy dostępne, jak już wspomniano, bez względu na poziom wiedzy. Uważam, że różne źródła materiałów szkoleniowych często oferują „ukryte klejnoty”, aby dać więcej wglądu w rzeczy, których nie wziąłeś pod uwagę lub w inny sposób przeoczyłeś. Klasa M102 jak wspomniano jest zbudowany i prowadzony przez Adama Commerford za którymi może świadczyć ma wysoki poziom wiedzy na dużych drożeń MongoDB i innych architektur danych. Warto poświęcić przynajmniej czas na zastanowienie się nad nowym spojrzeniem na to, co możesz myśleć, że już wiesz.