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

98

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?

Braintapper
źródło
Drogi @Braintapper, w tej chwili jesteśmy w tej samej sytuacji z naszą aplikacją, która musi obsługiwać wielu dzierżawców. Czy masz jakieś doświadczenia, którymi chcesz się podzielić? Byłoby wspaniale, dziękuję.
Joshua Muheim
3
W przypadku mojej aplikacji ostatecznie zdecydowałem się na Postgresql (korzystamy z relacyjnej bazy danych z pewnymi funkcjami podobnymi do NoSQL poprzez rozszerzenie hstore) zamiast MongoDB i obsługi wielu dzierżawców w Railsach z zakresem. Używamy podobnego podejścia do tego zastosowanego w tym Railscast: railscasts.com/episodes/388-multitenancy-with-scopes
Braintapper
2
Wiem, że wybrano już odpowiedź na to pytanie, ale ktokolwiek inny powinien zapoznać się z tym oficjalnym dokumentem na stronie mongohq: support.mongohq.com/use-cases/multi-tenant.html . Wyraźnie opowiada się przeciwko rozwiązaniu @Braintapper poniżej
lafamie
1
Zaktualizowano odpowiedź. Informacje zawarte w linku nie były łatwo dostępne w maju 2010 r.
Braintapper
@Braintapper czy używasz teraz rozwiązania postgresql (opartego na railscasts.com)? Chcę go używać, ale nie jestem pewien, czy zwiększa bezpieczeństwo i ilu najemców może obsłużyć! proszę o Twoją opinię na temat tego doświadczenia. dzięki
medBouzid

Odpowiedzi:

73

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.

Ruslan Kiskinov
źródło
9
Domyślam się, że oryginalny link jest martwy, poszedł na zarchiwizowany: web.archive.org/web/20140812091703/http://support.mongohq.com/…
Peter
Witam, jak możemy stworzyć nową bazę danych z aktualną bazą danych przy użyciu mongodb?
HEMAL
@Russian Jak poradzimy sobie z indeksowaniem, jeśli wybieramy opcję 1
Robins Gupta
10

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

Braintapper
źródło
2
Jak sugerowano w innych odpowiedziach, punkt 2 nie jest dobrym podejściem. Rozważ zmianę zaakceptowanej odpowiedzi, ponieważ może to przeoczyć innych programistów.
clopez
1
Zmieniono akceptowaną odpowiedź, ponieważ wiele się zmieniło od 2010 r., Kiedy po raz pierwszy zadano pytanie.
Braintapper
3

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.

AJ.
źródło
Znam ten artykuł MSDN, ponieważ moim pierwotnym planem było użycie relacyjnej bazy danych. Moje dane są jednak dość nieustrukturyzowane, co zmusza mnie teraz do zbadania baz danych NoSQL, takich jak MongoDB. Nie wydaje się, że MongoDB obsługuje ACL tak, jak robi to Lotus Domino, i naprawdę nie chcę wymyślać koła na nowo, co sprawia, że ​​myślę, że 2 lub 3 to najlepszy sposób. Nie wiem też, czy istnieją ograniczenia, które mogę napotkać pod względem liczby kolekcji lub dbs dozwolonych w MongoDB.
Braintapper
3

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.

TTT
źródło
0

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ś.

Osleynin Mambell Ramos
źródło
-2

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.

Sumedh
źródło