🥇Els globals són espases de tresor per emmagatzemar dades. Arbres. Part 2

3. Variants d'estructures en utilitzar globals

Una estructura com un arbre ordenat té diversos casos especials. Considerem aquells que tenen valor pràctic quan es treballa amb globals.

3.1 Cas especial 1. Un node sense branques

Els globals es poden utilitzar no només com una matriu, sinó també com a variables regulars. Per exemple, com a comptador:

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

En aquest cas, el global, a més del seu significat, també pot tenir branques. Un no exclou l'altre.

3.2 Cas especial 2. Un vèrtex i moltes branques

En general, aquesta és una base clau-valor clàssica. I si desem una tupla de valors com a valor, obtindrem una taula molt normal amb una clau primària.

Per implementar una taula sobre globals, haurem de generar nosaltres mateixos files a partir dels valors de la columna i després desar-los al global mitjançant la clau primària. Per fer possible tornar a dividir la cadena en columnes durant la lectura, podeu utilitzar:

caràcters delimitadors.

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

un esquema rígid en el qual cada camp ocupa un nombre predeterminat de bytes. Com es fa a les bases de dades relacionals.

una funció especial $LB (disponible a la memòria cau), que crea una cadena de valors.

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

Curiosament, no és difícil utilitzar globals per fer alguna cosa semblant als índexs secundaris a les bases de dades relacionals. Anomenem a aquestes estructures índex globals. Un índex global és un arbre auxiliar per cercar ràpidament camps que no formen part de la clau primària del global principal. Per omplir-lo i utilitzar-lo, heu d'escriure codi addicional.

Creem un índex global a la primera columna.

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

Ara, per cercar ràpidament informació a la primera columna, hem de mirar el global ^i i trobeu les claus primàries (id) corresponents al valor desitjat de la primera columna.

En inserir un valor, podem crear immediatament tant el valor com l'índex globals per als camps obligatoris. I per fiabilitat, englobem-ho tot en una transacció.

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

Detalls sobre com fer-ho a M taules sobre globals, emulació d'índexs secundaris.

Aquestes taules funcionaran tan ràpidament com a les bases de dades tradicionals (o fins i tot més ràpid) si les funcions per inserir/actualitzar/suprimir files s'escriuen en COS/M i es compilen.Vaig comprovar aquesta declaració amb proves sobre INSERT i SELECT a granel en una taula de dues columnes, inclòs l'ús de les ordres TSTART i TCOMMIT (transaccions).

No he provat escenaris més complexos amb accés concurrent i transaccions paral·leles.

Sense utilitzar transaccions, la taxa d'inserció va ser de 778 insercions/segon per milió de valors.
Amb 300 milions de valors - 422 insercions/segon.

Quan s'utilitzen transaccions: 572 insercions/segon per a insercions de 082 milions. Totes les operacions es van realitzar a partir del codi M compilat.
Els discs durs són normals, no SSD. RAID5 amb reescriptura. Processador Phenom II 1100T.

Per provar una base de dades SQL d'una manera similar, heu d'escriure un procediment emmagatzemat que realitzarà insercions en un bucle. Quan vaig provar MySQL 5.5 (emmagatzematge InnoDB), amb aquest mètode vaig rebre nombres de no més de 11K insercions per segon.
Sí, la implementació de taules en globals sembla més complexa que en bases de dades relacionals. Per tant, les bases de dades industrials sobre globals tenen accés SQL per simplificar el treball amb dades tabulars.

En general, si l'esquema de dades no canvia amb freqüència, la velocitat d'inserció no és crítica i tota la base de dades es pot representar fàcilment en forma de taules normalitzades, llavors és més fàcil treballar amb SQL, ja que proporciona un nivell d'abstracció més alt. .

En aquest cas concret ho volia demostrar globals poden actuar com a constructor per crear altres bases de dades. Com un assemblador en què es poden escriure altres idiomes. Aquí teniu exemples de com podeu crear anàlegs a globals valor-clau, llistes, conjunts, bases de dades tabulars i orientades a documents.

Si necessiteu crear algun tipus de base de dades no estàndard amb un esforç mínim, hauríeu de mirar cap a globals.

3.3 Cas especial 3. Arbre de dos nivells, cada node del segon nivell té un nombre fix de branques

Segurament ho heu endevinat: aquesta és una implementació alternativa de taules sobre globals. Comparem aquesta implementació amb l'anterior.

Taules en un arbre de dos nivells vs. en un arbre d'un sol nivell.

Contres
Pros

Més lent per a la inserció, ja que cal definir el nombre de nodes igual al nombre de columnes.
Més consum d'espai en disc. Com que els índexs globals (entens com a índexs de matriu) amb noms de columnes ocupen espai de disc i es dupliquen per a cada fila.

Accés més ràpid als valors de columnes individuals, ja que no cal analitzar la cadena. Segons les meves proves, és un 11,5% més ràpid en 2 columnes i més en un nombre més gran de columnes.
És més fàcil canviar l'esquema de dades
Codi més clar

Conclusió: no per a tothom. Com que la velocitat és un dels avantatges més clau dels globals, no serveix de res utilitzar aquesta implementació, ja que probablement no funcionarà més ràpid que les taules de bases de dades relacionals.

3.4 Cas general. Arbres i arbres ordenats

Qualsevol estructura de dades que es pugui representar com un arbre encaixa perfectament amb els globals.

3.4.1 Objectes amb subobjectes

Aquesta és l'àrea d'ús tradicional dels globals. En l'àmbit mèdic hi ha un gran nombre de malalties, medicaments, símptomes i mètodes de tractament. És irracional crear una taula amb un milió de camps per a cada pacient. A més, el 99% dels camps estaran buits.

Imagineu una base de dades SQL de taules: "pacient" ~ 100 camps, "Medicina" - 000 camps, "Teràpia" - 100 camps, "Complicacions" - 000 camps, etc. etcètera. O podeu crear una base de dades de molts milers de taules, cadascuna per a un tipus de pacient específic (i es poden solapar!), tractaments, medicaments i milers de taules més per a connexions entre aquestes taules.

Els globals són ideals per a la medicina, ja que permeten crear per a cada pacient una descripció precisa de la seva història clínica, diverses teràpies i les accions dels medicaments, en forma d'arbre, sense perdre espai en disc addicional en columnes buides, com ho faria. ser el cas en un cas relacional.

Utilitzant globals és convenient crear una base de dades amb dades sobre persones, quan és important acumular i sistematitzar un màxim d'informació diversa sobre el client. Això és demanat en medicina, banca, màrqueting, arxiu i altres àrees

.
Per descomptat, en SQL també podeu emular un arbre amb només unes poques taules (EAV, 1,2,3,4,5,6,7,8,9,10), però això és significativament més complicat i serà més lent. Essencialment, hauríeu d'escriure un global que funcioni en taules i amagar tot el treball amb taules sota una capa d'abstracció. És incorrecte emular la tecnologia de nivell inferior (globals) utilitzant tecnologia de nivell superior (SQL). Inadequat.

No és cap secret que canviar l'esquema de dades a les taules gegants (ALTER TABLE) pot trigar una bona quantitat de temps. MySQL, per exemple, fa ALTER TABLE ADD|DROP COLUMN copiant completament la informació de la taula antiga a la taula nova (motors MyISAM, InnoDB provats). Que pot penjar una base de dades de treball amb milers de milions de registres durant dies, si no setmanes.

Canviar l'estructura de dades si fem servir globals no ens costa res. En qualsevol moment podem afegir les propietats noves que necessitem a qualsevol objecte, a qualsevol nivell de la jerarquia. Els canvis associats amb el canvi de nom de branques es poden executar en segon pla en una base de dades en execució.

Per tant, quan es tracta d'emmagatzemar objectes amb un gran nombre de propietats opcionals, els globals són una bona opció.

A més, permeteu-me recordar que l'accés a qualsevol de les propietats és instantani, ja que en el global tots els camins són arbres B.

Les bases de dades globals, en general, són un tipus de base de dades orientada a documents amb la capacitat d'emmagatzemar informació jeràrquica. Per tant, les bases de dades orientades a documents poden competir amb les globals en l'àmbit de l'emmagatzematge de registres mèdics. Però encara no és ben bé el mateixPrenem MongoDB per comparar. En aquest domini perd davant els globals per les següents raons:

Mida del document. La unitat d'emmagatzematge és text en format JSON (més precisament BSON) amb un volum màxim d'uns 16 MB. La restricció es va fer específicament perquè la base de dades JSON no s'alentiri durant l'anàlisi si s'hi emmagatzema un document JSON enorme i després s'hi accedeix mitjançant camps. Aquest document ha de contenir tota la informació sobre el pacient. Tots sabem com de gruixuts poden ser els registres dels pacients. La mida màxima de la targeta de 16 MB posa immediatament fi als pacients la targeta de malaltia dels quals inclou fitxers de ressonància magnètica, exploracions de raigs X i altres estudis. En una branca del global podeu tenir gigabytes i terabytes d'informació. En principi, podem acabar amb això, però continuaré.
Temps de consciència/canvi/supressió de noves propietats en el quadre del pacient. Aquesta base de dades ha de llegir tot el mapa a la memòria (això és una gran quantitat!), analitzar BSON, afegir/canviar/suprimir un nou node, actualitzar índexs, empaquetar-lo a BSON i desar-lo al disc. Un global només necessita accedir a una propietat específica i manipular-la.
Accés ràpid a propietats individuals. Amb moltes propietats en un document i la seva estructura multinivell, l'accés a les propietats individuals serà més ràpid a causa del fet que cada camí del global és un arbre B. A BSON, heu d'analitzar linealment el document per trobar la propietat desitjada.

3.3.2 Matrius associatius

Les matrius associatives (fins i tot amb matrius imbricades) s'ajusten perfectament als globals. Per exemple, aquesta matriu de PHP es mostrarà a la primera imatge 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 Documents jeràrquics: XML, JSON

També s'emmagatzema fàcilment a globals. Es pot disposar de diferents maneres per a l'emmagatzematge.

XML
La manera més senzilla de descompondre XML en globals és emmagatzemar els atributs d'etiquetes als nodes. I si es necessita un accés ràpid als atributs de l'etiqueta, els podem moure a branques separades.

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

A COS, això correspondria al codi:

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

Nota: Per a les matrius XML, JSON i associatives, podeu trobar moltes maneres diferents de mostrar-les en globals. En aquest cas, no hem reflectit l'ordre de les subetiquetes a l'etiqueta de la nota. A nivell mundial ^xml les subetiquetes es mostraran en ordre alfabètic. Per reflectir estrictament l'ordre, podeu utilitzar, per exemple, la pantalla següent:

JSON.
La primera imatge de la secció 3.3.1 mostra un reflex d'aquest document JSON:

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

3.3.4 Estructures idèntiques connectades per relacions jeràrquiques

Exemples: l'estructura de les oficines de vendes, la ubicació de les persones en una estructura de MLM, la base de dades d'obertures als escacs.

Base de dades de debut. Podeu utilitzar l'estimació de la força del traç com a valor d'índex del node global. Aleshores, per triar el moviment més fort, n'hi haurà prou amb triar la branca amb més pes. Al global, totes les branques de cada nivell s'ordenaran per força de moviment.

L'estructura de les oficines de vendes, l'estructura de les persones en MLM. Els nodes poden emmagatzemar determinats valors de memòria cau que reflecteixen les característiques de tot el subarbre. Per exemple, el volum de vendes d'un subarbre determinat. En qualsevol moment podem obtenir una xifra que reflecteixi els assoliments de qualsevol branca.

4. En quins casos és més beneficiós utilitzar globals?

La primera columna presenta casos en què obtindreu un augment de velocitat important mitjançant l'ús de globals, i la segona quan es simplificarà el disseny o el model de dades.

Accelerar
Facilitat de tractament/presentació de dades

Inserció [amb ordenació automàtica a cada nivell], [indexació per clau mestra]
Eliminació de subarbres
Objectes amb moltes propietats imbricades que requereixen accés individual
Estructura jeràrquica amb la possibilitat de saltar les branques secundàries de qualsevol branca, fins i tot les inexistents
Travessa en profunditat dels subarbres

Objectes/entitats amb un gran nombre de propietats/entitats opcionals [i/o imbricades].
Dades sense esquemes. Quan sovint poden aparèixer noves propietats i desaparèixer les antigues.
Heu de crear una base de dades personalitzada.
Bases de camins i arbres de decisió. Quan és convenient representar camins com un arbre.
Eliminació d'estructures jeràrquiques sense utilitzar recursivitat

Extensió "Els globals són espases de tresor per emmagatzemar dades. Matrius dispersos. Part 3".

renúncia: Aquest article i els meus comentaris al respecte són la meva opinió i no representen la posició oficial d'InterSystems Corporation.

Font: www.habr.com

Els globals són espases de tresor per emmagatzemar dades. Arbres. Part 2