graphprotocol / graphprotocol/graph-node
Rules-based system to control index creation and similar attributes
オープン
まだ誰も着手していません。
Stale
- 主要言語
- Rust
- スター
- 3.2k
- フォーク
- 1.1k
- 平均マージ
- 4日 1時間
- マージ済み PR(30日)
- 1
説明
There are a few things that can be set manually through graphman or directly by manipulating the database that affect how subgraph data is stored, and can help query performance. Those items include:
- custom indexes (multicolumn indexes or partial indexes)
- creation of default attribute indexes (a lot of them are never used)
- account-like optimization
- statistics target
- amount of history
An example of what that could like like in YAML form is
# Sketch of what an index definition file could look like. The file will
# contain many entries like this one
- rule: Messari analytics subgraphs
match:
# All subgraphs whose name matches this regex will be treated according
# to these actions
name: messari/.*
actions:
# Keep 10,000 blocks of history
- history: 10000
- entity:
name: LiquidityPoolSnapshot
index:
- on: [pool, timestamp]
- entity:
name: LiquidityPool
# Turn off attribute indexes
default_indexes: false
# Set the table to account-like
account-like: true
# Increase the statistics target
stats-target: 300
# Create some custom indexes
index:
# Use a GiST index since we use block_range
- on: [block_range, timestamp, id]
method: gist
# A partial index that only covers blocks after a certain point
# TODO: since the block number means different things on
# different networks, we should either use a timespan or let users
# match on network
- on: [timestamp, id]
after: 15664000
- on: [pool_address, block_range, timestamp]
method: gist
We need to think more about the way in which operators interact with these rules. Some requirements:
- changing rules should not require a restart of
graph-node - it should be possible to list rules, delete them etc.
- rules should be applied when a subgraph is deployed, but there should also be tooling to apply a new rule to an existing deployment.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
graphman と既存のデータベース操作パスを入口として使用し、まず現在のインデックス、履歴、属性の設定がどのように表現され、適用されているかを把握する。ルールを一覧表示、削除、graph-node を再起動せずに再読み込み、デプロイ時に適用し、既存のデプロイメントに適用する方法を定義する。完了条件は、これらのワークフローが仕様化され、テストでカバーされていることである。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- rust
- 領域
- databases
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100