Projektuję system z MongoDb (wersja 64-bitowa) do obsługi dużej liczby użytkowników (około 100 000), a każdy użytkownik będzie dysponował dużą ilością danych (około 1 miliona rekordów).Baza danych MongoDb kontra Kolekcja
Jaka jest najlepsza strategia projektowania?
Dump wszystkie rekordy w jednej kolekcji
posiada kolekcji dla każdego użytkownika
bazę danych dla każdego użytkownika.
Wielkie dzięki,
Więc patrzysz gdzieś w regionie ze 100 miliardów rekordów (1 milion rekordów * 100 000 użytkowników).
Preferowanym sposobem radzenia sobie z dużymi ilościami danych jest utworzenie uszkodzonego klastra, który dzieli dane na kilka serwerów, które są prezentowane jako pojedyncza jednostka logiczna za pośrednictwem klienta mongo.
Dlatego odpowiedzią na twoje pytanie jest umieszczenie wszystkich twoich zapisów w jednym zbiorczym zestawie.
Liczba wymaganych odłamków i konfiguracja klastra zależy od wielkości danych i innych czynników, takich jak liczba i rozkład odczytów i zapisów. Odpowiedzi na te pytania są prawdopodobnie bardzo specyficzne dla twojej wyjątkowej sytuacji, więc nie będę próbował ich odgadnąć.
Najprawdopodobniej zacznę od zdecydowania, ilu fragmentów masz czasu i maszyn dostępnych do skonfigurowania i przetestowania systemu na klastrze z wielu maszyn. Na podstawie tego działania możesz zdecydować, czy potrzebujesz więcej lub mniej odłamków w klastrze:
Architektura z shardowaniem jest zdecydowanie istotna w tym scenariuszu, ale twój post nie odnosi się do kwestii OP, która dotyczyła tego, czy używać jednej kolekcji, wielu kolekcji czy wielu baz danych. – Philipp
Ach tak, opcje 2 i 3 były dla mnie tak intuicyjne, że zapomniałem wyraźnie zaznaczyć, że powinieneś umieścić je w jednym zbiorze i odłamie – chrisbunney
@chrisbunney Jakie są Twoje 2 centy za używanie wzorca "baz danych lub kolekcji dla każdy użytkownik "wyłącznie w celu bezpieczeństwa i uproszczonego zarządzania kontrolą dostępu? – kommradHomer
O kolekcji na każdy użytkowników:
Przez domyślnej konfiguracji, MongoDB jest ograniczona do 12k kolekcjach. Możesz zwiększyć rozmiar tego przy pomocy --nssize, ale nie jest to nieograniczone. I trzeba policzyć indeks do tego 12k. (sprawdź koncepcję "przestrzeni nazw" w dokumentacji mongo).
O bazy danych dla każdego użytkownika:
dla punktu widzenia modelu, który jest bardzo ciekawy. Techniczne, nie ma limitu na mongo, ale prawdopodobnie masz limit z deskryptorem pliku (limit od ciebie OS/ustawienia).
Tak jak @Rohit mówi, dwa ostatnie nie są dobre. Może powinieneś wyjaśnić więcej o swojej sprawie. Może można wyciąć użytkowników do różnych kolekcji (np. Po jednej na każdą pierwszą literę imienia itp. Lub do każdej usługi firmy ...). I, oczywiście, użyjcie odłamek.
Edycja: może MongoDb nie jest najlepszą bazą danych dla Twojego przypadku użycia.
Szukasz 100 000 000 szczegółowych rekordów dla 100 000 użytkowników?
Wielu ludzi nie rozumie, że MongoDB jest dobry w skalowaniu poziomym. Skalowanie poziome jest zwykle klasyfikowane jako skalowanie ogromnych pojedynczych kolekcji danych na wielu (wielu) serwerach w ogromnym klastrze.
Tak więc już w przypadku korzystania z pojedynczego zbioru dla typowych danych (tj. Jednej kolekcji o nazwie user i jednej o nazwie detail) odpowiadasz głównym celom i kompilacjom MongoDB.
MongoDB, jak wspomniano, przez innych nie jest tak dobry w skalowaniu w pionie w wielu kolekcjach. Na początku ma limit nssize i nawet jeśli początkowe kolekcje 12K to szacowane na w rzeczywistości ze względu na rozmiar indeksu, możesz mieć tylko 5K kolekcji w bazie danych.
Tak więc kolekcja na użytkownika nie jest w ogóle możliwa. Będzie używać MongoDB wbrew jego głównym zasadom.
Posiadanie bazy danych na jednego użytkownika wiąże się z tymi samymi problemami, a może nawet więcej, ze względu na pojedyncze kolekcje na użytkownika.
Nigdy nie spotkałem się z kimś, kto nie jest w stanie przeskalować MongoDB do miliardów, a nawet blisko 100 miliardów (lub więcej) na zoptymalizowanej konfiguracji, jednak nie rozumiem, dlaczego nie jest w stanie; po tym wszystkim Facebook jest w stanie wprowadzić skalę MySQL do 100 miliardów na użytkownika (dla odłamków 32K +), a koncepcja shardingu jest podobna między dwiema bazami danych.
Tak więc istnieje teoria i możliwość. Chodzi przede wszystkim o wybór właściwego schematu i koncepcji odłamków oraz klucza (i serwerów i sieci itd. Itd. Itd.).
Jeśli miałeś okazję napotkać problemy, które można podzielić na dzielenie kolekcji archiwalnych lub usunięte elementy z głównej kolekcji, ale myślę, że to przesada, zamiast tego chcesz mieć pewność, że MongoDB wie, gdzie znajduje się każdy segment Twojego ogromnego zbioru danych. w dowolnym momencie na serwerze głównym i upewnij się, że dane są zawsze gorące, w ten sposób zapytania, które nie wykonują globalnego i rozproszonego OP, powinny być dość szybkie.
Z pewnością nie ostatni 2. –
Z punktu widzenia architektury bazy danych polecam użyć pojedynczego zbioru, ale nie jestem pewien, czy nadal są one skalowane tak dobrze, gdy masz w nich setki * miliardów * rekordów. – Philipp