Globals estas trezoraj glavoj por stoki datumojn. Arboj. Parto 2

Komenci - vidu parton 1.

3. Variantoj de strukturoj kiam oni uzas globalojn

Strukturo kiel ordigita arbo havas diversajn specialajn kazojn. Ni konsideru tiujn, kiuj havas praktikan valoron kiam oni laboras kun tutmondaj.

3.1 Speciala kazo 1. Unu nodo sen branĉoj

Globaloj povas esti uzataj ne nur kiel tabelo, sed ankaŭ kiel regulaj variabloj. Ekzemple, kiel nombrilo:

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

En ĉi tiu kazo, la tutmonda, krom sia signifo, ankaŭ povas havi branĉojn. Unu ne ekskludas la alian.

3.2 Speciala kazo 2. Unu vertico kaj multaj branĉoj

Ĝenerale, ĉi tio estas klasika ŝlosilvalora bazo. Kaj se ni konservas opon da valoroj kiel valoro, ni ricevos tre ordinaran tabelon kun ĉefa ŝlosilo.

Por efektivigi tabelon pri globaloj, ni mem devos generi vicojn el la kolumnaj valoroj, kaj poste konservi ilin al la tutmonda uzante la ĉefan ŝlosilon. Por ebligi denove dividi la ŝnuron en kolumnojn dum legado, vi povas uzi:

1. limsignoj.

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

2. rigida skemo en kiu ĉiu kampo okupas antaŭfiksitan nombron da bajtoj. Kiel oni faras en rilataj datumbazoj.
3. speciala funkcio $LB (disponebla en Cache), kiu kreas ĉenon de valoroj.

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

Interese, ne estas malfacile uzi globalojn por fari ion similan al sekundaraj indeksoj en interrilataj datumbazoj. Ni nomu tiajn strukturojn indeksajn tutmondajn. Indekso tutmonda estas helparbo por rapide serĉi kampojn kiuj ne estas parto de la ĉefa ŝlosilo de la ĉefa tutmonda. Por plenigi ĝin kaj uzi ĝin, vi devas skribi plian kodon.

Ni kreu tutmondan indekson sur la unua kolumno.

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

Nun, por rapide serĉi informojn en la unua kolumno, ni devas rigardi en la tutmondan ^i kaj trovu la ĉefajn ŝlosilojn (id) respondajn al la dezirata valoro de la unua kolumno.

Enmetinte valoron, ni povas tuj krei kaj la valorajn kaj indeksajn tutmondojn por la postulataj kampoj. Kaj por fidindeco, ni envolvu ĉion en transakcio.

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

Detaloj pri kiel fari ĝin sur M tabeloj pri globaloj, emulado de sekundaraj indeksoj.

Tiaj tabeloj funkcios same rapide kiel en tradiciaj datumbazoj (aŭ eĉ pli rapide) se la funkcioj por enmeti/ĝisdatigi/forviŝi vicojn estas skribitaj en COS/M kaj kompilitaj.Mi kontrolis ĉi tiun deklaron per provoj pri amasa INSERT kaj SELECT en unu du-kolumnan tabelon, inkluzive de uzado de la komandoj TSTART kaj TCOMMIT (transakcioj).

Mi ne testis pli kompleksajn scenarojn kun samtempa aliro kaj paralelaj transakcioj.

Sen uzi transakciojn, la eniga indico estis 778 enmetoj/sekundo por miliono da valoroj.
Kun 300 milionoj da valoroj - 422 enmetoj/sekundo.

Kiam vi uzas transakciojn - 572 enmetoj/sekundo por 082M enmetoj. Ĉiuj operacioj estis faritaj de kompilita M-kodo.
Malmolaj diskoj estas regulaj, ne SSD. RAID5 kun Reskribo. Procesoro Phenom II 1100T.

Por testi SQL-datumbazon en simila maniero, vi devas skribi konservitan proceduron, kiu faros enmetojn en buklo. Provante MySQL 5.5 (InnoDB-stokado), uzante ĉi tiun metodon mi ricevis nombrojn ne pli ol 11K enmetojn sekundo.
Jes, la efektivigo de tabeloj sur globaloj aspektas pli kompleksa ol en interrilataj datumbazoj. Tial, industriaj datumbazoj pri globaloj havas SQL-aliron por simpligi laboron kun tabelaj datumoj.

Ĝenerale, se la datumskemo ne ŝanĝiĝos ofte, la enmetrapideco ne estas kritika kaj la tuta datumbazo povas esti facile reprezentita en la formo de normaligitaj tabeloj, tiam estas pli facile labori kun SQL, ĉar ĝi disponigas pli altan nivelon de abstraktado. .

En ĉi tiu aparta kazo mi volis montri tion globals povas funkcii kiel konstrukciisto por krei aliajn datumbazojn. Kiel asemblero en kiu aliaj lingvoj povas esti skribitaj. Jen ekzemploj pri kiel vi povas krei analogojn sur globaloj ŝlosilvaloro, listoj, aroj, tabelaj, dokument-orientitaj datumbazoj.

Se vi bezonas krei ian ne-norman datumbazon kun minimuma peno, tiam vi devus rigardi al tutmondaj.

3.3 Speciala kazo 3. Dunivela arbo, ĉiu nodo de la dua nivelo havas fiksan nombron da branĉoj

Vi verŝajne divenis: ĉi tio estas alternativa efektivigo de tabeloj pri globaloj. Ni komparu ĉi tiun efektivigon kun la antaŭa.

Tabeloj sur dunivela arbo vs. sur ununivela arbo.

Miksoj
Puloj

1. Pli malrapida por enmeto, ĉar vi devas agordi la nombron da nodoj egala al la nombro da kolumnoj.
2. Pli da diskspaco-konsumo. Ĉar tutmondaj indeksoj (komprenitaj kiel tabelaj indeksoj) kun kolonnomoj okupas diskospacon kaj estas duobligitaj por ĉiu vico.

1. Pli rapida aliro al la valoroj de individuaj kolumnoj, ĉar ne necesas analizi la ĉenon. Laŭ miaj provoj, ĝi estas 11,5% pli rapida sur 2 kolumnoj kaj pli sur pli granda nombro da kolumnoj.
2. Pli facile ŝanĝi datumskemon
3. Pli klara kodo

Konkludo: ne por ĉiuj. Ĉar rapideco estas unu el la plej ŝlosilaj avantaĝoj de tutmondaj, estas malmulte da signifo uzi ĉi tiun efektivigon, ĉar ĝi plej verŝajne funkcios ne pli rapide ol tabeloj en interrilataj datumbazoj.

3.4 Ĝenerala kazo. Arboj kaj ordigitaj arboj

Ajna datumstrukturo, kiu povas esti reprezentita kiel arbo, perfekte kongruas kun globaloj.

3.4.1 Objektoj kun subobjektoj

Ĉi tiu estas la areo de tradicia uzo de tutmondoj. En la medicina kampo estas grandega nombro da malsanoj, medikamentoj, simptomoj kaj kuracaj metodoj. Estas neracie krei tabelon kun miliono da kampoj por ĉiu paciento. Plie, 99% de la kampoj estos malplenaj.

Imagu SQL-datumbazon de tabeloj: "paciento" ~ 100 kampoj, "Medicino" - 000 kampoj, "Terapio" - 100 kampoj, "Komplikaĵoj" - 000 kampoj, ktp. kaj tiel plu. Aŭ vi povas krei datumbazon de multaj miloj da tabeloj, ĉiu por specifa speco de paciento (kaj ili povas interkovri!), traktadoj, medikamentoj, kaj miloj pli da tabeloj por ligoj inter ĉi tiuj tabeloj.

Globals estas idealaj por medicino, ĉar ili permesas krei por ĉiu paciento precizan priskribon de lia anamnisto, diversaj terapioj kaj la agoj de medikamentoj, en formo de arbo, sen malŝpari kroman diskospacon sur malplenaj kolonoj, kiel farus. estu la kazo en rilata kazo.

Uzante globalojn estas oportune krei datumbazon kun datumoj pri homoj, kiam gravas amasigi kaj sistemigi maksimume diversajn informojn pri la kliento. Ĉi tio estas postulata en medicino, bankado, merkatado, arkivado kaj aliaj areoj

.
Kompreneble, en SQL vi ankaŭ povas kopii arbon kun nur kelkaj tabeloj (EAV, 1,2,3,4,5,6,7,8,9,10), tamen ĉi tio estas signife pli komplika kaj estos pli malrapida. Esence, vi devus skribi tutmondan, kiu funkcias sur tabeloj kaj kaŝi la tutan laboron kun tabeloj sub abstrakta tavolo. Estas malĝuste kopii malaltnivelan teknologion (tutmonde) uzante pli altnivelan teknologion (SQL). Nekonvena.

Ne estas sekreto, ke ŝanĝi la datuman skemon sur gigantaj tabloj (ALTER TABLE) povas preni sufiĉe da tempo. MySQL, ekzemple, faras ALTER TABLE ADD|DROP COLUMN tute kopiante informojn de la malnova tabelo al la nova tabelo (provitaj MyISAM, InnoDB-motoroj). Kiu povas pendigi funkciantan datumbazon kun miliardoj da rekordoj dum tagoj, se ne semajnoj.

Ŝanĝi la datumstrukturon se ni uzas globalojn kostas al ni nenion. En ajna momento ni povas aldoni iujn ajn novajn ecojn, kiujn ni bezonas al iu ajn objekto, je ajna nivelo de la hierarkio. Ŝanĝoj asociitaj kun renomado de branĉoj povas esti rulitaj en la fono sur kuranta datumbazo.


Tial, kiam temas pri stokado de objektoj kun grandega nombro da laŭvolaj propraĵoj, tutmondaj estas bonega elekto.

Cetere, mi memorigu vin, ke aliro al iu ajn el la propraĵoj estas tuja, ĉar en la tutmonda ĉiuj vojoj estas B-arboj.

Tutmondaj datumbazoj, ĝenerale, estas speco de dokument-orientita datumbazo kun la kapablo stoki hierarkiajn informojn. Tial, dokument-orientitaj datumbazoj povas konkuri kun tutmondaj en la kampo de stokado de medicinaj registroj. Sed ĝi ankoraŭ ne estas tute samaNi prenu MongoDB por komparo. En ĉi tiu domajno ĝi perdas kontraŭ la tutmondaj pro la sekvaj kialoj:

1. Dokumenta grandeco. La stoka unuo estas teksto en formato JSON (pli precize BSON) kun maksimuma volumo de ĉirkaŭ 16MB. La limigo estis farita specife por ke la JSON-datumbazo ne malrapidiĝas dum analizado se grandega JSON-dokumento estas konservita en ĝi kaj tiam alirebla per kampoj. Ĉi tiu dokumento devas enhavi ĉiujn informojn pri la paciento. Ni ĉiuj scias kiom dikaj paciencaj registroj povas esti. La maksimuma kartgrandeco de 16MB tuj ĉesigas pacientojn, kies malsankarto inkluzivas MRI-dosierojn, Rentgenradiajn skanaĵojn kaj aliajn studojn. En unu branĉo de la tutmonda vi povas havi gigabajtojn kaj terabajtojn da informo. Principe ni povas ĉesigi ĉi tion, sed mi daŭrigos.
2. Tempo de konscio/ŝanĝo/forigo de novaj trajtoj en la diagramo de la paciento. Tia datumbazo devas legi la tutan mapon en memoron (ĉi tio estas granda kvanto!), analizi BSON, aldoni/ŝanĝi/forigi novan nodon, ĝisdatigi indeksojn, paki ĝin en BSON kaj konservi ĝin sur disko. Tutmondulo nur bezonas aliri specifan posedaĵon kaj manipuli ĝin.
3. Rapida aliro al individuaj propraĵoj. Kun multaj propraĵoj en dokumento kaj ĝia plurnivela strukturo, aliro al individuaj propraĵoj estos pli rapida pro la fakto, ke ĉiu vojo en la tutmonda estas B-arbo. En BSON, vi devas linie analizi la dokumenton por trovi la deziratan posedaĵon.

3.3.2 Asociaj tabeloj

Asociaj tabeloj (eĉ kun nestitaj tabeloj) konvenas perfekte sur globaloj. Ekzemple, tia tabelo de PHP estos montrata en la unua bildo 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 Hierarkiaj dokumentoj: XML, JSON

Ankaŭ facile konservebla en tutmondaj. Povas esti aranĝita en malsamaj manieroj por stokado.

XML
La plej facila maniero malkomponi XML en globalojn estas stoki etikedajn atributojn en nodoj. Kaj se necesas rapida aliro al etikedaj atributoj, tiam ni povas movi ilin en apartajn branĉojn.

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

Sur COS tio respondus al la kodo:

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

Komento: Por XML, JSON, asociaj tabeloj, vi povas elpensi multajn malsamajn manierojn montri sur globals. En ĉi tiu kazo, ni ne reflektis la ordon de la subetikedoj en la notetikedo. Tutmonde ^xml subetikedoj estos montrataj en alfabeta ordo. Por strikte reflekti la ordon, vi povas uzi, ekzemple, la sekvan ekranon:

JSON.
La unua bildo de sekcio 3.3.1 montras reflektadon de ĉi tiu JSON-dokumento:

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

3.3.4 Identaj strukturoj ligitaj per hierarkiaj rilatoj

Ekzemploj: la strukturo de vendaj oficejoj, la loko de homoj en MLM-strukturo, la datumbazo de malfermoj en ŝako.

Debuta datumbazo. Vi povas uzi la takson de batforto kiel la indeksa valoro de la tutmonda nodo. Tiam, por elekti la plej fortan movon, sufiĉos elekti la branĉon kun la plej granda pezo. En la tutmonda, ĉiuj branĉoj ĉe ĉiu nivelo estos ordigitaj laŭ mova forto.

La strukturo de vendaj oficejoj, la strukturo de homoj en MLM. Nodoj povas stoki certajn kaŝmemorvalorojn, kiuj reflektas la karakterizaĵojn de la tuta subarbo. Ekzemple, la vendokvanto de antaŭfiksita subarbo. Ĉiumomente ni povas akiri figuron reflektantan la atingojn de iu ajn branĉo.

4. En kiuj kazoj estas plej utile uzi globalojn?

La unua kolumno prezentas kazojn, kie vi ricevos signifan rapidan gajnon uzante globalojn, kaj la dua kiam la dezajno aŭ datummodelo estos simpligita.

Rapido
Facileco de datumtraktado/prezento

1. Enmeto [kun aŭtomata ordigo je ĉiu nivelo], [indeksado per ĉefŝlosilo]
2. Forigo de subarboj
3. Objektoj kun multaj nestitaj propraĵoj, kiuj postulas individuan aliron
4. Hierarkia strukturo kun la kapablo preteriri infanajn branĉojn de iu ajn branĉo, eĉ neekzistantaj
5. Profundo-unua trairado de subarboj

1. Objektoj/unuoj kun grandega nombro da laŭvolaj [kaj/aŭ nestitaj] propraĵoj/unuoj
2. Datenoj sen skemoj. Kiam novaj ecoj ofte povas aperi kaj malnovaj malaperas.
3. Vi devas krei kutiman datumbazon.
4. Vodaj bazoj kaj decidaj arboj. Kiam estas oportune reprezenti vojojn kiel arbon.
5. Forigante hierarkiajn strukturojn sen uzi rekursion

Daŭrigo "Tutmondoj estas trezoraj glavoj por konservi datumojn. Maldensaj tabeloj. Parto 3".

malgarantio: Ĉi tiu artikolo kaj miaj komentoj al ĝi estas mia opinio kaj havas neniun rilaton al la oficiala pozicio de InterSystems Corporation.

fonto: www.habr.com