🥇Ang mga global ay mga treasure-swords para sa pag-iimbak ng data. Mga puno. Bahagi 2

3. Mga variant ng mga istruktura kapag gumagamit ng globals

Ang isang istraktura tulad ng isang iniutos na puno ay may iba't ibang mga espesyal na kaso. Isaalang-alang natin ang mga may praktikal na halaga kapag nagtatrabaho sa mga global.

3.1 Espesyal na kaso 1. Isang node na walang mga sanga

Maaaring gamitin ang mga global hindi lamang tulad ng isang array, ngunit tulad din ng mga regular na variable. Halimbawa, bilang isang counter:

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

Sa kasong ito, ang global, bilang karagdagan sa kahulugan nito, ay maaari ding magkaroon ng mga sangay. Hindi ibinubukod ng isa ang isa.

3.2 Espesyal na kaso 2. Isang vertex at maraming sangay

Sa pangkalahatan, ito ay isang klasikong key-value base. At kung i-save natin ang isang tuple ng mga halaga bilang isang halaga, makakakuha tayo ng isang napaka-ordinaryong talahanayan na may pangunahing susi.

Upang ipatupad ang isang talahanayan sa mga global, kakailanganin nating bumuo ng mga hilera mula sa mga halaga ng column, at pagkatapos ay i-save ang mga ito sa global gamit ang pangunahing key. Upang gawing posible na hatiin muli ang string sa mga column kapag nagbabasa, maaari mong gamitin ang:

mga karakter ng delimiter.

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

isang matibay na pamamaraan kung saan ang bawat field ay sumasakop sa isang paunang natukoy na bilang ng mga byte. Tulad ng ginagawa sa mga relational database.
isang espesyal na function na $LB (magagamit sa Cache), na lumilikha ng isang string ng mga halaga.
```
Set ^t(id1) = $LB("col11", "col21", "col31")
Set ^t(id2) = $LB("col12", "col22", "col32")
```

Kapansin-pansin, hindi mahirap gumamit ng mga global para gumawa ng isang bagay na katulad ng mga pangalawang index sa mga relational database. Tawagin natin ang mga ganitong istrukturang index ng globals. Ang index global ay isang auxiliary tree para sa mabilis na paghahanap sa mga field na hindi bahagi ng pangunahing key ng pangunahing global. Upang punan ito at gamitin ito, kailangan mong magsulat ng karagdagang code.

Gumawa tayo ng index global sa unang column.

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

Ngayon, upang mabilis na maghanap ng impormasyon sa unang hanay, kailangan nating tingnan ang pandaigdigan ^i at hanapin ang mga pangunahing key (id) na tumutugma sa nais na halaga ng unang column.

Kapag naglalagay ng value, maaari naming agad na gawin ang value at index globals para sa mga kinakailangang field. At para sa pagiging maaasahan, ibalot natin ang lahat sa isang transaksyon.

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

Mga detalye kung paano ito gagawin sa M mga talahanayan sa globals, pagtulad sa pangalawang index.

Ang ganitong mga talahanayan ay gagana nang kasing bilis ng sa mga tradisyonal na database (o mas mabilis pa) kung ang mga function para sa pagpasok/pag-update/pagtanggal ng mga row ay nakasulat sa COS/M at pinagsama-sama.Sinuri ko ang pahayag na ito gamit ang mga pagsubok sa maramihang INSERT at SELECT sa isang talahanayan na may dalawang hanay, kasama ang paggamit ng TSTART at TCOMMIT na mga utos (mga transaksyon).

Hindi ko pa nasubukan ang mas kumplikadong mga sitwasyon na may kasabay na pag-access at parallel na mga transaksyon.

Nang hindi gumagamit ng mga transaksyon, ang insertion rate ay 778 inserts/second per million values.
Na may 300 milyong halaga - 422 pagsingit/segundo.

Kapag gumagamit ng mga transaksyon - 572 insert/segundo para sa 082M insert. Ang lahat ng mga operasyon ay isinagawa mula sa pinagsama-samang M code.
Ang mga hard drive ay regular, hindi SSD. RAID5 na may Write-back. Phenom II 1100T processor.

Upang subukan ang isang database ng SQL sa katulad na paraan, kailangan mong magsulat ng isang naka-imbak na pamamaraan na magsasagawa ng mga pagpapasok sa isang loop. Kapag sinusubukan ang MySQL 5.5 (imbakan ng InnoDB), gamit ang pamamaraang ito nakatanggap ako ng mga numero na hindi hihigit sa 11K na pagsingit bawat segundo.
Oo, ang pagpapatupad ng mga talahanayan sa mga global ay mukhang mas kumplikado kaysa sa mga relational na database. Samakatuwid, ang mga pang-industriya na database sa mga global ay may SQL access upang pasimplehin ang trabaho gamit ang tabular na data.

Sa pangkalahatan, kung ang schema ng data ay hindi madalas na magbabago, ang bilis ng pagpasok ay hindi kritikal at ang buong database ay madaling kinakatawan sa anyo ng mga normalized na talahanayan, kung gayon mas madaling magtrabaho kasama ang SQL, dahil nagbibigay ito ng mas mataas na antas ng abstraction. .

Sa partikular na kaso gusto kong ipakita iyon globals ay maaaring kumilos bilang isang constructor para sa paglikha ng iba pang mga database. Tulad ng isang assembler kung saan maaaring isulat ang iba pang mga wika. Narito ang mga halimbawa kung paano ka makakagawa ng mga analogue sa mga global key-value, mga listahan, set, tabular, mga database na nakatuon sa dokumento.

Kung kailangan mong lumikha ng ilang uri ng hindi karaniwang database na may kaunting pagsisikap, dapat kang tumingin sa mga global.

3.3 Espesyal na kaso 3. Dalawang antas na puno, bawat node ng ikalawang antas ay may nakapirming bilang ng mga sanga

Marahil ay nahulaan mo ito: ito ay isang alternatibong pagpapatupad ng mga talahanayan sa mga global. Ihambing natin ang pagpapatupad na ito sa nauna.

Mga talahanayan sa isang dalawang antas na puno vs. sa isang solong antas ng puno.

Cons
Pros

Mas mabagal para sa pagpasok, dahil kailangan mong itakda ang bilang ng mga node na katumbas ng bilang ng mga column.
Higit pang pagkonsumo ng espasyo sa disk. Dahil ang mga pandaigdigang index (nauunawaan bilang mga array index) na may mga pangalan ng column ay kumukuha ng espasyo sa disk at duplicate para sa bawat row.

Mas mabilis na pag-access sa mga halaga ng mga indibidwal na column, dahil hindi na kailangang i-parse ang string. Ayon sa aking mga pagsubok, ito ay 11,5% na mas mabilis sa 2 column at higit pa sa mas malaking bilang ng mga column.
Mas madaling baguhin ang schema ng data
Mas malinaw na code

Konklusyon: hindi para sa lahat. Dahil ang bilis ay isa sa mga pinakamahalagang benepisyo ng mga global, walang kabuluhan ang paggamit ng pagpapatupad na ito, dahil malamang na hindi ito gagana nang mas mabilis kaysa sa mga talahanayan sa mga relational na database.

3.4 Pangkalahatang kaso. Mga puno at nag-order ng mga puno

Ang anumang istruktura ng data na maaaring ilarawan bilang isang puno ay ganap na akma sa mga global.

3.4.1 Mga bagay na may mga paksa

Ito ang lugar ng tradisyonal na paggamit ng mga global. Sa larangang medikal mayroong isang malaking bilang ng mga sakit, gamot, sintomas, at paraan ng paggamot. Ito ay hindi makatwiran upang lumikha ng isang talahanayan na may isang milyong mga patlang para sa bawat pasyente. Bukod dito, 99% ng mga field ay walang laman.

Isipin ang isang database ng SQL ng mga talahanayan: "pasyente" ~ 100 mga patlang, "Gamot" - 000 mga patlang, "Therapy" - 100 mga patlang, "Mga Kumplikasyon" - 000 mga patlang, atbp. at iba pa. O maaari kang lumikha ng isang database ng maraming libu-libong mga talahanayan, bawat isa para sa isang partikular na uri ng pasyente (at maaari silang mag-overlap!), mga paggamot, mga gamot, at libu-libong higit pang mga talahanayan para sa mga koneksyon sa pagitan ng mga talahanayang ito.

Ang mga global ay perpekto para sa gamot, dahil pinapayagan ka nitong lumikha para sa bawat pasyente ng isang tumpak na paglalarawan ng kanyang medikal na kasaysayan, iba't ibang mga therapy, at mga pagkilos ng mga gamot, sa anyo ng isang puno, nang hindi nag-aaksaya ng dagdag na espasyo sa disk sa mga bakanteng column, tulad ng gagawin. maging ang kaso sa isang relational na kaso.

Ang paggamit ng globals ay maginhawa upang lumikha ng isang database na may data tungkol sa mga tao, kapag mahalagang mag-ipon at mag-systematize ng maximum na iba't ibang impormasyon tungkol sa kliyente. Ito ay hinihiling sa medisina, pagbabangko, marketing, pag-archive at iba pang mga lugar

.
Siyempre, sa SQL maaari mo ring tularan ang isang puno na may ilang mga talahanayan lamang (extension ng EAV, 1,2,3,4,5,6,7,8,9,10), gayunpaman ito ay mas kumplikado at magiging mas mabagal. Mahalaga, kailangan mong magsulat ng isang global na gumagana sa mga talahanayan at itago ang lahat ng gawain sa mga talahanayan sa ilalim ng isang abstraction layer. Mali na tularan ang mas mababang antas ng teknolohiya (globals) gamit ang mas mataas na antas na teknolohiya (SQL). Hindi naaangkop.

Hindi lihim na ang pagbabago ng schema ng data sa mga higanteng talahanayan (ALTER TABLE) ay maaaring tumagal ng isang patas na tagal ng oras. Ang MySQL, halimbawa, ay gumagawa ng ALTER TABLE ADD|DROP COLUMN sa pamamagitan ng ganap na pagkopya ng impormasyon mula sa lumang talahanayan patungo sa bagong talahanayan (nasubok na MyISAM, InnoDB engine). Na maaaring mag-hang up ng gumaganang database na may bilyun-bilyong talaan sa loob ng mga araw, kung hindi man linggo.

Ang pagbabago sa istruktura ng data kung gagamit tayo ng globals ay wala tayong gastos. Sa anumang oras maaari kaming magdagdag ng anumang mga bagong katangian na kailangan namin sa anumang bagay, sa anumang antas ng hierarchy. Ang mga pagbabagong nauugnay sa pagpapalit ng pangalan ng mga sangay ay maaaring patakbuhin sa background sa isang tumatakbong database.

Samakatuwid, pagdating sa pag-iimbak ng mga bagay na may malaking bilang ng mga opsyonal na katangian, ang mga global ay isang mahusay na pagpipilian.

Bukod dito, hayaan mong ipaalala ko sa iyo na ang pag-access sa alinman sa mga pag-aari ay instant, dahil sa pandaigdigang lahat ng mga landas ay B-tree.

Ang mga global database, sa pangkalahatan, ay isang uri ng database na nakatuon sa dokumento na may kakayahang mag-imbak ng hierarchical na impormasyon. Samakatuwid, ang mga database na nakatuon sa dokumento ay maaaring makipagkumpitensya sa mga global sa larangan ng pag-iimbak ng mga medikal na rekord. Ngunit hindi pa rin ito parehoKunin natin ang MongoDB para sa paghahambing. Sa domain na ito natatalo ito sa mga global para sa mga sumusunod na dahilan:

Laki ng dokumento. Ang storage unit ay text sa JSON format (mas tiyak na BSON) na may maximum na volume na humigit-kumulang 16MB. Ang paghihigpit ay partikular na ginawa upang ang JSON database ay hindi bumagal sa panahon ng pag-parse kung ang isang malaking JSON na dokumento ay nakaimbak dito at pagkatapos ay na-access ng mga field. Ang dokumentong ito ay dapat maglaman ng lahat ng impormasyon tungkol sa pasyente. Alam nating lahat kung gaano kakapal ang mga rekord ng pasyente. Ang maximum na laki ng card na 16MB ay agad na nagtatapos sa mga pasyente na ang card ng sakit ay kinabibilangan ng mga file ng MRI, X-ray scan at iba pang pag-aaral. Sa isang sangay ng global maaari kang magkaroon ng gigabytes at terabytes ng impormasyon. Sa prinsipyo, maaari nating tapusin ito, ngunit magpapatuloy ako.
Oras ng kamalayan/pagbabago/pagtanggal ng mga bagong katangian sa tsart ng pasyente. Ang nasabing database ay dapat basahin ang buong mapa sa memorya (ito ay isang malaking halaga!), i-parse ang BSON, magdagdag/magbago/magtanggal ng bagong node, mag-update ng mga index, mag-pack nito sa BSON, at i-save ito sa disk. Kailangan lang ng isang global na ma-access ang isang partikular na property at manipulahin ito.
Mabilis na pag-access sa mga indibidwal na pag-aari. Sa maraming pag-aari sa isang dokumento at sa multi-level na istraktura nito, magiging mas mabilis ang pag-access sa mga indibidwal na katangian dahil sa katotohanan na ang bawat landas sa pandaigdigan ay isang B-tree. Sa BSON, kailangan mong linearly na i-parse ang dokumento para mahanap ang gustong property.

3.3.2 Mga nag-uugnay na array

Ang mga nauugnay na array (kahit na may mga nested array) ay akmang-akma sa mga global. Halimbawa, ang naturang array mula sa PHP ay ipapakita sa unang larawan 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 Mga hierarchical na dokumento: XML, JSON

Madaling maimbak din sa mga global. Maaaring ilatag sa iba't ibang paraan para sa imbakan.

XML
Ang pinakamadaling paraan upang i-decompose ang XML sa mga global ay ang pag-imbak ng mga katangian ng tag sa mga node. At kung kailangan ng mabilis na pag-access sa mga katangian ng tag, maaari naming ilipat ang mga ito sa magkakahiwalay na sangay.

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

Sa COS ito ay tumutugma sa code:

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

Komento: Para sa XML, JSON, mga associative array, maaari kang makabuo ng maraming iba't ibang paraan ng pagpapakita sa mga global. Sa kasong ito, hindi namin ipinakita ang pagkakasunud-sunod ng mga subtag sa note tag. Sa buong mundo ^xml ang mga subtag ay ipapakita sa alpabetikong pagkakasunud-sunod. Upang mahigpit na ipakita ang pagkakasunud-sunod, maaari mong gamitin, halimbawa, ang sumusunod na display:

JSON.
Ang unang larawan mula sa seksyon 3.3.1 ay nagpapakita ng repleksyon ng dokumentong ito ng JSON:

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

3.3.4 Magkaparehong mga istruktura na konektado ng mga hierarchical na relasyon

Mga halimbawa: ang istraktura ng mga opisina ng pagbebenta, ang lokasyon ng mga tao sa isang istraktura ng MLM, ang database ng mga pagbubukas sa chess.

Debut sa database. Maaari mong gamitin ang stroke force estimate bilang index value ng global node. Pagkatapos, upang piliin ang pinakamalakas na galaw, sapat na upang piliin ang sangay na may pinakamalaking timbang. Sa pandaigdigan, ang lahat ng sangay sa bawat antas ay pag-uuri-uriin ayon sa lakas ng paggalaw.

Ang istraktura ng mga opisina ng pagbebenta, ang istraktura ng mga tao sa MLM. Ang mga node ay maaaring mag-imbak ng ilang mga halaga ng caching na nagpapakita ng mga katangian ng buong subtree. Halimbawa, ang dami ng benta ng isang ibinigay na subtree. Sa anumang sandali ay makakakuha tayo ng figure na sumasalamin sa mga nagawa ng anumang sangay.

4. Sa anong mga kaso pinaka-kapaki-pakinabang ang paggamit ng globals?

Ang unang column ay nagpapakita ng mga kaso kung saan makakakuha ka ng malaking pagtaas ng bilis sa pamamagitan ng paggamit ng globals, at ang pangalawa kapag ang disenyo o modelo ng data ay pasimplehin.

bilis
Dali ng pagproseso/pagtatanghal ng data

Pagpasok [na may awtomatikong pag-uuri sa bawat antas], [pag-index sa pamamagitan ng master key]
Pag-alis ng mga subtree
Mga bagay na may maraming nested property na nangangailangan ng indibidwal na access
Hierarchical na istraktura na may kakayahang i-bypass ang mga sanga ng bata mula sa anumang sangay, kahit na wala
Lalim-unang pagtawid ng mga subtree

Mga bagay/entity na may malaking bilang ng opsyonal [at/o nested] na property/entity
Data na walang schema. Kapag madalas lumitaw ang mga bagong pag-aari at nawawala ang mga luma.
Kailangan mong lumikha ng isang pasadyang database.
Mga base ng landas at mga puno ng desisyon. Kapag ito ay maginhawa upang kumatawan sa mga landas bilang isang puno.
Pag-alis ng mga hierarchical na istruktura nang hindi gumagamit ng recursion

Karugtong "Ang mga pandaigdigan ay mga treasure-swords para sa pag-iimbak ng data. Kalat-kalat na mga array. Bahagi 3".

Pagtanggi sa pananagutan: Ang artikulong ito at ang mga komento ko dito ay opinyon ko at walang kaugnayan sa opisyal na posisyon ng InterSystems Corporation.

Pinagmulan: www.habr.com

Ang mga global ay mga treasure-sword para sa pag-iimbak ng data. Mga puno. Bahagi 2