A globálisok kincses kardok az adatok tárolására. fák. 2. rész

Első lépések – lásd az 1. részt.

3. A szerkezetek változatai globalok használatakor

Egy struktúrának, például egy rendezett fának számos speciális esete van. Nézzük azokat, amelyek gyakorlati értékkel bírnak a globálisokkal való munka során.

3.1 Speciális eset 1. Egy csomópont elágazás nélkül

A globálisokat nem csak tömbként, hanem reguláris változóként is használhatjuk. Például számlálóként:

Set ^counter = 0  ; установка счётчика
Set id=$Increment(^counter) ;  атомарное инкрементирование

Ebben az esetben a globálisnak a jelentése mellett ágai is lehetnek. Az egyik nem zárja ki a másikat.

3.2 Speciális eset 2. Egy csúcs és sok elágazás

Általában ez egy klasszikus kulcs-érték alap. És ha értékként mentünk egy sor értéket, akkor egy nagyon közönséges táblát kapunk elsődleges kulccsal.

A globális táblázatok megvalósításához magunknak kell sorokat generálnunk az oszlopértékekből, majd az elsődleges kulcs segítségével el kell mentenünk őket a globálisba. Ahhoz, hogy a karakterláncot olvasás közben ismét oszlopokra bontsa, a következőket használhatja:

1. határoló karakterek.

   Set ^t(id1) = "col11/col21/col31"
   Set ^t(id2) = "col12/col22/col32"

2. merev séma, amelyben minden mező előre meghatározott számú bájtot foglal el. Ahogy a relációs adatbázisokban teszik.
3. egy speciális $LB függvény (elérhető a gyorsítótárban), amely értéksort hoz létre.

   Set ^t(id1) = $LB("col11", "col21", "col31")
   Set ^t(id2) = $LB("col12", "col22", "col32")

Érdekes módon nem nehéz a globalokat használni a relációs adatbázisok másodlagos indexeihez hasonló dolgokra. Nevezzük az ilyen indexstruktúrákat globálisnak. A globális index egy segédfa olyan mezők gyors keresésére, amelyek nem részei a fő globális elsődleges kulcsának. Kitöltéséhez és használatához további kódot kell írni.

Hozzon létre egy globális indexet az első oszlopban.

Set ^i("col11", id1) = 1
Set ^i("col12", id2) = 1

Most, hogy gyorsan kereshessünk információkat az első oszlopban, a globálisba kell tekintenünk ^i és keresse meg az első oszlop kívánt értékének megfelelő elsődleges kulcsokat (id).

Érték beszúrásakor azonnal létrehozhatjuk a szükséges mezők értékét és index-globálisát is. A megbízhatóság érdekében pedig csomagoljuk be az egészet egy tranzakcióba.

TSTART
Set ^t(id1) = $LB("col11", "col21", "col31")
Set ^i("col11", id1) = 1
TCOMMIT

Részletek az M-en, hogyan kell csinálni táblázatok a globálisokról, másodlagos indexek emulációja.

Az ilyen táblák ugyanolyan gyorsan működnek, mint a hagyományos adatbázisokban (vagy még gyorsabban), ha a sorok beszúrásának/frissítésének/törlésének függvényei COS/M-ben vannak megírva és lefordítva.Ezt az utasítást tömeges INSERT és SELECT tesztekkel ellenőriztem egy kétoszlopos táblában, beleértve a TSTART és TCOMMIT parancsokat (tranzakciókat).

Nem teszteltem bonyolultabb forgatókönyveket egyidejű hozzáféréssel és párhuzamos tranzakciókkal.

A tranzakciók használata nélkül a beillesztési arány 778 361 beszúrás/másodperc volt millió értékenként.
300 millió értékkel - 422 141 betét/másodperc.

Tranzakciók használatakor - 572 082 betét/másodperc 50 millió beszúrás esetén. Minden műveletet a lefordított M kódból hajtottak végre.
A merevlemezek normálak, nem az SSD. RAID5 visszaírással. Phenom II 1100T processzor.

Egy SQL-adatbázis hasonló módon történő teszteléséhez meg kell írnia egy tárolt eljárást, amely ciklusban hajtja végre a beszúrásokat. A MySQL 5.5 (InnoDB tárhely) tesztelésekor ezzel a módszerrel másodpercenként legfeljebb 11 XNUMX beillesztést kaptam.
Igen, a táblák megvalósítása globálisokon bonyolultabbnak tűnik, mint a relációs adatbázisokban. Ezért a globális ipari adatbázisok SQL hozzáféréssel rendelkeznek a táblázatos adatokkal való munka egyszerűsítése érdekében.

Általánosságban elmondható, hogy ha az adatséma nem változik gyakran, a beillesztési sebesség nem kritikus, és a teljes adatbázis könnyen megjeleníthető normalizált táblák formájában, akkor könnyebb az SQL-lel dolgozni, mivel magasabb szintű absztrakciót biztosít. .

Ebben a konkrét esetben ezt akartam megmutatni A globals konstruktorként működhet más adatbázisok létrehozásához. Mint egy assembler, amelyen más nyelveket is lehet írni. Íme példák arra, hogyan hozhat létre analógokat a globálisokon kulcsérték, listák, halmazok, táblázatos, dokumentum-orientált adatbázisok.

Ha minimális erőfeszítéssel valamilyen nem szabványos adatbázist kell létrehoznia, akkor a globalok felé kell néznie.

3.3 Speciális eset 3. Kétszintű fa, a második szint minden csomópontja fix számú ággal rendelkezik

Valószínűleg kitaláltad: ez a táblák alternatív megvalósítása a globalokon. Hasonlítsuk össze ezt a megvalósítást az előzővel.

Táblázatok egy kétszintű fán vs. egyszintű fán.

Hátrányok
Érvek

1. Lassabb a beszúráshoz, mivel a csomópontok számát az oszlopok számával kell megegyezni.
2. Több lemezterület felhasználás. Mivel az oszlopnevekkel rendelkező globális indexek (ezek tömb indexek) lemezterületet foglalnak el, és minden sorhoz megkettőződnek.

1. Gyorsabb hozzáférés az egyes oszlopok értékéhez, mivel nincs szükség a karakterlánc elemzésére. Tesztjeim szerint 11,5 oszlopon 2%-kal gyorsabb, nagyobb számú oszlopon több.
2. Könnyebben módosítható adatséma
3. Világosabb kód

Következtetés: nem mindenkinek. Mivel a gyorsaság a globalok egyik legfontosabb előnye, nincs értelme ennek a megvalósításnak, mivel valószínűleg nem fog gyorsabban teljesíteni, mint a relációs adatbázisok táblái.

3.4 Általános eset. Fák és rendezett fák

Bármilyen faként ábrázolható adatstruktúra tökéletesen illeszkedik a globálisokhoz.

3.4.1 Objektumok alobjektumokkal

Ez a globálisok hagyományos használatának területe. Az orvostudományban rengeteg betegség, gyógyszer, tünet és kezelési módszer létezik. Irracionális egy olyan táblázatot létrehozni, amely minden beteg számára millió mezőt tartalmaz. Ráadásul a mezők 99%-a üres lesz.

Képzeljen el egy táblázatokból álló SQL adatbázist: „beteg” ~ 100 000 mező, „Gyógyászat” - 100 000 mező, „Terápia” - 100 000 mező, „Szövődmények” - 100 000 mező stb. stb. Vagy létrehozhat egy adatbázist sok ezer táblázatból, mindegyik egy adott betegtípushoz (és átfedhet!), kezelésekről, gyógyszerekről és több ezer további táblázatból a táblák közötti kapcsolatokhoz.

A globálok ideálisak az orvostudomány számára, mivel lehetővé teszik, hogy minden beteg számára pontos leírást készítsen a kórtörténetéről, a különféle terápiákról és a gyógyszerek hatásáról, egy fa formájában anélkül, hogy extra lemezterületet pazarolna az üres oszlopokra. legyen így egy relációs esetben.

A globalok használatával kényelmesen lehet létrehozni egy adatbázist az emberek adataival, amikor fontos a klienssel kapcsolatos maximum különféle információk felhalmozása és rendszerezése. Erre van kereslet az orvostudományban, a bankszektorban, a marketingben, az archiválásban és más területeken

.
Természetesen SQL-ben emulálhatunk egy fát néhány táblával (EAV, 1,2,3,4,5,6,7,8,9,10), azonban ez lényegesen bonyolultabb és lassabb lesz. Lényegében egy globálisat kell írnia, amely táblákon működik, és el kell rejtenie a táblázatokkal végzett összes munkát egy absztrakciós réteg alá. Helytelen az alacsonyabb szintű technológiát (globális) emulálni magasabb szintű technológiával (SQL). Alkalmatlan.

Nem titok, hogy az adatséma megváltoztatása óriási táblákon (ALTER TABLE) meglehetősen sok időt vehet igénybe. A MySQL például úgy ALTER TABLE ADD|DROP COLUMN-t, hogy teljesen átmásolja az információkat a régi táblából az új táblába (tesztelt MyISAM, InnoDB motorok). Ami egy működő adatbázist rekordmilliárdokkal képes felakasztani napokra, ha nem hetekre.

Az adatstruktúra megváltoztatása, ha globalokat használunk, semmibe nem kerül. Bármikor hozzáadhatunk bármilyen új tulajdonságot bármely objektumhoz, a hierarchia bármely szintjén. Az ágak átnevezésével kapcsolatos változtatások futtathatók a háttérben egy futó adatbázison.


Ezért a rengeteg opcionális tulajdonsággal rendelkező objektumok tárolásánál a globalok nagyszerű választás.

Sőt, hadd emlékeztesselek arra, hogy bármelyik tulajdonsághoz való hozzáférés azonnali, mivel a globálisan minden út B-fa.

A globális adatbázisok általában egyfajta dokumentum-orientált adatbázisok, amelyek képesek hierarchikus információk tárolására. Ezért a dokumentum-orientált adatbázisok felvehetik a versenyt a globálisokkal az orvosi feljegyzések tárolása terén. De ez még mindig nem ugyanazVegyük összehasonlításul a MongoDB-t. Ebben a tartományban a következő okok miatt veszít a globálisokkal szemben:

1. Dokumentum mérete. A tárolóegység JSON formátumú (pontosabban BSON) szöveg, körülbelül 16 MB maximális térfogattal. A korlátozást kifejezetten azért hozták, hogy ne lassuljon le a JSON-adatbázis az elemzés során, ha egy hatalmas JSON-dokumentumot tárolnak benne, majd mezőkkel hozzáférnek. Ennek a dokumentumnak tartalmaznia kell a betegre vonatkozó összes információt. Mindannyian tudjuk, milyen vastagok lehetnek a betegnyilvántartások. A 16 MB-os maximális kártyaméret azonnal véget vet azoknak a betegeknek, akiknek a betegségkártyája MRI-fájlokat, röntgenfelvételeket és egyéb tanulmányokat tartalmaz. A globális világ egyik ágában gigabájt és terabájt információ lehet. Ennek elvileg véget vethetünk, de folytatom.
2. Az eszméletvesztés/változás/új tulajdonságok törlésének ideje a páciens diagramjából. Egy ilyen adatbázisnak be kell olvasnia a teljes térképet a memóriába (ez nagy mennyiség!), elemeznie kell a BSON-t, hozzáadni/módosítani/törölni egy új csomópontot, frissítenie kell az indexeket, be kell csomagolnia BSON-ba, és lemezre kell mentenie. A globálisnak csak egy adott tulajdonsághoz kell hozzáférnie, és azt manipulálnia kell.
3. Gyors hozzáférés az egyes ingatlanokhoz. A dokumentumban található sok tulajdonságnak és többszintű szerkezetének köszönhetően az egyes tulajdonságokhoz való hozzáférés gyorsabb lesz, mivel a globálisban minden elérési út egy B-fa. A BSON-ban lineárisan kell elemeznie a dokumentumot a kívánt tulajdonság megtalálásához.

3.3.2 Asszociatív tömbök

Az asszociatív tömbök (még beágyazott tömbök esetén is) tökéletesen illeszkednek a globálisokhoz. Például egy ilyen PHP tömb jelenik meg az első képen 3.3.1.

$a = array(
  "name" => "Vince Medvedev",
  "city" => "Moscow",
  "threatments" => array(
    "surgeries" => array("apedicectomy", "biopsy"),
    "radiation" => array("gamma", "x-rays"),
    "physiotherapy" => array("knee", "shoulder")
  )
);

3.3.3 Hierarchikus dokumentumok: XML, JSON

Globálisban is könnyen tárolható. Tárolás céljából többféleképpen elhelyezhető.

XML
Az XML globálisra bontásának legegyszerűbb módja, ha a címkeattribútumokat csomópontokban tárolja. Ha pedig gyors hozzáférésre van szükség a címke attribútumokhoz, akkor azokat külön ágakba helyezhetjük.

<note id=5>
<to>Вася</to>
<from>Света</from>
<heading>Напоминание</heading>
<body>Позвони мне завтра!</body>
</note>

COS-en ez a kódnak felel meg:

Set ^xml("note")="id=5"
Set ^xml("note","to")="Саша"
Set ^xml("note","from")="Света"
Set ^xml("note","heading")="Напоминание"
Set ^xml("note","body")="Позвони мне завтра!"

megjegyzés: Az XML, JSON és asszociatív tömbök esetében sokféle megjelenítési módot találhat a globálisokon. Ebben az esetben nem tükröztük az alcímkék sorrendjét a jegyzetcímkében. Globálisan ^xml Az alcímkék ábécé sorrendben jelennek meg. A sorrend szigorú megjelenítéséhez használhatja például a következő képernyőt:

JSON.
A 3.3.1 szakasz első képe ezt a JSON-dokumentumot mutatja:

var document = {
  "name": "Vince Medvedev",
  "city": "Moscow",
  "threatments": {
    "surgeries": ["apedicectomy", "biopsy"],
    "radiation": ["gamma", "x-rays"],
    "physiotherapy": ["knee", "shoulder"]
  },
};

3.3.4 Hierarchikus kapcsolatokkal összekapcsolt azonos struktúrák

Példák: az értékesítési irodák felépítése, az emberek elhelyezkedése egy MLM-struktúrában, a sakk nyitásainak adatbázisa.

Debütált adatbázis. A löketerő becslését használhatja a globális csomópont indexértékeként. Ezután a legerősebb lépés kiválasztásához elegendő a legnagyobb súlyú ágat választani. A globális szinten az összes ág minden szinten a mozgás erőssége szerint lesz rendezve.

Az értékesítési irodák felépítése, az emberek felépítése az MLM-ben. A csomópontok tárolhatnak bizonyos gyorsítótárazási értékeket, amelyek tükrözik a teljes részfa jellemzőit. Például egy adott részfa értékesítési volumene. Bármelyik ág teljesítményét tükröző figurát bármikor kaphatunk.

4. Milyen esetekben a legelőnyösebb a globalok használata?

Az első oszlop azokat az eseteket mutatja be, amikor jelentős sebességnövekedést ér el a globalok használatával, a második pedig azokat az eseteket mutatja be, amikor a tervezés vagy az adatmodell egyszerűsödik.

Sebesség
Könnyű adatfeldolgozás/bemutatás

1. Beszúrás [automatikus rendezéssel minden szinten], [indexelés főkulccsal]
2. Részfák eltávolítása
3. Számos beágyazott tulajdonsággal rendelkező objektumok, amelyek egyéni hozzáférést igényelnek
4. Hierarchikus struktúra, amely képes megkerülni a gyermekágakat bármely ágról, még a nem létezőkről is
5. Részfák mélység-első bejárása

1. Objektumok/entitások nagyszámú opcionális [és/vagy beágyazott] tulajdonsággal/entitással
2. Séma nélküli adatok. Amikor gyakran megjelenhetnek új ingatlanok, és eltűnnek a régiek.
3. Egyéni adatbázist kell létrehoznia.
4. Útvonalalapok és döntési fák. Amikor kényelmes az ösvényeket faként ábrázolni.
5. Hierarchikus struktúrák eltávolítása rekurzió használata nélkül

Kiterjesztés „A globálok kincses kardok az adatok tárolására. Ritka tömbök. 3. rész".

A felelősség megtagadása: Ez a cikk és a hozzá fűzött megjegyzéseim az én véleményem, és nincs összefüggésben az InterSystems Corporation hivatalos álláspontjával.

Forrás: will.com