Multi-tenant - Database Structure

Buna,

Pentru multi-tenant, exista 3 structuri:

  1. A database for each tenant
  2. Separated database schema for each tenant
  3. Single database (shared) with tenant_id

Am cautat de cateva zile raspunsul acestei intrebari si sunt multe pareri. Nu stiu care este cea mai buna solutie sa incepi o aplicatie Saas si sa nu ai surprize pe viitor.

Intreb pe cei care au experienta cu asa tip de aplicatie, voi cum recomandati?

1 sau 2, dă cu banul

Niciodată nu aș alege 3.

Mai ales în ziua de azi când discutăm de containere, distributie geografică in funcție de clienți, etc.

In ziua de azi costurile au scăzut prea mult ca să mai merite riscul cu o singură bază de date masivă.

Dacă pătește ceva toți clienții au pierdut.

Plus codul trebuie să fie extrem de bine testat ca să nu ai probleme și să își vadă clienții datele unul altora.

Ieri si azi am analizat zeci si sute de articole pe aceasta tema. Sunt multe articole ce spun ca varianta 2 este cea mai buna. Adica are balance intre cost si developing.

Doar ca azi am dat peste cateva raspunsuri pe forumu-uri care spun ca: google si salesforce folosesc o singura baza de date, ei separa chiriasii (tenants) prin orgID, tenant_id…etc. Si anume aceasta informatie m-a pus pe ganduri. Si ma intreb, cum le reuseste sa aiba asa o baza mega-uriasa?

Probabil partitii si mirrors. Si o gramda de back-ups. Dar daca o companie mare face un lucru, oare inseamna ca e corect?

Eu cred ca Salesforce doar are bani sa mentina o arhitectura problematica.

Lucram pe arhitectura multi-tenant pot zice ca varianta cu fiecare tenant cu baza lui de date separata si fiecare baza de date pe masina sa independenta e modul corect de a lucra.

Lucrand cu baze de date separate nu avem niciodata problema ca detele unui client ar putea fi vazute de altul, daca pica o masina e doar pentru un client si daca un client are un spike de trafic, e afectata doar o baza de date.

Am trecut prin faza cand aveam totul pe o masina si ni s-au intamplat toate relele:

  • spike-uri care omorau toti clientii;
  • a cazut masina, au murit toti clientii;
  • daca faceam un test pentru o imbunatatire, erau reporniti toti clientii (doar am zis ca lucram cu o singura baza de date, si live, si testare)

Noi platim vreo 27 de euro pe masina cu baza de date. Categoric pot cumpara masini virtuale la 10 euro sau mai ieftine dar clientii mei au o afinitate pentru un ofertant de-al lor.

1 Like

Are logica, probabil ei doresc sa schimbe structura, dar deja este prea riscant si tarziu.

Deacord, dar asta este cam scump.

Ei bine, sa presupune ca alegem varianta: fiecare tenant cu baza lui de date.

La 50, 100, 200 mai poti sa te descurci cu migratiile. Dar cum sta treaba atunci cand ai peste 5000 de tenants?
Atunci cand faci o schimbare in API si in migratii. La care prima din ele faci upload pe server? Ma gandesc ca daca faci upload la API, si are nevoie de o tabela noua din baza de date, iar la un tenant inca nu au fost migrate tabelele noi, va fi o eroare.

Cum mai exact se procedeaza in asa proiecte mari?

2 Likes

E adevarat, nu avem mii de tenants. Nici macar zeci.

E putin ciudat sa vorbim de mii de tenants. Idea unei astfel de arhitecturi, zic eu, are sens cand fiecare client iti da niste bani seriosi pentru serviciul furnizat. La ce estimez eu ca avem e vorba de zeci de mii de euro per tenant pe luna. Si e vorba de niste servicii complexe.

Adica arhitectura asta are logica cand oferi unui client, de genul Lidl, toata infrastructura sa isi tina un anume serviciu in picioare. Noi oferim pe langa baza de date si un ecosistem de aplicatii ca fiecare sa aiba propria lui afacere. Practic ei doar stau si vin cu idei cum sa arate site-ul, mai schimba o poza, o descriere, in rest totul se petrece automat.

Vorbim aici de importuri de date, de prelucrare, afisare, realizarea comenzilor, the whole nine yards.

Si si aici e un domeniu… pe muchie de cutit. Daca clientul cere alti furnizori, alte reguli de business, alte procese, deja intram in discutii pentru a ii construi un ecosistem particularizat. Cu angajat de programatori, cu project manageri, etc.

1 Like

Eu vorbesc de aplicatii SaaS, care au pachete cu max 50 euro pe luna si nu este B2B. Adica se pot inregistra pe zi zeci de tenants care platesc cate 15, 30, 50 euro lunar. Eu totusi am inceput sa adaptez arhitectura cu “database schema” per tenant, desi am inceput cu single database, dar la un moment dat am inteles ca baza de date va deveni una uriasa.

In acest caz nu vad cum o arhitectura multi-tenant ar ajuta. Sunt niste costuri atasate.

Totusi, ia lucrurile pe rand. Mai intai sa faci 1 000 de euro pe luna, apoi 10 000 pe luna. Daca ajungi acolo e ok sa regandesti arhitectura.

Eu am ales database schema, adica nu vorbesc ca fiecare tenant sa aiba o instanta de baza de date.
In cazul meu, nu vad o problema cu costurile.

Nu stiu la ce se refera expresia aceea.

@RedGuard Cred ca se referă la o arhitectură similară cu Postgresql, unde într-o bază de date poti să ai mai multe schemas. Spre deosebire de MySQL unde database = schema.

@lao9s Din variantele enumerate de tine am lucrat cel mai mult fix cu 3, tocmai pentru că la mine tenants = grupuri de clienți, deci fiecare avea datele lui dar exista și seturi de date comune între toti.
Dacă aș fi avut cate o bază date date pentru fiecare client și una cu datele generale ar fi fost mai geu de gestionat (dacă adaug o functionlitate noua care necesită modificari ale structurii de date ar fi trebuit să migrez cateva mii de baze de date). Pentru alte proiecte poate voi compartimentaliza datele în baze date diferite, cine știe.

Cred că până la urma nu există soluție universal valabila cand vine voba de compartimentalizarea datelor ci trebuie să alegi în functie de specificul proiectului și de resursele (umane, financiare) de care dispui tu/firma/clientul.

PS: în general opțiunile 1 și 2 sunt echivalente, diferența între schema și database fiind doar implementarea pe RDBMS-ul tău.

2 Likes

Well, poti avea:

  • o singura baza de date cu campuri aferente fiecarui tenant. Practic un alt camp agregator peste conceptul de user (adica un tenant are mai multi utilizatori specifici, ajungi sa ai un singur set de tabele dar foarte mari - in cazul nostru ar fi cateva sute de milioane de intrari pentru un singur tabel);
  • o singura baza de date cu tabele prefixate cu tenantX_*
  • mai multe baze de date pe o singura masina, fiecare DB cu aceleasi tabele dar cu date diferite;
  • mai multe baze de date (instante MySQL) ruland fiecare pe masina sa

Da, noi lucram cu MySQL, schema inseamna structura bazei de date. Tabele, coloane, indecsi.

Eu ma iau dupa ceva ce am citit acum o luna. In loc sa faci un prototip complet functional cu deciziile corecte pentru a sustine si un tenant si 1 000, faci un mock-up de cateva zile. Costa o suta-doua de euro si “merge si asa”. Daca prinde tractiune si lumea da bani, well, la 10 000 de euro pe luna poti sa angajezi 3 oameni si sa regandesti arhitectura.

In toata cariera mea nu am vazut o aplicatie scrisa o singura data si care sa nu necesite o regandire de la zero dupa cativa ani. Ma gandesc la Dropbox care a inceput salvand fisiere ca BLOB intr-o baza de date MySQL.

3 Likes

eu cred ca toate sunt corecte in functie de caz
in 90% din cazuri varianta 3 e cea mai la indemana, poti duce zeci de milioane de inregistrari cu un buget si power man redus, ai backup usor, ai varianta de master-slave usor pt intensive reads

fara a sti mai multe detalii despre proiect e greu sa dezbatem varianta corecta pt tine

1 Like

Multumesc la toti pentru raspunsuri. Cred ca merg mai departe pe varianta 2.

Mergi pe o varianta hibrida in care ai X clienti per baza de date si astfel ai un “nucleu” (cluster) pe care il multiplici de N* X ori. O baza centrala ar trebui sa pastreze eventualele informatii comune precum si locatiile clusterelor si versiunile lor. Apoi faci o instalare desteapta si automatizata astfel incat sa poti reactualiza sursele si structura BD pe clustere. Si implementezi fie pe subdomenii fi cu API sau microservicii. Avantajul ar fi ca ai un produs inainte sa il scalezi la 1M useri.

1 Like

Ai mei 2 cenți. Toate 3 variantele sunt bune **
** dacă developerii știu și înțeleg ce fac

Exemplu 1. DB sau DB server/client
Cazul lu’ Saga. E nightmare la ei. Ne avand nici un control asupra aplicatiei, asta e cel mai retard-proof
Clientul poate sa paseze intre ei DB-urile, chiar in cadru aceluiasi client, se pot muta pe instante diferite.
Timpi de backup automat, relativi mici
Posibilitatea de a avea versiuni diferite la schema.
Minimum data corruption
Skill: n00b

Exemplul 2. Multiple DB in cadrul aceluiasi server sau tabele cu prefixe unice
Caz: small to medium SaaS De multe ori cazi in capcana de a avea un client care te-a cam prins de cojones ca a ajuns sa iti aduca 60%+ din revenue si are nevoie de atentie speciala.
Vrei totul sa fie la tine, ca sa ai control la Intelectual Property, dar clientul ala special ba o ia inaintea celorlalti ba vrea chestii custom si nu ii pasa de SaaS-ul tau.
In cazul asta poti sa ai schemas diferite, cu minim efort de migrare. Scalezi la inceput vertical, dupa care orizontal. Maxim vei face partitionare, dupa ~10mil de rows
Master->Slave sau Proxysql-> Master -> Multi slave
Skill: “ai facut de cel putin 2 ori in viata ta un master-slave”

Exemplul 3. The true SaaS
Esti in control complet. Tu decizi ce features intra si cand.
Scalezi direct orizontal. Nu scapi de partitionare si sharding, dar macar nu mai e bataie de cap cu multi schema, multi migrations, bla bla
ProxySQL (Read/Write split) -> Galera Cluster Writes -> Disposable read replicas in autoscale
Skill: poti recita changelogs de la innodb din memorie / Participi la flame wars pe jira-ul lu MariaDB

6 Likes

Am avut de aface cu toate variantele, și din experiența avuta pana acum îmi place sa merg cu varianta single db ( cu sharding de clienți, la nevoie ) pe pricing pointurile simple și cu varianta 3 pentru clienți enterprise.

2 Likes