Jakie jest zalecane podejście do wielodostępnych baz danych w MongoDB?

Myślę o utworzeniu aplikacji wielodostępnej przy użyciu MongoDB. Nie wiem, ilu najemców bym jeszcze miał, ale chciałbym mieć możliwość skalowania do tysięcy.

Przychodzą mi do głowy trzy strategie:

1. Wszyscy dzierżawcy w tej samej kolekcji, przy użyciu pól specyficznych dla dzierżawcy w celu zapewnienia bezpieczeństwa
2. 1 kolekcja na dzierżawcę w jednej udostępnionej bazie danych
3. 1 baza danych na dzierżawcę

Głos w mojej głowie sugeruje, żebym wybrał opcję 2.

Czy ktoś myśli i implikacje?

Mam ten sam problem do rozwiązania i rozważenia wariantów. Ponieważ mam wieloletnie doświadczenie w tworzeniu wielodostępnych aplikacji SaaS, zamierzałem również wybrać drugą opcję w oparciu o moje wcześniejsze doświadczenia z relacyjnymi bazami danych.

Podczas poszukiwań znalazłem ten artykuł na stronie wsparcia mongodb (dodany, ponieważ już go nie ma): https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi -tenant.html

Chłopaki stwierdzili, że za wszelką cenę unikają drugiej opcji, co, jak rozumiem, nie jest specyficzne dla mongodb. Mam wrażenie, że dotyczy to większości baz danych NoSQL, które badałem (CoachDB, Cassandra, CouchBase Server itp.) Ze względu na specyfikę projektu bazy danych.

Kolekcje (lub zasobniki, czy jakkolwiek nazywają to w różnych bazach danych) to nie to samo, co schematy zabezpieczeń w RDBMS, mimo że zachowują się jak kontener dla dokumentów, które są bezużyteczne przy stosowaniu dobrej separacji dzierżawców. Nie mogę znaleźć bazy danych NoSQL, która może zastosować ograniczenia bezpieczeństwa w oparciu o kolekcje.

Oczywiście możesz użyć zabezpieczeń opartych na rolach mongodb, aby ograniczyć dostęp na poziomie bazy danych / serwera. ( http://docs.mongodb.org/manual/core/authorization/ )

Polecam pierwszą opcję, gdy:

• Masz wystarczająco dużo czasu i zasobów, aby poradzić sobie ze złożonością projektowania, wdrażania i testowania tego scenariusza.
• Jeśli nie zamierzasz mieć dużych różnic w strukturze i funkcjonalności w bazie danych dla różnych dzierżawców.
• Projekt aplikacji umożliwi dzierżawcom wprowadzanie tylko minimalnych dostosowań w czasie wykonywania.
• Jeśli chcesz zoptymalizować przestrzeń i zminimalizować wykorzystanie zasobów sprzętowych.
• Jeśli zamierzasz mieć tysiące lokatorów.
• Jeśli chcesz szybko i niedrogo skalować.
• Jeśli NIE zamierzasz tworzyć kopii zapasowych danych na podstawie dzierżawców (przechowuj osobne kopie zapasowe dla każdego dzierżawcy). Jest to możliwe nawet w tym scenariuszu, ale wysiłek będzie ogromny.

Wybrałbym wariant 3, gdyby:

• Będziesz mieć małą listę lokatorów (kilkaset).
• Specyfika biznesu wymaga, abyś potrafił obsługiwać duże różnice w strukturze baz danych dla różnych najemców (np. Integracja z systemami firm trzecich, import-eksport danych).
• Projekt Twojej aplikacji umożliwi klientom (dzierżawcom) wprowadzanie znaczących zmian w czasie wykonywania aplikacji (dodawanie modułów, dostosowywanie pól itp.).
• Jeśli masz wystarczająco dużo zasobów, aby szybko skalować w poziomie z nowymi węzłami sprzętowymi.
• Jeśli musisz zachować wersje / kopie zapasowe danych na dzierżawcę. Również przywrócenie będzie łatwe.
• Istnieją ograniczenia prawne / regulacyjne, które zmuszają Cię do trzymania różnych najemców w różnych bazach danych (nawet w centrach danych).
• Jeśli chcesz w pełni wykorzystać gotowe funkcje zabezpieczeń mongodb, takie jak role.
• Między najemcami występują duże różnice w wielkości (masz wielu małych najemców i kilku bardzo dużych).

Jeśli zamieścisz dodatkowe informacje o swojej aplikacji, być może mogę udzielić ci bardziej szczegółowych porad.

Znalazłem dobrą odpowiedź w komentarzach pod tym linkiem:

http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/

Zasadniczo opcja nr 2 wydaje się być najlepszym rozwiązaniem.

Cytat z komentarza Davida Myttona:

Zdecydowaliśmy się nie mieć bazy danych dla każdego klienta ze względu na sposób, w jaki MongoDB przydziela swoje pliki danych. Każda baza danych używa własnego zestawu plików:

Pierwszy plik bazy danych to nazwa_bazy danych.0, następnie nazwa_bazy_danych.1 itd. Nazwa_bazy_db.0 będzie miała 64 MB, nazwa_bazy.1 128 MB itd., Do 2 GB. Gdy pliki osiągną rozmiar 2 GB, każdy kolejny plik również będzie miał 2 GB.

Zatem jeśli ostatni obecny plik danych ma, powiedzmy, 1 GB, ten plik może być w 90% pusty, jeśli został niedawno osiągnięty.

z instrukcji.

Gdy użytkownicy rejestrują się w wersji próbnej i próbują, otrzymywaliśmy coraz więcej baz danych o rozmiarze co najmniej 2 GB, nawet jeśli cały plik danych nie był używany. Okazało się, że zajmuje to ogromną ilość miejsca na dysku w porównaniu z kilkoma bazami danych dla wszystkich klientów, w których miejsce na dysku można wykorzystać z maksymalną wydajnością.

Fragmentowanie będzie standardowo dokonywane na podstawie kolekcji, co stanowi problem, w którym kolekcja nigdy nie osiągnie minimalnego rozmiaru, aby rozpocząć fragmentowanie, jak ma to miejsce w przypadku wielu naszych (np. Kolekcje przechowujące tylko dane logowania użytkownika). Jednak zażądaliśmy, aby można to było zrobić również na poziomie bazy danych. Zobacz http://jira.mongodb.org/browse/SHARDING-41

W przypadku wielu kolekcji nie ma kompromisów w zakresie wydajności. Zobacz http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

Istnieje rozsądny artykuł w witrynie MSDN dotyczący architektury danych dla wielu dzierżawców, do którego warto się odwołać. Niektóre kluczowe tematy poruszone w tym artykule:

• Względy ekonomiczne
• Bezpieczeństwo
• Uwagi najemcy
• Regulacyjne (prawne)
• Obawy dotyczące zestawu umiejętności

Omówiono również niektóre wzorce konfiguracji oprogramowania jako usługi (SaaS).

Dodatkowo warto przyjrzeć się ciekawemu opisowi od facetów z SQL Anywhere .

Moje osobiste podejście - jeśli nie masz pewności co do wymuszonego bezpieczeństwa / zaufania, wybrałbym opcję 3 lub jeśli obawy dotyczące skalowalności zabraniają co najmniej powrotu do opcji 2. To powiedziawszy ... Nie jestem profesjonalistą w MongoDB. Denerwuję się używając wspólnego „schematu” - ale z radością poddam się bardziej doświadczonym praktykom.

Wybrałbym opcję 2.

Możesz jednak ustawić opcję wiersza polecenia mongod.exe --smallfiles. Oznacza to, że największy rozmiar pliku zakresu będzie wynosił 0,5 gigabajta, a nie 2 gigabajty. Przetestowałem to z Mongo 1.42. Tak więc opcja 3 nie jest niemożliwa.

Według moich badań w MongoDB. Trucos y consejos. Aplicaciones multitenant. ta opcja nie jest zalecana, jeśli nie wiesz, ilu najemców możesz mieć, może to być tysiące i byłoby to skomplikowane, jeśli chodzi o sharding, wyobraź sobie również, że masz tysiące kolekcji w jednej bazie danych ... Więc w twoim przypadku tak zaleca się użycie opcji pierwszej. Teraz, jeśli masz zamiar mieć ograniczoną liczbę użytkowników, jest już inaczej i tak, możesz użyć opcji drugiej, tak jak myślałeś.

Chociaż dyskusja dotyczy NoSQL, a przede wszystkim MongoDB, w Citus używamy PostgreSQL i budujemy rozproszoną / podzieloną na fragmenty bazę danych z wieloma dzierżawcami.

Nasz przewodnik po przypadkach użycia przedstawia przykładową aplikację, obejmującą schemat i różne funkcje specyficzne dla wielu dzierżawców.

W przypadku bardziej nieustrukturyzowanych danych używamy kolumny JSONB PostgreSQL do przechowywania takich danych specyficznych dla dzierżawców.