Prestanda är inte sämre, nödvändigtvis. Som artikeln förklarar finns det specifika förhållanden som gör att schemat blir bättre eller sämre beroende på din applikationsdesign och arbetsbelastning. Låt mig förklara avvägningarna mellan "tenant-schema" kontra "shared-table"-metoderna:
tenant-schema är bäst när man har ett relativt litet antal ganska stora hyresgäster. Ett exempel på detta skulle vara en bokföringsapplikation, med endast betalda prenumerationsanvändare. Saker som gör det till det bästa alternativet för dig är:
- ett litet antal hyresgäster med mycket data vardera
- ett relativt enkelt schema utan många tabeller per klient
- ett behov av att anpassa scheman för vissa hyresgäster
- möjlighet att använda databasroller per hyresgäst
- krav på att migrera en klients data från en server till en annan
- möjlighet att skapa en dedikerad appserver i ditt moln för varje hyresgäst
Saker som gör det till ett dåligt presterande alternativ inkluderar:
- många hyresgäster med väldigt lite data vardera
- statslöst förhållningssätt till anslutningar där varje begäran kan vara vilken hyresgäst som helst
- klientbibliotek eller orm som cachar metadata för alla tabeller (som ActiveRecord)
- ett krav på effektiv, högpresterande anslutningspoolning och/eller cachning
- problem med VACUUM och andra PostgreSQL-administrativa operationer som skalas dåligt över 1000-tals tabeller.
Huruvida tenant-schema är dåligt för migrering/schemaändringar beror verkligen på hur du gör dem. Det är dåligt för att implementera en universell schemaändring snabbt, men bra för att implementera schemaändringar som en gradvis utrullning mellan hyresgäster.
delad tabell fungerar bättre för situationer när du har många hyresgäster, och många av dina hyresgäster har väldigt lite data. Ett exempel på detta skulle vara en social medial mobilapplikation som tillåter gratiskonton och därmed har tusentals övergivna konton. Andra saker som gör modellen med delat bord till nytta är:
- bättre för anslutningspooling, eftersom alla anslutningar kan använda samma pool
- bättre för PostgreSQL-administration, på grund av färre tabeller totalt
- bättre för migrering och schemaändringar, eftersom det bara finns en "uppsättning" tabeller
Den största nackdelen med delad tabell är behovet av att lägga till klientfiltervillkoret på varje enskild fråga i applikationslagret. Det är också problematiskt eftersom:
- Frågor som sammanfogar många tabeller kan fungera dåligt eftersom klientfiltret kastar ut frågeplanering
- tabeller som växer till 100 miljoner rader kan orsaka specifika prestanda- och underhållsproblem
- inget sätt att göra klientspecifika programändringar eller schemauppgraderingar
- dyrare att migrera hyresgäster mellan servrar
Så vilken modell som "presterar bättre" beror verkligen på vilka avvägningar som skadar dig värst.
Det finns också en hybridmodell, "tenant-view", där den faktiska informationen lagras i delade tabeller, men varje applikationsanslutning använder vyer över säkerhetsbarriärer för att se data. Detta har några av avvägningarna för varje modell. I första hand har den säkerhetsfördelarna med tenant-schema-modellen med några av prestandanackdelarna med båda modellerna.