Meerdere klanten; één gehoste applicatie. U beschrijft een database met meerdere tenants.
Wanneer u een multi-tenant database bouwt, moet u rekening houden met
- bevragen
- kosten
- isolatie en bescherming van gegevens
- onderhoud, en
- herstel na noodgevallen.
Multi-tenant oplossingen variëren van één database per tenant (niets gedeeld) tot één rij per tenant (alles gedeeld).
"Niets gedeeld", "aparte database", of één database per tenant
- Duurste per klant. (Grote aantallen clients impliceren grote aantallen servers.)
- Hoogste graad van gegevensisolatie.
- Herstel na noodgevallen voor een enkele huurder is eenvoudig en duidelijk.
- Onderhoud is theoretisch moeilijker, omdat er in elke database wijzigingen moeten worden doorgevoerd. Maar uw dbms kan gemakkelijk het uitvoeren van opgeslagen procedures in elke database ondersteunen. (SQL Server heeft een ongedocumenteerde, door het systeem opgeslagen procedure, bijvoorbeeld sp_msforeachdb. U kunt waarschijnlijk uw eigen procedure schrijven.) "Niets gedeeld" is ook het gemakkelijkst aan te passen, maar dat levert ook meer onderhoudsproblemen op.
- Laagste aantal rijen per tabel. De querysnelheid is bijna optimaal.
"Alles gedeeld", of "gedeeld schema", of "één database per planeet"
- Minst duur per huurder.
- Laagste mate van gegevensisolatie. Elke tabel heeft een kolom die aangeeft tot welke tenant een rij behoort. Aangezien rijen van huurders in elke tabel worden gemengd, is het relatief eenvoudig om per ongeluk de gegevens van andere huurders bloot te leggen.
- Herstel na rampen voor een enkele huurder is relatief ingewikkeld; je moet individuele rijen in veel tabellen herstellen.
- Structureel onderhoud is eenvoudiger, aangezien alle huurders de tafels delen. Het verhoogt echter de communicatiebelasting, omdat je elke wijziging met elke huurder moet communiceren en coördineren. Het is niet gemakkelijk aan te passen.
- Hoogste aantal rijen per tabel. Snelle query's zijn moeilijker, maar het hangt af van hoeveel tenants en hoeveel rijen. Je zou gemakkelijk naar VLDB-territorium kunnen kantelen.
Tussen "niets gedeeld" en "alles gedeeld" staat "gedeeld schema".
"Gedeeld schema"
- Tenants delen een database, maar elke tenant heeft zijn eigen benoemde schema. De kosten vallen tussen "niets gedeeld" en "alles gedeeld"; grote systemen hebben doorgaans minder servers nodig dan "niets gedeeld", meer servers dan "alles gedeeld".
- Veel betere isolatie dan 'alles delen'. Niet zo veel isolatie als "niets delen". (U kunt machtigingen VERLENEN en INTREKKEN voor schema's.)
- Noodherstel voor één tenant vereist het herstellen van een van de vele schema's. Dit is relatief eenvoudig of vrij moeilijk, afhankelijk van je dbms.
- Onderhoud is makkelijker dan "niets delen"; niet zo eenvoudig als "alles delen". Het is relatief eenvoudig om een opgeslagen procedure te schrijven die in elk schema in een database wordt uitgevoerd. Het is gemakkelijker om gemeenschappelijke tabellen onder huurders te delen dan met "niets gedeeld".
- Meestal meer actieve tenants per server dan "niets gedeeld", wat betekent dat ze meer bronnen delen (degraderen). Maar niet zo erg als "alles gedeeld".
Microsoft heeft een goed artikel over multi-tenant architectuur met meer details. (De link is naar slechts één pagina van een document met meerdere pagina's.)