Note to moderator: The title of this post got changed to "Designing GraphQL schemas", which isn't correct. Please fix it back to the original title "Getting started with Dgraph and GraphQL+-".
Also, looks like the actual article about "Designing GraphQL schemas" got removed from the front page. It was in the top 10 just few minutes ago.
1. Is there any option like to do a free text search across multiple predicates at once e.g: I want to search for node(N) which satisfy "X Y" e.g: "john china", where "john" is 'name' predicate and china is 'country' predicate; and both these are grand children at unknown depths of some parent(N).
1. Yeah, you can run full-text search across multiple predicates, and then if you have reverse indices set up, you can chase their "parents".
2. We're investigating it.
3. You can find all the outbound edges, yes. But, you can't find all the inbound edges, without scanning over the entire DB which we don't recommend for performance reasons. However, if you have reverse indices, you could find inbound edges.
4. You can use /export endpoint [1] and then use live/bulk loader to reimport. That's the equivalent of backup/restore in Open Source version.
Is anyone using Dgraph out in the wild? I was meaning to look into it for a toy project to build my own crawler, and news discovery engine, and I have some questions...
1) What extra utility does it provide over other DBMSes with graph abstractions?
2) Is the join-depth problem an actual thing?[0] Does Dgraph solve some real-world problems for you for complex queries?
3) Are there 'pure' graph database systems out there that compete with Dgraph?
Dgraph is being used by many big and small companies in the wild. Some public examples are Intuit [1] and VMware [2].
1. Graph abstractions all suffer from high fan-out problem. Because all processing of data needs to be done at the abstraction layer, queries which deep traversals or lots of results in intermediate steps end up fetching lots of data repeatedly. This causes query performance to suffer. This is why many performance focused users avoid anything deeper than depth-2 queries with typical DBs / layers.
2. A way to think about this question is: Are data denormalization and duplication actual things? Indeed they are. If the DB did not suffer from join depth performance, these two things wouldn't need to exist.
I was hoping to hear about real-world use-cases. It's hard to make a commitment to a nascent technology, when there are already more established solutions, if they are flawed in some way that can be worked around... or if the performance hit is acceptable... or where the benefit of switching is hard to visualize.
It was probably a misstep to criticize Google, as you did in the link in my post. Your ressentiment only highlighted that respected people at Google voted against your technology. It did catch my attention, but it might have burnt some bridges, and left me with a lingering question mark.
I think if you're sincere about adoption of your technology, it has to be couched in clear terms of how it will fulfill business needs, and I'd like to see that. I'm intrigued by this performance gain, but I need a strong argument to help me decide if it's worth the opportunity cost to try Dgraph to make something.
Thanks for the link. It does indeed illuminate business utility. A problem (for you, not me), is that people might realize they need a dedicated graph database down the track after they've built their infrastructure around a typical RDBMS. Might be a foolish question, but do you have any tooling/strategies that help an org transition to Dgraph, or use it parasitically? Seems if an org could get a taste of what Dgraph could do for them, they'd be more likely to invest in it.
> My comments about Google were accurate.
Accuracy wasn't the issue.
I look forward to seeing where Dgraph goes, and I might give it a try in the future.
So far we have been focused on delivering to folks who already are convinced about graphs. We absolutely need to do a better job at selling Dgraph and showing value early on to the orgs who don't yet understand the need for a graph solution. Our foray into GraphQL is a step in that direction, but we need to do more education.
Modern RDBMS's can now address "graph"-like schemata and use cases via recursive queries, which are part of the SQL standard. No need for a separate abstraction on top of it, much less for "processing of data at the abstraction layer".
I'm guessing the abstraction has now been internalized. Unless the representation and operations underneath have been customized, and provide the same transaction guarantees and parsimony that a native graph database would for graph operations.
Also, looks like the actual article about "Designing GraphQL schemas" got removed from the front page. It was in the top 10 just few minutes ago.
https://news.ycombinator.com/item?id=22921571