Istnieją teoretyczne granice, co pokażę poniżej, ale nawet dolna granica jest ładna wysoki. Prawidłowe obliczenie granic nie jest łatwe, ale rząd wielkości powinien być wystarczający.
mmapv1
Rzeczywisty limit zależy od kilku rzeczy, takich jak długość nazw fragmentów i tym podobnych (to suma, jeśli masz ich kilkaset tysięcy), ale oto przybliżone obliczenia z rzeczywistymi danymi.
Każdy fragment potrzebuje trochę miejsca w konfiguracyjnej bazie danych, która jest ograniczona, jak każda inna baza danych, do 32 TB na pojedynczej maszynie lub w zestawie replik. Na serwerach, którymi administruję, średni rozmiar wpisu w config.shards wynosi 112 bajtów. Ponadto każda porcja wymaga około 250 bajtów informacji o metadanych. Załóżmy, że optymalne rozmiary porcji są zbliżone do 64 MB.
Możemy mieć maksymalnie 500 000 porcji na serwer. 500 000 * 250 bajtów to 125 MB dla informacji porcji na fragment. Tak więc na fragment mamy 125 000112 MB na fragment, jeśli zmaksymalizujemy wszystko. Dzielenie 32 TB przez tę wartość pokazuje nam, że możemy mieć maksymalnie nieco poniżej 256 000 shardów w klastrze.
Każdy fragment z kolei może pomieścić 32 TB danych. 256 000 * 32 TB to 8,19200 eksabajtów lub 8192 000 terabajtów. To byłby limit dla naszego przykładu.
Powiedzmy, że ma 8 eksabajtów. W tej chwili można to łatwo przetłumaczyć na „Wystarczy do wszystkich praktycznych celów”. Aby zrobić wrażenie:wszystkie dane przechowywane przez Bibliotekę Kongresu (prawdopodobnie jedną z największych bibliotek na świecie pod względem wielkości kolekcji) zawierają dane o szacunkowej wielkości około 20 TB, w tym materiały audio, wideo i cyfrowe. Można to zmieścić w naszym teoretycznym klastrze MongoDB około 400 000 razy. Zauważ, że jest to dolna granica maksymalnego rozmiaru przy użyciu konserwatywnych wartości.
WiredTiger
Teraz dobra część:Silnik pamięci masowej WiredTiger nie ma tego ograniczenia:rozmiar bazy danych nie jest ograniczony (ponieważ nie ma limitu liczby plików danych, które można wykorzystać), więc możemy mieć nieograniczoną liczbę fragmentów. Nawet jeśli mamy te shardy działające na mmapv1 i tylko nasze serwery konfiguracyjne na WT, rozmiar a staje się prawie nieograniczony – ograniczenie do 16,8 mln TB pamięci RAM w systemie 64-bitowym może gdzieś spowodować problemy i spowodować indeksy config.shard kolekcja, która ma zostać zamieniona na dysk, blokując system. Mogę się tylko domyślać, ponieważ mój kalkulator odmawia pracy z liczbami w tym obszarze (a jestem zbyt leniwy, aby robić to ręcznie), ale szacuję limit tutaj w dwucyfrowym obszarze yottabajta (i miejsca potrzebnego do hostowania tego gdzieś wielkości Teksasu).
Wniosek
Nie martw się o maksymalny rozmiar danych w środowisku sharded. Bez względu na wszystko, jest wystarczająco dużo, nawet przy najbardziej konserwatywnym podejściu. Użyj shardingu i gotowe. Btw:nawet 32 TB to cholernie dużo danych:większość znanych mi klastrów przechowuje mniej danych i odłamków, ponieważ wykorzystanie IOPS i pamięci RAM przekroczyło pojemność pojedynczego węzła.
