3 ms·

Im a big fan of GraphDatabase's since about 10 years. I even wrote my own "in memory graph storage" in golang for a specific use case that none of the big Graph

Im a big fan of GraphDatabase's since about 10 years. I even wrote my own "in memory graph storage" in golang for a specific use case that none of the big GraphDatabase's could cover at the time. That said - i WISH people would embrase the existing GraphDatabases more and make the hosters support them as standard, rather than abusing existing relational databases for graph purposes. And to make it clear,i'm not talking about my own experimental one, i mean stuff like Neo4j, OrientDB etc.

belter 2y ago
When you look at AWS Neptune database implementation details, it looks realy close to the Aurora backend... :-) https://docs.aws.amazon.com/neptune/latest/userguide/migration-architectural-differences.html https://docs.aws.amazon.com/neptune/latest/userguide/migrati...
- voodooEntity 2y ago
  Hrhr very true. Also, the last time i checked neptune, it could only be run in AWS but there was no public application image for local tinkering/dev. But its some years ago to be fair - maybe have changed.
SJC_Hacker 2y ago
The only problem with representing graphs on an RDBMS is the queries. So whats the big issue if queries are added which can handle the graph cases?
- voodooEntity 2y ago
  Thats like saying why do we need json we can represent it also in a textfile but accessing values can be more tricky. Sure you can represent a GraphDB in a RDBMS - but graphdbs are optimized for their specific use case. Therefor for example locking of resources is optimized for said purpose. When going a "Edge" and "Node" table approach, locking is by default rather unoptimized in many RDBMS. Just one simple example.
  - SJC_Hacker 2y ago
    > Thats like saying why do we need json we can represent it also in a textfile but accessing values can be more tricky. If your text processing stack works good enough, and JSON only solves edge cases, then I think its a legit argument against adding another tech to the stack. Its not like everyone immediately switched over to JSON even if they could have. And the analogy may not be the best - in the case of graph databases, they don't do what RDBMS can do, at least not as efficiently. So if we need some graph functionality in our RDBMS, do we split the database and use a "real" graph database or just incorporate the graph functionality into the existing DB? The choice seems quite easy for me, because there are whole host of issues in splitting DBs (duplication of information, inconsistency, etc.)
    - voodooEntity 2y ago
      Well i took the best example that came to my mind at that moment. may not be the best analogy but well its what it is. My point was not about people enrichhing an existing RDMBS concept with Graph, it was about using RDBMS as Graph (as only purpose). So maybe i wasn't exact enaugh in my definition. Therefor: "If your purpose is to use the benefits of Graph and you want to use it for this purpose only, use a GraphDB and dont use a RDBMS and make it a GraphDB." I hope thats better now.
taurknaut 2y ago
> rather than abusing existing relational databases for graph purposes. In my experience, the vast majority of graphs can be embedded in relational databases just fine and most people don't want general graph querying. People just don't like optimizing queries (or equivalently the schema to enable such queries). I personally have never seen a pitch for graph databases that makes them seem attractive for more than data exploration on your local machine.
- hobs 2y ago
  Yep, something like adjacency lists have solved a lot of dumb recursive queries/"graph queries" for me, usually because the graph doesn't change much and is just a few nodes deep.
- voodooEntity 2y ago
  Well im working since multiple years on a private lets call it "research" project which deeply relies on growing/deep structured graphs. I don't think that GraphDBs should a default choice, but there are cases in which they just perform better. Could i write my research project with a relational DB? Yes - i tried - and it sucked xD
jsumrall 2y ago
My personal opinion is that nobody should touch OrientDB with a 10 ft pole.
- voodooEntity 2y ago
  I started with orientdb than switched to Neo4j. Orientdb was good for starting tbf, but we talking about 10+ years back. Now i would definately default to Neo4j
- esafak 2y ago
  Why?

belter 2y ago

When you look at AWS Neptune database implementation details, it looks realy close to the Aurora backend... :-) https://docs.aws.amazon.com/neptune/latest/userguide/migration-architectural-differences.html https://docs.aws.amazon.com/neptune/latest/userguide/migrati...

voodooEntity 2y ago
Hrhr very true. Also, the last time i checked neptune, it could only be run in AWS but there was no public application image for local tinkering/dev. But its some years ago to be fair - maybe have changed.

SJC_Hacker 2y ago

The only problem with representing graphs on an RDBMS is the queries. So whats the big issue if queries are added which can handle the graph cases?

voodooEntity 2y ago
Thats like saying why do we need json we can represent it also in a textfile but accessing values can be more tricky. Sure you can represent a GraphDB in a RDBMS - but graphdbs are optimized for their specific use case. Therefor for example locking of resources is optimized for said purpose. When going a "Edge" and "Node" table approach, locking is by default rather unoptimized in many RDBMS. Just one simple example.
- SJC_Hacker 2y ago
  > Thats like saying why do we need json we can represent it also in a textfile but accessing values can be more tricky. If your text processing stack works good enough, and JSON only solves edge cases, then I think its a legit argument against adding another tech to the stack. Its not like everyone immediately switched over to JSON even if they could have. And the analogy may not be the best - in the case of graph databases, they don't do what RDBMS can do, at least not as efficiently. So if we need some graph functionality in our RDBMS, do we split the database and use a "real" graph database or just incorporate the graph functionality into the existing DB? The choice seems quite easy for me, because there are whole host of issues in splitting DBs (duplication of information, inconsistency, etc.)
  - voodooEntity 2y ago
    Well i took the best example that came to my mind at that moment. may not be the best analogy but well its what it is. My point was not about people enrichhing an existing RDMBS concept with Graph, it was about using RDBMS as Graph (as only purpose). So maybe i wasn't exact enaugh in my definition. Therefor: "If your purpose is to use the benefits of Graph and you want to use it for this purpose only, use a GraphDB and dont use a RDBMS and make it a GraphDB." I hope thats better now.

taurknaut 2y ago

> rather than abusing existing relational databases for graph purposes. In my experience, the vast majority of graphs can be embedded in relational databases just fine and most people don't want general graph querying. People just don't like optimizing queries (or equivalently the schema to enable such queries). I personally have never seen a pitch for graph databases that makes them seem attractive for more than data exploration on your local machine.

hobs 2y ago
Yep, something like adjacency lists have solved a lot of dumb recursive queries/"graph queries" for me, usually because the graph doesn't change much and is just a few nodes deep.
voodooEntity 2y ago
Well im working since multiple years on a private lets call it "research" project which deeply relies on growing/deep structured graphs. I don't think that GraphDBs should a default choice, but there are cases in which they just perform better. Could i write my research project with a relational DB? Yes - i tried - and it sucked xD

jsumrall 2y ago

My personal opinion is that nobody should touch OrientDB with a 10 ft pole.

voodooEntity 2y ago
I started with orientdb than switched to Neo4j. Orientdb was good for starting tbf, but we talking about 10+ years back. Now i would definately default to Neo4j
esafak 2y ago
Why?