Több-bérlős SaaS-adatbázis bérlői mintái
A következőre vonatkozik:
Azure SQL Database
Ez a cikk a több-bérlős SaaS-alkalmazásokhoz elérhető bérlői modelleket ismerteti.
Több-bérlős SaaS-alkalmazás tervezésekor gondosan ki kell választania az alkalmazás igényeinek leginkább megfelelő bérlői modellt. A bérlői modell határozza meg, hogy az egyes bérlők adatai hogyan lesznek leképezve a tárolóra. A bérlői modell kiválasztása hatással van az alkalmazások tervezésére és felügyeletére. Néha költséges később másik modellre váltani.
V. SaaS-fogalmak és terminológia
A Szolgáltatott szoftver (SaaS) modellben a vállalat nem ad el licenceket a szoftvernek. Ehelyett minden ügyfél bérleti díjat fizet a vállalatának, így minden ügyfél a vállalat bérlője lesz.
A bérleti díjért cserébe minden bérlő hozzáférést kap az SaaS-alkalmazás összetevőihez, és az adatai az SaaS rendszerben vannak tárolva.
A bérlői modell a bérlők tárolt adatainak rendszerezését jelenti:
- Egybérlős: Minden adatbázis csak egy bérlőtől tárol adatokat.
- Több-bérlős: Minden adatbázis több különálló bérlő adatait tárolja (az adatvédelmet biztosító mechanizmusokkal).
- Hibrid bérlői modellek is elérhetők.
B. A megfelelő bérlői modell kiválasztása
A bérlői modell általában nem befolyásolja az alkalmazás működését, de valószínűleg hatással van a teljes megoldás egyéb aspektusaira. Az egyes modellek értékeléséhez a következő kritériumok szolgálnak:
Méretezhetőség:
- Bérlők száma.
- Tárterület bérlőnként.
- Tárolás összesítve.
- Munkateher.
Bérlői elkülönítés: Adatelkülönítés és teljesítmény (hogy az egyik bérlő számítási feladatai hatással vannak-e másokra).
Bérlőnkénti költség: Adatbázis költségei.
A fejlesztés összetettsége:
- Sémamódosítások.
- Lekérdezések módosítása (a minta megköveteli).
Működési összetettség:
- A teljesítmény monitorozása és kezelése.
- Sémakezelés.
- Bérlő visszaállítása.
- Vészhelyreállítás
Testreszabhatóság: A séma testreszabásának egyszerű támogatása, amely bérlőspecifikus vagy bérlői osztályspecifikus.
A bérlői vitafórum az adatrétegre összpontosít. De fontolja meg egy pillanatra az alkalmazásréteget . Az alkalmazásréteg monolitikus entitásként van kezelve. Ha az alkalmazást sok kis összetevőre osztja, a bérlői modell választása változhat. Egyes összetevőket másként kezelhet, mint a többit mind a bérlői, mind a használt tárolási technológiával vagy platformmal kapcsolatban.
C. Önálló egybérlős alkalmazás egybérlős adatbázissal
Alkalmazásszintű elkülönítés
Ebben a modellben a teljes alkalmazás minden bérlőre egyszer települ. Az alkalmazás minden példánya önálló példány, így soha nem lép kapcsolatba más különálló példányokkal. Az alkalmazás minden példányának csak egy bérlője van, ezért csak egy adatbázisra van szüksége. A bérlő saját adatbázissal rendelkezik.
Minden alkalmazáspéldány külön Azure-erőforráscsoportban van telepítve. Az erőforráscsoport olyan előfizetéshez tartozhat, amely a szoftverszállító vagy a bérlő tulajdonában van. Mindkét esetben a szállító kezelheti a bérlő szoftverét. Minden alkalmazáspéldány úgy van konfigurálva, hogy csatlakozzon a megfelelő adatbázishoz.
Minden bérlői adatbázis egyetlen adatbázisként van üzembe helyezve. Ez a modell biztosítja a legnagyobb adatbázis-elkülönítést. Az elkülönítéshez azonban elegendő erőforrást kell lefoglalni az egyes adatbázisokhoz a maximális terhelés kezeléséhez. Itt nem számít, hogy a rugalmas készletek nem használhatók a különböző erőforráscsoportokban vagy különböző előfizetésekben üzembe helyezett adatbázisokhoz. Ez a korlátozás teszi ezt az önálló egybérlős alkalmazásmodellt a legdrágább megoldássá az adatbázis teljes költség szempontjából.
Szállítók kezelése
A szállító akkor is hozzáférhet az összes önálló alkalmazáspéldány adatbázisaihoz, ha az alkalmazáspéldányok különböző bérlői előfizetésekben vannak telepítve. A hozzáférés SQL-kapcsolatokon keresztül érhető el. Ez a többpéldányos hozzáférés lehetővé teszi a szállító számára, hogy központosítsa a sémakezelést és az adatbázisközi lekérdezéseket jelentéskészítési vagy elemzési célokra. Ha ilyen központosított felügyeletre van szükség, olyan katalógust kell üzembe helyezni, amely leképezi a bérlői azonosítókat az adatbázis URI-jaira. Az Azure SQL Database egy skálázási kódtárat biztosít, amelyet együtt használnak a katalógusok biztosításához. A horizontálisan horizontálisan horizontálisan elnevezett kódtár hivatalosan Elastic Database-ügyféloldali kódtár.
D. Több-bérlős alkalmazás bérlőnkénti adatbázissal
Ez a következő minta egy több-bérlős alkalmazást használ, amely számos adatbázissal rendelkezik, és mindegyik egy-bérlős adatbázis. Minden új bérlőhöz új adatbázis van kiépítve. Az alkalmazásszint vertikálisan felskálázható csomópontonként további erőforrások hozzáadásával. Vagy az alkalmazás horizontális felskálázása további csomópontok hozzáadásával történik. A skálázás számítási feladaton alapul, és független az egyes adatbázisok számától vagy méretétől.
Bérlő testreszabása
Az önálló alkalmazásmintához hasonlóan az egybérlős adatbázisok használata is erős bérlői elkülönítést biztosít. Minden olyan alkalmazásban, amelynek modellje csak egy-bérlős adatbázisokat határoz meg, az adott adatbázis sémája testre szabható és optimalizálható a bérlőhöz. Ez a testreszabás nem érinti az alkalmazás többi bérlőit. Előfordulhat, hogy a bérlőknek az összes bérlő által igényelt alapvető adatmezőn túli adatokra is szükségük lehet. Emellett előfordulhat, hogy a további adatmezőnek indexre van szüksége.
A bérlőnkénti adatbázissal egyszerűen testre szabható egy vagy több különálló bérlő sémája. Az alkalmazás szállítójának olyan eljárásokat kell megterveznie, amelyek nagy léptékben kezelik a séma testreszabásait.
Rugalmas készletek
Amikor az adatbázisok ugyanabban az erőforráscsoportban vannak üzembe helyezve, rugalmas készletekbe csoportosíthatók. A készletek költséghatékony módon osztják meg az erőforrásokat számos adatbázisban. Ez a készletbeállítás olcsóbb, mint az, ha minden adatbázisnak elég nagynak kell lennie ahhoz, hogy megfeleljen az általa tapasztalt használati csúcsoknak. Annak ellenére, hogy a készletezett adatbázisok közösen férnek hozzá az erőforrásokhoz, továbbra is magas szintű teljesítményelkülönítést érhetnek el.
Az Azure SQL Database biztosítja a megosztás konfigurálásához, monitorozásához és kezeléséhez szükséges eszközöket. A készletszintű és az adatbázisszintű teljesítménymetrikák az Azure Portalon és az Azure Monitor-naplókon keresztül is elérhetők. A metrikák nagyszerű betekintést nyújtanak az összesítő és a bérlőspecifikus teljesítménybe is. Az egyes adatbázisok áthelyezhetők a készletek között, hogy fenntartott erőforrásokat biztosítsanak egy adott bérlőnek. Ezek az eszközök lehetővé teszik a jó teljesítmény költséghatékony biztosítását.
Üzemeltetési skálázás bérlőnkénti adatbázishoz
Az Azure SQL Database számos felügyeleti funkcióval rendelkezik, amelyek nagy méretű adatbázisok, például több mint 100 000 adatbázis kezelésére szolgálnak. Ezek a funkciók teszik elfogadhatóvá az adatbázis bérlőnkénti mintáját.
Tegyük fel például, hogy egy rendszer egyetlen adatbázisa egy 1000 bérlős adatbázis. Az adatbázis 20 indexet tartalmazhat. Ha a rendszer 1000 egybérlős adatbázissá alakul át, az indexek mennyisége 20 000-re nő. Az Automatikus finomhangolás részeként az Azure SQL Database-ben alapértelmezés szerint engedélyezve vannak az automatikus indexelési funkciók. Az automatikus indexelés mind a 20 000 indexet és azok folyamatos létrehozási és elvetési optimalizálását kezeli. Ezek az automatizált műveletek egy adott adatbázisban történnek, és más adatbázisok hasonló műveletei nem koordinálják vagy korlátozzák őket. Az automatikus indexelés másként kezeli az indexeket egy foglalt adatbázisban, mint egy kevésbé foglalt adatbázisban. Az indexkezelés ilyen típusú testreszabása nem lenne praktikus az adatbázis-bérlőnkénti skálán, ha ezt a hatalmas felügyeleti feladatot manuálisan kellene elvégezni.
A méretezhető egyéb felügyeleti funkciók közé tartoznak a következők:
- Beépített biztonsági másolatok.
- Magas rendelkezésre állás.
- Lemezen történő titkosítás.
- Teljesítménytelemetria.
Automatizálás
A felügyeleti műveletek egy devops-modellen keresztül szkriptelhetők és ajánlhatók fel. A műveletek automatizálhatók és közzétehetők az alkalmazásban.
Automatizálhatja például egy bérlő helyreállítását egy korábbi időpontra. A helyreállításnak csak a bérlőt tároló egyetlen bérlős adatbázist kell visszaállítania. Ez a visszaállítás nincs hatással a többi bérlőre, ami megerősíti, hogy a felügyeleti műveletek az egyes bérlők részletes szintjén vannak.
E. Több-bérlős alkalmazás több-bérlős adatbázisokkal
Egy másik elérhető minta a több-bérlős adatbázisokban lévő bérlők tárolása. Az alkalmazáspéldány tetszőleges számú több-bérlős adatbázissal rendelkezhet. A több-bérlős adatbázisok sémájának egy vagy több bérlőazonosító oszlopot kell tartalmaznia, hogy az adott bérlő adatai szelektíven lekérhetők legyenek. Emellett előfordulhat, hogy a séma néhány táblát vagy oszlopot igényel, amelyeket csak a bérlők egy részhalmaza használ. A statikus kód- és referenciaadatok tárolása azonban csak egyszer történik, és az összes bérlő megosztja őket.
A bérlői elkülönítés feláldozva
Adatok: A több-bérlős adatbázisok szükségszerűen feláldozzák a bérlői elkülönítést. Több bérlő adatait egy adatbázisban tárolja a rendszer. A fejlesztés során győződjön meg arról, hogy a lekérdezések soha nem tehetnek közzé több bérlőtől származó adatokat. Az SQL Database támogatja a sorszintű biztonságot, amely kikényszerítheti, hogy a lekérdezésből visszaadott adatok hatóköre egyetlen bérlőre terjedjen ki.
Feldolgozás: A több-bérlős adatbázisok számítási és tárolási erőforrásokat osztanak meg az összes bérlőjén. Az adatbázis egésze nyomon követhető, hogy elfogadhatóan működik-e. Az Azure-rendszer azonban nem rendelkezik beépített módon ezeknek az erőforrásoknak az egyes bérlők általi monitorozására vagy kezelésére. Ezért a több-bérlős adatbázis nagyobb kockázattal jár, ha zajos szomszédokkal találkozik, ahol az egyik túlaktív bérlő számítási feladatai hatással vannak az ugyanabban az adatbázisban lévő többi bérlő teljesítményére. További alkalmazásszintű monitorozás figyelheti a bérlői szintű teljesítményt.
Alacsonyabb költségek
A bérlőnkénti legalacsonyabb költség általában a több-bérlős adatbázisoké. Egyetlen adatbázis erőforrásköltségei alacsonyabbak, mint egy egyenértékű méretű rugalmas készlet esetében. Emellett az olyan forgatókönyvek esetében, ahol a bérlőknek csak korlátozott tárterületre van szükségük, akár több millió bérlő is tárolható egyetlen adatbázisban. Egyetlen rugalmas készlet sem tartalmazhat több millió adatbázist. Egy készletenként 1000 adatbázist tartalmazó, 1000 készletet tartalmazó megoldás azonban elérheti a milliós nagyságrendet, és fennáll a veszélye annak, hogy a kezelés nem megfelelő.
A több-bérlős adatbázismodellek két változatát az alábbiakban tárgyaljuk, a horizontálisan tagolt több-bérlős modell a legrugalmasabb és skálázhatóbb.
F. Több-bérlős alkalmazás egyetlen több-bérlős adatbázissal
A legegyszerűbb több-bérlős adatbázisminta egyetlen adatbázist használ az összes bérlő adatainak tárolására. A további bérlők hozzáadásakor az adatbázis felskálázódik több tárolási és számítási erőforrással. Ez a vertikális felskálázás lehet minden, amire szükség lehet, bár mindig van egy végső méretezési korlát. Azonban jóval a korlát elérése előtt az adatbázis nem lesz kezelhető.
Az egyes bérlőkre összpontosító felügyeleti műveletek összetettebbek a több-bérlős adatbázisokban való implementáláshoz. És nagy léptékben ezek a műveletek elfogadhatatlanul lassúak lehetnek. Ilyen például az adatok időponthoz kötött visszaállítása egyetlen bérlő esetében.
G. Több-bérlős alkalmazás horizontális több-bérlős adatbázisokkal
A legtöbb SaaS-alkalmazás egyszerre csak egy bérlő adatait éri el. Ez a hozzáférési minta lehetővé teszi, hogy a bérlői adatok több adatbázis vagy szegmens között legyenek elosztva, ahol minden bérlő összes adata egy szegmensben található. Több-bérlős adatbázismintával kombinálva a horizontális modell szinte korlátlan skálázást tesz lehetővé.
Szegmensek kezelése
A horizontális skálázás összetettebbé teszi mind a tervezést, mind az üzemeltetési felügyeletet. A bérlők és adatbázisok közötti leképezés fenntartásához katalógus szükséges. Emellett felügyeleti eljárásokra is szükség van a szegmensek és a bérlői populáció kezeléséhez. Az eljárásokat például szegmensek hozzáadására és eltávolítására, valamint a bérlői adatok szegmensek közötti áthelyezésére kell tervezni. A skálázás egyik módja egy új szegmens hozzáadása és új bérlőkkel való feltöltése. Máskor egy sűrűn lakott szegmenst két kevésbé sűrűn lakott szegmensre oszthat fel. Miután több bérlőt áthelyeztek vagy megszüntettek, egyesítheti a ritkán lakott szegmenseket. Az egyesítés költséghatékonyabb erőforrás-kihasználtságot eredményezne. A bérlők a szegmensek között is áthelyezhetők a számítási feladatok kiegyensúlyozása érdekében.
Az SQL Database egy felosztási/egyesítési eszközt biztosít, amely együttműködik a horizontális skálázási kódtárral és a katalógusadatbázissal. A megadott alkalmazás feloszthatja és egyesítheti a szegmenseket, és áthelyezheti a bérlői adatokat a szegmensek között. Az alkalmazás ezen műveletek során a katalógust is fenntartja, és az érintett bérlőket offline állapotúként jelöli meg az áthelyezés előtt. Az áthelyezés után az alkalmazás újra frissíti a katalógust az új leképezéssel, és újra online állapotba helyezi a bérlőt.
Kisebb adatbázisok könnyebben kezelhetők
A bérlők több adatbázis közötti elosztásával a több-bérlős több-bérlős megoldás kisebb, könnyebben felügyelt adatbázisokat eredményez. Ha például egy adott bérlőt egy korábbi időpontra állít vissza, az egyetlen kisebb adatbázis biztonsági másolatból való visszaállítását igényli, nem pedig egy nagyobb adatbázist, amely az összes bérlőt tartalmazza. Az adatbázis mérete és az adatbázisonkénti bérlők száma kiválasztható a számítási feladatok és a felügyeleti erőfeszítések egyensúlyának érdekében.
Bérlőazonosító a sémában
A használt horizontális skálázási módszertől függően további korlátozások léphetnek fel az adatbázissémára. Az SQL Database felosztási/egyesítési alkalmazásához szükség van arra, hogy a séma tartalmazza a horizontális skálázási kulcsot, amely általában a bérlőazonosító. A bérlőazonosító az összes szegmenses tábla elsődleges kulcsának első eleme. A bérlőazonosító lehetővé teszi, hogy a felosztási/egyesítési alkalmazás gyorsan megkeresse és áthelyezhesse az adott bérlőhöz társított adatokat.
Rugalmas készlet szegmensekhez
A horizontálisan megosztott több-bérlős adatbázisok rugalmas készletekbe helyezhetők. Általánosságban elmondható, hogy sok egybérlős adatbázis használata egy készletben ugyanolyan költséghatékony, mint néhány több-bérlős adatbázisban lévő bérlő. A több-bérlős adatbázisok akkor előnyösek, ha nagy számú viszonylag inaktív bérlő van.
H. Hibrid szegmenses több-bérlős adatbázismodell
A hibrid modellben minden adatbázis rendelkezik a bérlőazonosítóval a sémában. Az adatbázisok egyszerre több bérlő tárolására is képesek, és az adatbázisok horizontálisan skálázhatók. Tehát a séma szempontjából ezek mind több-bérlős adatbázisok. A gyakorlatban azonban ezen adatbázisok némelyike csak egy bérlőt tartalmaz. Ettől függetlenül az adott adatbázisban tárolt bérlők mennyisége nincs hatással az adatbázis sémájára.
Bérlők áthelyezése
Egy adott bérlőt bármikor áthelyezhet a saját több-bérlős adatbázisába. Bármikor meggondolhatja magát, és visszateheti a bérlőt egy több bérlőt tartalmazó adatbázisba. Az új adatbázis kiépítésekor bérlőt is hozzárendelhet az új egybérlős adatbázishoz.
A hibrid modell akkor ragyog, ha nagy különbségek vannak az azonosítható bérlőcsoportok erőforrás-igényei között. Tegyük fel például, hogy az ingyenes próbaverzióban részt vevő bérlők nem garantálják ugyanazt a magas teljesítményt, mint a bérlők előfizetése. Előfordulhat, hogy a szabályzat az ingyenes próbaidőszakban lévő bérlők számára egy több-bérlős adatbázisban lesz tárolva, amely az összes ingyenes próbaverziós bérlő között meg van osztva. Ha egy ingyenes próbaverziós bérlő előfizet az alapszintű szolgáltatási szintre, a bérlő áthelyezhető egy másik több-bérlős adatbázisba, amely kevesebb bérlővel rendelkezhet. A Prémium szolgáltatási szintért fizető előfizetőt áthelyezheti saját új egybérlős adatbázisába.
Készletek
Ebben a hibrid modellben az előfizető bérlők egybérlős adatbázisai erőforráskészletekbe helyezhetők, így csökkenthetők az adatbázis bérlőnkénti költségei. Ez a bérlőnkénti adatbázismodellben is megtörténik.
I. Bérlői modellek összehasonlítva
Az alábbi táblázat a fő bérlői modellek közötti különbségeket foglalja össze.
| Mérés | Önálló alkalmazás | Adatbázis bérlőnként | Horizontális több-bérlős |
|---|---|---|---|
| Méretezés | Medium 1-100-ás |
Nagyon magas 1-100 000-et |
Korlátlan 1-1 000 000s |
| Bérlői elkülönítés | Nagyon magas | Magas | Alacsony; kivéve az egyetlen bérlőt (amely egyedül van egy MT db-ben). |
| Adatbázis költsége bérlőnként | Magas; csúcsokhoz méretezve van. | Alacsony; használt készletek. | A legalacsonyabb, az MT DBs-ekben lévő kis bérlők esetében. |
| Teljesítményfigyelés és -kezelés | Csak bérlőnként | Összesítés + bérlőnként | Összesített; bár bérlőnkénti, csak egyes felhasználók esetén. |
| A fejlesztés összetettsége | Alacsony | Alacsony | Közepes; skálázás miatt. |
| Működési összetettség | Alacsony-Magas. Egyedileg egyszerű, összetett, nagy léptékű. | Alacsony közepes. A minták nagy léptékben kezelik az összetettségeket. | Alacsony-Magas. Az egyéni bérlőkezelés összetett. |