Globālie ir dārgumu zobeni datu glabāšanai. Koki. 2. daļa

Darba sākšana — skatiet 1. daļu.

3. Struktūru varianti, lietojot globālās

Tādai struktūrai kā sakārtots koks ir dažādi īpaši gadījumi. Apskatīsim tos, kuriem ir praktiska vērtība, strādājot ar globālajiem.

3.1 Īpašs gadījums 1. Viens mezgls bez atzariem

Globālos var izmantot ne tikai kā masīvu, bet arī kā parastos mainīgos. Piemēram, kā skaitītājs:

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

Šajā gadījumā globālajam papildus nozīmei var būt arī atzari. Viens neizslēdz otru.

3.2. Īpašs gadījums 2. Viena virsotne un daudzi zari

Kopumā šī ir klasiska atslēgas vērtību bāze. Un, ja mēs saglabāsim vērtību virkni kā vērtību, mēs iegūsim ļoti parastu tabulu ar primāro atslēgu.

Lai ieviestu globālo tabulu, mums pašiem būs jāģenerē rindas no kolonnu vērtībām un pēc tam jāsaglabā tās globālajā, izmantojot primāro atslēgu. Lai lasīšanas laikā virkni atkal varētu sadalīt kolonnās, varat izmantot:

1. norobežojošās rakstzīmes.

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

2. stingra shēma, kurā katrs lauks aizņem iepriekš noteiktu baitu skaitu. Kā tas tiek darīts relāciju datu bāzēs.
3. īpaša funkcija $LB (pieejama kešatmiņā), kas izveido vērtību virkni.

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

Interesanti, ka nav grūti izmantot globālos rādītājus, lai veiktu kaut ko līdzīgu sekundārajiem indeksiem relāciju datu bāzēs. Sauksim šādas indeksu struktūras par globālajām. Globālais indekss ir palīgkoks, lai ātri meklētu laukus, kas nav daļa no galvenā globālā primārās atslēgas. Lai to aizpildītu un izmantotu, ir jāieraksta papildu kods.

Pirmajā kolonnā izveidosim globālu indeksu.

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

Tagad, lai ātri meklētu informāciju pirmajā kolonnā, mums ir jāielūkojas globālajā ^i un atrodiet primārās atslēgas (id), kas atbilst vēlamajai pirmās kolonnas vērtībai.

Ievietojot vērtību, mēs nekavējoties varam izveidot gan vērtību, gan indeksa globālos parametrus nepieciešamajiem laukiem. Un uzticamības labad iekļausim to visu darījumā.

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

Sīkāka informācija par to, kā to izdarīt vietnē M tabulas par globālajiem, sekundāro indeksu emulācija.

Šādas tabulas darbosies tikpat ātri kā tradicionālajās datubāzēs (vai pat ātrāk), ja rindu ievietošanas/atjaunināšanas/dzēšanas funkcijas tiks ierakstītas COS/M un kompilētas.Es pārbaudīju šo paziņojumu, veicot lielapjoma INSERT un SELECT testus vienā divu kolonnu tabulā, tostarp izmantojot komandas TSTART un TCOMMIT (transakcijas).

Es neesmu pārbaudījis sarežģītākus scenārijus ar vienlaicīgu piekļuvi un paralēliem darījumiem.

Neizmantojot darījumus, ievietošanas ātrums bija 778 361 ievietojums sekundē uz miljonu vērtību.
Ar 300 miljoniem vērtību - 422 141 ieliktnis sekundē.

Izmantojot transakcijas - 572 082 ieliktņi/sek par 50M ieliktņiem. Visas darbības tika veiktas no apkopotā M koda.
Cietie diski ir parasti, nevis SSD. RAID5 ar atrakstīšanu. Phenom II 1100T procesors.

Lai līdzīgā veidā pārbaudītu SQL datu bāzi, jums ir jāuzraksta saglabāta procedūra, kas veiks ievietošanu cilpā. Pārbaudot MySQL 5.5 (InnoDB krātuvi), izmantojot šo metodi, es saņēmu skaitļus ne vairāk kā 11 XNUMX ievietošanas sekundē.
Jā, tabulu ieviešana globālajās sistēmās izskatās sarežģītāka nekā relāciju datu bāzēs. Tāpēc rūpnieciskajām datubāzēm globālajos datubāzēs ir SQL piekļuve, lai vienkāršotu darbu ar tabulas datiem.

Parasti, ja datu shēma nemainīsies bieži, ievietošanas ātrums nav kritisks un visu datu bāzi var viegli attēlot normalizētu tabulu veidā, tad ir vieglāk strādāt ar SQL, jo tas nodrošina augstāku abstrakcijas līmeni. .

Šajā konkrētajā gadījumā es gribēju to parādīt globals var darboties kā konstruktors citu datu bāzu izveidei. Tāpat kā montētājs, kurā var rakstīt citās valodās. Šeit ir piemēri, kā izveidot analogus globālajos tālruņos atslēgas vērtības, saraksti, kopas, tabulas, uz dokumentiem orientētas datu bāzes.

Ja ar minimālu piepūli jāizveido kāda nestandarta datu bāze, tad jāskatās uz globālajiem.

3.3. Īpašs gadījums 3. Divu līmeņu koks, katram otrā līmeņa mezglam ir noteikts zaru skaits

Jūs droši vien uzminējāt: šī ir alternatīva tabulu ieviešana globālajās ierīcēs. Salīdzināsim šo ieviešanu ar iepriekšējo.

Tabulas uz divu līmeņu koka vs. uz vienlīmeņa koka.

Mīnusi
Plusi

1. Lēnāk ievietošanai, jo jums ir jāiestata mezglu skaits, kas vienāds ar kolonnu skaitu.
2. Lielāks diska vietas patēriņš. Tā kā globālie indeksi (tiek saprasti kā masīva indeksi) ar kolonnu nosaukumiem aizņem vietu diskā un tiek dublēti katrai rindai.

1. Ātrāka piekļuve atsevišķu kolonnu vērtībām, jo ​​nav nepieciešams parsēt virkni. Saskaņā ar maniem testiem tas ir par 11,5% ātrāks uz 2 kolonnām un vairāk uz lielāku kolonnu skaitu.
2. Vieglāk mainīt datu shēmu
3. Skaidrāks kods

Secinājums: ne visiem. Tā kā ātrums ir viena no galvenajām globālajām priekšrocībām, nav jēgas izmantot šo ieviešanu, jo tā, visticamāk, nedarbosies ātrāk nekā tabulas relāciju datu bāzēs.

3.4. Vispārējs gadījums. Koki un sakārtoti koki

Jebkura datu struktūra, ko var attēlot kā koku, lieliski iederas ar globālajām vērtībām.

3.4.1 Objekti ar apakšobjektiem

Šī ir globālu tradicionālās izmantošanas joma. Medicīnas jomā ir milzīgs skaits slimību, medikamentu, simptomu un ārstēšanas metožu. Ir neracionāli izveidot tabulu ar miljons laukiem katram pacientam. Turklāt 99% lauku būs tukši.

Iedomājieties SQL tabulu datu bāzi: “pacients” ~ 100 000 lauku, “Medicīna” – 100 000 lauku, “Terapija” – 100 000 lauku, “Komplikācijas” – 100 000 lauku utt. un tā tālāk. Vai arī varat izveidot datu bāzi ar daudziem tūkstošiem tabulu, katra noteiktam pacienta tipam (un tās var pārklāties!), ārstēšanas metodēm, medikamentiem un tūkstošiem citu tabulu savienojumu starp šīm tabulām.

Globālie modeļi ir ideāli piemēroti medicīnai, jo ļauj katram pacientam izveidot precīzu viņa slimības vēstures, dažādu terapiju un medikamentu darbības aprakstu koka veidā, netērējot papildu vietu diskā tukšās kolonnās, kā tas būtu. būt relāciju gadījumā.

Izmantojot globalus, ir ērti izveidot datu bāzi ar datiem par cilvēkiem, kad ir svarīgi uzkrāt un sistematizēt maksimāli daudz dažādu informāciju par klientu. Tas ir pieprasīts medicīnā, banku darbībā, mārketingā, arhivēšanā un citās jomās

.
Protams, SQL var arī emulēt koku tikai ar dažām tabulām (EAV, 1,2,3,4,5,6,7,8,9,10), tomēr tas ir ievērojami sarežģītāk un būs lēnāks. Būtībā jums būtu jāraksta globāls, kas darbojas uz tabulām, un viss darbs ar tabulām jāpaslēpj zem abstrakcijas slāņa. Ir nepareizi atdarināt zemāka līmeņa tehnoloģijas (globālos), izmantojot augstāka līmeņa tehnoloģiju (SQL). Nepiemērots.

Nav noslēpums, ka datu shēmas maiņa milzu tabulās (ALTER TABLE) var aizņemt diezgan daudz laika. MySQL, piemēram, veic ALTER TABLE ADD|DROP COLUMN, pilnībā kopējot informāciju no vecās tabulas uz jauno tabulu (pārbaudīti MyISAM, InnoDB dzinēji). Kas var piekārt darba datubāzi ar miljardiem ierakstu dienām, ja ne nedēļām.

Datu struktūras maiņa, ja mēs izmantojam globālos datus, mums neko nemaksā. Jebkurā laikā mēs varam pievienot jebkurus jaunus rekvizītus, kas mums nepieciešami jebkuram objektam, jebkurā hierarhijas līmenī. Izmaiņas, kas saistītas ar zaru pārdēvēšanu, var palaist fonā strādājošā datu bāzē.


Tāpēc, ja runa ir par objektu glabāšanu ar lielu skaitu izvēles īpašību, globālie ir lieliska izvēle.

Turklāt atgādināšu, ka piekļuve jebkuram īpašumam ir tūlītēja, jo globālā mērogā visi ceļi ir B-koki.

Globālās datu bāzes kopumā ir uz dokumentiem orientētas datu bāzes veids ar iespēju uzglabāt hierarhisku informāciju. Tāpēc uz dokumentiem orientētas datu bāzes var konkurēt ar globālajām datubāzēm medicīnisko ierakstu glabāšanas jomā. Bet tas joprojām nav gluži tas patsSalīdzinājumam ņemsim MongoDB. Šajā domēnā tā zaudē globālajiem spēlētājiem šādu iemeslu dēļ:

1. Dokumenta izmērs. Krātuves vienība ir teksts JSON formātā (precīzāk BSON) ar maksimālo apjomu aptuveni 16 MB. Ierobežojums tika izveidots īpaši, lai JSON datubāze nepalēninātu parsēšanas laikā, ja tajā tiek glabāts milzīgs JSON dokuments un pēc tam tam tiek piekļūts ar laukiem. Šajā dokumentā jābūt visai informācijai par pacientu. Mēs visi zinām, cik biezi var būt pacientu ieraksti. Maksimālais kartes izmērs 16 MB nekavējoties pieliek punktu pacientiem, kuru slimības kartē ir iekļauti MRI faili, rentgena skenēšana un citi pētījumi. Vienā pasaules atzarā var būt gigabaiti un terabaiti informācijas. Principā mēs tam varam pielikt punktu, bet es turpināšu.
2. Apziņas/izmaiņas/jaunu īpašību dzēšanas laiks pacienta diagrammā. Šādai datubāzei ir jānolasa atmiņā visa karte (tas ir liels daudzums!), parsē BSON, jāpievieno/maina/dzēš jauns mezgls, jāatjaunina indeksi, jāiepako BSON un jāsaglabā diskā. Globālajam ir tikai jāpiekļūst noteiktam rekvizītam un ar to jārīkojas.
3. Ātra piekļuve atsevišķiem īpašumiem. Ja dokumentā ir daudz rekvizītu un tā daudzlīmeņu struktūra, piekļuve atsevišķiem rekvizītiem būs ātrāka, jo katrs globālais ceļš ir B-koks. Programmā BSON dokuments ir lineāri jāparsē, lai atrastu vajadzīgo rekvizītu.

3.3.2. Asociatīvie masīvi

Asociatīvie masīvi (pat ar ligzdotiem masīviem) lieliski iederas globālajos rādītājos. Piemēram, šāds masīvs no PHP tiks parādīts pirmajā attēlā 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. Hierarhiskie dokumenti: XML, JSON

Arī viegli glabājas globālajos. Var izkārtot dažādos veidos uzglabāšanai.

XML
Vienkāršākais veids, kā sadalīt XML globālos veidos, ir saglabāt tagu atribūtus mezglos. Un, ja ir nepieciešama ātra piekļuve tagu atribūtiem, mēs varam tos pārvietot atsevišķās filiālēs.

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

Uz COS tas atbilstu kodam:

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

Piezīme: XML, JSON un asociatīvajiem masīviem varat izdomāt daudz dažādu veidu, kā attēlot globālos attēlus. Šajā gadījumā mēs neatspoguļojām piezīmju tagā esošo apakštagu secību. Globāli ^xml apakšbirkas tiks parādītas alfabētiskā secībā. Lai precīzi atspoguļotu pasūtījumu, varat izmantot, piemēram, šādu displeju:

JSON.
Pirmajā attēlā no sadaļas 3.3.1 ir parādīts šī JSON dokumenta atspoguļojums:

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

3.3.4. Identiskas struktūras, kas savienotas ar hierarhiskām attiecībām

Piemēri: pārdošanas biroju struktūra, cilvēku atrašanās vieta MLM struktūrā, šaha atvērumu datubāze.

Debijas datubāze. Gājiena spēka aprēķinu varat izmantot kā globālā mezgla indeksa vērtību. Tad, lai izvēlētos spēcīgāko gājienu, pietiks izvēlēties zaru ar vislielāko svaru. Globālajā pasaulē visas filiāles katrā līmenī tiks sakārtotas pēc kustības stipruma.

Pārdošanas biroju struktūra, cilvēku struktūra MLM. Mezgli var saglabāt noteiktas kešatmiņas vērtības, kas atspoguļo visa apakškoka īpašības. Piemēram, dotā apakškoka pārdošanas apjoms. Jebkurā brīdī mēs varam iegūt figūru, kas atspoguļo jebkuras nozares sasniegumus.

4. Kādos gadījumos visizdevīgāk ir izmantot globālos?

Pirmajā kolonnā ir parādīti gadījumi, kad jūs iegūsit ievērojamu ātruma pieaugumu, izmantojot globālos parametrus, bet otrajā ailē, kad dizains vai datu modelis tiks vienkāršots.

Ātrums
Datu apstrādes/pasniegšanas vienkāršība

1. Ievietošana [ar automātisku kārtošanu katrā līmenī], [indeksēšana pēc galvenās atslēgas]
2. Apakškoku noņemšana
3. Objekti ar daudziem ligzdotiem rekvizītiem, kuriem nepieciešama individuāla piekļuve
4. Hierarhiska struktūra ar iespēju apiet bērnu atzarus no jebkuras, pat neesošas, filiāles
5. Apakškoku šķērsošana dziļumā

1. Objekti/entītijas ar lielu skaitu izvēles [un/vai ligzdotu] rekvizītu/entītiju
2. Dati bez shēmām. Kad bieži var parādīties jauni īpašumi un pazust vecie.
3. Jums ir jāizveido pielāgota datu bāze.
4. Ceļu bāzes un lēmumu koki. Kad ir ērti attēlot ceļus kā koku.
5. Hierarhisku struktūru noņemšana, neizmantojot rekursiju

Pagarināšana “Globāli ir dārgumu zobeni datu glabāšanai. Reti masīvi. 3. daļa.

Atbildības noraidīšana: Šis raksts un mani komentāri par to ir mans viedoklis, un tiem nav nekādas saistības ar InterSystems Corporation oficiālo nostāju.

Avots: www.habr.com