Evaringen met OrientDB

[HollowGamer]

Gisteren kwam ik tijdens het Google-en, deze (NoSQL?) database tegen.
Het leek mij een goed alternatief voor een MySQL database die ik normaal gebruik voor projecten.

O.a. de benchmarks, uitgebreide mogelijkheden en syntax spraken mij erg aan.
Er kwamen wel wat negatieve punten naar voren (topics bij Stackoverflow), o.a. dat het niet zo erg geschikt zou zijn voor relaties. Maar als ik zo het algemene beeld neem, lijkt het allemaal wel mee te vallen.

Nu moet ik eerlijk zeggen dat dit mijn eerste ervaring zou zijn met een noSQL database. Maar ik heb wel al ervaring met JSON, PHP en MySQL. Ik ben nu ook overtuigd dat het 'wiel opnieuw uitvinden' niet altijd beter is.

Nu was ik aan het denken om gebruikt te maken van de volgende onderdelen, voor een simpel en eenvoudig CMS-systeem:
OrientDB-PHP
Memcached voor PHP-sessies, of zou dit ook in de OrientDB kunnen?

Mijn vragen:
- Wat zijn jullie ervaringen met OrientDB (of vergelijks)?
- Heeft er toevallig ook iemand ervaring met OrientDB-PHP?
De reden dat ik het vraag, is dat er voor mij nog geen totaal beeld is, over de voor en nadelen.

Alvast bedankt!

[HMS]

Als je data model lijkt op een graaf (graph) is het misschien het overwegen waard, anders kunnen wij er ook niet zo heel veel over zeggen. Misschien dat iemand hier er ervaring mee heeft en je wat tips kan geven, maar of het een goede keus is voor je projecten moet je zelf bepalen.

Daarnaast wel een vreemde opmerking dat een graaf database slecht zou zijn in relaties, gezien het feit dat een graaf een verzameling nodes en edges is. Waarbij je de edges zou kunnen zien als de relaties van nodes onderling.

Verdiep je aub eerst even in NoSQL en graph databases voordat je de beslissing neemt om over te stappen

[Kettrick]

Een graph database is een geheel ander datamodel dan een relationele database, je werkt door verschillende nodes met properties aan elkaar te knopen middels relaties ( met properties ).

Ik heb een tijdje met neo4j gewerkt ( een andere graph database ) en was daar behoorlijk van onder de indruk, maar het is een geheel andere manier van denken.

[qless]

Ik zou voor een CMS liever met een document-store no-sql database werken, zoals MongoDB of CouchDB. Zelf veel goede ervaringen met MongoDB.

[Phyxion]

Als je echt een graph db zoekt is OrientDB fijn om mee te werken, maar als je dit niet nodig hebt (volgens de informatie die je gegeven hebt niet) zou ik dit niet gebruiken.

[ Voor 16% gewijzigd door Phyxion op 30-10-2014 15:29 ]

[HollowGamer]

Het is geen serieus project ofzo, gewoon om weer eens wat te programmeren en wat beter noSQL te begrijpen.

De reden dat ik er eens naar wil kijken, is dat het zoveel voordelen lijkt te hebben:
- Mogelijkheid tot loadbalancing/fail-over
- Hogere snelheden/verwerking
- Flexibel
- JSON basis

Het is dus vooral om iets nieuws te leren, en te ontdekken wat de voordelen zouden zijn.

Ik heb diverse artikelen gelezen (mede die van Tweakers), maar sommige zijn voorstander en andere zijn weer tegenstander. Vandaar dat ik eens wilde vragen hoe er eigenlijk over gedacht wordt.
OrientDB leek mij ook interessant, omdat dit volgens de makers zoveel voordelen zou zijn t.o.v. MongoDB, etc.

[raptorix]

Een noSql database gebruiken voor caching op de voorkant van je CMS is een goed idee, maar ik zou dat ten sterkste afraden omdat ook voor je "CMS" data te doen, ik kan je daar nog wel een mooi horror verhaal over vertellen

[HollowGamer]

Vertel

[Janoz]

Een noSQL-oplossing is niet zomaar een vervanging voor een SQL-oplossing. Als jij denkt dat je je relationele database zomaar even kunt vervangen door een graph database voor je cms-projectje 'om er iets van te leren' ben je precies vanaf de verkeerde kant begonnen.

De hele NoSQL stroming is op gang gekomen doordat relationele databases in sommige gevallen niet (meer) toereikend zijn. Dat is niet omdat relationele databases slechter zijn, maar omdat er andere eisen gesteld worden. Dat moet vervolgens ook je startpunt zijn. De eisen die je aan je applicatie (en voorbnamelijk je datalaag) stelt bepalen voor welke database oplossing je zou moeten gaan.

Als jij nu denkt dat je OrientDB gaat leren door hem in te zetten op een plek waar je normaal een relationele database zou gebruiken zul je er niks van leren. Je zou juist uit moeten zoeken wat de eigenschappen van een graph database zijn en wat de voor- en nadelen zijn tov relationele databases. Als je dat gedaan hebt zul je waarschijnlijk zelf ook wel inzien waarom je voor je leer project beter een profielensite dan een CMS kunt maken.

[Adimeuz]

HollowGamer schreef op vrijdag 31 oktober 2014 @ 13:01:
Vertel

Ik kwam, tijdens een onderzoekje, deze pagina tegen. Best interessant. Klinkt allemaal heel leuk dat noSQL, maar men vergeet of weet vaak niet wat de toepassingen hier nu echt van zijn.

[raptorix]

HollowGamer schreef op vrijdag 31 oktober 2014 @ 13:01:
Vertel

http://ayende.com/blog/15...racos-nhibernates-pullout

Ben zelf Umbraco gebruiker van eerste uur, Umbraco gebruikte tot versie 5 gewoon native SQL, echter men dacht dat het wel handig zou zijn om nHibernate in te zetten (ik weet het, hoeft niet specifiek no Sql te zijn), maar principe is het zelfde.

CMS'en gebruiken over het algemeen een platsgeslagen niet relationeel database model, ter voorbeeld, waar je in een normaal database model een tabel zou maken voor bijvoorbeeld de entiteit auteur of boek, doen CMS'en dat op een andere manier, je maakt bijvoorbeeld een tabel waarin je alle entiteiten opslaat, een tabel waar je alle velden opslaat, en een tabel waarin je de uiteindelijke data opslaat. Mits je goede queries schrijft is dit goed te doen, echter je zit nog steeds met het nadeel dat in het CMS deel elk veld doorgaans met 1 of meer queries uit de database opgehaald moet worden. Echter zet je hier noSql voor in, dan krijg je verre van handige queries/code omdat noSql in principe geen gebruik van joins maakt. Je zou dit uiteraard nog kunnen rechtbreien door data in gedenormaliseerde "views" of zelfs tables te kunnen opslaan, maar juist je CMS data is erg kwetsbaar en wil je juist relationeel benaderen.

Wat er met Umbraco 5 gebeurde is dat men vooral met kleine sets data getest heeft, qua performance gaat dat nog goed, maar met het toenemen van de hoeveelheid data nemen je performance problemen exponentieel toe. Echter men had dit pas in een heel laat stadium door, en aangezien dit zo sterk in de core zat verweven heeft men moeten besluiten om 1.5 jaar development te moeten laten vervallen. Voor 1 van de grootste opensource projecten op CMS gebied was dit natuurlijk een enorme domper.

[Grijze Vos]

Hoe is dat nhibernate verhaal een voorbeeld van nosql horror? nhibernate is een O/R mapper die bovenop een sql db werkt...

[Janoz]

Een aantal punten die je noemt zullen best kloppen, maar alles bij elkaar slaat het nergens op.

NHibernate heeft helemaal niks met NoSQL te maken. NHibernate is een ORM. Object-Relational Mapper. Een tussenlaag welke het relationele model van een relationele database (dus per definitie niet een noSQL oplossing) mapt op een object model.

Wat je vervolgens beschrijft is het database in database antipattern. Ikzelf zou niet zeggen dat dat automatisch zo afgedwongen wordt door een CMS. Ik kan me goed voorstellen dat je ook een CMS kunt bouwen zonder dat anti pattern. Echter is het inderdaad zo dat door dit anti-pattern de kans erg groot is dat een ORM je sterk tegen gaat werken. Wanneer je je joins niet gedefinieerd hebt in je datamodel (en bijvoorbeeld alleen in je queries) dan kan het ORM niet zijn queries optimaliseren en dan loop je inderdaad tegen het N+1 selects probleem aan.

Kortom. Je hele verhaal heeft een heel hoog klok klepel gehalte.

[raptorix]

Grijze Vos schreef op dinsdag 04 november 2014 @ 09:49:
Hoe is dat nhibernate verhaal een voorbeeld van nosql horror? nhibernate is een O/R mapper die bovenop een sql db werkt...

Dat snap ik, maar je krijgt met dezelde problematiek te maken, ik had misschien iets duidelijker in mijn uitleg moeten zijn.

[raptorix]

Janoz schreef op dinsdag 04 november 2014 @ 09:54:
Een aantal punten die je noemt zullen best kloppen, maar alles bij elkaar slaat het nergens op.

NHibernate heeft helemaal niks met NoSQL te maken. NHibernate is een ORM. Object-Relational Mapper. Een tussenlaag welke het relationele model van een relationele database (dus per definitie niet een noSQL oplossing) mapt op een object model.

Wat je vervolgens beschrijft is het database in database antipattern. Ikzelf zou niet zeggen dat dat automatisch zo afgedwongen wordt door een CMS. Ik kan me goed voorstellen dat je ook een CMS kunt bouwen zonder dat anti pattern. Echter is het inderdaad zo dat door dit anti-pattern de kans erg groot is dat een ORM je sterk tegen gaat werken. Wanneer je je joins niet gedefinieerd hebt in je datamodel (en bijvoorbeeld alleen in je queries) dan kan het ORM niet zijn queries optimaliseren en dan loop je inderdaad tegen het N+1 selects probleem aan.

Kortom. Je hele verhaal heeft een heel hoog klok klepel gehalte.

Zelfde als hierboven, en ja je kunt een CMS model maken wat dit pattern niet gebruikt, ik heb in verleden bijvoorbeeld met Smartsite gewerkt welke bijvoorbeeld views per documenttype genereert en data per document wel in 1 fysieke table opslaat, echter het genereren van database structures is over algemeen ook niet echt best practice.

Mijn verhaal doelde er meer op (zoals je zelf ook omschrijft) dat noSql zich niet goed leent voor operaties waar je normaliter te maken hebt met data die fysiek over meerdere tabellen begeeft.

[Janoz]

Je verhaal heeft helemaal niks met NoSQL te maken. Je verhaal gaat over een implementatie van een anti-pattern waardoor het gebruik van een standaard tool enorme performance problemen geeft. Nergens in dit verhaal wordt de relationele database vervangen door iets anders.

[beany]

OrientDB inhoudelijk:

Ik heb er mee getest en kwam tot de conclusie dat het niet heel erg volwassen is. API's zijn inconsistent en concepten kunnen overnacht wijzigen lijkt het soms wel.

Ik vond Neo4j een stuk beter 'aanvoelen'.

En bedenk je ook dat op plekken waar je een graphdb verwacht ze vaak geen graphdb gebruiken(linkedin gebruikt b.v. mysql).

Ook zijn graphdb's lastiger horizontaal te schalen. De oprichter van Neo4j heeft daar wel eens wat over uitgelegd in een filmpje, is ergens op youtube wel te vinden denk ik, of zelfs op hun website zelf.