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

Terjesztési oszlopok kiválasztása az Azure Cosmos DB for PostgreSQL-ben

  • Cikk

A KÖVETKEZŐKRE VONATKOZIK: Azure Cosmos DB for PostgreSQL (a Citus adatbázisbővítménye a PostgreSQL-re)

Az egyes táblák elosztási oszlopának kiválasztása az egyik legfontosabb modellezési döntés. Az Azure Cosmos DB for PostgreSQL szegmensekben tárolja a sorokat a sorok terjesztési oszlopának értéke alapján.

A megfelelő választási lehetőség a kapcsolódó adatokat ugyanazon a fizikai csomóponton csoportosítja, ami gyorsabbá teszi a lekérdezéseket, és támogatja az ÖSSZES SQL-funkciót. Helytelen választás esetén a rendszer lassan fut.

Általános tippek

Az alábbi négy kritérium alapján választhatja ki az elosztott táblák ideális terjesztési oszlopát.

  1. Válasszon egy oszlopot, amely az alkalmazás számítási feladatainak központi része.

    Erre az oszlopra úgy gondolhat, mint a "szív", a "központi darab" vagy az adatok particionálásának természetes dimenziója.

    Példák:

    • device_id IoT-számítási feladatban
    • security_id olyan pénzügyi alkalmazás esetében, amely nyomon követi az értékpapírokat
    • user_id felhasználói elemzésekben
    • tenant_id több-bérlős SaaS-alkalmazáshoz

  2. Válasszon egy tisztességes számosságot és egyenletes statisztikai eloszlású oszlopot.

    Az oszlopnak sok értékkel kell rendelkeznie, és alaposan és egyenletesen el kell osztania az összes szegmens között.

    Példák:

    • Több mint 1000 számosság
    • Ne válasszon olyan oszlopot, amely a sorok nagy százalékában azonos értékkel rendelkezik (adateltérés)
    • Egy SaaS-számítási feladat esetén, ha egy bérlő sokkal nagyobb a többinél, az adateltéréshez vezethet. Ebben a helyzetben a bérlői elkülönítés használatával létrehozhat egy dedikált szegmenst a bérlő kezeléséhez.

  3. Válasszon ki egy olyan oszlopot, amely a meglévő lekérdezések előnyeit élvezi.

    Tranzakciós vagy üzemeltetési számítási feladatok esetén (ahol a legtöbb lekérdezés csak néhány ezredmásodpercet vesz igénybe), válasszon egy oszlopot, amely szűrőként WHERE jelenik meg a lekérdezések legalább 80%-ának záradékaiban. Az oszlop például a device_id következőben található SELECT * FROM events WHERE device_id=1: .

    Az elemzési számítási feladatokhoz (ahol a legtöbb lekérdezés 1–2 másodpercet vesz igénybe) válasszon egy oszlopot, amely lehetővé teszi a lekérdezések párhuzamosságát a feldolgozó csomópontok között. Egy oszlop például gyakran előfordul a GROUP BY záradékokban, vagy egyszerre több értéket kérdez le.

  4. Válasszon egy oszlopot, amely a nagy táblák többségében található.

    Az 50 GB-nál nagyobb táblákat el kell osztani. Ha mindegyikhez ugyanazt a terjesztési oszlopot választja, a munkavégző csomópontokon közösen keresheti meg az oszlop adatait. A közös hely hatékonyabbá teszi a JOIN-k és az összesítők futtatását, valamint az idegen kulcsok kikényszerítését.

    A többi (kisebb) tábla lehet helyi vagy referenciatábla. Ha a kisebb táblának elosztott táblákkal kell CSATLAKOZNIa, készítsen referenciatáblázatot.

Példák a használati esetekre

Általános kritériumokat láttunk a terjesztési oszlop kiválasztásához. Most lássuk, hogyan alkalmazhatók a gyakori használati esetekre.

Több-bérlős alkalmazások

A több-bérlős architektúra hierarchikus adatbázismodellezéssel osztja el a lekérdezéseket a fürt csomópontjai között. Az adathierarchia tetejét bérlőazonosítónak nevezzük, és minden táblában egy oszlopban kell tárolni.

Az Azure Cosmos DB for PostgreSQL a lekérdezéseket vizsgálja meg annak megtekintéséhez, hogy melyik bérlőazonosítót foglalja magában, és megkeresi a megfelelő táblaszegélyt. A lekérdezést egyetlen feldolgozó csomópontra irányítja, amely a szegmenst tartalmazza. Az ugyanazon a csomóponton elhelyezett összes releváns adattal rendelkező lekérdezést kolocationnak nevezzük.

Az alábbi ábra a több-bérlős adatmodellben való elhelyezést szemlélteti. Két táblát, fiókokat és kampányokat tartalmaz, amelyeket a program terjeszt.account_id Az árnyékolt mezők szegmenseket jelölnek. A zöld szegmensek együtt vannak tárolva egy feldolgozó csomóponton, a kék szegmensek pedig egy másik munkavégző csomóponton. Figyelje meg, hogy a fiókok és kampányok közötti illesztési lekérdezések az összes szükséges adatot együtt tartalmazzák egy csomóponton, ha mindkét tábla ugyanarra a account_id korlátozódik.

Több-bérlős elhelyezés

Ha saját sémájában szeretné alkalmazni ezt a tervet, azonosítsa, hogy mi minősül bérlőnek az alkalmazásban. Gyakori példa erre a cég, a fiók, a szervezet vagy az ügyfél. Az oszlop neve a következőhöz hasonló company_id lesz: vagy customer_id. Vizsgálja meg az egyes lekérdezéseket, és kérdezze meg magától, hogy működik-e, ha több WHERE záradékkal korlátozná az összes érintett táblát ugyanazzal a bérlőazonosítóval rendelkező sorokra? A több-bérlős modellben lévő lekérdezések hatóköre egy bérlőre terjed ki. Az értékesítéssel vagy leltárral kapcsolatos lekérdezések hatóköre például egy adott tárolón belül van.

Ajánlott eljárások

  • Táblák elosztása egy közös tenant_id oszlop szerint. Például egy olyan SaaS-alkalmazásban, ahol a bérlők vállalatok, a tenant_id valószínűleg a company_id.
  • Kis bérlőközi táblák átalakítása referenciatáblákká. Ha több bérlő osztozik egy kis információtáblán, ossza el referenciatáblázatként.
  • Az összes alkalmazás-lekérdezés szűrésének korlátozása tenant_id szerint. Minden lekérdezésnek egyszerre egy bérlő adatait kell kérnie.

Olvassa el a több-bérlős oktatóanyagot , amely bemutatja, hogyan hozhat létre ilyen típusú alkalmazást.

Valós idejű alkalmazások

A több-bérlős architektúra hierarchikus struktúrát vezet be, és adat-elhelyezést használ a lekérdezések bérlőnkénti irányításához. Ezzel szemben a valós idejű architektúrák az adataik adott terjesztési tulajdonságaitól függenek a magas párhuzamos feldolgozás érdekében.

Az "entitásazonosítót" a valós idejű modell terjesztési oszlopainak kifejezéseként használjuk. Jellemző entitások a felhasználók, gazdagépek vagy eszközök.

A valós idejű lekérdezések általában dátum vagy kategória szerint csoportosított numerikus aggregátumokat kérnek. Az Azure Cosmos DB for PostgreSQL elküldi ezeket a lekérdezéseket az egyes szegmenseknek részleges eredményekért, és összeállítja a végső választ a koordinátor csomópontján. A lekérdezések akkor futnak a leggyorsabban, ha a lehető legtöbb csomópont járul hozzá, és ha egyetlen csomópontnak sem kell aránytalanul nagy mennyiségű munkát végeznie.

Ajánlott eljárások

  • Válasszon egy magas számosságú oszlopot terjesztési oszlopként. Összehasonlításként a rendeléstáblák Állapot mezője az Új, a Fizetős és a Szállítási értékekkel nem megfelelő választás a terjesztési oszlopban. Csak azt a néhány értéket feltételezi, amely korlátozza az adatokat tároló szegmensek számát és a feldolgozható csomópontok számát. A magas számosságú oszlopok között érdemes kiválasztani azokat az oszlopokat is, amelyeket gyakran használnak csoportosítási záradékokban vagy illesztési kulcsként.
  • Válasszon egy páros eloszlású oszlopot. Ha egy táblát egy olyan oszlopon oszt el, amely bizonyos gyakori értékekhez van elosztva, a táblában lévő adatok általában bizonyos szegmensekben halmozódnak fel. A szegmenseket tartalmazó csomópontok végül több munkát végeznek, mint más csomópontok.
  • Tény- és dimenziótáblák elosztása a közös oszlopokon. A ténytábla csak egy terjesztési kulccsal rendelkezhet. A másik kulcshoz csatlakozó táblák nem lesznek együtt a ténytáblával. Válasszon ki egy dimenziót, amely az illesztés gyakorisága és az illesztési sorok mérete alapján van kiválasztva.
  • Néhány dimenziótáblát referenciatáblákká alakít. Ha egy dimenziótáblát nem lehet a ténytáblával együtt áthelyezni, a dimenziótábla másolatainak a referenciatábla formájában az összes csomópontra való elosztásával javíthatja a lekérdezési teljesítményt.

Olvassa el a valós idejű irányítópult-oktatóanyagot , amely bemutatja, hogyan hozhat létre ilyen típusú alkalmazásokat.

Idősoradatok

Egy idősoros számítási feladatban az alkalmazások lekérdezik a legutóbbi információkat, miközben régi információkat archiválnak.

Az azure Cosmos DB for PostgreSQL-ben az idősoradatok modellezésének leggyakoribb hibája az időbélyeg használata terjesztési oszlopként. Az időalapú kivonateloszlás látszólag véletlenszerűen osztja el az időtartományokat különböző szegmensekbe ahelyett, hogy az időtartományokat szegmensekben tartanák. Az időt tartalmazó lekérdezések általában időtartományokra hivatkoznak, például a legfrissebb adatokra. Az ilyen típusú kivonateloszlás hálózati többletterheléshez vezet.

Ajánlott eljárások

  • Ne válasszon időbélyeget terjesztési oszlopként. Válasszon másik terjesztési oszlopot. Több-bérlős alkalmazásokban használja a bérlőazonosítót, vagy valós idejű alkalmazásban használja az entitásazonosítót.
  • Használja inkább a PostgreSQL-tábla particionálását. Táblaparticionálással az időrendbe rendezett adatok nagy tábláját több öröklődő táblára bonthatja, és mindegyik tábla különböző időtartományokat tartalmaz. A Postgres-particionált táblák elosztása szegmenseket hoz létre az örökölt táblákhoz.

Következő lépések