关于graph:深入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 的数据库构造。

subgraph 是个外围数据库，外面寄存着所有子图的根底信息；
每当创立一个新的子图的时候，就会有一个新的数据库产生，比方上图中 sgd1 是給第一个子图的数据库，数据库名字按序号递增。

每次新创建的 subgraph 会寄存在上面表中

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

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

以下是一些外围的表：

subgraph: 寄存 subgraph 的根本信息，比方名字，创立工夫，block range 等；
subgraph_deployment：寄存 subgraph 的布署信息以及和区块链的同步信息，比方最早和最迟的区块号等；
subgraph_error: 子图在布署过程中碰到的一些谬误。

每个 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 区块链技术交换群，独特推动区块链技术遍及和倒退~

关于graph:深入The-Graph数据库

The Graph 表构造

Subgraph 数据库存储

每个 subgraph 的存储

版本控制