Neo4j és gráf adatbázisok

Adatbázis: SQL, XML DB

Keresek olyan embert aki már használt ilyen technológiát és tudna válaszolni pár kérdésre. Nekem ez az egész új, nemrég futottam bele, de valószínűleg ez lenne a jó megoldás egy régóta fejemben levő ötletre, ezt szeretném validálni.

Nem sok magyar nyelvű információt találtam, angol meg mint a tenger, ezért inkább olyannal beszélnék, akinek van tapasztalata.

Alapvetően C#-ben gondolkozom, windows alapon - ez mennyire megvalósítható vagy nagy sz*pás?
Cypher query language bevezetés - paraméterezés?
Adatbázis működtetés, mentés, security
Mi az a Rexster és kell-e nekem
... etc

ha valaki hajlandó lenne vmi IM eszközön, telefonon rászánni egy kis időt az életéből hálás lennék :)

  • 11142 megtekintés

( vandorpatkany | 2015. 02. 13., p – 14:47 )

C# téren nem nagyon tudok releváns infóval szolgálni, eddig főként Javaból csináltam ilyeneket.
A Cypher query jó dolog, viszont a gráf-dbk közül csak a Neo4J támogatja, szóval imlementációhoz leszel kötve vele.
Ha nem veszed meg az enterpise licenset, a mentés és a clusterezés nem támogatott, szóval production környezetbe kicsit rizikós.
Ha Neo4J 1.x verzió, akkor használhatod a Tinkerpop frameworköt, ami egy általános Graph API (Gremlin mint query language, Blueprint mint általános API, Rexster mint általános Graph szerver). Neo4J 2.x től kezdve a Tinkerpop framework hivatalosan nem támogatott, vagyis nemigen van lehetőséged Rexstert használni.

Gremlin: gráf adatbázisok lekérdezésére/bejárására szolgáló nyelv. A gremlin segítségével járod be a csomópontokat és az éleket. Ilyen utasítások egy Gremlin interpreteren keresztül adhatók ki, ilyen pl a Gremlin console, vagy a Gremlin API.
Rest-api: verziófüggő, hogy milyen lekérdezések hajthatók végre vele.
Rexster: alapesetben egy adatbázis-motort használsz, viszont ennek nincs grafikus felülete. Ebben segit a Rexster. A neo4j esetében letöltheted a neo4j szervert is, ami feleslegessé teszi különálló rexster szerver használatát.

A neo4j is java alapú, valamint teljesítményben is kb ugyanott vannak. Amiben nagy különbség van, az az ingyenes verziók tudása, valamint a fizetős verziók ára.
A neo4j nem támogatja pl a clusterezést, live backupot, sok processzormag használatát az ingyenes verzióban, míg az OrientDB alapból tudja ezeket. Árazásban is nagyon nagy különbség van, a hivatalos enterprise license az OrientDB-nél kb tizedannyi (esetenként 1/100-a) a neo4j árának (az ár nyilván az adott felhasználásra szabott, szóval ez nem minden esetre igaz, lehet olyan use-case,ahol paritásban vannak).

Ahogy nezem az OrientDB minden szeretne lenni: RDBMS, GraphDB, Document es K/V store. Mi a tapasztalatod, hogy teljesit ezekben a szerepekben? Most hallottam rola eloszor es izgalmasnak tunik, mert le lehetne valtani a MongoDB es Neo4j parost egy rendszerrel. Persze az utanaolvasas keves, erdekelnenek szemelyes tapasztalatok is.

Itt van róla szó, hogy ezt hogyan kell elképzelni: http://www.orientechnologies.com/docs/last/orientdb.wiki/Choosing-betwe…
A rétegek egymásra épülnek, nem pedig különálló struktúrát takarnak. A diszken, fájlszinten a különbség csak az egyes elemekhez kapcsolódó metaadatokban tér el. Ennek előnye, hogy objektumszinten ugyanazt az indexstruktúrát definiálod ha az adatot dokumentumként vagy gráf-pontként tárolod és indexeled egy vagy több attribútumra. Viszont mivel a metaadatokban van eltérés, ezek (általában) nem kompatibilisek egymással.

Tapasztalat: relációs adatbázisként csak nagyon nyakatekert megvalósításokat tudok elképzelni, soha nem láttam még ekként használni (ez nyilván nem jelenti azt, hogy nem lehet). Gráf és dokumentum db-ként viszont már jópárszor használtam, és eddig mindig meg voltam vele elégedve. K/V storeként nem annyira ajánlom, ahhoz lassabb, és több helyet foglal (~2x) mint a konkurencia. Csak abban az esetben használtam K/V storeként, amikor egy java alkalmazásba kellett egy embedded megoldás ilyen esetre, de itt a sebesség/tárhely csak kb. utolsó kritérium volt, elsődleges cél a beágyazhatóság volt.

Fejlesztőként dolgozom, így sajnos nem tudok releváns infóval szolgálni e téren, hogy ez hogyan konfigurálható, miként oldható meg. Annyit tudok csak hozzátenni, hogy eddig ahányszor ilyenre volt szükség, az üzemeltetéssel foglalkozó kollégák mindig meg tudták oldani az elosztott üzemeltetést és a magas rendelkezésre állást. Eddig egyszer sem mondták, hogy ez így nem fog menni :) Eddig a legnagyobb konfiguráció 20 node-ot tartalmazott master-master replikációban, load-balancerrel, stb, de hogy ezt hogy csinálták, az sajnos nem az én asztalom, én csak 1 connection url-t használtam :).

( szenyo | 2015. 09. 02., sze – 10:40 )

Sziasztok! Neo4j-vel kapcsolatosan keressük az itthoni felhasználókat.
Van egy meetup-unk, amit ezért hoztunk létre.
Egy összejövetelünk volt már, de most szervezzük a másodikat, és jó lenne, ha találnánk még felhasználókat.