Czy sharding jest skuteczny w przypadku małych kolekcji?

11

Wygląda na to, że dzielenie bazy danych jest świetne, jeśli mam ogromne zbiory. Co się stanie, jeśli będę mieć dużo kolekcji dość dużych rozmiarów? Powiedzmy, że dla 1 zbioru 100 000 000 dokumentów (niezbyt dużych komentarzy) dzielenie na fragmenty jest skuteczne. Czy działa również w przypadku 10 000 kolekcji zawierających po 10 000 dokumentów?

(Myślę, że to pytanie jest nadal aktualne dla baz danych zorientowanych na tabelę, jeśli zastąpisz kolekcje tabelami i dokumenty wierszami. Jeśli to możliwe, chciałbym poznać teoretyczną odpowiedź, a także odpowiedź w konkretnym scenariuszu MongoDB, jeśli jest inny niż teoretyczny odpowiedź.)

mongodb João Pinto Jerónimo
źródło

Odpowiedzi:

5

Czy działa również w przypadku 10 000 kolekcji zawierających po 10 000 dokumentów?

Większość ludzi ma problem z „pojedynczą dużą kolekcją”, dlatego dzielenie fragmentów jest wyraźnie przydatne w celu zmniejszenia problemów związanych z równoważeniem tych danych.

Jednak gdy masz 10 000 małych kolekcji, Twój ból głowy prawdopodobnie nie „równoważy danych”. Przy tak wielu małych kolekcjach problem prawdopodobnie dotyczy śledzenia tych kolekcji. W zależności od rozmiaru dokumentu możesz nawet nie przekroczyć dolnej granicy faktycznego dzielenia na fragmenty.

W przypadku naprawdę małych kolekcji można użyć mało znanego polecenia movePrimary do zarządzania lokalizacją danych.

Oczywiście, innym sposobem spojrzenia na to jest to, dlaczego masz kolekcje 10 000? Kolekcja nie potrzebuje jednorodnych obiektów, a przy kolekcjach 10 000 większość z nich musi zostać wygenerowana. Całkiem możliwe jest przechowywanie różnych „typów” danych w tej samej kolekcji, zmniejszenie liczby kolekcji, a następnie włączenie tego typu jako części klucza niezależnego fragmentu.

Gates VP
źródło
Dzięki, właśnie starałem się dowiedzieć, czy najlepiej jak mogę pozbyć się tych kolekcji i zrobić dużą. Miałem już mnóstwo kolekcji, ponieważ słyszałem powszechne przekonanie: „Ogromne kolekcje są dla ciebie złe, ponieważ indeksy nie mieszczą się w pamięci RAM i bardzo wolno będzie je wyszukiwać i aktualizować”. Ale wydaje mi się, że sharding został stworzony, aby rozwiązać ten problem ... Dzięki !!
João Pinto Jerónimo
Szczerze mówiąc, uważam, że często można również „oszukiwać” indeksy. Jeśli masz dwa zbiory fooi baro tej samej strukturze danych, można połączyć je w bazkolekcji i zastąpić _ids(w kodzie) { _id: "foo123" }, { _id: "bar123" }. Masz większy indeks, ale masz tylko jeden indeks, który obejmuje ten typ. Nie jest to wymóg, tylko „jedzenie do namysłu”.
Gates VP,
4

Sharding MongoDB polega na dzieleniu kolekcji na mniejsze „fragmenty” i równomierne rozprowadzanie ich na wielu komputerach. Domyślny rozmiar porcji, który jest na ogół najbardziej wydajny, to 200 MB. Więc jeśli kolekcja nie wzrośnie znacznie powyżej 200 MB, nie podzieli się na części i dlatego nie będzie się kwalifikować do dzielenia na fragmenty, więc nie będzie żadnych korzyści.

W ogólnym przypadku dzielenie danych na wielu komputerach jest bardzo skutecznym sposobem skalowania odczytów, zapisów i zapytań. Korzystasz z wielu procesorów, dysków twardych i pamięci, pracując równolegle do odczytu, zapisu i przetwarzania danych. Skalowanie pamięci jest szczególnie ważne w MongoDB, gdzie wysoka wydajność jest bardzo wrażliwa na dopasowanie danych do pamięci.

Chris Fulstow
źródło
Domyślna porcja FYI wynosi 64 MB od 1.8.
Gates VP