Megosztás a következőn keresztül:


Rugalmas fürtök skálázási modelljei az Azure Database for PostgreSQL-ben

A horizontális skálázás az adatbázisrendszerekben és az elosztott számítástechnikában használt technika, amellyel több kiszolgáló vagy csomópont között horizontálisan particionálhatók az adatok. Ez magában foglalja egy nagy adatbázis vagy adatkészlet kisebb, kezelhetőbb részekre, úgynevezett szegmensekre való felosztását. A szegmensek az adatok egy részhalmazát tartalmazzák, és a szegmensek együttesen alkotják a teljes adathalmazt.

Az Azure Database for PostgreSQL rugalmas kiszolgálópéldányokon futó fürtök kétféle adatparticionálást kínálnak: soralapút és sémaalapút. Minden lehetőség saját kompromisszumokkal rendelkezik, így kiválaszthatja az alkalmazás követelményeinek leginkább megfelelő megközelítést.

Soralapú horizontális skálázás

Az önálló adatbázis megosztott sémamodelljének szilánktáblái, más néven soralapú horizontális skálázás, a bérlők ugyanazon a táblán belüli sorokként működnek együtt. A bérlőt egy terjesztési oszlop definiálásával határozzuk meg, amely lehetővé teszi a táblák vízszintes felosztását.

A soralapú horizontális skálázás a leghatékonyabb hardveres módszer. A bérlők sűrűn vannak csomagolva és elosztva a fürt csomópontjai között. Ehhez a megközelítéshez azonban gondoskodnia kell arról, hogy a séma összes táblája tartalmazza a terjesztési oszlopot, és hogy az alkalmazás összes lekérdezése az adott oszlop szerint szűrjön. A soralapú horizontális skálázás az IoT-számítási feladatokban és a legjobb hardverhasználati árrést nyújtja.

Előnyök:

  • A legjobb teljesítmény.
  • A legjobb bérlői sűrűség csomópontonként.

Hátránya:

  • Sémamódosítást igényel.
  • Alkalmazás-lekérdezés-módosításokat igényel.
  • Minden bérlőnek ugyanazt a sémát kell tartalmaznia.

Sémaalapú horizontális skálázás

A sémaalapú horizontális skálázás a megosztott adatbázis, egy különálló sémamodell, és a séma lesz az adatbázis logikai szegmense. A több-bérlős alkalmazások bérlőnként egy sémát használhatnak a bérlői dimenzió mentén történő könnyű szilánkoláshoz. A lekérdezési módosításokra nincs szükség, és az alkalmazásnak csak egy kis módosításra van szüksége a bérlőváltáskor a megfelelő search_path beállításához. A sémaalapú horizontális skálázás ideális megoldás mikroszolgáltatások és független szoftverszállítók számára olyan alkalmazások üzembe helyezéséhez, amelyek nem tudják elvégezni a soralapú horizontális skálázáshoz szükséges módosításokat.

Előnyök:

  • A bérlők heterogén sémákkal rendelkezhetnek.
  • Nincs szükség sémamódosításra.
  • Nincs szükség alkalmazás-lekérdezés-módosításra.
  • A sémaalapú horizontális skálázási SQL-kompatibilitás jobb, mint a soralapú horizontális skálázás.

Hátránya:

  • Csomópontonként kevesebb bérlő van a soralapú horizontális skálázáshoz képest.

Horizontális skálázási kompromisszumok

Sémaalapú horizontális skálázás Soralapú horizontális skálázás
Több-bérlős modell Séma elkülönítése bérlőnként Megosztott táblák bérlőazonosító-oszlopokkal
Citus-verzió 12.0+ Az összes verzió
További lépések a Vanilla PostgreSQL-hez képest Nincs, csak a konfiguráció módosítása A create_distributed_table minden táblán a > bérlőazonosító alapján oszthatja el a táblákat
Bérlők száma 1-10k 1-1 M+
Adatmodellezési követelmény Nincs idegen kulcs az elosztott sémák között Minden táblában szerepelnie kell egy bérlőazonosító oszlopnak (egy terjesztési oszlopnak, más néven horizontális kulcsnak), valamint az elsődleges kulcsokban az idegen kulcsok
Sql-követelmény egycsomópontos lekérdezésekhez Egyetlen elosztott séma használata lekérdezésenként Az illesztéseknek és a WHERE záradékoknak tartalmazniuk kell tenant_id oszlopot
Párhuzamos bérlőközi lekérdezések Nem Igen
Egyéni tábladefiníciók bérlőnként Igen Nem
Hozzáférés-vezérlés Sémaengedélyek Sémaengedélyek
Bérlők közötti adatmegosztás Igen, hivatkozástáblák használata (külön sémában) Igen, referenciatáblák használatával
Bérlő és szegmens elkülönítése Minden bérlő saját szegmenscsoporttal rendelkezik definíció szerint Adott bérlői azonosítóknak saját szegmenscsoportot adhat a isolate_tenant_to_new_shard