Pracuję nad aplikacją w której każdy użytkownik będzie miał swoją bazę lub schemat w ramach jednej bazy.
Pytanie które podejście będzie lepsze pod względem wydajności zapytań?
Baza to Posgtres.
0
2
Jak dużego ruchu oraz wolumenu danych się spodziewasz?
3
Z technicznego punktu widzenia łatwiej się zarządza 1 bazą z wieloma schematami niż wieloma bazami z pojednycznym schematem
0
powiedzmy że około 2000-3000 wpisów na dzień per user (baza/schemat), długodystansowo może się tego nazbierać i wzrosnąć (przez kilka lat).
Jeśli nie ma to zbytnio dużego znaczenia pod względem wydajności to chyba bym poszedł w kierunku baza per user (łatwiejszy backup w razie potrzeby, można dać uprawnienia do bazy odrębnemu userowi a nie jeden wspólny dla wszystkich baz, duża separacja od danych innych userów, itp.).
2
Zajedziesz się ... każdy nowy user to create database set owner create tables itd. Każdy nowy user to poprawa skryptów robiących backup. Jeśli zajdzie potrzeba wymiany danych między userami to bedziesz musiał dblinki robić. Innymi słowy po kilkudziesięciu userach bedziesz żałował tego podejścia. Tym bardziej że pewnie z czasem bedzie się to rozwijać. A teraz wyobraz sobie ze do usera musisz cos dodać... bedziesz ten sam skrypt odpalał na każdej bazie z osobna ? Moim zdaniem samobój... no chyba ze placa ci za administrację od ilości baz
0
@woolfik to samo sie tyczy schemat per user bo masz kopie tabel w kazdym schemacie i aktualizacja musiala by leciec po kazdym schemacie. Natomast podejscie row per user czyli dodatkowa kolumna z id usera i wspolna baza oraz tabele, to raczej mocno by sie moglo odbic w pozniejszym etapie na wydajnosci.
3
mocno by sie moglo odbic w pozniejszym etapie na wydajnosci.
IMO wystarczy dorzucić partycję tabeli po tenant_id i będzie załatwione.
1
@Jarek Korcek: > ##### Jarek Korcek napisał(a):
@woolfik to samo sie tyczy schemat per user bo masz kopie tabel w kazdym schemacie i aktualizacja musiala by leciec po kazdym schemacie. Natomast podejscie row per user czyli dodatkowa kolumna z id usera i wspolna baza oraz tabele, to raczej mocno by sie moglo odbic w pozniejszym etapie na wydajnosci.
Chyba nie do końca rozumiesz o czym pisałem. Jesli masz "n" schematów na których jest tabela "users" i chcesz np dodać pole to robisz sobie skrypt, który w pętli leci po information_schema.tables where tabname = 'users" i uruchamiasz wszystko raz bez względu na ilość schematów.
W przypadku oddzielnych baz musisz napisać jakiś kawałek oprogramowania (zewnętrznego np w pythonie, javie czy czymkolwiek) co będzie robić connect do bazy A robić alter, disconnect, connect do bazy B alter ... itd. Ewentualnie robisz sobie DBLinki na poszczególne tabele co jest jeszcze bardziej karkołomne.
Nie spotkałem się nigdy w żadnej firmie z podejściem aby user miał swoją bazę. Natomiat co do wydajności to ci @Patryk27 opisał jak się to załatwia. W każdym razie wybór należy do Ciebie ale zobaczysz za jakiś czas, że takie rozwiązanie powoduje więcej problemów niż korzyści.
0
Masz racje ze schemat per user bedzie duzo latwiejszy w utrzymaniu. Nie jestem mocny w bazach ale czy aby na pewno nie bedzie roznicy w wydajnosci miedzy podejsciem baza per user a schemat per user?
Pytam bo w przyszlosci moze byc kilkadziesiat tysiecy userow.
1
W przypadku postgresa kazda baza / tabela i dane w nich zapisane to zwykle pliki. Odpowiednie partycjonowanie zalatwi temat. Pracowałem z systemami gdzie w jednej tabeli było blisko 2 tb danych i przy odpowiednim zarządzaniu baza chodziła błyskawicznie