Multi-Tenant vs Single-Tenant | Pareizas SaaS arhitekturas izvele

Katram SaaS produktam ir jaatbild uz fundamentalu jautajumu: ka apkalpot vairakus klientus no vienas programmaturas? Atbilde ir jusu nomniecibas modelis. Tas ietekme izmaksas, drosibu, veiktspeeju un to, cik atri varat publicet. Pareiza izvele agri pasarga jus no sapeigam migracijam velak.

Definicijas

Multi-tenant

Viena lietojumprogrammas instance apkalpo visus klientus. Visi dala vienus serverus, vienu koda bazi un biezi vienu datu bazi. Katra klienta dati ir logiski izoleti, bet infrastruktura ir kopiga.

Iedomajieties to ka daudzdzivoklu namu. Katrs iremnieks dzivo viena nama, dala liftu un gaitenus, bet katram ir savs aizslegts dzivoklis ar saviem meebeliem.

Single-tenant

Katrs klients sanem savu dedicetu lietojumprogrammas instanci. Atsevissi serveri, atseviskas datu bazes, dazreiz atseviskas koda bazes. Starp klientiem nekas nav kopigs.

Iedomajieties to ka atseviskas majas. Katram iremniekam ir sava eka, savas komunikacijas, savs pagalms. Pilniga izolacija, bet dargak uzturet.

Ka multi-tenancy stradaa

Ir triss biezas pieejas multi-tenant arhitekturai, katrai ar atskiriigiem kompromisiem.

1. modelis: Kopiga lietojumprogramma, kopiga datu baze

Visi nomnieki dala vienu lietojumprogrammas instanci un vienu datu bazi. Nomnieku dati ir atdaliti, izmantojot nomnieka identifikatoru (parasti tenant_id kolonna) katraa tabula.

Arhitektura:

• Viens lietojumprogrammas serveris (vai klasteris) apstrada visus pieprasijumus.
• Viena datu baze glaba visu nomnieku datus.
• Katrs vaicajums ietver WHERE tenant_id = ? klauzulu, lai ierobezotu datus uz pareizo nomnieku.

Prieksrocibas:

• Zemakas infrastrukturas izmaksas. Viena datu baze, viens lietotnes izvietojums.
• Vienkaarsaak izvietot un atjauninat. Publicejiet vienreiz, visi sanem izmainas.
• Viegli apkopot datus pa nomniekiem analitiikai un atskaiteem.

Trukumi:

• Augstakais datu nopluudes risks, ja vaicajums aizmirst nomnieka filtru.
• Viens trokssnaings nomnieks var paslikttinat veiktspeeju visiem.
• Datu bazes migracijas ietekme visus nomniekus vienlaikus.
• Visgrutaak atbilst datu rezidences regulam.

Si ir visbiezaka pieeja B2B SaaS produktiem ar lielu skaitu mazu lidz videeju klientu.

2. modelis: Kopiga lietojumprogramma, atseviskas datu bazes

Visi nomnieki dala vienu lietojumprogrammas instanci, bet katrs nomnieks sanem savu datu bazi. Lietojumprogramma novirza vaicajumus uz pareizo datu bazi, pamatojoties uz autentificeto nomnieku.

Arhitektura:

• Viens lietojumprogrammas serveris (vai klasteris) apstradaa visus pieprasijumus.
• Atsevisska datu baze katram nomniekam.
• Marsrutesanas slaanis kartee nomnieka identitati uz pareizo datu bazes savienojumu.

Prieksrocibas:

• Stipraka datu izolacija. Nav risku starpnomnieku vaicajumiem.
• Vieglak atbilst datu rezidences prasiibam. Jus varat novietot katru datu bazi nomnieka prasitaja regiona.
• Katram nomniekam atsevisska rezerves kopesana un atjaunoosana ir vienkarsa.
• Viena nomnieka liela sloggze neblokeees tabulas citiem nomniekiem.

Trukumi:

• Vairak infrastrukturas parvaldibai. Simtiem nomnieku nozime simtiem datu bazu.
• Shemu migracijas japiemero katrai datu bazei atsevisski.
• Starpnomnieku atskaites prasa vaicajumus no vairakam datu bazem.
• Augsstakas izmaksas neka pilnigi kopigs modelis.

Si ir speeciiga vidusceela produktiem, kam vajadziga labaka izolacija bez pilnas single-tenancy izmaksam.

3. modelis: Atsevisska lietojumprogramma, atsevisska datu baze

Katrs nomnieks sanem savu dedicetu lietojumprogrammas instanci un savu datu bazi. Pilnigi izoleets. Sis butiiba ir single-tenancy, bet parrvaldits no SaaS pakalpojumu sniedzeja, nevis klienta.

Arhitektura:

• Dediceets lietojumprogrammas izvietojums katram nomniekam.
• Dediceta datu baze katram nomniekam.
• Marsrutesanas slaanis (biezi slodzes sadalitajs vai API varteja) novirza datplsmu uz pareizo instanci.

Prieksrocibas:

• Pilniga izolacija. Nav kopiigu resursu starp nomniekiem.
• Maksimala elastiba pielgosanai katram nomniekam.
• Viena nomnieka veiktspeeja nekad neiietekme citu.
• Vienkaarrsaaakais atbilstibas stasts.

Trukumi:

• Augsstakas infrastrukturas izmaksas.
• Izvietosanas sarezgiitiba aug lineari ar nomnieku skaitu.
• Atjauninajumi jaievies katrai instancei atsevisski (vai loti rupigi jaautomatize).
• Ekonomiski nemerogojas lielam skaitam mazu nomnieku.

Sis modelis ir pamatots uznemumu SaaS, kur klienti pieprasa dedicetu infrastrukturu un ir gatavi maksat premium.

Prieksrocibas un trukumi vienaa skatiena

Faktors	Multi-Tenant (kopiga DB)	Multi-Tenant (atseviskas DB)	Single-Tenant
Infrastrukturas izmaksas	Zemakas	Videjas	Augsstakas
Datu izolacija	Logiska (rindu limena)	Fiziska (datu bazes limena)	Pilniga
Izvietosanas sarezgiitiba	Zema	Videja	Augsta
Atjauninasanas atrums	Tuleej visiem	Tuliteja lietotne, katrai DB migracijas	Katrai instancei
Pielgosana	Ierobezota	Ierobezota	Pilna
Atbilstba	Grutaak	Merena	Visvieglak
Merogojamiba (nomnieku skaits)	Lieliska	Laba	Slikta
Trokssnaiga kaimina risks	Augsts	Videjs	Nav

Datu izolacija un drosba

Datu izolacija ir viissvariigaakais apsveerums jebkura nomniecibas modeli. Drosibas parkaapums, kur viens nomnieks var piekluut cita nomnieka datiem, ir katastrofaals SaaS biznesam. Tas var iznicinat uzticiibu, parkaptt regullas un beigt uznemumu.

Rindu limena drosba

Kopiga datu bazes modeli PostgreSQL rindu limena drosiba (RLS) ir viena no speciigaakajam aizsardzibam pret datu nopludi. RLS piespiiez nomnieku izolaciju datu bazes limeni, nevis lietojumprogrammas limeni. Pat ja jusu lietojumprogrammas kodam ir kluda, kas aizmirst filtret pec nomnieka, datu baze pati noverrs starpnomnieku pieeju.

Luk, ka to iestatit:

-- Ieslgt RLS tabulai
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Izveidot politiku, kas ierobeo pieeju pasreizjam nomniekam
CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

-- Piespiest RLS ar tabulas paisniekiem
ALTER TABLE projects FORCE ROW LEVEL SECURITY;

Pirms jebkura vaicajuma izpildes iestatiet nomnieka kontekstu:

-- Iestatit katra pieprasijuma/transakcijas sakum
SET LOCAL app.current_tenant_id = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890';

-- Tagad is vaicjums automtiski atgriez tikai pasreizj nomnieka datus
SELECT * FROM projects;
-- Nav nepieciesama WHERE klauzula. RLS to apstrd.

Lietojumprogrammas limena izolacija

Papildus datu bazes limena drosiibai jusu lietojumprogrammai jabut jaapiespieez nomnieku robezas:

// Starpslnis, kas iestata nomnieka kontekstu katram pieprasjumam
async function tenantMiddleware(req: Request, res: Response, next: NextFunction) {
  const tenantId = extractTenantId(req); // No JWT, subdomena vai galvenes

  if (!tenantId) {
    return res.status(401).json({ error: "Tenant not identified" });
  }

  // Iestatit nomnieka kontekstu datu bzes savienojumam
  await db.raw(`SET LOCAL app.current_tenant_id = '${tenantId}'`);

  req.tenantId = tenantId;
  next();
}

Aizsardziba dziluma ir princips sheit. Nekad nepajaujieties uz vienu izolacijas slani. Apvienojiet lietojumprogrammas limena filtresanu, datu bazes limena drosibu un regularus drosiibas auditus.

Veiktspeejas apsveerumi

Kopigas datu bazes izaicinajumi

Kopiga datu baze visi nomnieki sacensas par vieniem resursiem. Nomnieks, kas palaiz smagu atskaiti, var paaleeninat vaicajumus visiem parejiem. Mazinajumi ietver:

• Savienojumu kopasana. Izmantojiet PgBouncer vai lidzigu riku, lai noverstu viena nomnieka datu bazes savienojumu izsmsanu.
• Vaicajumu taimautii. Iestatiet maksimaalo izpildes laiku, lai izbraucis vaicajums nevaretu bloket resursus bezgaligi.
• Atruma ierobezosana. Piespiediet katram nomniekam ierobezojumus API pieprasijumiem un datu bazes operacijam.
• Lasssanas replikas. Novirziet smagas lasssanas operacijas (atskaites, eksporti) uz repliku, lai tas neietekmetu primaro datu bazi.

Atsevissku datu bazu prieksrocibas

Ar katram nomniekam atsevissku datu bazi veiktspeejas izolacija ir iebuveta. Viena nomnieka smagais darba slogs ietekme tikai vinu datu bazi. Jus varat ari piedaalit lielakas vai mazakas datu bazes, pamatojoties uz katra nomnieka planu un lietojumu.

Kompromiss ir parvaldibas pieskaitamas izmaksas. 500 datu bazu monitorings ir grutaks neka vienas. Automatizeti riki klust neaizstaajami.

Izmaksu sekas meroga

Apskatisim dazus aptuveenus skaitlus. Pienemmsim, ka jums ir 100 nomnieku.

Kopiga datu baze (multi-tenant):

• 1 lietojumprogrammu klasteris: ~200 EUR/menesi
• 1 parvaldita PostgreSQL instance: ~100 EUR/menesi
• Kopa: ~300 EUR/menesi (3 EUR par nomnieku)

Atseviskas datu bazes (multi-tenant):

• 1 lietojumprogrammu klasteris: ~200 EUR/menesi
• 100 mazas datu bazes instances: ~2 000 EUR/menesi
• Kopa: ~2 200 EUR/menesi (22 EUR par nomnieku)

Single-tenant:

• 100 lietojumprogrammu instances: ~5 000 EUR/menesi
• 100 datu bazes instances: ~2 000 EUR/menesi
• Kopa: ~7 000 EUR/menesi (70 EUR par nomnieku)

Sie skaitli ir vienkarsoti, bet modelis saglabaajas. Kopiga infrastruktura ir dramatiski letaka. Ar 1 000 nomniekiem starpiba klust vel lielaka.

Tapec cenosanai ir jaaatbilst arhitekturai. Ja jus iekasejat 20 EUR menesi un palaizat single-tenant infrastrukturu par 70 EUR par nomnieku, jus zaudejat naudu par katru klientu.

Kad izveleties multi-tenant

Multi-tenant arhitektura ir pareiza izvele, kad:

• Jus buvejat B2B SaaS maziem un videjiem uznemumiem. Liels apjoms, zemaaki cenu punkti un standarta funkciju kopas.
• Izmaksu efektivitate ir svariiga. Jums ir jasatura infrastrukturas izmaksas zemaas attieciiba pret ienakumiem.
• Velaties atrus, vienotus atjauninajumus. Izvietojiet vienreiz, visi nomnieki sanem uzlabojumu.
• Jusu klientiem nav vajadziga dediceta infrastruktura. Lielaka dala mazo un videjo uznemumu neuztraucas par to, kur vinu dati atrodas, ja vien tie ir drosi.
• Jus esat agriinaja stadija. Saciet ar multi-tenant. Tas ir letaaks un vienkarsaaks. Jus vienmeer varat piedavat single-tenant velak uznemumu klientiem.

Kad izveleties single-tenant

Single-tenant arhitektura ir pamatota, kad:

• Jus pardodat uznemumiem. Lielas organizacijas biezi prasa dedicetu infrastrukturu ka dalu no vinu iepirkuma procesa.
• Atbilstba to prasa. Nozareem ka veselibas aprupe (HIPAA), finanses (SOX, PCI-DSS) un valdibai ir striktas datu izolacijas prasibas.
• Klientiem ir vajadziga pielgosana. Ja katram klientam ir vajadziigas atskirigas konfiguracijas, integracijas vai pat funkcijas, single-tenant sniedz elastiibu.
• Jusu cenu punkts to atbalsta. Ja iekasejat 5 000 EUR vai vairak menesi par klientu, infrastrukturas izmaksas ir viegli attaisnotas.
• Datu rezidence ir strikta prasiba. Kad datiem jabut noteikta valsti, atsevisska infrastruktura katram nomniekam ir vistiesaka pieeja.

Hibrdas pieejas

Jums nav jaaizvelas tikai viena. Daudzi veiksmigi SaaS uznemumi izmanto hibridu modeli:

• Multi-tenant standarta pakapem. Bezmaksas, starter un pro klienti dala infrastrukturu. Tas uztur zemas izmaksas un lauj merogoties.
• Single-tenant uznemumiem. Premium klienti sanem dedicetas instances ar pielgotiem SLA, atbilstibas sertifikatiem un dedicetu atbalstu.

Lietojumprogrammas kods ir viens un tas pats. Izvietosanas modelis atskiras. Tam ir vajadziga laba infrastrukturas automatizacija, bet tas ir pieradits modelis.

Ka ieviest hibridu modeli

1. Buvejiet lietotni ka multi-tenant vispirms. Visa nomnieku izolacijas logika paliek tada pati neatkarigi no izvietosanas modela.
2. Izmantojiet infrastructure-as-code (Terraform, Pulumi vai CDK), lai automatizetu vides izveidi.
3. Izveidojiet nodroosinassanas konveijeru, kas var iedarbinaat jaunu dedicetu vidi minuusu, nevis dienu laika.
4. Uzturiet vienu koda bazi. Tas pats Docker attels darbojjas gan koplietojamas, gan dedicetas vides. Konfiguracija (nevis kods) nosaka uzvedbu.

Datu bazes strategijas detalizeti

Datu baze ir vieta, kur nomniecibas lemumiem ir visielaaaka ietekme. Luk, triss pieraditas strategijas.

1. strategija: Kopigas tabulas ar tenant_id

Katrai tabulai ir tenant_id kolonna. Visi vaicajumi filtre pec tas.

CREATE TABLE projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_projects_tenant ON projects(tenant_id);

-- Vienmr vaict ar nomnieka kontekstu
SELECT * FROM projects WHERE tenant_id = $1;

Labakais prieks: lielaakajai dalai SaaS produktu. Vienkarsi, izmaksu efektivi, labi saprotami.

2. strategija: Shema katram nomniekam

Katrs nomnieks sanem savu PostgreSQL shemu kopiga datu baze. Tabulam ir tada pati struktura, bet dati ir fiziski atdaliti.

-- Izveidot shmu jaunam nomniekam
CREATE SCHEMA tenant_abc123;

-- Izveidot tabulas nomnieka shem
CREATE TABLE tenant_abc123.projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Iestatit meklanas ceu katram pieprasjumam
SET search_path TO tenant_abc123, public;

-- Tagad vaicjumi ir automtiski ierobezoti
SELECT * FROM projects;

Labakais prieks: produktiem, kam vajadziga stipraka izolacija neka rindu limena, bet nevelas atsevissku datu bazu izmaksas. Stradaa labi lidz dazziem simtiem nomnieku.

3. strategija: Atseviskas datu bazes

Katrs nomnieks sanem dedicetu PostgreSQL instanci (vai dedicetu datu bazi kopiga serveri).

// Datu bzes savienojumu marsrtana
class TenantDatabaseRouter {
  private connections: Map<string, DatabasePool> = new Map();

  async getConnection(tenantId: string): Promise<DatabasePool> {
    if (this.connections.has(tenantId)) {
      return this.connections.get(tenantId)!;
    }

    const config = await this.loadTenantDbConfig(tenantId);
    const pool = new DatabasePool({
      host: config.host,
      port: config.port,
      database: config.database,
      user: config.user,
      password: config.password,
    });

    this.connections.set(tenantId, pool);
    return pool;
  }

  private async loadTenantDbConfig(tenantId: string): Promise<DbConfig> {
    // Meklt nomnieka datu bzes savienojuma detaas
    // no centrls konfigurcijas glabtuves
    return await configStore.get(`tenants/${tenantId}/database`);
  }
}

Labakais prieks: uznemumu SaaS ar augstas vertibas klientiem, striktam atbilstibas prasibam vai datu rezidences pienakumiem.

Lemuma pienemsana

Luk, vienkaars lemumu pienemmsanas ietvars:

1. Kads ir jusu merksa klienta lielums? SMB norada uz multi-tenant. Uznemums norada uz single-tenant vai hibridu.
2. Kads ir jusu cenu punkts? Zem 100 EUR/menesi jums ir vajadzigs multi-tenant, lai butu pelnooss. Virs 1 000 EUR/menesi single-tenant klust dzivotspejigs.
3. Kadas ir atbilstibas prasibas? Reguletas nozares biezi prasa stipraku izolaciju.
4. Cik nomnieku jus gaidat? Simtiem vai tukstosieem nomnieku vajag kopigu infrastrukturu. Desmit lidz piiecdeesmit lieli nomnieki var stradat ar dedicetam instancem.
5. Kada ir jusu komandas operacionals kapacitate? Single-tenant prasa vairak DevOps investiciju. Multi-tenant ir operacionali vienkaarsaaks.

Ja neesat parliecinati, saciet ar multi-tenant ar kopigu datu bazi un rindu limena drosibu. Ta ir zemako izmaksu opcija, ta ir droosa, ja ieviesta pareizi, un ta saglaba jusu arhitekturu vienkaarsu. Jus vienmeer varat pievienot dedicetu pakapi uznemumu klientiem velak.

Gala sledziens

Nav universali pareiza nomniecibas modela. Pareiza izvele ir atkariga no jusu klientiem, jusu cenossanas, jusu atbilstibas prasibam un jusu operacionalaam spejam.

Lielaakajai dalai SaaS produktu jabut jaasak ar multi-tenant. Tas ir letaak, vienkaarsaak un labi merogojas. Ejot uz augstaku tirgu un sakot pardot lielakam organizacijam, pievienojiet single-tenant opcijas klientiem, kam tas ir vajadzigs un kas par to maksas atbilstosi.

Arhitekturai ir jaaapkalpo bizness, nevis otradi. Buvejiet klientiem, kas jums ir sodien, un projektejiet ar pietiekamu elastiibu, lai apkalpotu klientus, kurus velaties rit.

---

Vajadziga palidziba pareizas arhitekturas izvele jusu SaaS produktam? Mes esam buvejusi multi-tenant un single-tenant sistemas dazadas nozares. Nosakisim labako pieeju jusu projektam.