Jaki typ bazy dla takiego projektu bedzie odpowiedni?

0

Jestem na etapie wyboru technologii dla nowego projektu. Ogolne dzialanie jest takie ze kazdy zarejestrowny klient bedzie mial tworzona swoja baze danych (wiec baz moze po pewnym czasie byc kilka tysiecy lub wiecej). Silnik bazodanowy musi obslugiwac transakcje, byc skalowalny (bedzie dzialal w chmurze, wysoka dostepnosc oraz wydajnosc). Chcialbym tez uniknac replikacji baz na kazdej z uruchomionej instancji (mysle ze 2 kopie per baza wystarcza do zapewnienia dostepnosci) Postgresql czy moze MongoDB?

1

To chyba jednak zależy głównie od tego co będzie w tych bazach a nie od tego ile ich będzie.

0

Ogolnie nic specjalnego, beda to bazy przechowujace zamowienia konkretnych sklepow, klientow itp

4

Dlaczego każdy klient będzie miał własną bazę danych?I kto to jest "klient"?

0

Klient mam na mysli firme posiadajaca sklep dla ktorej bedzie aplikacja sklepowa. Czyli baza per sklep

1

Ja robię takie coś na MySQL przy czym cały backup, replikacje, cluster MySql itp. gwarantuje mi już firma hostingowa i w ogóle mnie to nie interesuje.
Czyli innymi słowy mam na serwerze założone 250 pustych ponumerowanych baz ( bo u mojego operatora bazy da się jedynie przez panel zakładać - nie mają do tego żadnego API ).
Do tego mam jeden system centralny zarządzający. Jak rejestrujemy nowego klienta ( lub teoretycznie u Ciebie może się rejestrować sam ) to dla jego instancji przedzielana kolejna wolna baza, odpalane są odpowiednie skrypty i gotowe ...
Bez problemu coś analogicznego zrobisz na Postgresql bo sama baza nie ma tutaj nic do rzeczy.

3

A nie lepiej stworzyć wspólną tabelę "zamówienia", w której do zamówień będziesz przypisywał id sklepu? Dlaczego wykluczasz takie podejście i koniecznie chcesz stworzyć osobną bazę dla każdego klienta?

3
ToTomki napisał(a):

A nie lepiej stworzyć wspólną tabelę "zamówienia", w której do zamówień będziesz przypisywał id sklepu? Dlaczego wykluczasz takie podejście i koniecznie chcesz stworzyć osobną bazę dla każdego klienta?

Zagadnienia tu rozważane na anglijskom jazykie nazywają się **multitenancy **i są (przynajmniej) dwie szkoły falenicka i otwocka - również wielu klientów w jednej tabeli jest możliwe

UPDATE:
Pięknie wyłożone to mają w Eclipselink. Warto przeczytać dokładnie, nawet jeśli nie mówimy o Javie / JPA
https://www.eclipse.org/eclipselink/documentation/2.5/solutions/multitenancy001.htm

0

Ja zdaję sobie sprawę, że to można zrobić osobno, pytanie tylko czy to faktycznie ma sens (czasami ma, czasami nie - czy obsługa sklepów faktycznie jest warta takiej zabawy?) i chciałbym poznać biznesowe powody takiej decyzji, bo może jednak warto użyć architektury innego typu.

2
Jarek Korcek napisał(a):

Silnik bazodanowy musi obslugiwac transakcje, byc skalowalny (...) Postgresql czy moze MongoDB?

A to mongo już obsługuje transakcje? O ile nie piszesz w node i nie potrzebujesz asynchronicznego klienta to brałbym PostgreSQLa.z 5 lat temu mówili że jedna instancja PostgreSQLa wytrzymuje do 1T. Jak masz więcej niż 1T per instancje to chyba tylko Cassandra (i jej odmiany) jest sensowna. Przy czym wtedy wchodzi zabawa w klaster i każdy z nodów też ma tylko ok 1T danych + 2-3 T danych replikowanych z innych nodów

3
ToTomki napisał(a):

A nie lepiej stworzyć wspólną tabelę "zamówienia", w której do zamówień będziesz przypisywał id sklepu? Dlaczego wykluczasz takie podejście i koniecznie chcesz stworzyć osobną bazę dla każdego klienta?

Do dziś wspieram taki system stron internetowych z CMS ( kiedyś w jego ramach obsługiwałem około 350 stron - teraz już tylko około 50 ). I moje wnioski są następujące:

  1. Bardzo łatwe zarządzanie i rozwój jako całości ;
  2. Trudności jeśli jeden z klientów chce rozbudować swoją opcję lub chce zapłacić za coś wyjątkowego ( wtedy niestety dostają to wszyscy i cały system puchnie ) ;
  3. Wymagana dużo większa koncentracja na bezpieczeństwie. Każda akcja musi weryfikować instancję i prawa do zapisywania swoich rekordów ( to upierdliwe );
  4. No i wadą jest ogólnie bezpieczeństwo bo jak pada to wszystko.
  5. Poważna wada: zarządzanie Cache, zliczanie zajętości danych jednego Klienta i ogromne trudności w obliczaniu faktycznego obciążenia generowanego przez jednego Klienta.
  6. W przypadku tabel z bardzo dużą ilością danych zaczynają się grube kłopoty. Np. gdy jeden klient ma 200000 rekordów to to raczej nie jest problem gdy mamy go w jednej bazie ale gdy takich klientów w jednej bazie mamy 50 to robi się nam miliony rekordów a to już zaczyna być problm.

Zebrane przez prawie 10 lat doświadczenia z tym rozwiązaniem doprowadziły mnie do wniosku, że lepiej trzymać kopie baz dla każdego klienta osobno. Obecnie robię to tak, że:

  1. Każdy klient ma swoją kopię front-end na własnym koncie FTP oraz własną bazę danych tym samym można dać klientowi dostęp do jednego i drugiego a nawet może być na jego serwezrze.
  2. Front i panel administracyjny CMS+CRM korzystają ze wspólnego dla wszystkich API ("mięso systemu" nie dostępne dla Klienta) , które po autoryzacji łączy się z odpowiednią bazą(klienta). Błędy pojawiają się głównie w API więc naprawy są równie proste co w modelu z jedną bazą. Dopisywanie kolejnych funkcji API dla wybranych Klientów nie obciąża całości rozwiązania a nowe funkcje nie muszą być nawet widoczne dla każdego z Klientów.
  3. Wadą są aktualizacje baz i front-end bo podczas tworzenia skryptów wymagana była większa uwaga i staranność nić w rozwiązaniu wspólny frontend+wspólna baza. Jednak dość szybko cały update i tak został sprowadzony do uruchamiania na serwerze jednego skryptu i poczekania kilka minut.

Podsumowując te dwie metody osobiście polecam tworzenie osobnych instancji bazy dla każdego Klienta. Może trochę więcej pracy na początku ale spokój umysłu i elastyczność rozwiązania szybko to wynagradzają. Dopóki był to tylko CMS to rozwiązanie z jedną bazą było super. Jednak jak baza została rozbudowana o CRM i sporą bazę produktową to praca wynikająca z konieczności pisania wszystkiego mając na uwadze "wieloinstancyjność" zaczęła być zbyt czasochłonna a ryzyko popełnienia błędu w zakresie bezpieczeństwa dramatycznie rosło.

2

To jest proste. Jeśli musisz sumować (robić średnie i inne analizy) zamówienia dla wielu "klientów", to trzymasz w jednej tabeli.
Jeśli nie jest to wskazane, albo wręcz zabronione, to trzymasz to w oddzielnych bazach lub schematach.

1 użytkowników online, w tym zalogowanych: 0, gości: 1