Git based db?

Fejlesztés

Feladat:
van 1 csmó fajta objektum, a típusa és egy adott szám azonosítja. Minden típusnak van 1 csomó mezője, amik nem fedik egymást, pl. A típusú dolog:
A: a1...a235 B dolog: b1...b56, Néha megjelenik egy új példány, néha eltűnik 1, de általában csak változnak
Ezeket könnyen kéne tudni összehasonlítani, hogy mi változott az előző pár verzióhoz képest. Mindig azt akarom csinálni, hogy T-10 naphoz képest a T=0 változat miben tér el.
Gondoltam:
okosan szerializálom őket, pl. minden mező külön sorba kerüljön, rögzített sorrendben az adott típusú dologra nézve
Mindent fájlokban tárolok, pl.:
[url][/url]

Git-be az egészet , minden letöltési ciklus egy commit. a változás kezelését rábízom a diff-re. Nincs olyan, hogy a típusból néha az egyik mezője nem szerepel (az üres mezőre majd kitalálok vmit), vagyis elvben nem lesz olyan, hogy 1-1 sor kiesik ezért felborul a sze/de-rializáció. Későbbiekben lehet olyan, hogy eltűnnek mezők vagy lesznek újak, de az az adott típus összes példányára vonatkozik.

Mit gondolnak azok, akik csináltak már ilyesmit?
-igen, ha egyadott példány kell, az fájlművelet, relatív ritkán fog kelleni
-kell neki a git. Hát, kell.
-Fel kell készíteni arra, ha szétborul a repó. Hát, fel.
+ relatív egyszerű a backup. push, oszt kabát.

  • 1628 megtekintés

Mi lenne, ha a git-tol csak azt kerned le, hogy melyik fileok valtoztak, majd beolvasnad azoknak a regi es uj valtozatat, a diffet pedig te irnad meg (pl. ket JSON kozotti diffet kene)?

Kikerestem, hogy a gitbol kb ezek kellenenek hozza:

$ git diff --name-only HEAD~10 HEAD
$ git show HEAD~10:path/to/file

( golgota | 2017. 06. 21., sze – 08:16 )

Het en erre inkabb egy elastic-ot hasznalnek. Van tipus, azonosito, meg a datum. Ha ugyanaz a tipus es az azonosito a datum akkor is kulonbozo ha valtozott. Igy a tipust es azonositot lekerve adott idopont kozott az osszes valtozat lejon es ezekre kell csak diffet mondani. Sot ebben az esetben azt is meg tudod kerdezni, hogy adott mezo tenyleg valtozott e ket "verzio" (timestamp) kozott. Stb. Stb.

Bar itt olvastam egy jot a versioning hasznalatara a dokumentumokon:
https://www.elastic.co/blog/versioning#sthash.aazLgxnb.dpbs
https://www.elastic.co/blog/elasticsearch-versioning-support#sthash.e13…

( connor v | 2017. 06. 21., sze – 07:57 )

Szerintem a git itt csak a diffet szolgálná, így a storage-re lehet találni bármit, diffelni meg lehet gittől függetlenül is.

Bocs, akkor nem voltam egyértelmű. Én a bármely storage esetén nem úgy gondoltam, hogy minden mező külön mező és úgy hasonlítod össze őket, hanem egy nagy text amire ráengeded a diff-et (key-value storage pl). Ugyan ott vagy mint a git-es megoldás. Nyilván a storage kiválasztása előtt érdemes tudni, hogy read heavy vagy write heavy.

( uid_15426 | 2017. 06. 21., sze – 11:01 )

A te problemad kicsit a CDC-re hasonlit (change data capture). En valoszinuleg beledobnam Kafka-ba, es Streams-el KTable-n keresztul nezegetnem a friss meg a regi ojjektumokat.

A git az oke, de nagyon lassu. A Kafka meg szinten vegulis egy commit log. Csak gyors.

----------------------
while (!sleep) sheep++;

( asch v | 2017. 06. 21., sze – 15:58 )

Van épp egy ehhez hasonló félkész projektem. Nekem tetszik ez a megoldás, persze azzal számolni kell, hogy a git-nek van egy overheadje. Ha a becsült adatmennyiségekkel jól fog működni, akkor hajrá.

Amire én használom, ott két plusz dolgot használok ki a git-ből:

* Végtelen múlt memória - bármely múltbéli állapot visszaállítható. Ezt csak rendszergazda tudja megtenni, a UI-ra nem vezetem ki, de véletlen törlések esetén segíthet.
* Elosztott működés akár elosztott update-tel is megoldódik, ami pedig egyáltalán nem egyszerű hagyományos adatbázis esetén

Az elosztott működést úgy találtam ki, hogy:

* 1 fájlban tárolok 1 "adatlapot" - ez az adatkezelés egysége
* Ha változtat egy user egy fájlt, akkor új random nevű fájl (pl: adatlapkulcs+kliensazonosító+dátum+random) jön létre ugyanazon kulcshoz, az előzőt meg letöröljük.
* A GUI úgy működik, hogy ha egy kulcshoz több adatlap tartozik, akkor mindet megjeleníti. Esetleg felhvhatja a figyelmet, ha egy kulcshoz két adatlap tartozik, akkor össze kell nézni és törölni kell az egyiket (lényegében merge művelet)

Hogy is működik ez?

* offline is írható az adatbázis, amikor online kerül egy kliens, akkor git műveletekkel szinkronizál
* git merge sosem fut konfliktra - mivel egyik fájl sincsen szerkesztve, és sosincs fájlnévütközés. Ezért nincs olyan, hogy valaki ne tudna dolgozni addig, amíg fel nem old egy konfliktust a verziókezelőben.
* ha egyszerre szerkesztettek egy adatlapot, akkor megduplázódik az adatlap. Felhasználói interakció szükséges, ami a szemmel összenézést és az egyik törlését jelenti.
* Az előnye az, hogy nem technikai ember is fel tudja fogni, mégis van minimális merge támogatás. A konflikt várhatóan nagyon ritka lesz, de remélhetőleg ilyenkor nem kell magyarázni a teendőt, mert csak fogják is kitörlik az egyik változatot és kész.