5 ms·
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 intersectio
by 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 agoI 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 agoSo, 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 agoSounds good, thanks!