Výkon není nutně horší. Jak je vysvětleno v článku, existují specifické podmínky, díky kterým je přístup schématu lepší nebo horší v závislosti na návrhu vaší aplikace a pracovní zátěži. Dovolte mi vysvětlit kompromisy mezi přístupy „schéma nájemce“ a „sdílená tabulka“:
schéma nájemce je nejlepší, když máte relativně malý počet poměrně velkých nájemníků. Příkladem může být účetní aplikace pouze s placenými uživateli předplatného. Mezi věci, které z něj činí výkonnější možnost, patří:
- malý počet nájemců, každý s velkým množstvím dat
- poměrně jednoduché schéma bez velkého množství tabulek na tenanta
- potřeba přizpůsobit schémata některých nájemců
- schopnost využívat databázové role na každého klienta
- požadavek na migraci dat tenanta z jednoho serveru na druhý
- možnost vytvořit vyhrazený aplikační server ve vašem cloudu pro každého tenanta
Mezi věci, které z ní dělají nevýkonnou možnost, patří:
- mnoho nájemců, každý s velmi malým množstvím dat
- bezstavový přístup k připojení, kde každý požadavek může být libovolný tenant
- klientská knihovna nebo orm, který ukládá do mezipaměti metadata pro všechny tabulky (jako ActiveRecord)
- požadavek na efektivní a vysoce výkonné sdružování připojení a/nebo ukládání do mezipaměti
- problémy s VACUUM a dalšími administrativními operacemi PostgreSQL, které se špatně škálují na 1000 tabulek.
Zda je schéma tenanta pro migrace/změny schématu špatné, skutečně závisí na tom, jak je provádíte. Je to špatné pro rychlé zavedení univerzální změny schématu, ale dobré pro nasazení změn schématu jako postupného zavádění napříč tenanty.
sdílený stůl funguje lépe v situacích, kdy máte mnoho nájemců a mnoho z nich má velmi málo dat. Příkladem by mohla být mobilní aplikace sociálních médií, která umožňuje bezplatné účty, a tak má tisíce opuštěných účtů. Další věci, díky kterým je model sdílené tabulky výhodný, jsou:
- lepší pro sdružování připojení, protože všechna připojení mohou používat stejný fond
- lepší pro administraci PostgreSQL, protože celkově je méně tabulek
- lepší pro migrace a změny schématu, protože existuje pouze jedna "sada" tabulek
Hlavní nevýhodou sdílené tabulky je potřeba připojit podmínku filtru tenanta ke každému jednotlivému dotazu v aplikační vrstvě. Je to také problematické, protože:
- dotazy, které se připojují k mnoha tabulkám, mohou fungovat špatně, protože filtr tenantů narušuje plánování dotazů
- tabulky, které narostou na 100 milionů řádků, mohou způsobit specifické problémy s výkonem a údržbou
- žádný způsob, jak provádět změny aplikací nebo upgrady schématu specifické pro tenanta
- migrace tenantů mezi servery je dražší
Který model „funguje lépe“ tedy skutečně závisí na tom, které kompromisy vás bolí nejhůře.
Existuje také hybridní model, „tenant-view“, kde jsou skutečná data uložena ve sdílených tabulkách, ale každé připojení aplikace používá zobrazení bezpečnostní bariéry pro zobrazení dat. To má některé z kompromisů každého modelu. Primárně má bezpečnostní výhody modelu tenant-schema s některými výkonnostními nevýhodami obou modelů.