3 ms·

Yes, here's the roadmap: https://github.com/dgraph-io/dgraph/issues/1 https://github.com/dgraph-io/dgraph/issues/1 We do filter by predicates, and have plans t

by mrjn 11y ago

Yes, here's the roadmap: https://github.com/dgraph-io/dgraph/issues/1 https://github.com/dgraph-io/dgraph/issues/1 We do filter by predicates, and have plans to do sort and limit, including count. DGraph is designed to accommodate all these use cases really well. The idea is that you shouldn't need much on top of DGraph, because the query latency should be low; maybe Memcached. But, in the graph world, a single edge change can affect many queries, and so we've designed DGraph to provide low latency for arbitrarily complex queries. The schemas would be enforced via GraphQL, i.e. the query language, not via the storage mechanism. This allows you to change the definition of types of entities, without changing the corresponding data. This is incredible for both backwards compatibility, and quick iterations.

lobster_johnson 11y ago
Thanks. I didn't see any examples of predicates in the GraphQL, other than basic graph edge traversal. Do you have any? Does DGraph use indexes to back the predicates? If so, do indexes have to be pre-declared? To explain, we layer ElasticSearch on top of our current document store because we don't want to manage an "index schema" manually; we have tons of different apps on top of the same document store, and they have all sorts of ad-hoc queries where it would simply be easier to (like ES does) index everything rather than require the app to declare a schema. Not sure I understand your schema explanation. We're talking about schemas for validating document data, yes?
- mrjn 11y ago
  We don't yet have intersection, which is what you're looking for. But, it's in the roadmap, and as I mentioned, the design is built around efficient intersections (all posting lists are sorted lists of uint64s). So, DGraph supports arbitrary complexity, so we try to not optimize for any particular query. Hence, you don't need to specify indices. We automatically generate posting lists, which store all the objects for a given (subject, predicate). For e.g., all the friends of X is stored in a single value, which is a sorted list of UIDs (uint64). When we do sorting, we'll provide a way to specify which predicates to sort by. That'd be something that the user would have to provide; that we can't automatically deduce. For e.g., movie sorting by year of release etc. Re: schema, have a look at GraphQL type system: https://facebook.github.io/graphql/#sec-Type-System https://facebook.github.io/graphql/#sec-Type-System This explains how types can be specified, and enforced while inputting data; and retrieving data.
  - lobster_johnson 11y ago
    I think I see what you mean — sorry, I don't really think in triplets and to me a predicate is usually an algebraic term, not a data model term. Without value indexes, how would your data model optimize for queries like (year >= 1975) or (title like "%thing%)? If I understand you correctly, the client would pass a schema along with each mutation? It's something we considered and quickly discarded for our own data layer, because it's not a good data model. Every client now has to know how to express its current schema, which puts too much of a burden on the client. For example, we have a lot of microservices that all share the same data and schema, and to avoid boilerplate we'd have to build client glue (in 3 different languages) to let them share a schema.
    - mrjn 11y ago
      So, for filters like year >= 1975, that'd be part of our sorting feature push, which would also help with this sort of filter. Also, string matching / name search, is in our roadmap as well. The clients don't need to pass the schema on every mutation. DGraph could be provided the "schema" part of GraphQL when run, so all the servers have a common knowledge of what's the schema -- and the clients can assume that knowledge, without having to be repetitive. So, no your clients in different languages wouldn't have to share any schema.
      - lobster_johnson 11y ago
        Sounds good, thanks!

by mrjn 11y ago

lobster_johnson 11y ago

Thanks. I didn't see any examples of predicates in the GraphQL, other than basic graph edge traversal. Do you have any? Does DGraph use indexes to back the predicates? If so, do indexes have to be pre-declared? To explain, we layer ElasticSearch on top of our current document store because we don't want to manage an "index schema" manually; we have tons of different apps on top of the same document store, and they have all sorts of ad-hoc queries where it would simply be easier to (like ES does) index everything rather than require the app to declare a schema. Not sure I understand your schema explanation. We're talking about schemas for validating document data, yes?

mrjn 11y ago
We don't yet have intersection, which is what you're looking for. But, it's in the roadmap, and as I mentioned, the design is built around efficient intersections (all posting lists are sorted lists of uint64s). So, DGraph supports arbitrary complexity, so we try to not optimize for any particular query. Hence, you don't need to specify indices. We automatically generate posting lists, which store all the objects for a given (subject, predicate). For e.g., all the friends of X is stored in a single value, which is a sorted list of UIDs (uint64). When we do sorting, we'll provide a way to specify which predicates to sort by. That'd be something that the user would have to provide; that we can't automatically deduce. For e.g., movie sorting by year of release etc. Re: schema, have a look at GraphQL type system: https://facebook.github.io/graphql/#sec-Type-System https://facebook.github.io/graphql/#sec-Type-System This explains how types can be specified, and enforced while inputting data; and retrieving data.
- lobster_johnson 11y ago
  I think I see what you mean — sorry, I don't really think in triplets and to me a predicate is usually an algebraic term, not a data model term. Without value indexes, how would your data model optimize for queries like (year >= 1975) or (title like "%thing%)? If I understand you correctly, the client would pass a schema along with each mutation? It's something we considered and quickly discarded for our own data layer, because it's not a good data model. Every client now has to know how to express its current schema, which puts too much of a burden on the client. For example, we have a lot of microservices that all share the same data and schema, and to avoid boilerplate we'd have to build client glue (in 3 different languages) to let them share a schema.
  - mrjn 11y ago
    So, for filters like year >= 1975, that'd be part of our sorting feature push, which would also help with this sort of filter. Also, string matching / name search, is in our roadmap as well. The clients don't need to pass the schema on every mutation. DGraph could be provided the "schema" part of GraphQL when run, so all the servers have a common knowledge of what's the schema -- and the clients can assume that knowledge, without having to be repetitive. So, no your clients in different languages wouldn't have to share any schema.
    - lobster_johnson 11y ago
      Sounds good, thanks!