Wydajność niekoniecznie jest gorsza. Jak wyjaśniono w artykule, istnieją określone warunki, które sprawiają, że schemat jest lepszy lub gorszy w zależności od projektu aplikacji i obciążenia. Pozwólcie, że wyjaśnię kompromisy między podejściem „schematu dzierżawcy” a „wspólnym stołem”:
Schemat najemcy jest najlepsze, gdy masz stosunkowo małą liczbę dość dużych najemców. Przykładem może być aplikacja księgowa, z tylko płatnymi użytkownikami subskrypcji. Rzeczy, które sprawiają, że jest to lepsza opcja dla Ciebie, to:
- mała liczba najemców, każdy z dużą ilością danych
- stosunkowo prosty schemat bez wielu tabel na najemcę
- konieczność dostosowania schematów niektórych najemców
- możliwość korzystania z ról bazy danych na dzierżawcę
- wymaganie migracji danych najemcy z jednego serwera na drugi
- możliwość uruchomienia dedykowanego serwera aplikacji w Twojej chmurze dla każdego najemcy
Rzeczy, które sprawiają, że jest to słaba opcja, to:
- wielu najemców z bardzo małą ilością danych
- bezstanowe podejście do połączeń, w których każde żądanie może być dowolnym dzierżawcą
- biblioteka klienta lub orm, który buforuje metadane dla wszystkich tabel (np. ActiveRecord)
- wymaganie wydajnego, wysokowydajnego pulowania połączeń i/lub buforowania
- problemy z VACUUM i innymi operacjami administracyjnymi PostgreSQL, które słabo skalują się w tysiącach tabel.
To, czy schemat dzierżawy jest zły dla migracji/zmian schematu, naprawdę zależy od tego, jak je wykonujesz. Jest to złe dla szybkiego wdrażania uniwersalnej zmiany schematu, ale dobre dla wdrażania zmian schematu jako stopniowego wdrażania wśród najemców.
wspólny stół działa lepiej w sytuacjach, gdy masz wielu dzierżawców, a wielu dzierżawców ma bardzo mało danych. Przykładem może być mobilna aplikacja społecznościowa, która pozwala na darmowe konta, a tym samym ma tysiące porzuconych kont. Inne rzeczy, które sprawiają, że model wspólnego stołu jest korzystny to:
- lepiej dla puli połączeń, ponieważ wszystkie połączenia mogą korzystać z tej samej puli
- lepsze dla administracji PostgreSQL, z powodu mniejszej liczby tabel
- lepsze dla migracji i zmian schematu, ponieważ istnieje tylko jeden „zestaw” tabel
Główną wadą udostępnionej tabeli jest konieczność dołączania warunku filtru dzierżawcy do każdego pojedynczego zapytania w warstwie aplikacji. Jest to również problematyczne, ponieważ:
- zapytania, które łączą wiele tabel, mogą mieć niską wydajność, ponieważ filtr dzierżawy odrzuca planowanie zapytań
- tabele, które rosną do 100 milionów wierszy, mogą powodować określone problemy z wydajnością i konserwacją
- nie ma możliwości wprowadzania zmian aplikacji specyficznych dla dzierżawy lub aktualizacji schematu
- droższa migracja najemców między serwerami
Tak więc, który model „działa lepiej” naprawdę zależy od tego, które kompromisy szkodzą Ci najbardziej.
Istnieje również model hybrydowy „tenant-view”, w którym rzeczywiste dane są przechowywane we wspólnych tabelach, ale każde połączenie aplikacji korzysta z widoki barier bezpieczeństwa aby wyświetlić dane. Ma to pewne kompromisy każdego modelu. Przede wszystkim ma zalety związane z bezpieczeństwem modelu schematu dzierżawcy z niektórymi wadami wydajności obu modeli.
