关于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表构造

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