深入The Graph数据库

The Graph网络对Web3的查询层和API层进行了去中心化，消除了DApp开发者目前面临的取舍难题：到底是开发一个高性能应用，还是开发一个完全去中心化的应用。目前，开发者可以在自己的基础架构上运行一个Graph节点，也可以在我们的托管服务上开发一个。其中，开发者构建和部署从Web3数据源提取数据并为其编制索引的子图。目前已经有许多领先的以太坊项目创建了子图，包括Uniswap、ENS、DAOstack、Synthetix和Moloch等。在The Graph网络中，任何索引器都能够通过抵押Graph代币（GRT）参与到网络中，并在提供查询服务的过程赚取费用和通货膨胀奖励。用户则按照使用次数进行付费，使用日益增长的索引器，此做法证明了供需规律也适用于该协议提供的服务。

The Graph 简单理解相当于是区块链上面的搜索引擎，爬取区块链上的区块数据， 然后根据用户制定的规则进行搜索，方便各个DApp查询。

本文将深入The Graph的数据库，看看The Graph是怎么实现数据存储的。

The Graph表结构

上面是The Graph的数据库结构。

• subgraph是个核心数据库，里面存放着所有子图的基础信息；
• 每当创建一个新的子图的时候， 就会有一个新的数据库产生，比如上图中sgd1是給第一个子图的数据库， 数据库名字按序号递增。

Subgraph数据库存储

每次新创建的subgraph会存放在下面表中

新创建subgraph的时候会有些的数据库生成， 专门用来存放该subgraph里面定义的schema。

如果上传的subgraph的文件没有发生变化， 则不会重新生成新的数据库。

以下是一些核心的表：

• subgraph: 存放subgraph的基本信息，比如名字，创建时间， block range等；
• subgraph_deployment：存放subgraph的布署信息以及和区块链的同步信息， 比如最早和最迟的区块号等；
• subgraph_error: 子图在布署过程中碰到的一些错误。

每个subgraph的存储

每个subgraph自己的数据库里面，存放着子图里面schema entity对应的表。 每个子图定义的entity对应一张表，表结构对应entity的结构。 比如下面这个entity的定义：

type Token @entity {
  # token address
  id: ID!

  # mirrored from the smart contract
  symbol: String!
  name: String!
  decimals: BigInt!

  # used for other stats like marketcap
  totalSupply: BigInt!

  # token specific volume
  tradeVolume: BigDecimal!
  tradeVolumeUSD: BigDecimal!
  untrackedVolumeUSD: BigDecimal!

  # transactions across all pairs
  txCount: BigInt!

  # liquidity across all pairs
  totalLiquidity: BigDecimal!

  # derived prices
  derivedETH: BigDecimal

  # derived fields
  tokenDayData: [TokenDayData!]! @derivedFrom(field: "token")
  pairDayDataBase: [PairDayData!]! @derivedFrom(field: "token0")
  pairDayDataQuote: [PairDayData!]! @derivedFrom(field: "token1")
  pairBase: [Pair!]! @derivedFrom(field: "token0")
  pairQuote: [Pair!]! @derivedFrom(field: "token1")
}

对应的表结构

CREATE TABLE "sgd1"."token" (
  "id" text COLLATE "pg_catalog"."default" NOT NULL,
  "symbol" text COLLATE "pg_catalog"."default" NOT NULL,
  "name" text COLLATE "pg_catalog"."default" NOT NULL,
  "decimals" numeric NOT NULL,
  "total_supply" numeric NOT NULL,
  "trade_volume" numeric NOT NULL,
  "trade_volume_usd" numeric NOT NULL,
  "untracked_volume_usd" numeric NOT NULL,
  "tx_count" numeric NOT NULL,
  "total_liquidity" numeric NOT NULL,
  "derived_eth" numeric,
  "vid" int8 NOT NULL DEFAULT nextval('"sgd1".token_vid_seq'::regclass),
  "block_range" int4range NOT NULL
)

我们可以看到，除了entity里面定义的字段之外，表里面还有 "vid", 还有 "block_range"字段，这2个字段主要是用来做数据的版本控制的。也就是同一个id的数据，每次里面字段发生变化的时候都会产生一个新的版本。

版本控制

The Graph的数据表会自动对每条记录进行版本的迭代。比如下面例子中， 其实是同一条数据的不同版本，因为其Id 一致的代表是同一条数据， "block_range"标明了某个数据版本的有效区块区间。

这样的做法可以记录同一个id的数据随着区块的变化产生的版本变化，也可追溯到历史版本，保证了历史数据的不丢失。

作者：Bernie
原文链接：http://blockgeek.com/129d/3ad7

---

欢迎区块链行业志同道合的小伙伴添加小极微信，加入blockgeek区块链技术交流群，共同推动区块链技术普及和发展~