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

Horizontális elbontás az Azure DocumentDB-ben a skálázhatóság érdekében

Az Azure DocumentDB támogatja a horizontális skálázást az adatok és a forgalom horizontális elosztásához. A gyűjteményen belüli dokumentumok logikai szegmenseknek nevezett adattömbökre vannak osztva.

A felosztás minden gyűjtemény esetében egyénileg van definiálva a gyűjtemény dokumentumstruktúrájának kijelölt shard kulcsának használatával. Az adatok ezután adattömbökbe kerülnek, és mindegyik adattömb egy logikai partíciónak felel meg. A szegmenskulcs tulajdonság minden egyedi értékének dokumentumai ugyanabban a logikai szegmensben találhatók.

A szilánkos gyűjteménybe beszúrt összes dokumentum esetében a szegmenskulcs tulajdonság értéke kivonatolt a kijelölt logikai szegmens kiszámításához. A szolgáltatás teljes mértékben felügyeli a logikai tömbök elhelyezését és a fürtön belüli összes logikai tömb elosztását, ezzel mentesítve a felhasználót a kapcsolódó feladatoktól.

Logikai szeletek

Minden olyan dokumentum, amely ugyanazt az értéket tartalmazza a szegmenskulcshoz, ugyanahhoz a logikai szegmenshez tartozik.

Vegyük például az Alkalmazottak nevű gyűjteményt az alábbi dokumentumstruktúrával.

Ez a táblázat a szegmenskulcs értékeinek logikai partíciókra való leképezését mutatja be.

Dokumentumazonosító Töredékkulcs értéke Logikai töredék
"12345" "Steve Smith" 1. szegmens
"23456" "József, Kovács" Shard 2
"34567" "Steve Smith" 1. szegmens
"45678" "Michael Smith" 3. szegmens
"56789" "József, Kovács" 2. szegmens

  • A gyűjtemények logikai szegmenseinek száma nincs korlátozva. A gyűjtemények annyi logikai szegmenst tartalmazhatnak, mint az egyes dokumentumokban a szegmenskulcs tulajdonságának egyedi értékével rendelkező dokumentumok.

  • Egyetlen logikai szegmens méretének sincs korlátja.

  • Emellett a szolgáltatás nem korlátozza a tranzakciókat egy logikai szegmens hatókörére. Az Azure DocumentDB támogatja a több logikai szegmensre és a fürt több fizikai szegmensére vonatkozó olvasási és írási tranzakciókat.

Fizikai szegmensek

A fizikai szilánkok az adatok tartósításáért és az adatbázis-tranzakciók teljesítéséért felelős mögöttes gépek és lemezek. A logikai szegmensekkel ellentétben a szolgáltatás a fedél alatt kezeli a fizikai szegmenseket.

A fizikai szegmensek száma a fürt létrehozásakor van meghatározva, és növelhető, ha az adatbázis mérete idővel növekszik. Az önálló szegmensfürtök egyetlen fizikai szegmenst (csomópontot) használnak, amely teljes mértékben felelős a fürt tárolási és adatbázis-tranzakcióiért. A több szegmenses fürtök elosztják az adatokat és a tranzakciókötetet a fürt fizikai szegmensei között.

Logikai rekeszek leképezése fizikai rekeszekre

Új logikai szegmensek hozzáadásakor a fürt zökkenőmentesen frissíti a logikai és a fizikai szegmensek leképezését. Hasonlóképpen, a címtér hozzárendelése az egyes fizikai szegmensekhez módosul, amint új fizikai szegmensek kerülnek hozzáadásra a fürthöz, ezt követően pedig a logikai szegmensek újra kiegyensúlyozódnak a fürtön belül.

A logikai és fizikai részek leképezéséhez használt hash tartomány egyenletesen oszlik el a fürt fizikai részei között. Minden fizikai töredék egyenlő méretű vödröt birtokol a kivonattartomány egy részéből. Minden megírt dokumentum esetében a szegmenskulcs tulajdonság értéke kivonatolt, a kivonat értéke pedig meghatározza a dokumentumnak a mögöttes fizikai szegmenshez való leképezését. Belsőleg több logikai szegmens is egyetlen fizikai szegmensre van leképezve. Ezenkívül a logikai szegmensek soha nem osztódnak meg fizikai szegmensek között, és a logikai szegmensek összes dokumentuma csak egy fizikai szegmensre van leképezve.

Az előző példára épülő, két fizikai szegmenst tartalmazó fürt használatával ez a táblázat a dokumentumok fizikai szegmensekre való leképezését mutatja be.

Dokumentumazonosító Shard kulcs értéke Logikai szegmens Fizikai töredék
"12345" "Steve Smith" 1. szegmens Fizikai töredék 1
"23456" "József, Kovács" 2. szegmens Fizikai szegmens 2
"34567" "Steve Smith" 1. szegmens Fizikai szegmens 1
"45678" "Michael Smith" 3. szegmens Fizikai töredék 1
"56789" "József, Kovács" 2. szegmens Fizikai töredék 2

Fizikai szegmensek kapacitása

A fürt telepítésekor kiválasztott fürtréteg határozza meg egy fizikai szegmens processzor- és memóriakapacitását. Hasonlóképpen a tárolási termékváltozat határozza meg a fizikai szegmensek tárolási és IOPS-kapacitását. A nagyobb fürtszintek nagyobb számítási teljesítményt és nagyobb memóriát biztosítanak, míg a nagyobb tárolólemezek több tárhelyet és IOPS-t biztosítanak. Az olvasás-intenzív munkaterhelések nagyobb fürtszint előnyeit élvezik, míg az írás-intenzív munkaterhelések nagyobb tárolási SKU előnyeit élvezik. A fürtszint vertikálisan fel- és leskálázható a fürt létrehozása után az alkalmazás változó igényei alapján.

Több szegmenses fürtökben az egyes fizikai szegmensek kapacitása megegyezik. A fürtszint vagy a tárolási SKU felskálázása nem változtatja meg a logikai szeletek fizikai szeleteken való elhelyezését. A felskálázási művelet után a fizikai shardok száma változatlan marad, így elkerülhető a klaszter adatainak újraegyensúlyozása.

A fizikai szegmens számítási, memória-, tárolási és IOPS-kapacitása határozza meg a logikai szegmensekhez rendelkezésre álló erőforrásokat. Azok a szeletkulcsok, amelyek nem rendelkeznek egyenletes tárterület- és kérelemtérfogat-eloszlással, egyenetlen tárolás és átviteli sebesség fogyasztását okozhatják a fürtben. A forró partíciók a fizikai szegmensek egyenetlen kihasználtságát okozhatják, ami kiszámíthatatlan teljesítményt és átviteli sebességet eredményezhet. Így a széttagolt fürtök gondos tervezést igényelnek annak érdekében, hogy az alkalmazás követelményeinek idővel történő változásával a teljesítmény konzisztens maradjon.

Replikakészletek

Minden fizikai töredék replikák egy csoportjából áll, amelyeket replikakészletként is emlegetünk. Minden replika az adatbázismotor egy példányát üzemelteti. A replikakészletek tartóssá, magas rendelkezésre állásúvá és konzisztenssé teszik a fizikai szegmensen belüli adattárat. A fizikai szegmenst alkotó replikák öröklik a fizikai szegmens tárolási és számítási kapacitását. Az Azure DocumentDB automatikusan kezeli a replikakészleteket.

Ajánlott eljárások az adatok horizontális felosztásához

  • Az Azure DocumentDB-ben nincs szükség shardolásra, hacsak a kollekció tárolási és tranzakciós térfogata nem lépi túl egyetlen fizikai shard kapacitását. A szolgáltatás például shardonként 32 TB lemezt biztosít. Ha egy gyűjteményhez 32 TB-nál többre van szükség, akkor szeletelni kell.

  • Nem szükséges egy több fizikai shardot tartalmazó klaszter összes gyűjteményét shard-olni. Szeletelt és nem szeletelt gyűjtemények ugyanabban a fürtben együtt létezhetnek. A szolgáltatás optimálisan osztja el a fürtön belüli gyűjteményeket, hogy a fürt számítási és tárolási erőforrásait a lehető leg egyenletesen kihasználja.

  • A nehéz alkalmazások olvasásához a szegmenskulcsot a leggyakoribb lekérdezési minták alapján kell kiválasztani. A gyűjtemény leggyakrabban használt lekérdezésszűrőjét szilánkkulcsként kell kiválasztani az adatbázis-tranzakciók legnagyobb százalékának optimalizálásához a keresés egyetlen fizikai szegmensre való honosításával.

  • A nagy írási terhelésű alkalmazások esetében, ahol az írási teljesítmény fontosabb az olvasásnál, egy szegmenskulcsot kell választani az adatok fizikai szegmensek közötti egyenletes elosztásához. A legnagyobb számosságú partíció kulcsok lehetővé teszik a lehető legegyenletesebb eloszlást.

  • Az optimális teljesítmény érdekében a logikai szegmensek tárolási méretének 4 TB-nál kisebbnek kell lennie.

  • Az optimális teljesítmény érdekében a logikai szegmenseket egyenletesen el kell osztani a tárolásban és a kérések volumenét a klaszter fizikai szegmensei között.

Gyűjtemény horizontális felosztása

Vegye figyelembe a következő dokumentumot a "cosmicworks" adatbázisban és az "employee" gyűjteményben

{
    "firstName": "Steve",
    "lastName": "Smith",
    "companyName": "Microsoft",
    "division": "Azure",
    "subDivision": "Data & AI",
    "timeInOrgInYears": 7
}

Az alábbi minta a cosmicworks adatbázisban lévő alkalmazotti gyűjteményt a firstName mező alapján szilánkokra bontja.

use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})

A gyűjtemény egy rendszergazdai paranccsal is skálázható:

use cosmicworks;
db.adminCommand({
  "shardCollection": "cosmicworks.employee",
  "key": {"firstName": "hashed"}
})

Bár nem ideális, hogy a shard kulcsot módosítsuk, miután a gyűjtemény tárterületének mérete jelentősen megnőtt, a reshardCollection paranccsal módosíthatja a shard kulcsot.

use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})

A gyűjtemény egy rendszergazdai paranccsal is újraszilárdulhat:

use cosmicworks;
db.adminCommand({
  "reshardCollection": "cosmicworks.employee",
  "key": {"lastName": "hashed"}
})

A bevált módszer szerint indexet kell létrehozni a shard kulcs tulajdonságon.

use cosmicworks;
db.runCommand({
  createIndexes: "employee",
  indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
  blocking: true
})

Következő lépések

Az Azure DocumentDB migrálási lehetőségei

  • Last updated on