🥇Globaly jsou meče pokladů pro ukládání dat. Stromy. Část 2

3. Varianty struktur při použití globálů

Struktura, jako je uspořádaný strom, má různé speciální případy. Zvažme ty, které mají praktickou hodnotu při práci s globálními.

3.1 Speciální případ 1. Jeden uzel bez větví

Globální lze použít nejen jako pole, ale také jako běžné proměnné. Například jako počítadlo:

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

V tomto případě může mít globální kromě svého významu i větve. Jedno nevylučuje druhé.

3.2 Speciální případ 2. Jeden vrchol a mnoho větví

Obecně se jedná o klasický základ párů klíč–hodnota. A pokud uložíme n-tici hodnot jako hodnotu, získáme velmi obyčejnou tabulku s primárním klíčem.

Abychom mohli implementovat tabulku na globals, budeme muset sami vygenerovat řádky z hodnot sloupců a poté je uložit do globální pomocí primárního klíče. Aby bylo možné řetězec při čtení opět rozdělit do sloupců, můžete použít:

oddělovací znaky.

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

rigidní schéma, ve kterém každé pole zabírá předem určený počet bajtů. Jak se to dělá v relačních databázích.

speciální funkce $LB (dostupná v Cache), která vytváří řetězec hodnot.

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

Zajímavé je, že není těžké použít globals k něčemu podobnému jako sekundární indexy v relačních databázích. Nazvěme takové struktury indexové globální. Globální index je pomocný strom pro rychlé vyhledávání polí, která nejsou součástí primárního klíče hlavního globalu. Chcete-li jej vyplnit a použít, musíte napsat další kód.

Vytvořme globální index na prvním sloupci.

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

Nyní, abychom mohli rychle vyhledat informace v prvním sloupci, musíme se podívat do globálního ^i a najděte primární klíče (id) odpovídající požadované hodnotě prvního sloupce.

Při vkládání hodnoty můžeme okamžitě vytvořit jak hodnoty, tak i indexy pro požadovaná pole. A kvůli spolehlivosti to vše zabalíme do transakce.

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

Podrobnosti o tom, jak to udělat na M tabulky na globals, emulace sekundárních indexů.

Takové tabulky budou fungovat stejně rychle jako v tradičních databázích (nebo ještě rychleji), pokud jsou funkce pro vkládání/aktualizaci/mazání řádků napsány v COS/M a zkompilovány.Toto tvrzení jsem ověřil testy na hromadné INSERT a SELECT do jedné dvousloupcové tabulky, včetně použití příkazů TSTART a TCOMMIT (transakce).

Složitější scénáře se souběžným přístupem a paralelními transakcemi jsem netestoval.

Bez použití transakcí byla rychlost vkládání 778 361 vložení za sekundu na milion hodnot.
S 300 miliony hodnot - 422 141 vložek za sekundu.

Při použití transakcí - 572 082 vložek za sekundu pro 50 milionů vložek. Všechny operace byly provedeny z kompilovaného M kódu.
Pevné disky jsou běžné, ne SSD. RAID5 se zpětným zápisem. Procesor Phenom II 1100T.

Chcete-li otestovat databázi SQL podobným způsobem, musíte napsat uloženou proceduru, která bude provádět vkládání ve smyčce. Při testování MySQL 5.5 (úložiště InnoDB) jsem pomocí této metody obdržel čísla ne více než 11 XNUMX vložení za sekundu.
Ano, implementace tabulek na globalech vypadá komplexněji než v relačních databázích. Proto mají průmyslové databáze na globals přístup SQL pro zjednodušení práce s tabulkovými daty.

Obecně platí, že pokud se schéma dat nebude často měnit, rychlost vkládání není kritická a celá databáze může být snadno reprezentována ve formě normalizovaných tabulek, pak je snazší pracovat s SQL, protože poskytuje vyšší úroveň abstrakce. .

V tomto konkrétním případě jsem to chtěl ukázat globals mohou fungovat jako konstruktor pro vytváření dalších databází. Jako assembler, ve kterém lze psát jiné jazyky. Zde jsou příklady toho, jak můžete vytvářet analogy na globálech klíč-hodnota, seznamy, sady, tabulkové, dokumentově orientované databáze.

Pokud potřebujete vytvořit nějaký druh nestandardní databáze s minimálním úsilím, měli byste se podívat na globální.

3.3 Speciální případ 3. Dvouúrovňový strom, každý uzel druhé úrovně má pevný počet větví

Pravděpodobně jste uhodli: jedná se o alternativní implementaci tabulek na globals. Porovnejme tuto implementaci s předchozí.

Tabulky na dvouúrovňovém stromu vs. na jednoúrovňovém stromě.

Zápory
Pros

Pomalejší pro vkládání, protože musíte nastavit počet uzlů rovný počtu sloupců.
Větší spotřeba místa na disku. Protože globální indexy (chápané jako indexy polí) s názvy sloupců zabírají místo na disku a jsou duplikovány pro každý řádek.

Rychlejší přístup k hodnotám jednotlivých sloupců, protože není potřeba analyzovat řetězec. Podle mých testů je o 11,5 % rychlejší na 2 sloupcích a více na větším počtu sloupců.
Snazší změna datového schématu
Jasnější kód

Závěr: ne pro každého. Vzhledem k tomu, že rychlost je jednou z nejdůležitějších výhod globals, nemá smysl používat tuto implementaci, protože s největší pravděpodobností nebude fungovat rychleji než tabulky v relačních databázích.

3.4 Obecný případ. Stromy a objednané stromy

Jakákoli datová struktura, která může být reprezentována jako strom, se dokonale hodí ke globálním.

3.4.1 Objekty s dílčími objekty

Toto je oblast tradičního použití globals. V lékařské oblasti existuje obrovské množství nemocí, léků, symptomů a léčebných metod. Je iracionální vytvořit tabulku s milionem polí pro každého pacienta. Navíc bude 99 % polí prázdných.

Představte si SQL databázi tabulek: „pacient“ ~ 100 000 polí, „Medicína“ – 100 000 polí, „Terapie“ – 100 000 polí, „Komplikace“ – 100 000 polí atd. a tak dále. Nebo můžete vytvořit databázi mnoha tisíc tabulek, každou pro konkrétní typ pacienta (a mohou se překrývat!), léčby, léků a tisíce dalších tabulek pro spojení mezi těmito tabulkami.

Globals jsou ideální pro medicínu, protože vám umožňují vytvořit pro každého pacienta přesný popis jeho anamnézy, různých terapií a působení léků ve formě stromu, aniž byste plýtvali dalším místem na disku prázdnými sloupci, jak by tomu bylo být případ v relačním případě.

Pomocí globals je vhodné vytvořit databázi s údaji o lidech, kdy je důležité shromáždit a systematizovat maximum různých informací o klientovi. To je žádané v medicíně, bankovnictví, marketingu, archivnictví a dalších oblastech

.
Samozřejmě v SQL můžete také emulovat strom s několika tabulkami (Eav, 1,2,3,4,5,6,7,8,9,10), je to však podstatně složitější a bude to pomalejší. V podstatě byste museli napsat globál, který funguje na tabulkách, a veškerou práci s tabulkami skrýt pod vrstvu abstrakce. Je nesprávné emulovat technologii nižší úrovně (globály) pomocí technologie vyšší úrovně (SQL). Nemístný.

Není žádným tajemstvím, že změna datového schématu na obřích tabulkách (ALTER TABLE) může trvat poměrně dlouho. MySQL například provádí ALTER TABLE ADD|DROP COLUMN úplným zkopírováním informací ze staré tabulky do nové tabulky (testované motory MyISAM, InnoDB). Což může zavěsit fungující databázi s miliardami záznamů na dny, ne-li týdny.

Změna struktury dat, pokud používáme globals, nás nic nestojí. Kdykoli můžeme přidat jakékoli nové vlastnosti, které potřebujeme k jakémukoli objektu, na jakékoli úrovni hierarchie. Změny spojené s přejmenováním větví lze spouštět na pozadí na běžící databázi.

Proto, pokud jde o ukládání objektů s obrovským množstvím volitelných vlastností, jsou globals skvělou volbou.

Navíc mi dovolte, abych vám připomněl, že přístup ke kterékoli z vlastností je okamžitý, protože v globálním měřítku jsou všechny cesty B-stromy.

Globální databáze jsou obecně typem databáze orientované na dokumenty se schopností ukládat hierarchické informace. Dokumentově orientované databáze proto mohou v oblasti uchovávání zdravotnické dokumentace konkurovat světům. Ale pořád to není úplně onoPro srovnání si vezmeme MongoDB. V této doméně prohrává s globálními z následujících důvodů:

Velikost dokumentu. Úložnou jednotkou je text ve formátu JSON (přesněji BSON) o maximálním objemu cca 16MB. Omezení bylo provedeno speciálně proto, aby se databáze JSON nezpomalila během analýzy, pokud je v ní uložen velký dokument JSON a poté k němu přistupují pole. Tento dokument by měl obsahovat všechny informace o pacientovi. Všichni víme, jak tlusté mohou být záznamy pacientů. Maximální velikost karty 16 MB okamžitě ukončí pacienty, jejichž karta nemoci obsahuje soubory MRI, rentgenové snímky a další studie. V jedné větvi globálního můžete mít gigabajty a terabajty informací. V zásadě to můžeme ukončit, ale budu pokračovat.
Čas vědomí/změny/vymazání nových vlastností v pacientově diagramu. Taková databáze musí načíst celou mapu do paměti (to je velké množství!), analyzovat BSON, přidat/změnit/smazat nový uzel, aktualizovat indexy, zabalit do BSON a uložit na disk. Globální potřebuje pouze přístup k určité vlastnosti a manipulovat s ní.
Rychlý přístup k jednotlivým nemovitostem. S mnoha vlastnostmi v dokumentu a jeho víceúrovňovou strukturou bude přístup k jednotlivým vlastnostem rychlejší díky skutečnosti, že každá cesta v globálu je B-strom. V BSON musíte dokument lineárně analyzovat, abyste našli požadovanou vlastnost.

3.3.2 Asociativní pole

Asociativní pole (i s vnořenými poli) se perfektně hodí na globály. Například takové pole z PHP se zobrazí na prvním obrázku 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 Hierarchické dokumenty: XML, JSON

Také snadno uložené v globálních. Pro skladování lze rozložit různými způsoby.

XML
Nejjednodušší způsob, jak rozložit XML na globály, je uložit atributy značek do uzlů. A pokud je potřeba rychlý přístup k atributům značek, můžeme je přesunout do samostatných větví.

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

Na COS by to odpovídalo kódu:

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

Poznámka: Pro XML, JSON, asociativní pole můžete přijít s mnoha různými způsoby zobrazení na globálech. V tomto případě jsme nezohlednili pořadí dílčích značek ve značce poznámky. Globálně ^xml dílčí značky se zobrazí v abecedním pořadí. Pro striktní vyjádření objednávky můžete použít například následující zobrazení:

JSON.
První obrázek ze sekce 3.3.1 ukazuje odraz tohoto dokumentu JSON:

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

3.3.4 Identické struktury spojené hierarchickými vztahy

Příklady: struktura obchodních zastoupení, umístění lidí ve struktuře MLM, databáze otvorů v šachu.

Databáze debutů. Odhad síly zdvihu můžete použít jako hodnotu indexu globálního uzlu. Pak, aby bylo možné vybrat nejsilnější tah, bude stačit vybrat větev s největší váhou. Globálně budou všechny větve na každé úrovni seřazeny podle síly pohybu.

Struktura obchodních zastoupení, struktura lidí v MLM. Uzly mohou ukládat určité hodnoty mezipaměti, které odrážejí vlastnosti celého podstromu. Například objem prodeje daného podstromu. V každém okamžiku můžeme získat číslo odrážející úspěchy jakéhokoli oboru.

4. V jakých případech je nejvýhodnější použít globals?

První sloupec představuje případy, kdy použitím globalů dosáhnete výrazného zvýšení rychlosti, a druhý, kdy se zjednoduší návrh nebo datový model.

Rychlost
Jednoduchost zpracování/prezentace dat

Vkládání [s automatickým tříděním na každé úrovni], [indexování podle hlavního klíče]
Odstranění podstromů
Objekty s mnoha vnořenými vlastnostmi, které vyžadují individuální přístup
Hierarchická struktura se schopností obejít podřízené větve z jakékoli větve, i té neexistující
Procházení podstromy do hloubky

Objekty/entity s velkým počtem volitelných [a/nebo vnořených] vlastností/entit
Data bez schématu. Kdy se často mohou objevovat nové vlastnosti a staré mizet.
Musíte vytvořit vlastní databázi.
Základy cest a rozhodovací stromy. Kdy je vhodné reprezentovat cesty jako strom.
Odstranění hierarchických struktur bez použití rekurze

Prodloužení „Globalové jsou poklady pro ukládání dat. Řídká pole. Část 3".

Odmítnutí odpovědnosti: Tento článek a mé komentáře k němu jsou mým názorem a nemají žádný vztah k oficiálnímu stanovisku InterSystems Corporation.

Zdroj: www.habr.com

Globals jsou meče pokladů pro ukládání dat. Stromy. Část 2