Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Graph query languages: Cypher vs. Gremlin vs. nGQL

nebula-graph.io

Post reply on HN
Print view View original

51–60 of 66 posts

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

#51

Post by p_l »

tasogare wrote: post #17
mark_l_watson wrote: post #7

Sorry, but this article fails big time: no mention at all of SPARQL. For application developers, having access to general public Knowledge Graphs like DBPedia and WikiData can be a very good resource. While I am also a big fan of more general graph databases like Neo4J, not even mentioning SPARQL is such a HUGE OMISSION that I have to suspect some commercially motivated bias in this article. The decision of which gra…

Is there any SPARQL implementation that returns results under 10 seconds on a big dataset? Because, I never found a public SPARQL endpoint that gives remotely acceptable response time.

Someone already mentioned that public endpoints aren't good benchmarks.

But there are many performant SPARQL-enabled databases (back when I wrote my Master's in 2014, that even included Oracle), and they are indeed quite performant - though there are details like batch/realtime materialization and the like.

In my experience, AllegroGraph was pretty fast enough (apparently someone even uses it now to translate between HL7 schemas of multiple providers in USA)

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

#52

Post by p_l »

AtlasBarfed wrote: post #43
tasogare wrote: post #22

Earlier quoted context omitted.

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 y…

Both Prolog and SPARQL/RDF/Semantic Web are used at scale and pretty extensively. Unfortunately often behind closed doors, but there are very performant systems involved.

URIs and RDF in general don't need to use public HTTP links or anything like that, meanwhile the layered systems like OWL and RDFS provide some impressive features for implementing complex systems, especially when you actually want to use a semantic graph instead of loosely-schemed bag of nodes and vertices common in non-RDF graph databases.

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

#53

Post by prashnts »

henryfjordan wrote: post #48
frant-hartm wrote: post #47

Earlier quoted context omitted.

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.

Thank you, everyone in this thread! These are some helpful insights.

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

#54

Post by staticautomatic »

frant-hartm wrote: post #46
karatestomp wrote: post #21

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.

I posted a thread recently about my struggle to evaluate neo against multi model alternatives but have not gotten any useful replies. Any chance I could pick your brain? Email in my profile.

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

#55

Post by jamie-vesoft »

bionhoward wrote: post #34

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…

Interesting story with Neo4j and RedisGraph. Thanks for your suggestion. We are going to support OpenCypher. We will also take a look at AQL and include it in our next version. :)

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

#56

Post by jamie-vesoft »

zachrip wrote: post #38

Unrelated to the content, but can you please not put white on yellow like that? It's basically impossible for me to read with cataracts.

You meant the pictures right? Sorry for the bad experience. Will definitely improve our color palette for future posts.

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

#57

Post by FridgeSeal »

frant-hartm wrote: post #47
henryfjordan wrote: post #44

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?

DGraph is perfectly capable of doing these with a query language extremely similar to GraphQL (and as of v2 will natively support GraphQL):

https://docs.dgraph.io/master/query-language/#k-shortest-pat...

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

#59

Post by pgt »

carapace wrote: post #25
pgt wrote: post #19

No mention of Datalog? http://www.learndatalogtoday.org/

FWIW there's a Prolog-based graph DB called Terminus: https://medium.com/terminusdb https://github.com/terminusdb I don't know much about it but they are associated with Seshat Global History Databank http://seshatdatabank.info/ which, if I understand correctly, is something like a serious attempt at "psychohistory" (like in Asimov's Foundation.) https://medium.com/terminusdb/stuffing-the-whole-human-histo...

Thanks for TerminusDB. I'm currently implementing a toy datalog-based graph DB in Clojure backed by RocksDB.

(I wish Terminus didn't publish articles on Medium, where you need an account to read)

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

#60

Post by AtlasBarfed »

p_l wrote: post #52
AtlasBarfed wrote: post #43

Earlier quoted context omitted.

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 y…

Both Prolog and SPARQL/RDF/Semantic Web are used at scale and pretty extensively. Unfortunately often behind closed doors, but there are very performant systems involved. URIs and RDF in general don't need to use public HTTP links or anything like that, meanwhile the layered systems like OWL and RDFS provide some impressive features for implementing complex systems, especially when you actually want to use a semantic…

So sqarql rdf should stick to it's limited application space and let more generally applicable graph technologies go their own way
Post reply on HN