Toto tu len tak necham :: Something smarter than us is going to emerge


node:	Toto tu len tak necham
template:	4
parent:	neo4j a grafove databazy
owner:	ventYl
viewed by:
created:	20.03.2017 - 17:37:04

cwbe coordinatez:
101
63540
63542
8188908
8317649

ABSOLUT
KYBERIA

permissions
you:	r,
system:	public
net:	yes

neurons
stats|by_visit|by_K source tiamat K|my_K|given_K last commanders polls
total descendants::8
total children::2
1 ❤️

show[ 2 | 3] flat

Pred par rokmi som pracoval na projekte bitemporalnej grafovej/objektovej databazy. Vkuse sme sa stretavali (a vlastne sa stale stretavam) s projektami, ktore su postavene na relacnych databazach a tento model si beru aj do navrhu aplikacie a je to uplne nahovno.

Neslo to ani cestou objektovych databaz, kde drvivu vacsinu prace spravi engine, ale za cenu toho, ze je treba objekt ulozit v znamom formate, ani cestou noSQL, kde vsetku robotu urobi aplikacia.

Bol to svojim sposobom experiment, Dali sme dokopy noSQL BLOB ACID-compliant storage rozsireny o podporu temporality (bitemporalny storage a solvovanie temporalnych constraintov nad tymto storage-om), pridali podporu vytvarania "ofarbenych" prepojeni a nad tym sme postavili mechanizmus grafovych temporalnych constraintov pre kontrolu ofarbeni (a ak map pamat neklame aj hierarchickych typovych tagov). Komunikacne rozhranie bol SQL-podobny jazyk modifikovany pre potreby grafovo orientovanych dotazov. Zhruba to vedelo definovat typove tagy (classy) vratane dedicnosti, definovat ofarbenia, constrainty pre kombinaciu ofarbenia a typov v case, CRUD dotazy a vyhladavanie. Kedze sme nechceli, aby databaza vedela cokolvek o vnutornostiach ulozenych dat (pretoze to znizuje rychlost a limituje flexibilitu) tak bolo vyhladavanie postavene grafovo a musela na nom participovat aplikacia. Vedeli sme vytiahnut nejaky podgraf na zaklade filtra vlastnosti, ziskat kliku, rozdiely grafov a take prkotiny. Zda sa mi, ze sme nejako mali vymyslene aj lexikalne hladanie, ale uz sa nepamatam, ako. Neviem ci na to nebol do aplikacie callback.

Bohuzial v stadiu tesne pred sparovanim backendu a frontendu zomrelo financovanie a cely vyvojovy tim bol rozpusteny a vypusteny, takze sa nikdy nedozviem, ci by to bolo zivotaschopne. Sem-tam uvazujem nad tym, ze by som vyzobral zdrojaky a nejako to dotiahol ako open-source.

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

000001010006354000063542081889080831764908321954

heh, dnes som narazil na jeden google projekt:
https://opensource.google.com/projects/badwolf
https://github.com/google/badwolf

00000101000635400006354208188908083176490832195408322371

na ten si spominam, ale uz ti nepoviem, preco som sa po jeho studiu rozhodol, ze je aj tak dobry napad napisat si vlastnu databazu :)

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

000001010006354000063542081889080831764908317718

https://arxiv.org/abs/1604.08568
https://github.com/SocioPatterns/neo4j-dynagraph/wiki/Representing-time-dependent-graphs-in-Neo4j

btw, o kolko dat sa jednalo?

00000101000635400006354208188908083176490831771808317728

ten paper este v tej dobe neexistoval (2011 / 2012) :) dokonca tusim, ze v tej dobe temporalitu do tej miery nemala implementovana ziadna relacna databaza (bitemporalne tabulky s temporalnymi constraintami tusim nevie ani orekl mozno ani dnes). existovali akurat specifikacie pre jazyk TSQL92.

Netrufnem si odhadnut aka by bola skalovatelnost, keby sa frontend sparoval s backendom. Performance schedulera bola velka neznama. Datovy storage bol Berkeley DB a pokial viem, najvacsim performance bottleneckom tam bolo solvovanie temporalnych constraintov (pretoze to je NP uplna mrska).

Ak by si velmi chcel, tak najdem diplomovku a skusim sa pozriet, ci v nej mam nejake performance testy solvera. Nasim cielom bolo na to nasadit system na spravu a monitoring inteligentnej budovy vratane storage-u prevadzkovych logov, takze zaznamov by boli radovo statisice.

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

0000010100063540000635420818890808317649083177180831772808317743

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.