Live data from Hacker News

Graph query languages: Cypher vs. Gremlin vs. nGQL

nebula-graph.io

41–50 of 66 posts

Re: Graph query languages: Cypher vs. Gremlin vs. nGQL

#42

We evaluated umpteen graph dbs this past year and chose vanilla Postgres instead because Neo4j/RedisGraph have insane licenses. It’s useful you’re comparing these languages. I would suggest to make yours more like Cypher, specifically the arrows are much less verbose than BIDIRECT/ REVERSELY, and MATCH is a lot less verbose and more powerful than other query languages. It sucks to want to use Neo4j then not be able t…

You should take a look at ONgDB https://www.graphfoundation.org/projects/ongdb/

and might find some of these blog posts helpful https://blog.igovsol.com/

Re: Graph query languages: Cypher vs. Gremlin vs. nGQL

#43
post #10

Earlier quoted context omitted.

Yes.. I work on several projects that leverage SPARQL. The article is also remiss in not mentioning the work the W3C is doing along with Neo4J to do its own alignment ( https://www.w3.org/Data/events/data-ws-2019/ ). Indeed, this article seems very self serving in its omissions. There is a follow up meeting planned soon for that too. Also, much of the work in validation (SHACL, Shex) of graphs leverages SPARQL so it'…

From your link "W3C's RDF uses URIs (Web addresses) for nodes and link labels in directed graphs. This has the advantage of enabling them to be dereferenced to obtain further information, making for a Web of linked data. In particular, nodes can be dereferenced to graphs on remote databases." I think spreading those kind of lies[1] if a part of why there is a divide between the W3C (at least the RDF community) and th…

Yeah, the SPARQL people need to realize that the semantic web was a massive dud in the programming and database market, and a lot of that was overreach, overpromise, and a lack of focus on "real-world" problems.

Thus, if someone is looking to unify graph QLs that are in actual use in "business" problems, SPARQL and the overall RDF aren't going to get attention. You can start with the fact that RDF basically assumes you want to globally address all your data with URIs, which will result in ridiculously verbose overhead in naming/addressing. Nevermind the fact that such things basically promise some sort of long term durability that the actual web has shown doesn't exist. After all, today's URI link to URI www.tla.com/link/to/some/data can mean the world wide wrestling foundation one day, and the world wildlife foundation the next.

In particular, Gremlin was adopted by DSE / Titan / successor to Titan which ran atop Cassandra for near-limitless scalability.

RDF and the Semantic web, while being intended for the massive WWW, seemed to not have any care for demonstrating techniques, queries, and architectures at scale.

Likewise, are Datalog and Prolog used extensively?

Re: Graph query languages: Cypher vs. Gremlin vs. nGQL

#44

Earlier quoted context omitted.

If you have any opinions on GraphQL vs Cypher, I’d really appreciate it! Context: In web app usage scenario the tooling available for GraphQL seems more popular (with react libraries) than Cypher.

Completely different use case and purpose. Cypher is a graph query language. GraphQL is an API query language to query tree like structures (trees...), nothing to do with graphs actually.

GraphQL can be totally be used to represent and query true graphs, not just trees. The data gets materialized into nested JSON (which can be thought of as a tree) but that doesn't mean it doesn't represent a graph.

Other than that though, you are quite correct, the two do not serve the same purpose.

Neo4j has an extension that exposes a GraphQL API that converts the queries to Cypher (https://neo4j.com/developer/graphql/#neo4j-graphql-java). I've used it for some basic things but for anything complex you need to be careful and inspect the queries it produces.

Re: Graph query languages: Cypher vs. Gremlin vs. nGQL

#45

We evaluated umpteen graph dbs this past year and chose vanilla Postgres instead because Neo4j/RedisGraph have insane licenses. It’s useful you’re comparing these languages. I would suggest to make yours more like Cypher, specifically the arrows are much less verbose than BIDIRECT/ REVERSELY, and MATCH is a lot less verbose and more powerful than other query languages. It sucks to want to use Neo4j then not be able t…

Neo4j is licensed as GPLv3 unless you want the enterprise features (replication). I've run the non-enterprise version in production and it was working fine for a limited workload. Replication would have been nice at some scales but it wasn't the reads that were the issue anyway, it was the writes which replication wouldn't help anyway.

RedisGraph is licensed under their weird license but as far as I can tell you just can't expose the RedisGraph API directly to your customers. Building an API on top of it that adds some abstractions should be fine (think a social network powered by the extension). I could be wrong about that though.

Are you actually doing graph work in Postgres? I learned about recursive CTE queries once upon a time and that was what prompted adoption of Neo4j.

(I'm not a lawyer and don't take legal advice from the internet)

Re: Graph query languages: Cypher vs. Gremlin vs. nGQL

#46
post #18

Earlier quoted context omitted.

I was really attracted to graph databases mainly for the ability to do joins in effectively constant time rather than O(log N) time. But then I realized that sharding and localizing data can accomplish roughly the same thing. Also the graph database doesn’t have to duplicate data so much for joins, saving on memory. If you are going to have a huge dataset, build your data as RDMBS first and then make a cache in a gra…

I came to exactly the same conclusion after having Neo4j pushed on a project by managers who'd been sold by their "it's great for everything!" marketing. At least as of ~2 years ago, no, it wasn't. Fine for a narrow set of query types for data of a very specific kind of shape (dense graph) that you don't care about much and can re-generate if it gets screwed up. Unsuitable as a "database of record" (poor integrity en…

What version did you use? What you are describing sounds like Neo4j from around 6 years ago, not today.

Re: Graph query languages: Cypher vs. Gremlin vs. nGQL

#47

Earlier quoted context omitted.

Completely different use case and purpose. Cypher is a graph query language. GraphQL is an API query language to query tree like structures (trees...), nothing to do with graphs actually.

GraphQL can be totally be used to represent and query true graphs, not just trees. The data gets materialized into nested JSON (which can be thought of as a tree) but that doesn't mean it doesn't represent a graph. Other than that though, you are quite correct, the two do not serve the same purpose. Neo4j has an extension that exposes a GraphQL API that converts the queries to Cypher ( https://neo4j.com/developer/gra…

How would you query for a path or cycle of arbitrary length in GraphQL?

Re: Graph query languages: Cypher vs. Gremlin vs. nGQL

#48

Earlier quoted context omitted.

GraphQL can be totally be used to represent and query true graphs, not just trees. The data gets materialized into nested JSON (which can be thought of as a tree) but that doesn't mean it doesn't represent a graph. Other than that though, you are quite correct, the two do not serve the same purpose. Neo4j has an extension that exposes a GraphQL API that converts the queries to Cypher ( https://neo4j.com/developer/gra…

How would you query for a path or cycle of arbitrary length in GraphQL?

You cannot do that directly out-of-the box, but you can write your server to include directives for that. See some discussion here: https://github.com/graphql/graphql-spec/issues/91

Also just because you cannot query at arbitrary depths doesn't mean that GraphQL doesn't work with graphs, just that it might be a poor choice of tool for that work.

Re: Graph query languages: Cypher vs. Gremlin vs. nGQL

#49

Earlier quoted context omitted.

I came to exactly the same conclusion after having Neo4j pushed on a project by managers who'd been sold by their "it's great for everything!" marketing. At least as of ~2 years ago, no, it wasn't. Fine for a narrow set of query types for data of a very specific kind of shape (dense graph) that you don't care about much and can re-generate if it gets screwed up. Unsuitable as a "database of record" (poor integrity en…

What version did you use? What you are describing sounds like Neo4j from around 6 years ago, not today.

About two years ago. Whatever was current then. We had a paid license too because this client was all-in on N4J. They had their own internal champion who'd set himself up as the "Neo4j expert" and got them to send him to conferences and hang out on phone calls and try to fix the fires he was partially responsible for but didn't get blamed for. All their projects had serious issues resulting from their insistence on a particular stack, which had basically nothing really capable of protecting data consistency at any point. We had to fight for TypeScript (vs. their prefered vanilla Javascript) to gain a tiny semblance of sanity, productivity, and stability in that environment.

Transactions in N4j couldn't handle modifying one entity [edit:the schema of one entity type, I mean] while updating another, which was pretty limiting (say, you want to do safe Rails-migrations-style version bumps in the DB in the same transaction as your modifications, so they can't get out of sync). Constraints capabilities and data types were very limited. Perf if you stepped off the Golden Path, which was easy to do by accident with something that looked boring and normal, was mediocre at best for our use case (smallish sparse sub-graph fetching, mostly)

[EDIT] meanwhile, all the official material from N4J was doing its MongoDBest to sell itself as 100% suitable for production for 100% of use cases, because of course it was. Look anywhere else and you got a very different, more accurate story.

Post reply on HN