共计 2469 个字符，预计需要花费 7 分钟才能阅读完成。
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 区块链技术交换群，独特推动区块链技术遍及和倒退~
