Re[3]: Toto tu len tak necham :: Remember, remember, the velvet November


node:	Re[3]: Toto tu len tak necham
template:	4
parent:	Re[2]: Toto tu len tak necham
owner:	ddd
viewed by:
created:	20.03.2017 - 20:27:36

cwbe coordinatez:
101
63540
63542
8188908
8317649
8317718
8317728
8317743

ABSOLUT
KYBERIA

permissions
you:	r,
system:	public
net:	yes

ak pod temporalnymi constraitmi myslis kliku a tak, tak kopec tych veci sa pre ohranicene velkosti sa to uz vie robit celkom rychlo, jeden smer sa vola sa to fixed-parameter tractability, aj ked teda zrovna klika tam nespada :)

000001010006354000063542081889080831764908317718083177280831774308317791

Velmi zjednodusene: temporalne constrainty su constrainty pre casove vztahy (medzi zaznamami). ucebnicovy priklad temporalneho constraintu je, ze ty sa nemozes narodit skor ako sa narodil tvoj otec a neskor ako by zomrel (ak zanedbame 9 mesiacov tehotenstva). Vypoved v praci nemozes dostat skor, nez si do nej nastupil, atd.

Temporalna databaza je potom taka databaza, ktora ma k zaznamu priradeny aj interval v ktorom je zaznam platny. Z principu potom ide o databazy verzovane, pretoze pre rozne intervaly mozes mat rozne verzie zaznamu.

Bi-temporalna databaza je potom taka databaza, ktora ma timestampy 2. Nie len interval pre platnost entity, napr. ze ty ako osoba si existoval od svojho narodenia a existujes do svojej smrti. Ale aj interval pre platnost zaznamu (t.j. ze zaznam bol vytvoreny v den, ked ti dali vystavit rodny list, ... a bol platny kym sa v nom nespravila zmena).

Tu sa veci zacinaju celkom zaujimavo komplikovat, pretoze skala vztahov je celkom siroka. Napr. mozes chciet vynutit, aby medzi intervalmi platnosti dvoch po sebe iducich verzii zaznamu pre tu istu entitu bola nulova medzera, ale nie je to vseobecne nutne pravidlo. Naopak nie je ziaduce, aby v jednom case boli platne 2 verzie zaznamu. Ale moze sa stat, ze existuju prekryvajuce sa intervaly existencie dvoch roznych entit, atd.

Fundamenty mas potom na seba navrstvene nasledovne:

Na spodku mas storage engine, u nas to bolo BDB, takze ACID compliant s perspektivou clusteringu.

Nad tym je vrstva pridavajuca podporu pre bi-temporalne zaznamy, constraint recorder (ten je v podstate interne tiez len privatna tabulka v ramci storage enginu) a constraint solver. Volanie constraint solvera je automaticke pomocou callbackov pri CRUD operaciach nad datami.

Nad tym je postavena vrstva implementujuca grafovo/lean-objektovo orientovany pristup k datam. Tu su definovane typove tagy a ich hierarchia (opat ulozene ako privatna tabulka v ramci enginu, potencialne temporalna - takze je mozne verzovat aj typovy system grafovej databazy!), ofarbenia hran (tiez potencialne temporalne) a constrainty pre konstrukciu grafu (opat s podporou temporality, navyse tu aj na urovni definicie constraintu, takze bolo mozne zachytit vztah casu platnosti / existencie zaznamov vo vztahu k hrane).

Uplne na vrchu bol parser SQL-like jazyka, scheduler a sietova vrstva. Jazyk mal "DDL" na typovy system, system ofarbenia hran a temporalne constrainty. "DML" pracoval s timestampovanymi BLOBmi (takze DB nevidela dovnutra zaznamu, ale vedela rozsah platnosti) a mal podporu pre robenie rezov.

Takze vo vysledku bolo mozne nadefinovat typovy system pre data v databaze, system ofarbenia hran a definovat pravidla, ktore umoznovali zachytit temporalitu vztahov.

Co taka temporalna pacmaga dokaze out of box a je celkom zaujimave: Ak sa databazou zacnu robit rezy. Rez je v podstate to, ak sa nebudes pytat na vztahy medzi zaznamami poslednej znamej verzie pre aktualny timestamp, ale bud budes cestovat v case po verziach zaznamov (co si databaza o tomto svete myslela pred rokom?) alebo po realnom case (ako vyzeral svet pred rokom?). Bi-temporalna databaza vie robit rezy v oboch dimenziach naraz. Toto bolo implementovane na vrstve pridavajucej temporalitu, takze z pohladu grafoveho layera to bolo transparentne (e.g. nemal by byt vykonnostny rozdiel medzi dotazom na poslednu znamu verziu 'obrazu' skutocneho sveta a dotaz na nejaky snapshot z minulosti).

Bi-temporalne rezy v relacnych databazach bez podpory temporalnych constraintov casto dost skripu, pretoze nie je velky problem najst "deravy" rez, ale pri grafovych databazach to IMHO funguje lepsie.

V ~~prvej~~nultej verzii sme myslim nemali aktivne zapnutu podporu verzovania typovych systemov ani constraintov, pretoze sme chceli vediet, ci to vobec poriadne funguje, ale perspektiva na to tam bola (a z hladiska implementacie slo len nastavit storage pre constrainty ako temporalny a pridat podporu do parsera.

Shitty life is like radiation. You can sustain it for long time if daily doses are small.

00000101000635400006354208188908083176490831771808317728083177430831779108317906

haluz, ja osobne by som to vrstvenie robil uplne opacne, db engine by obsahoval vsetky zname data a logika temporality by bola v aplikacnej casti na urovni kodu.
tj, vzdy by sa robila vseobecna query na zobratie subgrafu (aj so vsetkymi verziami entity) a az priamo v kode aplikacie by sa filtrovalo na temporalitu ci bi-temporalitu.

0000010100063540000635420818890808317649083177180831772808317743083177910831790608318044

tym ti ale typicky v case rastie objem dat, ktore bude aplikacia na rovnaku kveru dostavat proporcionalne s tym, aky bude traffic na databaze.

plus poziadavka na vytiahnutie vsetkych multiverzii rovnakeho zaznamu v domene transakcneho casu nie je uplne typicky workflow. v domene realneho casu je to workflow pomerne zriedkavy a grafove operacie sa nad tym dost dobre robit nedaju, pretoze integrita skrz verzie zaznamu nie je garantovana.

ale ano, existuju riesenia pre podporu temporaliy (zvacsa v relacnych databazach), ktore funguju podobnym sposobom.

Shitty life is like radiation. You can sustain it for long time if daily doses are small.