1.概念

1.1 XID <-> UID

所有实体会被分配一个唯一的64位整型id，即UID。如果某个尸体有一个外部id(external id)，即XID，DGraph会取出XID的指纹，并保存对应的UID。如果某个实体没有XID，DGraph只会添加一个新的UID，并标明这个UID已用。所有的posting list都通过UID引用实体。由于UID是8字节的整数，这种数据表示非常高效。在数据导入的时候，我们需要每个唯一的实体有一个唯一的UID。

1.2 Edges

典型的数据格式是RDF NQuad:

• 主语(Subject), 谓语(Predicate), 宾语(Object), 标签(Label), aka
• 实体(Entity), 属性(Attribute), 另一个实体或值(Other Entity / Value),标签(Label)

两种专门用语在Dgraph的代码里可以交替使用。Dgraph的edge是有向的，例如Subject -> Object。这也是查询执行的方向

可以自动生成一个反向的边。如果用户想按相反的方向执行查询，需要将reverse edge定义为schema的一部分

在Dgraph内部，RDF NQuad倍解析为下面的格式：

type DirectedEdge struct {
  Entity      uint64
  Attr        string
  Value       []byte
  ValueType   uint32
  ValueId     uint64
  Label       string
  Lang        string
  Op          DirectedEdge_Op // Set or Delete
  Facets      []*facetsp.Facet
}

不考虑输入的话，Entity以及 Object/ValueId都通过上面的XID <-> UID被转化成UID格式。

1.3 Posting List

概念上，posting list包含与一个Attribute关联的所有有向边，通过如下格式：

Attribute: Entity -> sorted list of ValueId 
//Everything in uint64 representation.

例如，如果我们存储一个朋友的列表，例如：

那么，将生成一个friend的posting list。在这个PL中查找Me会生成一个friend的列表，即[person0, person1, person2, person3]

拥有这个结构的一个很大优势是可以把需要做一个join的所有数据保存在一个PL中。这意味着，一个到持有PL的服务器RPC调用的结果是一个连接，而不需要更多的网络调用，减少查询需要的连接

顾名思义，PL是Posting的列表，用Protocol Buffers表示的话，它是这个样子：

message Posting {
  fixed64 uid = 1;
  bytes value = 2;
  enum ValType {
    DEFAULT = 0;
    BINARY = 1;
    INT = 2; // We treat it as int64.
    FLOAT = 3;
    BOOL = 4;
    DATE = 5;
    DATETIME = 6;
    GEO = 7;
    UID = 8;
    PASSWORD = 9;
    STRING = 10;

  }
  ValType val_type = 3;
  enum PostingType {
    REF=0;          // UID
    VALUE=1;        // simple, plain value
    VALUE_LANG=2;   // value with specified language
    // VALUE_TIMESERIES=3; // value from timeseries, with specified timestamp
  }
  PostingType posting_type = 4;
  bytes metadata = 5; // for VALUE_LANG: Language, for VALUE_TIMESERIES: timestamp, etc..
  string label = 6;
  uint64 commit = 7;  // More inclination towards smaller values.
  repeated facetsp.Facet facets = 8;

  // TODO: op is only used temporarily. See if we can remove it from here.
  uint32 op = 12;
}

message PostingList {
  repeated Posting postings = 1;
  bytes checksum = 2;
  uint64 commit = 3; // More inclination towards smaller values.
}

Dgraph中的所有数据都会首先使用Protocol Buffers序列化为字节数组后被存储或传输。当结果被返回给用户的时候，protocol buffer对象会被转换为JSON对象

在一个PL中通常有超过一个的Posting

RDF标签在每个posting中用label表示

现在Dgraph还不能通过查询获得label，但是将来会可以的

1.4 Badger

PostingList是通过Badger提供服务的，BadgerDB是一个嵌入式的、持久化的、简单的快速键值数据库，它使用纯Go语言开发.BadgerDB决定应该从内存、SSD或磁盘上提供多少数据。此外，它还支持在key上使用布隆过滤器，使随机查询的效率更高

为了让Badger对内存有完全的访问权限，以优化cache，每台服务器上都有一个Badger。每个实例包含这台服务器上的所有posting list

Posting list在Badger上以键值对的格式存储，例如：

(Predicate, Subject) --> PostingList

1.5 Group

包含同一个谓语(Predicate)的那些Posting list组成了一个group。每台服务器可以存储多个不同的group。

Group的配置文件用于确定每台服务器应该保存哪些group。在将来的版本中，在线的Dgraph服务器将可以使用探试法(heuristics)移动标签(tablets)

如果某个group变的太大，它可以被分割。在这种情况下，一个谓语实际上被分到两个group上，像下面这样：

Original Group:
            (Predicate, Sa..z)
  After split:
  Group 1:  (Predicate, Sa..i)
  Group 2:  (Predicate, Sj..z)

注意，这些key是被存储在RocksDB里的，因此group的split将会保持排序。例如，按字段顺序排序，在主语(subject)之前的被分到一个分组里，在主语之后的分到另一个分组里

1.6 复制与服务器故障

如果可能的话，每个group至少需要被三个服务器保存。当某台服务器故障时，其他保存同一个group数据的服务器可以继续提供服务

1.7 新服务器及发现

Dgraph集群可以自动检测加入到集群中的新服务器，建立连接，并将新服务器应该保存的group数据发过去

1.8 预写日志

对数据库的写入不会立马通过RocksDB写到磁盘上，而是先写到磁盘上的预写日志(Write ahead logs)里，这样可以避免posting list的经常重建

1.9 修改

除了被写入预写日志之外，对数据库的修改还会被存储在内存中，作为不可变的Posting list之上的一个可变层。它允许用户遍历Postings，仿佛它们是被排过序的，而无需重建posting list

当一个posting list在内存中有被修改后，它被视为dirty的。Dgraph会周期性地重新生成不可变的版本，并将改变写入RocksDB。注意，写入RocksDB的过程是异步的，这意味着它们并不会立刻被刷写到磁盘，但在服务器宕机的时候，这可能会导致数据丢失。但是不用担心，在Posting list被初始化的时候，会读取预写日志，这时丢失的数据会被补上

每当重新生成posting list的时候，Dgraph还会写一个包含最后一次提交日志的时间戳，用来决定在初始化posting list的时候从预写日志回溯多久的数据。（Every time we regenerate a posting list, we also write the max commit log timestamp that was included – this helps us figure out how long back to seek in write-ahead logs when initializing the posting list, the first time it’s brought back into memory.）

1.10 事务

Dgraph现在还不支持事务。

0.9版本已经支持事务

With the availability of transactions, a user can query for data, and then write their mods back atomically. Thus, upsert and mutation variables can be done via client-side logic, instead of baking this limiting functionality in the server.

一个修改可以由多条边组成，每条边可能属于不同的Posting list。Dgraph需要RWMutex来提供posting list上的锁。而在多个posting list上不存在锁

这意味着，一些边会比其他边先写入，而这时候读的话，只能读到部分被提交的数据。但是，还是有一致性保证的，当一个mutation成功的时候，任何成功的读操作都可以读到所有被更新的数据

如果一个mutation失败了，由用户决定是擦出部分写入的数据，还是用正确的逻辑重写。Dgraph的回复会说清楚哪些边没有被写入成功，用户可以设置正确的边来重新写入

局限性:

• 你应该考虑好是否你的读操作需要原子性的事务。除非你需要处理财务数据，这不是Dgraph的适用场景
• 为了保证原子性，每个mutation只能有一条边(RDF NQuads) 。这意味需要在clent及server之间反复地执行多次网络调用，这将影响你的写入吞吐量，但是会使错误处理的逻辑变得更简单

1.11版本

大体上来说，Dgraph存储有两种类型的数据，一种是关系(relationship)数据，一种是值

 Me friend person0    [Relation]
 Me name "Константи́н" [Value]

DGraph保存Posting list的方式，

2.最小化网络调用