Prestaties zijn niet noodzakelijkerwijs slechter. Zoals in het artikel wordt uitgelegd, zijn er specifieke voorwaarden die de schemabenadering beter of slechter maken, afhankelijk van uw toepassingsontwerp en werkbelasting. Laat me de afwegingen van de "tenant-schema" versus "gedeelde-tabel"-benaderingen uitleggen:
tenant-schema is het beste wanneer u een relatief klein aantal redelijk grote huurders heeft. Een voorbeeld hiervan is een boekhoudapplicatie, met alleen betalende abonnementsgebruikers. Dingen die het de beter presterende optie voor u maken, zijn onder meer:
- een klein aantal huurders met elk veel gegevens
- een relatief eenvoudig schema zonder veel tabellen per tenant
- noodzaak om de schema's van sommige tenants aan te passen
- mogelijkheid om gebruik te maken van databaserollen per tenant
- vereiste om de gegevens van een tenant van de ene server naar de andere te migreren
- mogelijkheid om voor elke huurder een speciale appserver in uw cloud op te zetten
Dingen die het een slecht presterende optie maken, zijn onder meer:
- veel huurders met elk zeer weinig gegevens
- stateloze benadering van verbindingen waarbij elk verzoek een willekeurige tenant kan zijn
- clientbibliotheek of orm die metagegevens voor alle tabellen in de cache opslaat (zoals ActiveRecord)
- een vereiste voor efficiënte, hoogwaardige pooling en/of caching van verbindingen
- problemen met VACUUM en andere PostgreSQL-beheerbewerkingen die slecht schalen over duizenden tabellen.
Of het tenant-schema slecht is voor migraties/schemawijzigingen, hangt er echt van af hoe u ze doet. Het is slecht voor het snel uitrollen van een universele schemawijziging, maar goed voor het implementeren van schemawijzigingen als een geleidelijke uitrol over tenants.
gedeelde tafel werkt beter voor situaties waarin u veel huurders hebt en veel van uw huurders zeer weinig gegevens hebben. Een voorbeeld hiervan is een mobiele app voor sociale media die gratis accounts toestaat en dus duizenden verlaten accounts heeft. Andere dingen die het gedeelde tafelmodel voordelig maken, zijn:
- beter voor pooling van verbindingen, omdat alle verbindingen dezelfde pool kunnen gebruiken
- beter voor PostgreSQL-beheer, vanwege minder tabellen in totaal
- beter voor migraties en schemawijzigingen, aangezien er maar één "set" tabellen is
Het belangrijkste nadeel van een gedeelde tabel is de noodzaak om de tenantfiltervoorwaarde toe te voegen aan elke afzonderlijke query in de toepassingslaag. Het is ook problematisch omdat:
- query's die veel tabellen samenvoegen, presteren mogelijk slecht omdat het tenantfilter de queryplanning in de weg staat
- tabellen die groeien tot 100 miljoen rijen kunnen specifieke prestatie- en onderhoudsproblemen veroorzaken
- geen manier om tenant-specifieke applicatiewijzigingen of schema-upgrades door te voeren
- duurder om tenants tussen servers te migreren
Dus welk model "beter presteert" hangt er echt van af welke afwegingen u het meest pijn doen.
Er is ook een hybride model, "tenant-view", waarbij de feitelijke gegevens worden opgeslagen in gedeelde tabellen, maar elke applicatieverbinding gebruikt weergaven beveiligingsbarrière om de gegevens te bekijken. Dit heeft enkele nadelen van elk model. Het heeft in de eerste plaats de beveiligingsvoordelen van het tenant-schemamodel met enkele van de prestatienadelen van beide modellen.