Глобалите се ризници за складирање податоци. Дрвја. Дел 2

За почеток - видете дел 1.

3. Варијанти на структури при користење на глобални

Структура како нарачано дрво има различни посебни случаи. Да ги земеме предвид оние што имаат практична вредност кога работиме со глобални.

3.1 Посебен случај 1. Еден јазол без гранки

Глобалите може да се користат не само како низа, туку и како редовни променливи. На пример, како бројач:

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

Во овој случај, глобалното, покрај своето значење, може да има и гранки. Едното не го исклучува другото.

3.2 Посебен случај 2. Едно теме и многу гранки

Општо земено, ова е класична основа за клучна вредност. И ако зачуваме торка вредности како вредност, ќе добиеме многу обична табела со примарен клуч.

За да имплементираме табела за глобални, ќе треба самите да генерираме редови од вредностите на колоната, а потоа да ги зачуваме во глобалната користејќи го примарниот клуч. За да можете повторно да ја поделите низата во колони при читање, можете да користите:

1. разграничувачки знаци.

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

2. ригидна шема во која секое поле зафаќа однапред одреден број бајти. Како што се прави во релационите бази на податоци.
3. специјална функција $LB (достапна во Кеш), која создава низа од вредности.

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

Интересно, не е тешко да се користат глобалните за да се направи нешто слично на секундарните индекси во релационите бази на податоци. Да ги наречеме таквите структури индексни глобални. Глобалниот индекс е помошно стебло за брзо пребарување на полиња кои не се дел од примарниот клуч на главниот глобал. За да го пополните и користите, треба да напишете дополнителен код.

Ајде да создадеме глобален индекс на првата колона.

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

Сега, за брзо пребарување на информации во првата колона, треба да погледнеме во глобалната ^i и најдете ги примарните клучеви (id) што одговараат на саканата вредност од првата колона.

Кога вметнуваме вредност, можеме веднаш да креираме и глобални вредности и индекси за потребните полиња. И за сигурност, ајде да го завиткаме сето тоа во трансакција.

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

Детали за тоа како да го направите тоа на М табели за глобалните, емулација на секундарни индекси.

Таквите табели ќе работат толку брзо како во традиционалните бази на податоци (или уште побрзо) ако функциите за вметнување/ажурирање/бришење редови се напишани во COS/M и компајлирани.Ја проверив оваа изјава со тестови за масовно INSERT и SELECT во една табела со две колони, вклучително и користење на командите TSTART и TCOMMIT (трансакции).

Не сум тестирал посложени сценарија со истовремен пристап и паралелни трансакции.

Без користење на трансакции, стапката на вметнување беше 778 инсерти/секунда на милион вредности.
Со 300 милиони вредности - 422 инсерти/секунда.

При користење на трансакции - 572 инсерти/секунда за 082M инсерти. Сите операции беа извршени од компајлиран М код.
Хард дисковите се редовни, а не SSD. RAID5 со Write-back. Процесор Phenom II 1100T.

За да тестирате SQL база на податоци на сличен начин, треба да напишете складирана процедура која ќе врши вметнувања во јамка. При тестирање на MySQL 5.5 (InnoDB складирање), користејќи го овој метод добив броеви не повеќе од 11K вметнувања во секунда.
Да, имплементацијата на табелите на глобалните страни изгледа посложена отколку во релационите бази на податоци. Затоа, индустриските бази на податоци на глобалните имаат SQL пристап за да се поедностави работата со табеларни податоци.

Општо земено, ако шемата за податоци не се менува често, брзината на вметнување не е критична и целата база на податоци може лесно да се претстави во форма на нормализирани табели, тогаш е полесно да се работи со SQL, бидејќи обезбедува повисоко ниво на апстракција .

Во конкретниов случај сакав да го покажам тоа глобалните можат да дејствуваат како конструктор за креирање на други бази на податоци. Како асемблер на кој може да се пишуваат други јазици. Еве примери за тоа како можете да креирате аналози на глобални клуч-вредност, списоци, множества, табеларни, документи ориентирани бази на податоци.

Ако треба да креирате некаква нестандардна база на податоци со минимален напор, тогаш треба да погледнете кон глобалните.

3.3 Специјален случај 3. Двостепено дрво, секој јазол од второто ниво има фиксен број на гранки

Веројатно погодивте: ова е алтернативна имплементација на табели за глобални. Ајде да ја споредиме оваа имплементација со претходната.

Табели на дрво на две нивоа vs. на дрво на едно ниво.

Конс
Добрите

1. Побавно за вметнување, бидејќи треба да го поставите бројот на јазли еднаков на бројот на колони.
2. Повеќе потрошувачка на простор на дискот. Бидејќи глобалните индекси (разбрани како индекси на низи) со имиња на колони заземаат простор на дискот и се дуплираат за секој ред.

1. Побрз пристап до вредностите на поединечните колони, бидејќи нема потреба да се анализира низата. Според моите тестови, тоа е 11,5% побрзо на 2 колони и повеќе на поголем број колони.
2. Полесно е да се промени шемата за податоци
3. Појасен код

Заклучок: не за секого. Бидејќи брзината е една од најважните придобивки на глобалните, нема смисла да се користи оваа имплементација, бидејќи најверојатно нема да работи побрзо од табелите во релационите бази на податоци.

3.4 Општ случај. Дрвја и нарачани дрвја

Секоја структура на податоци што може да се претстави како дрво совршено се вклопува со глобалните.

3.4.1 Објекти со подобјекти

Ова е област на традиционална употреба на глобалните. Во медицинската област има огромен број на болести, лекови, симптоми и методи на лекување. Нерационално е да се создаде табела со милион полиња за секој пациент. Покрај тоа, 99% од полињата ќе бидат празни.

Замислете SQL база на податоци со табели: „пациент“ ~ 100 полиња, „Медицина“ - 000 полиња, „Терапија“ - 100 полиња, „Компликации“ - 000 полиња итн. и така натаму. Или можете да креирате база на податоци од многу илјадници табели, секоја за специфичен тип на пациент (и тие може да се преклопуваат!), третмани, лекови и уште илјадници табели за врски помеѓу овие табели.

Глобалите се идеални за медицина, бидејќи ви овозможуваат да креирате за секој пациент точен опис на неговата медицинска историја, различни терапии и дејството на лековите, во форма на дрво, без да трошите дополнителен простор на дискот на празни колони, како што би да биде случај во релациски случај.

Со користење на глобални, погодно е да се создаде база на податоци со податоци за луѓе, кога е важно да се акумулираат и систематизираат максимум различни информации за клиентот. Ова е барано во медицината, банкарството, маркетингот, архивирањето и други области

.
Се разбира, во SQL можете исто така да имитирате дрво со само неколку табели (ЕАВ, 1,2,3,4,5,6,7,8,9,10), сепак ова е значително покомплицирано и ќе биде побавно. Во суштина, ќе треба да напишете глобален кој работи на табели и да ја скриете целата работа со табели под слој на апстракција. Погрешно е да се емулира технологија од пониско ниво (глобални) користејќи технологија на повисоко ниво (SQL). Несоодветно.

Не е тајна дека менувањето на шемата за податоци на огромните табели (ALTER TABLE) може да потрае прилично време. MySQL, на пример, прави ALTER TABLE ADD|DROP COLOMN со целосно копирање на информации од старата табела во новата табела (тестирани MyISAM, InnoDB мотори). Што може да закачи работна база на податоци со милијарди записи со денови, ако не и недели.

Промената на структурата на податоците ако користиме глобални не чини ништо. Во секое време можеме да додадеме какви било нови својства што ни се потребни на кој било објект, на кое било ниво од хиерархијата. Промените поврзани со преименување гранки може да се извршат во заднина на базата на податоци што работи.


Затоа, кога станува збор за складирање на објекти со огромен број изборни својства, глобалните се одличен избор.

Дополнително, дозволете ми да ве потсетам дека пристапот до која било од својствата е моментален, бидејќи во глобалното сите патеки се Б-дрва.

Глобалните бази на податоци, генерално, се тип на база на податоци ориентирана кон документи со можност за складирање на хиерархиски информации. Затоа, базите на податоци ориентирани кон документи можат да се натпреваруваат со глобалните во полето на чување медицински досиеја. Но, сè уште не е сосема истоДа го земеме MongoDB за споредба. Во овој домен губи од глобалните од следниве причини:

1. Големина на документот. Единицата за складирање е текст во JSON формат (поточно BSON) со максимален волумен од околу 16MB. Ограничувањето е направено специјално за да не се забави JSON базата на податоци за време на парсирањето ако во неа се складира огромен JSON документ и потоа се пристапува преку полиња. Овој документ треба да ги содржи сите информации за пациентот. Сите знаеме колку може да биде густа евиденцијата на пациентите. Максималната големина на картичката од 16 MB веднаш става крај на пациентите чија картичка на болеста вклучува датотеки со МРИ, скенирање на рендген и други студии. Во една гранка на глобалното можете да имате гигабајти и терабајти информации. Во принцип, можеме да ставиме крај на ова, но јас ќе продолжам.
2. Време на свест/промена/бришење на нови својства во табелата на пациентот. Таквата база на податоци мора да ја прочита целата мапа во меморијата (ова е голема количина!), да го анализира BSON, да додава/промени/брише нов јазол, да ги ажурира индексите, да ја спакува во BSON и да ја зачува на дискот. Еден глобален треба само да пристапи до одреден имот и да манипулира со него.
3. Брз пристап до индивидуални имоти. Со многу својства во документот и неговата структура на повеќе нивоа, пристапот до поединечни својства ќе биде побрз поради фактот што секоја патека во глобалната е Б-дрво. Во BSON, треба линеарно да го анализирате документот за да го пронајдете саканото својство.

3.3.2 Асоцијативни низи

Асоцијативните низи (дури и со вгнездени низи) совршено се вклопуваат кај глобалните. На пример, таква низа од PHP ќе биде прикажана на првата слика 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 Хиерархиски документи: XML, JSON

Исто така лесно се складира во глобални. Може да се постави на различни начини за складирање.

XML
Најлесен начин да се разложи XML на глобални е да се складираат атрибутите на ознаките во јазли. И ако е потребен брз пристап до атрибутите на ознаките, тогаш можеме да ги преместиме во посебни гранки.

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

На COS ова би одговарало на кодот:

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

Коментар: За XML, JSON, асоцијативни низи, можете да смислите многу различни начини на прикажување на глобалните. Во овој случај, не го одразивме редоследот на подознаките во ознаката за белешки. Глобално ^xml подознаките ќе бидат прикажани по азбучен ред. За строго да го одразите редоследот, можете да го користите, на пример, следниов приказ:

JSON.
Првата слика од делот 3.3.1 покажува одраз на овој JSON документ:

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

3.3.4 Идентични структури поврзани со хиерархиски односи

Примери: структурата на канцелариите за продажба, локацијата на луѓето во структурата на MLM, базата на податоци за отворите во шахот.

Дебитантска база на податоци. Можете да ја користите проценката на силата на ударот како индексна вредност на глобалниот јазол. Потоа, за да се избере најсилниот потег, доволно ќе биде да се избере гранката со најголема тежина. Во глобалното, сите гранки на секое ниво ќе бидат подредени според силата на движење.

Структурата на продажните канцеларии, структурата на луѓето во МЛМ. Јазлите можат да складираат одредени вредности за кеширање што ги одразуваат карактеристиките на целото поддрво. На пример, обемот на продажба на дадено поддрво. Во секој момент можеме да добиеме фигура која ги одразува достигнувањата на која било гранка.

4. Во кои случаи е најкорисно да се користат глобални?

Првата колона ги прикажува случаите каде што ќе добиете значително зголемување на брзината со користење на глобални, а втората кога дизајнот или моделот на податоци ќе бидат поедноставени.

Брзина
Леснотија на обработка/презентација на податоците

1. Вметнување [со автоматско сортирање на секое ниво], [индексирање по главен клуч]
2. Отстранување на поддрвјата
3. Објекти со многу вгнездени својства кои бараат индивидуален пристап
4. Хиерархиска структура со можност да се заобиколат детските гранки од која било гранка, дури и од непостоечки
5. Длабочина-прво преминување на поддрва

1. Објекти/ентитети со огромен број на изборни [и/или вгнездени] својства/ентитети
2. Податоци без шема. Кога често може да се појават нови својства, а старите да исчезнат.
3. Треба да креирате сопствена база на податоци.
4. Основи на патеки и стебла на одлуки. Кога е погодно да се претстават патеките како дрво.
5. Отстранување на хиерархиски структури без употреба на рекурзија

Продолжување „Глобалите се ризници за складирање податоци. Ретки низи. Дел 3".

Општи услови: Оваа статија и моите коментари за неа се мое мислење и немаат врска со официјалниот став на InterSystems Corporation.

Извор: www.habr.com