From e25be7e1c31782b59ce20b97a24bf8e79ceb157c Mon Sep 17 00:00:00 2001 From: Manish R Jain <manish@snapknock.com> Date: Thu, 29 Oct 2015 08:23:44 +1100 Subject: [PATCH] notes about the docs --- docs/design.md | 2 ++ docs/example.md | 2 +- docs/mvp.md | 9 ++++++++- 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/docs/design.md b/docs/design.md index 79e6a1c2..bfe1c6b1 100644 --- a/docs/design.md +++ b/docs/design.md @@ -1,5 +1,7 @@ ## Overview +**This document is out of date, and probably inconsistent. Current focus is on MVP, which has [it's own doc](mvp.md).** + Dgraph is a distributed graph serving system, meant to be deployed in production, and tackle user queries in real time. The aim of the system is to run complicated joins by minimizing network calls required, and hence to keep end-to-end latency diff --git a/docs/example.md b/docs/example.md index f32f5f10..e44bfacf 100644 --- a/docs/example.md +++ b/docs/example.md @@ -58,5 +58,5 @@ It can be split sharded to fit on multiple machines, just like Bigtable sharding works. This would mean a few additional RPCs, but still no where near as many as would be required by existing datastores. -This system would allow infinite scalability, and yet production level latencies, +This system would allow vast scalability, and yet production level latencies, to support running complicated queries requiring deep joins. diff --git a/docs/mvp.md b/docs/mvp.md index 595a27e3..2cb8bcc1 100644 --- a/docs/mvp.md +++ b/docs/mvp.md @@ -36,7 +36,8 @@ Had considered Cap'n Proto before, but Flatbuffers team provides better Go suppo - For this version, stick to doing everything on a single server. Possibly still using TCP layer, to avoid complexities later. - Possibly use a simple go mutex library for txn locking. -- Use UUID as entity id. +- Use uint64 as entity id. +- Support [GraphQL](https://facebook.github.io/graphql/): Facebook's new Graph Query Language. - Provide sorting in this version. ## Concepts / Technologies Skipped @@ -82,6 +83,12 @@ Replica | Replica is defined as a non-leading copy of the shard after RAFT elect - One mutex lock per shard. - One single server, serving all shards. +## Posting List +- TODO: Write about how posting list reads and updates work. Possibly in another doc. + +## GraphQL +- TODO: Write about what features are supported in GraphQL. Possibly in another doc. + ## Write - Convert the query into individual instructions with posting lists. - Acquire write locks over all the posting lists. -- GitLab