Trudno powiedzieć, jaka jest optymalna wstawka zbiorcza — zależy to częściowo od rozmiaru wstawianych obiektów i innych niemierzalnych czynników. Możesz wypróbować kilka zakresów i zobaczyć, co zapewnia najlepszą wydajność. Alternatywnie, niektórzy ludzie lubią używać mongoimport, który jest dość szybki, ale dane importu muszą być w formacie json lub csv. Oczywiście istnieje mongorestore, jeśli dane są w formacie BSON.
Mongo może z łatwością obsługiwać miliardy dokumentów i może mieć miliardy dokumentów w jednej kolekcji, ale pamiętaj, że maksymalny rozmiar dokumentu to 16mb . W MongoDB jest wielu ludzi z miliardami dokumentów i jest wiele dyskusji na ten temat na Grupa użytkowników MongoDB Google . Oto dokument o korzystaniu z dużej liczby kolekcji, które możesz chcieć przeczytać, jeśli zmienisz zdanie i zamiast tego chcesz mieć wiele kolekcji. Im więcej masz kolekcji, tym więcej będziesz mieć indeksów, co prawdopodobnie nie jest tym, czego chcesz.
Oto prezentacja z Craigslist o wrzuceniu miliardów dokumentów do MongoDB i kolesia wpis na blogu .
Wygląda na to, że sharding byłby dobrym rozwiązaniem dla Ciebie, ale zazwyczaj sharding jest używany do skalowania na wielu serwerach i wiele osób robi to, ponieważ chcą skalować swoje zapisy lub nie są w stanie utrzymać zestawu roboczego (dane i indeksy) w pamięci RAM. Rozsądne jest rozpoczęcie od jednego serwera, a następnie przejście do fragmentu lub zestawu replik w miarę wzrostu danych lub potrzeby dodatkowej redundancji i odporności.
Jednak są inni użytkownicy, którzy używają wielu mongodów, aby ominąć ograniczenia blokowania jednego mongoda z dużą ilością zapisów. To oczywiste, ale nadal warto powiedzieć, ale konfiguracja multi-mongod jest bardziej złożona w zarządzaniu niż pojedynczy serwer. Jeśli twoje IO lub procesor nie są tutaj maksymalne, twój zestaw roboczy jest mniejszy niż pamięć RAM, a twoje dane są łatwe do utrzymania w równowadze (dość losowo dystrybuowane), powinieneś zauważyć poprawę (z shardingiem na jednym serwerze). Jako FYI istnieje możliwość rywalizacji o pamięć i IO. W wersji 2.2 poprawiono współbieżność z db blokowanie , podejrzewam, że powód takiego wdrożenia będzie znacznie mniejszy.
Musisz odpowiednio zaplanować swój ruch do shardingu, czyli dobrze przemyśleć wybór klucza sharda. Jeśli pójdziesz w ten sposób, najlepiej wstępnie podzielić i wyłączyć balanser. Przenoszenie danych w celu utrzymania równowagi przyniesie efekt przeciwny do zamierzonego, co oznacza, że będziesz musiał z góry zdecydować, jak je podzielić. Ponadto czasami ważne jest, aby zaprojektować dokumenty z myślą, że niektóre pola będą przydatne do shardingu lub jako klucz podstawowy.
Oto kilka dobrych linków —
- Wybieranie klucza Shard
- Wpis na blogu dotyczący kluczy fragmentów
- Przegląd prezentacji na temat shardingu
- Prezentacja na temat najlepszych praktyk shardingu
