ugrás a tartalomhoz

Backup your Database in Git

inf3rno · 2016. Feb. 13. (Szo), 15.45
Célszerű a kisebb adatbázisok backupjának verziózása, ha spórolni akarunk a hellyel
 
1

Sajnos nem jött be. Egy éve

Joó Ádám · 2016. Feb. 13. (Szo), 15.48
Sajnos nem jött be. Egy éve csinálom, és napi egyszeri mentés mellett egy 150 megabájtos MySQL dump azóta 11 gigabájtosra duzzasztotta a git repót, annak ellenére, hogy minden mentés végén futtatom a gc-t.
2

Lehet, hogy sokat kérek, de

inf3rno · 2016. Feb. 13. (Szo), 17.46
Lehet, hogy sokat kérek, de le tudod tesztelni, hogy nyersen a dump fájlok mondjuk zip-be tömörítve mennyik lennének? Lehet, hogy több értelme lenne mondjuk havi szinten egy zip-et csinálni, mint git-tel szórakozni, bár verziókövetés szempontjából kétségtelen, hogy a git a jobb.
3

Mármint egyetlen dump mennyi

Joó Ádám · 2016. Feb. 13. (Szo), 18.06
Mármint egyetlen dump mennyi lenne? Egyébként én is keresem a jobb megoldást, lehetőleg mind a verziózást, mind a tömörítést megtartva.
4

Nem, annyi dump, ami most

inf3rno · 2016. Feb. 13. (Szo), 18.24
Nem, annyi dump, ami most 11GB helyet foglal verziózva. De ha ez túl nagy adatmennyiség, akkor meg lehetne nézni, hogy csak egy havi anyagot szedsz ki a repo-ból külön fájlokba, és tömöríted be zippel, aztán azt összehasonlítod a git-es megoldással ugyanennyi felülírással. Erről kapásból lehetne írni egy blog bejegyzést.
5

Rendben, megpróbálom egy-két

Joó Ádám · 2016. Feb. 13. (Szo), 18.34
Rendben, megpróbálom egy-két napon belül, ha esetleg megfeledkeznék róla, akkor itt vagy mailben uppold a dolgot.
6

Okés, köszi!

inf3rno · 2016. Feb. 13. (Szo), 18.40
Okés, köszi! Kíváncsi vagyok, mert elvileg a git is tömörít. Nem nagyon értem, hogy mi foglalhat benne ennyi plusz helyet.
7

Erről mindenki mást ír,

Joó Ádám · 2016. Feb. 13. (Szo), 18.41
Erről mindenki mást ír, felületes kereséssel szinte lehetetlen érdemi választ kapni, hogy most akkor mikor és mennyire tömörít.
8

Percona XtraBackup

solkprog · 2016. Feb. 13. (Szo), 19.06
Percona XtraBackup -ot nézted?
Kell neked 1 évre visszamenőleg napi szintű backup?

Illetve ha törölsz gitből egy commitot akkor csökken a mérete a repónak? (sose néztem)
9

Percona XtraBackup -ot

Joó Ádám · 2016. Feb. 13. (Szo), 19.16
Percona XtraBackup -ot nézted?


Nem ismerem, de jó lenne adatbázis-agnosztikus megoldást találni.

Kell neked 1 évre visszamenőleg napi szintű backup?


Nem feltétlen, de szép lenne.

Illetve ha törölsz gitből egy commitot akkor csökken a mérete a repónak? (sose néztem)


Megnézhetem ezt is, miben gondolkodsz?
10

átgondoltam: nem szóltam.

solkprog · 2016. Feb. 13. (Szo), 19.42
közbe rájöttem hogy amire én gondoltam az ebben az esetben nem fog működni. Főleg nem automatizálva.

(azon a vonalon gondolkoztam hogy lehet törölni fájlt a git repóból komplett history-stúl (ezt csináltam már tök jól működik), rebase-el commitokat törölni elvileg (ezt sose csináltam), illetve azon a vonalon gondolkoztam hogy talán az utolsó 1 hónap history-ját valahogy ki lehetne menteni egy új repóba - bár az utóbbit nem tudom hogy lehet-e.)

Mondjuk egy olyan megoldás el tudok képzelni:
- a repóba hónap szinten mented a dump-ot. dump_2016_01.sql, és januárba erre mennek a dumpok, majd új hónapban új fájlt kezdesz a repóban.
- ilyenkor viszont már lehet törölni a 3 hónapnál régebbi fájlokat a repoból history-túl
(de nem tudom hogy csökken-e ilyenkor a repó tényleges mérete)
26

Hát szerintem valahogy

inf3rno · 2016. Feb. 14. (V), 18.05
Hát szerintem valahogy hasonlóan kéne ezt csinálni, mint a git flow-ot. Szóval granularitástól függően több branch kell, pl napi, havi és éves. Ezen kívül minden hónapban nyitnánk új napi és minden évben új havi branch-et, amibe átmásolnánk az aktuális backup fájlt (nem mergelnénk). Így mindig lenne egy aktuális napi, havi és éves branch, és eldönthetnénk, hogy visszamenőleg a már nem aktuálisokból mennyit tartunk meg.

- annual
  - 16-01-01
  - 15-01-01
  ...
- monthly (16)
  - 16-02-01
  - 16-01-01
- daily (16-02)
  - 16-02-14
  - 16-02-13
  - 16-02-12
  ...
  - 16-02-01
- archive daily (16-01)
  - 16-01-31
  - 16-01-30
  - 16-01-29
  ...
  - 16-01-01
- archive daily (15-12)
  - 15-12-31
  - 15-12-30
  - 15-12-29
  ...
  - 15-12-01
...
- archive monthly (15)
  - 15-12
  - 15-11
  - 15-10
  ...
  - 15-01
- archive monthly (14)
  - 14-12
  - 14-11
  - 14-10
  ...
  - 14-01
...


Mondjuk csinálhatjuk azt, hogy visszamenőleg 3 hónap napi mentéseit, illetve 1 év havi mentéseit tartjuk meg. Így nagyjából állandó 3x31 + ~15 (napi) + 12 + ~6 (havi) + ~5 (éves) = 131+/-20 a commit szám. Talán ha még jobban átgondoljuk, hogy melyik ág melyikből ágazzon le, pl a napi a havi commit-ból, a havi az éves commit-ból, stb., akkor még további helyet lehet spórolni, mert nem duplázza az adatot. Én legalábbis valahogy így csinálnám, ha tényleg irreálisan sok helyet foglal egy branch-en verziózva az összes napi mentés.

Elméletileg zip-be tömörítve is el lehet érni ugyanazt, mint gittel, hogy csak az új adat foglaljon helyet. Szóval branch-ek helyett pl egymásba rakott zip fájlokkal is meg lehetne oldani a kérdést, viszont szerintem az sérülékenyebb lenne, mint gittel csinálni. Ha neadjisten valami hiba kerül a fájlba, akkor kevés az esély rá, hogy bármit vissza tudunk nyerni a backup-okból.
30

A zipek egymásba ágyazása

Joó Ádám · 2016. Feb. 14. (V), 18.49
A zipek egymásba ágyazása szerintem a tömörítést is elég erősen lerontaná.
31

Szerintem ezt nehéz így

inf3rno · 2016. Feb. 14. (V), 19.44
Szerintem ezt nehéz így megmondani, mert a zip-et talán inkább csak az érdekli, hogy információ duplikálás van, az kevésbé érdekelheti, hogy az az információ már egyszer tömörítve lett. Kipróbálom, kíváncsi vagyok.
32

Kipróbáltam nem dumpon, hanem

inf3rno · 2016. Feb. 14. (V), 21.44
Kipróbáltam nem dumpon, hanem egy nodejs projekten, kb 100MB, pár tízezer fájl a dependencykkel együtt. Lemásoltam a mappát, az egyikből töröltem néhány dependency-t. Tömörítőnek 7z-t használtam és zip-be tömörítettem.

- a.) A két mappa együtt nyersen 183MB.
- b.) A két mappa együtt tömörítve 80.4MB.
- c.) Az egyik mappa zip-je és a másik nyerse betömörítve 72.6MB.

Az megint egy érdekes kérdés, hogy vajon miért kisebb a c.), mint a b.) holott én egyforma eredményt vártam, te meg pont a fordítottját.

A nagy mappa egyedül 100MB. Nem hiszem, hogy a Git ezen sokat javítana, bár én sem tudom, hogy belül milyen varázslatokat használ, meg ez a teszt sem a legjobb, mert az alap kérdésben sok kicsi napi szintű változásról volt szó, nem egy nagyról. Most nekem nincs megfelelő teszt adatom, hogy jobban megnézzem, megvárom, hogy Ádám mire jut vele a dumpjaival.
35

Nem teljesen azonos azzal

city99 · 2016. Feb. 19. (P), 10.17
Nem teljesen azonos azzal amit te irsz, mivel inkabb snapshot, de 10 eve hasznalunk egy scriptet ami egy virtualhostos webszerveren talalhato adatbazisokat menti kovetkezo kepen: h-v-ig 1 dump, minden penteken 1 honapra visszamenoleg 1 dump, es minden honap utolso penteket 1 evig visszamenoleg ez igy 23-24 dump osszesen.
Igaz igy nem lehet 3 honappal ezelotti szerdai allapotot reprezentalni, de a tapasztalat az hogy sose volt ra szukseg.
36

Reméljük soha nem is lesz.

inf3rno · 2016. Feb. 19. (P), 11.30
Reméljük soha nem is lesz. :-)
37

Ezeknel a szolgaltatasoknal

city99 · 2016. Feb. 19. (P), 13.46
Ezeknel a szolgaltatasoknal igy 18 ev tapasztalata szerintem eleg jo merites ;)
Termeszetesen komolyabb megoldasokat is hasznalunk, de ott komolyabb is az igeny es azokert komolyabban is hajlandok csengetni az ugyfelek ;)
13

Sorrend

vbence · 2016. Feb. 14. (V), 10.12
A rekordok sorrendje sokat számít, ha diffelsz. Állandó két mentés között? Pl: új rekordok kerüljenek mindig a régiek után.

Tuti, hogy minden rekord új sorba kerül? Ha jól emlékszem defaultban egy ideje egyetlen sorba kerül egy tábla, ami diff-ben a teljes sor két verzióját jelenti.
15

A dump --skip-extended-insert

Joó Ádám · 2016. Feb. 14. (V), 14.44
A dump --skip-extended-insert flaggel készül, egy rekord egy sor. Ránézve két commit közt a diffre, a változások a szükségeseknek tűnnek, a sorrend rendben kell legyen.

Tény, hogy hosszú a diff, mert sok rekord változik, de feltételezem, hogy a Git hatékonyan tárolja.
38

Időközben a repó elérte a 16

Joó Ádám · Aug. 23. (K), 01.47
Időközben a repó elérte a 16 gigabájtot. A mentést végző szkript minden commitot követően intéz egy git gc --auto hívást. Ma egy kézzel indított git gc --aggressive 2 óra 42 percen át futott, a memóriahasználata 73 gigabájton tetőzött, és 117 megabájtra csökkentette a tároló méretét.
39

Kifejtenéd? :-)

inf3rno · Aug. 23. (K), 02.44
Kifejtenéd? :-)
40

Melyik részt? :)

Joó Ádám · Aug. 23. (K), 12.55
Melyik részt? :)
41

Hát miért ennyivel jobb az

inf3rno · Aug. 23. (K), 23.59
Hát miért ennyivel jobb az agressive, mint az auto.
42

Közben valószínűnek tűnik,

Joó Ádám · Aug. 24. (Sze), 17.40
Közben valószínűnek tűnik, hogy a méretnövekedés elsődleges oka az volt, hogy nem futott elég sűrűn a GC, ugyanis az --auto csak egy küszöb fölött indítja el a folyamatot, és a gc.auto illetve gc.autopacklimit alapértelmezett értéke ehhez a felhasználáshoz túl magasnak tűnik.

Ezen túl azonban az --aggressive azért is ér el szignifikánsan jobb eredményt, mert az összes delta láncot eldobja, és újakat számol helyettük, ami azt jelenti, hogy bármely objektumhoz alapul vehet bármely más objektumot, olyat is, amelyik az objektum létrejöttekor még nem létezett.
43

Ezek szerint az agresszív

inf3rno · Aug. 24. (Sze), 18.58
Ezek szerint az agresszív ugyanúgy 3 óráig futna akkor is, ha most indítanád? Nem lehet valahogy levenni a limitet, hogy az auto intézze az agresszív helyett, és agresszívon csak néhány havonta futtatni?

Miben van neked 80GB RAM-od? :D
44

Ezek szerint az agresszív

Joó Ádám · Aug. 24. (Sze), 21.31
Ezek szerint az agresszív ugyanúgy 3 óráig futna akkor is, ha most indítanád?


Így van, de konfigurálható a láncok hossza, hogy hány objektumot vegyen figyelembe az optimális delta keresésekor, illetve a memóriahasználat (mint utólag kiderült), ezek nyilván befolyásolják, hogy mennyi időt vesz igénybe.

Nem lehet valahogy levenni a limitet, hogy az auto intézze az agresszív helyett, és agresszívon csak néhány havonta futtatni?


A limitet természetesen le lehet venni, és ez tűnik a célszerű megoldásnak. Ilyenkor inkrementális a folyamat, a meglévő deltákat érintetlen hagyja, így természetesen az elvi hatékonysága sosem lesz olyan, mint az agresszívnak, de a gyakorlatban elég jónak kell lennie, Linus legalábbis csak akkor javasolja az aggresszív módot, ha tudjuk, hogy a korábbi delták rosszak, mondjuk mert egy gyorsimport eredményei.

Miben van neked 80GB RAM-od? :D


A 120 gigabájtos, 20 magos szerverben, amire azután vittem fel, hogy harmadszor fogyott el alatta a memória a kisebb gépeken :)
45

Brute force. :D

inf3rno · Aug. 25. (Cs), 02.44
Brute force. :D Amikor a többet ésszel, mint erővel szabálya nem érvényes.
11

Mennyire szükséges mindez?

T.G · 2016. Feb. 14. (V), 09.33
(kicsit off, de azért mégsem...)

Néha hiányérzetem van, hogy egyáltalán nem foglalkozom az adatbázis és a verziókezelés témakörével. Még évekkel ezelőtt úgy döntöttem, hogy vagy akkor veszem elő ezt az egészet, ha kijön valami olyan tool, ami garantáltan problémamentes megoldást biztosít, vagy ha olyan szívásba ütközöm, ami annyira fájdalmas, hogy mégiscsak jó lesz egy félmegoldás.

Viszont érdekelne, hogy akik ezzel éles projekten foglalkoznak, náluk mi a motiváció? Nálunk az adatbázis módosítások 99%-a új oszlop, illetve új tábla hozzáadása. Legfeljebb a maradék 1% a nem használt oszlopok kukázása és az oszlopok típusának módosítása, ezek lennének a problémás adatbázis műveletek. Másik oldalról nem nagyon emlékszem, hogy mikor kellett éles környezetben visszaállni egy régebbi verzióra. Olyan meg még egyszer sem fordult elő, hogy pont akkor kellett visszaállni, amikor olyan adatbázis módosítás történt, amellyel a régi adatbázis felépítés nem működött volna. Igaz, kis cég, kevés fejlesztővel. Emiatt kérdezem, hogy másoknál ez valódi probléma?
12

Tartalom

Hidvégi Gábor · 2016. Feb. 14. (V), 09.56
A cikk és Ádámék inkább az adatbázis tartalmának verziókezeléséről beszélnek (hogy mindig csak a napi új tartalom kerüljön bele), te pedig a szerkezetéről. Egyébként mi is hasonlóan kis cég vagyunk, és ugyanúgy csak bővítünk. Az adatok szempontjából pedig teljes mentést végzünk, és 1-2 hétre visszamenőleg tárolunk mindent.
27

Itt már tárgyaltunk erről:

inf3rno · 2016. Feb. 14. (V), 18.20
Itt már tárgyaltunk erről: http://weblabor.hu/cikkek/adatbazisok-verziokovetese régebben. Elvileg két megoldás van, ha migrálni akarsz adatot egyik séma verzióról a másikra. Az egyik, hogy ilyen liquibase-hez hasonló programokhoz folyamodsz, ami a módosítás alapján átírja az adatot is biztonságosan. A másik, ha DDD - CQRS - ES hármast használsz, és csinálsz egy új adatbázist az aktuális séma alapján, amire végigpörgeted a rá vonatkozó domain eventeket, és ezek alapján végrehajtod a módosításokat. Az első általában gyorsabb, mert csak pár SQL parancsról van szó, viszont csak SQL adatbázisokra használható a Liquibase tudtommal. A második egyszerűbb, de lassabb, viszont bármilyen adatbázis típusra használható. Nagyjából ezek a lehetőségek. Akik komolyabban csinálják azt írták, hogy mindkettőt használják, szóval ha lehet nem kezdenek el események alapján újraépíteni adatbázist, hanem inkább liquibase-t használják, mert annyival gyorsabb nagy adatmennyiségnél. Én sem látom egyébként hatalmas gyakorlati hasznát, elvileg annyi előnye van csak, hogyha meg akarod nézni a kódod egy előző verzióját, akkor az adatbázist is átalakíthatod az ahhoz a verzióhoz illőre (szvsz. senki nem tölti ezzel az idejét). Szóval inkább csak fejlesztésnél lehet jelentősége, esetleg még akkor ha valami nagyon félresikerült deploy-nál, és gyorsan kell egy rollback a kódra és az adatbázisra is.
33

elvileg annyi előnye van

BlaZe · 2016. Feb. 14. (V), 21.58
elvileg annyi előnye van csak, hogyha meg akarod nézni a kódod egy előző verzióját, akkor az adatbázist is átalakíthatod az ahhoz a verzióhoz illőre (szvsz. senki nem tölti ezzel az idejét)
Azért mégis :) Ezt úgy hívják, hogy rollback testing, meg backward compatibility testing, amik igen fontos lépései a release sign-offnak.

Szóval inkább csak fejlesztésnél lehet jelentősége, esetleg még akkor ha valami nagyon félresikerült deploy-nál, és gyorsan kell egy rollback a kódra és az adatbázisra is.
Vagy ha több branchen folyik a fejlesztés. És amúgy igen, az instant rollback egy nagyon fontos feature.
34

Jólvan, lehet kicsit

inf3rno · 2016. Feb. 14. (V), 22.38
Jólvan, lehet kicsit tényleg elbagatelizáltam. xD
14

Kizárt dolognak tartom, hogy

MadBence · 2016. Feb. 14. (V), 14.26
Kizárt dolognak tartom, hogy a MySQL ne támogasson inkrekemtális backupot (valamilyen módon), én eléggé hackelésnek érzem ezt a gites dolgot.
16

Tudsz ellene elvi érvet

Joó Ádám · 2016. Feb. 14. (V), 14.50
Tudsz ellene elvi érvet felhozni? Én is vívódtam rajta egy sort, de végül nem tudtam megindokolni, miért ne. Más kérdés, hogy a gyakorlatban nem működik annyira fényesen, de ez lehet, hogy azért van, mert valamit rosszul csinálok.
17

Egy tetszőleges napi

Hidvégi Gábor · 2016. Feb. 14. (V), 15.01
Egy tetszőleges napi adatbázis visszaállítása, gondolom, jó lassú.

Milyen jellegűek ezek adatok, ahol számít, hogy mondjuk tavaly március ötödikén mik kerültek be az adatbázisba? Miért nem elég a - mondjuk - fél évvel korábbi adatokról egy havi mentés?
19

Egy tetszőleges napi

Joó Ádám · 2016. Feb. 14. (V), 15.13
Egy tetszőleges napi adatbázis visszaállítása, gondolom, jó lassú.


Teszteléshez általában a legújabbat használom, de úgy emlékszem fordult elő, hogy valamivel régebbit vettem elő, és nem tűnt vészesnek.

Milyen jellegűek ezek adatok, ahol számít, hogy mondjuk tavaly március ötödikén mik kerültek be az adatbázisba? Miért nem elég a - mondjuk - fél évvel korábbi adatokról egy havi mentés?


Az adatok jellege nem indokolja jobban, mint bármely más adaté, de az előnyeit szerintem te is belátod annak, ha (adott felbontás mellett) tetszőleges állapota látható az adatbázisnak.
21

Szerintem az adatok

Hidvégi Gábor · 2016. Feb. 14. (V), 15.21
Szerintem az adatok jellegétől függ, hogy a tetszőleges állapot visszaállításának van-e értelme, ezért kérdeztem. Mi például szinte mindig csak logikailag törlünk, emiatt bőven elég pár napra visszamenőleg tárolni egy-egy teljes mentést.
18

Ellenérv: adatbázist saját

Há.Zé. · 2016. Feb. 14. (V), 15.06
Ellenérv: adatbázist saját eszközeivel maceráljunk, egyéb célra kitalált szoftverrel ne, mert könnyen inkonzisztens/sérült adatbázis lehet az eredménye.

Ezen felül: verziókezelő mihez kezd bináris adatokkal?
20

adatbázist saját eszközeivel

Joó Ádám · 2016. Feb. 14. (V), 15.18
adatbázist saját eszközeivel maceráljunk, egyéb célra kitalált szoftverrel ne, mert könnyen inkonzisztens/sérült adatbázis lehet az eredménye.


Az adatbázist a saját eszköze macerálja, a mysqldump, csak a dumpok vannak egyszerű fájlok helyett Gitben tárolva.

verziókezelő mihez kezd bináris adatokkal


A Git fel szokta ismerni, és átlatszatlanul kezeli.
24

Magyarán tárolja a teljes

Há.Zé. · 2016. Feb. 14. (V), 15.57
Magyarán tárolja a teljes fájlt, nem csak az eltérést.
Szerintem ez csak egy felesleges plusz réteg. De te tudod.

Én csak az adatbázist módosító szkripteket tárolnám gitben.
Mysqldump szövegfájlt készít? Keverem az oracle exporttal?
25

Mysqldump szövegfájlt

Joó Ádám · 2016. Feb. 14. (V), 16.55
Mysqldump szövegfájlt készít?


Igen, SQL-t ír fájlba.
29

WHERE

Hidvégi Gábor · 2016. Feb. 14. (V), 18.40
Egy egyszerű "diff", ha minden táblához adsz egy új mezőt:
ALTER TABLE tabla ADD modositas_datuma TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

Aztán így dumpolsz (bash):
TEGNAP = `date --date="yesterday" +"%Y-%m-%d"`
mysqldump (...) --where='DATE(modositas_datuma) = ${TEGNAP}' | bzip2 > dump_${TEGNAP}.bz2
22

Működik, szóval ilyen

MadBence · 2016. Feb. 14. (V), 15.37
Működik, szóval ilyen értelemben nem tudok ellene érvelni. Ami szerintem nem vonzó benne:
  • nem minden backup stratégia (full/incremental/differential) képezhető le gitre (illetve a gites megoldás full backupokat csinál, amíg meg nem erőszakoljuk, hogy legyen talán inkrementális, de ez leginkább mágia, és nem egyszerű megnézni, hogy tulajdonképpen mi is a valós helyzet)
  • a mysqldump (és a párja) tuti lassabb, mint valami natív, binárisokkal dolgozó megoldás
  • a szöveges formátum biztosan több helyet foglal (még ha ráeresztünk valamilyen tömörítést is)
  • a gitbe elég mélyen bele kell magát ásnia az embernek, ha rá szeretné venni hatékony tömörítésre

Ugye a git alapvetően nem diffeket tárol, hanem minden objektum egy CAS-ban él. Ha túl sok (ugye ezt nekünk kell konfigurálni, hogy mi a túl sok) ilyen objektum van, akkor ezeket egy packba pakolja, ami már ténylegesen egy tömörített valaminek fogható föl (nem igazán ástam bele magam, de nekem az jött le, hogy ezek többé-kevésbé tömörített diffek). Persze ezekből is túl sok lesz egy idő után, szóval újra kell őket csomagolni (amihez megint valamilyen git varázslás kell).
23

A mysqldump és a szöveges

Joó Ádám · 2016. Feb. 14. (V), 15.49
A mysqldump és a szöveges formátum szerintem eléggé iparági sztenderd, legalábbis ott, ahol az adatmennyiség nem kíván mást.

A Git működéséről én is nagyjából ennyit tudok, és egyetértek vele hogy mágia.
28

Örülök, hogy előkerült, a

inf3rno · 2016. Feb. 14. (V), 18.26
Örülök, hogy előkerült, a MySQL tényleg tud incremental backup-ot, legalábbis van ilyen cikk a manual-ban: https://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en/mysqlbackup.incremental.html

Én személy szerint azzal sem voltam tisztában, hogy ilyesmi létezik. Full backup + Git helyett mindenképp megéri ezt használni, ha támogatja az adatbázis. Amihez nekem kell az pgsql és neo4j és mindkettő támogatja.