Jeśli MongoDB ma piętę achillesową, to fakt, że obsługuje tylko jednowątkowe zapisy i jednowątkowe redukcje map.
Jak zawsze, są tu kompromisy. Zapisy jednowątkowe to najprostszy sposób na uniknięcie problemów z blokowaniem i zminimalizowanie obciążenia. W ten sam sposób wielowątkowe redukcje map to świetny sposób na zablokowanie danych. Tak więc jednowątkowe redukcje mapy w systemie produkcyjnym są prawdopodobnie łatwiejsze i bezpieczniejsze.
Jednak nie jesteś tu bez narzędzi. MongoDB zapewni jeden wątek zapisu do każdej instancji. Więc jeśli shardujesz MongoDB, otrzymasz jeden wątek zapisu dla każdego fragmentu.
Jeśli chcesz mieć wiele indeksów w 2 miliardach wierszy, i tak przyjrzyj się fragmentowaniu. Trochę szybkiej matematyki:MongoID to 12 bajtów. Indeks na MongoID wyniesie 2B * 12 bajtów =22 GB+. Jeśli chcesz teraz dodać dwa dodatkowe indeksy (nawet tylko dwie 4-bajtowe liczby całkowite), mówimy o 7,5 GB dla każdego.
Tak więc w wierszach 2B mówisz o ponad 37 GB w indeksach (minimum ). Na większości serwerów 8-rdzeniowych oznacza to, że nie będziesz w stanie nawet przechowywać indeksów w pamięci, nie mówiąc już o żadnych danych.
Więc jeśli chcesz mieć tutaj poważną wydajność, będziesz chciał zacząć patrzeć na sharding. Tylko na podstawie ogólnych liczb. FWIW, MySQL nie byłby już biegły w obsłudze dokumentów 2B. Przy tak dużej ilości danych naprawdę będziesz chciał, aby wiele serwerów nadążało za obciążeniem.
