title
ऑपरेटिंग ग्राफ नोड

ग्राफ नोड हा घटक आहे जो सबग्राफ इंडेक्स करतो आणि परिणामी डेटा GraphQL API द्वारे क्वेरीसाठी उपलब्ध करतो. हे इंडेक्सर स्टॅकसाठी मध्यवर्ती आहे आणि यशस्वी इंडेक्सर चालवण्यासाठी ग्राफ नोडचे योग्य ऑपरेशन महत्वाचे आहे.

हे ग्राफ नोडचे संदर्भित विहंगावलोकन आणि इंडेक्सर्ससाठी उपलब्ध काही अधिक प्रगत पर्याय प्रदान करते. तपशीलवार दस्तऐवजीकरण आणि सूचना ग्राफ नोड भांडार मध्ये आढळू शकतात.

आलेख नोड

ग्राफ नोड हे ग्राफ नेटवर्कवर सबग्राफ अनुक्रमित करण्यासाठी, ब्लॉकचेन क्लायंटशी कनेक्ट करण्यासाठी, सबग्राफ अनुक्रमित करण्यासाठी आणि अनुक्रमित डेटा उपलब्ध करण्यासाठी संदर्भ अंमलबजावणी आहे पृच्छणे.

ग्राफ नोड (आणि संपूर्ण इंडेक्सर स्टॅक) बेअर मेटलवर किंवा क्लाउड वातावरणात चालवला जाऊ शकतो. केंद्रीय अनुक्रमणिका घटकाची ही लवचिकता आलेख प्रोटोकॉलच्या मजबुतीसाठी महत्त्वपूर्ण आहे. त्याचप्रमाणे, आलेख नोड स्रोत पासून तयार केला जाऊ शकतो किंवा अनुक्रमणिका [डॉकर प्रतिमा प्रदान केल्या](https:// पैकी एक वापरू शकतात hub.docker.com/r/graphprotocol/graph-node).

PostgreSQL डेटाबेस

ग्राफ नोडसाठी मुख्य स्टोअर, येथे सबग्राफ डेटा संग्रहित केला जातो, तसेच सबग्राफबद्दलचा मेटाडेटा आणि सबग्राफ-अज्ञेयवादी नेटवर्क डेटा जसे की ब्लॉक कॅशे आणि eth_call कॅशे.

नेटवर्क क्लायंट

In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple.

While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make eth_calls as part of indexing will require an archive node which supports EIP-1898, and subgraphs with callHandlers, or blockHandlers with a call filter, require trace_filter support (see trace module documentation here).

Network Firehoses - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose here.

आयपीएफएस नोड्स

सबग्राफ डिप्लॉयमेंट मेटाडेटा आयपीएफएस नेटवर्कवर संग्रहित केला जातो. सबग्राफ मॅनिफेस्ट आणि सर्व लिंक केलेल्या फाइल्स आणण्यासाठी सबग्राफ डिप्लॉयमेंट दरम्यान ग्राफ नोड प्रामुख्याने आयपीएफएस नोडमध्ये प्रवेश करतो. नेटवर्क इंडेक्सर्सना त्यांचे स्वतःचे IPFS नोड होस्ट करण्याची आवश्यकता नाही. नेटवर्कसाठी एक IPFS नोड https://ipfs.network.thegraph.com वर होस्ट केला आहे.

प्रोमिथियस मेट्रिक्स सर्व्हर

To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server.

Getting started from source

Install prerequisites

गंज
PostgreSQL
IPFS
Additional Requirements for Ubuntu users - To run a Graph Node on Ubuntu a few additional packages may be needed.

sudo apt-get install -y clang libpg-dev libssl-dev pkg-config

Setup

Start a PostgreSQL database server

initdb -D .postgres
pg_ctl -D .postgres -l logfile start
createdb graph-node

Clone Graph Node repo and build the source by running cargo build
Now that all the dependencies are setup, start the Graph Node:

cargo run -p graph-node --release -- \
  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
  --ethereum-rpc [NETWORK_NAME]:[URL] \
  --ipfs https://ipfs.network.thegraph.com

Kubernetes सह प्रारंभ करणे

A complete Kubernetes example configuration can be found in the indexer repository.

बंदरे

When it is running Graph Node exposes the following ports:

बंदर	Purpose	Routes	CLI Argument	Environment Variable
8000	GraphQL HTTP server (for subgraph queries)	/subgraphs/id/... /subgraphs/name/.../...	--http-port	-
8001	GraphQL WS (for subgraph subscriptions)	/subgraphs/id/... /subgraphs/name/.../...	--ws-port	-
8020	JSON-RPC (for managing deployments)	/	--admin-port	-
8030	Subgraph indexing status API	/graphql	--index-node-port	-
8040	Prometheus metrics	/metrics	--metrics-port	-

महत्त्वाचे: पोर्ट सार्वजनिकपणे उघड करण्याबाबत सावधगिरी बाळगा - प्रशासन पोर्ट लॉक डाउन ठेवले पाहिजेत. यामध्ये ग्राफ नोड JSON-RPC एंडपॉइंटचा समावेश आहे.

प्रगत ग्राफ नोड कॉन्फिगरेशन

सर्वात सोप्या पद्धतीने, ग्राफ नोड, ग्राफ नोड, एकल PostgreSQL डेटाबेस, एक IPFS नोड, आणि सबग्राफ अनुक्रमित करण्यासाठी आवश्यक असलेल्या नेटवर्क क्लायंटच्या एकाच उदाहरणासह ऑपरेट केला जाऊ शकतो.

हा सेटअप क्षैतिजरित्या स्केल केला जाऊ शकतो, अनेक ग्राफ नोड्स आणि त्या ग्राफ नोड्सला समर्थन देण्यासाठी एकाधिक डेटाबेस जोडून. प्रगत वापरकर्ते ग्राफ नोडच्या काही क्षैतिज स्केलिंग क्षमतांचा, तसेच काही अधिक प्रगत कॉन्फिगरेशन पर्यायांचा लाभ घेऊ इच्छितात, config.toml फाइल आणि ग्राफ नोडच्या पर्यावरणीय चलने.

`config.toml`

TOML कॉन्फिगरेशन फाईल CLI मध्ये उघड केलेल्या कॉन्फिगरेशनपेक्षा अधिक जटिल कॉन्फिगरेशन सेट करण्यासाठी वापरली जाऊ शकते. फाइलचे स्थान --config कमांड लाइन स्विचसह पास केले जाते.

When using a configuration file, it is not possible to use the options --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights.

A minimal config.toml file can be provided; the following file is equivalent to using the --postgres-url command line option:

[store]
[store.primary]
connection="<.. postgres-url argument ..>"
[deployment]
[[deployment.rule]]
indexers = [ "<.. list of all indexing nodes ..>" ]

Full documentation of config.toml can be found in the Graph Node docs.

एकाधिक ग्राफ नोड्स

ग्राफ नोड इंडेक्सिंग क्षैतिजरित्या स्केल करू शकते, अनुक्रमणिका विभाजित करण्यासाठी ग्राफ नोडची अनेक उदाहरणे चालवते आणि वेगवेगळ्या नोड्समध्ये क्वेरी करणे. हे फक्त स्टार्टअपवर वेगळ्या node_id सह कॉन्फिगर केलेले आलेख नोड्स चालवून केले जाऊ शकते (उदा. डॉकर कंपोझ फाइलमध्ये), जे नंतर config.toml फाइलमध्ये वापरले जाऊ शकते. समर्पित क्वेरी नोड्स निर्दिष्ट करण्यासाठी, इनजेस्टर अवरोधित करा, आणि उपयोजन नियम सह नोड्सवर सबग्राफ विभाजित करा.

Note that multiple Graph Nodes can all be configured to use the same database, which itself can be horizontally scaled via sharding.

डिप्लॉयमेंट नियम

एकापेक्षा जास्त आलेख नोड्स दिल्यास, नवीन सबग्राफची तैनाती व्यवस्थापित करणे आवश्यक आहे जेणेकरून समान सबग्राफ दोन भिन्न नोड्सद्वारे अनुक्रमित केला जाणार नाही, ज्यामुळे टक्कर होईल. हे उपयोजन नियम वापरून केले जाऊ शकते, जे डेटाबेस शार्डिंग वापरत असल्यास, सबग्राफचा डेटा कोणत्या shard मध्ये संग्रहित केला जावा हे देखील निर्दिष्ट करू शकते. डिप्लॉयमेंट नियम उपग्राफ नाव आणि नेटवर्कवर जुळू शकतात जे निर्णय घेण्यासाठी उपयोजन अनुक्रमित करत आहे.

उपयोजन नियम कॉन्फिगरेशनचे उदाहरण:

[deployment]
[[deployment.rule]]
match = { name = "(vip|important)/.*" }
shard = "vip"
indexers = [ "index_node_vip_0", "index_node_vip_1" ]
[[deployment.rule]]
match = { network = "kovan" }
# No shard, so we use the default shard called 'primary'
indexers = [ "index_node_kovan_0" ]
[[deployment.rule]]
match = { network = [ "xdai", "poa-core" ] }
indexers = [ "index_node_other_0" ]
[[deployment.rule]]
# There's no 'match', so any subgraph matches
shards = [ "sharda", "shardb" ]
indexers = [
    "index_node_community_0",
    "index_node_community_1",
    "index_node_community_2",
    "index_node_community_3",
    "index_node_community_4",
    "index_node_community_5"
  ]

तैनाती नियमांबद्दल येथे अधिक वाचा.

समर्पित क्वेरी नोड्स

Nodes can be configured to explicitly be query nodes by including the following in the configuration file:

[general]
query = "<regular expression>"

Any node whose --node-id matches the regular expression will be set up to only respond to queries.

शार्डिंगद्वारे डेटाबेस स्केलिंग

बर्‍याच वापराच्या प्रकरणांसाठी, ग्राफ-नोड उदाहरणास समर्थन देण्यासाठी एकच पोस्टग्रेस डेटाबेस पुरेसा आहे. जेव्हा ग्राफ-नोडचे उदाहरण एका पोस्टग्रेस डेटाबेसला मागे टाकते, तेव्हा ग्राफ-नोडच्या डेटाचे स्टोरेज एकाधिक पोस्टग्रेस डेटाबेसमध्ये विभाजित करणे शक्य आहे. सर्व डेटाबेस एकत्रितपणे आलेख-नोड उदाहरणाचे स्टोअर तयार करतात. प्रत्येक वैयक्तिक डेटाबेसला शार्ड म्हणतात.

शार्ड्सचा वापर एकाधिक डेटाबेसमध्ये सबग्राफ डिप्लॉयमेंट्स विभाजित करण्यासाठी केला जाऊ शकतो आणि डेटाबेसमध्ये क्वेरी लोड पसरवण्यासाठी प्रतिकृती वापरण्यासाठी देखील वापरला जाऊ शकतो. यामध्ये प्रत्येक ग्राफ-नोड ने प्रत्येक डेटाबेससाठी त्याच्या कनेक्शन पूलमध्ये ठेवल्या पाहिजेत अशा उपलब्ध डेटाबेस कनेक्शनची संख्या कॉन्फिगर करणे समाविष्ट आहे, जे अधिक सबग्राफ अनुक्रमित केले जात असल्याने वाढत्या प्रमाणात महत्त्वाचे होते.

जेव्हा तुमचा विद्यमान डेटाबेस ग्राफ नोडवर ठेवत असलेल्या लोडसह ठेवू शकत नाही आणि जेव्हा डेटाबेस आकार वाढवणे शक्य नसेल तेव्हा शार्डिंग उपयुक्त ठरते.

शार्ड्ससह प्रारंभ करण्यापूर्वी एकच डेटाबेस शक्य तितका मोठा करणे सामान्यतः चांगले आहे. एक अपवाद असा आहे की जिथे क्वेरी ट्रॅफिक सबग्राफ्समध्ये खूप असमानपणे विभाजित केले जाते; उच्च-आवाजातील सबग्राफ एका शार्डमध्ये आणि इतर सर्व गोष्टी दुसर्‍यामध्ये ठेवल्या गेल्यास अशा परिस्थितीत ते नाटकीयरित्या मदत करू शकते कारण त्या सेटअपमुळे उच्च-व्हॉल्यूम सबग्राफचा डेटा db-अंतर्गत कॅशेमध्ये राहण्याची अधिक शक्यता असते. कमी-व्हॉल्यूम सबग्राफमधून आवश्यक नसलेल्या डेटाद्वारे बदला.

कनेक्शन कॉन्फिगर करण्याच्या दृष्टीने, postgresql.conf मधील max_connections ने 400 (किंवा कदाचित 200 देखील) सेट करून प्रारंभ करा आणि store_connection_wait_time_ms आणि store_connection_checkout_count Prometheus मेट्रिक्स पहा. लक्षात येण्याजोग्या प्रतीक्षा वेळा (5ms वरील काहीही) हे एक संकेत आहे की तेथे खूप कमी कनेक्शन उपलब्ध आहेत; डेटाबेस खूप व्यस्त असल्यामुळे (जसे की उच्च CPU लोड) जास्त प्रतीक्षा वेळ देखील असेल. तथापि, डेटाबेस अन्यथा स्थिर वाटत असल्यास, उच्च प्रतीक्षा वेळ कनेक्शनची संख्या वाढवण्याची आवश्यकता दर्शवते. कॉन्फिगरेशनमध्ये, प्रत्येक ग्राफ-नोड उदाहरणे किती कनेक्शन वापरू शकतात ही एक वरची मर्यादा आहे आणि ग्राफ नोडला आवश्यक नसल्यास कनेक्शन उघडे ठेवणार नाही.

स्टोअर कॉन्फिगरेशनबद्दल येथे अधिक वाचा.

समर्पित ब्लॉक अंतर्ग्रहण

जर अनेक नोड्स कॉन्फिगर केले असतील तर, नवीन ब्लॉक्सच्या अंतर्ग्रहणासाठी जबाबदार असणारा एक नोड निर्दिष्ट करणे आवश्यक असेल, जेणेकरून सर्व कॉन्फिगर केलेले इंडेक्स नोड्स चेन हेडवर मतदान करत नाहीत. हे साखळी नेमस्पेसचा भाग म्हणून केले जाते, ब्लॉक अंतर्ग्रहणासाठी वापरले जाणारे node_id निर्दिष्ट करते:

[chains]
ingestor = "block_ingestor_node"

एकाधिक नेटवर्क समर्थन

आलेख प्रोटोकॉल इंडेक्सिंग रिवॉर्ड्ससाठी समर्थित नेटवर्क्सची संख्या वाढवत आहे आणि असे अनेक सबग्राफ आहेत जे असमर्थित नेटवर्क अनुक्रमित करतात ज्यावर इंडेक्सर प्रक्रिया करू इच्छितो. config.toml फाइल अर्थपूर्ण आणि लवचिक कॉन्फिगरेशनसाठी परवानगी देते:

एकाधिक नेटवर्क
प्रति नेटवर्क एकाधिक प्रदाते (हे प्रदात्यांमध्ये लोडचे विभाजन करण्यास अनुमती देऊ शकते आणि पूर्ण नोड्स तसेच संग्रहित नोड्सच्या कॉन्फिगरेशनला देखील अनुमती देऊ शकते, दिलेल्या वर्कलोडला परवानगी दिल्यास ग्राफ नोड स्वस्त प्रदात्यांकडे प्राधान्य देतो).
अतिरिक्त प्रदाता तपशील, जसे की वैशिष्ट्ये, प्रमाणीकरण आणि प्रदात्याचा प्रकार (प्रायोगिक फायरहोस समर्थनासाठी)

[chains] विभाग इथेरियम प्रदाते नियंत्रित करतो ज्यांना ग्राफ-नोड कनेक्ट केले जाते आणि जेथे प्रत्येक साखळीसाठी ब्लॉक आणि इतर मेटाडेटा संग्रहित केला जातो. खालील उदाहरण दोन चेन कॉन्फिगर करते, मेननेट आणि कोव्हन, जिथे मेननेटचे ब्लॉक्स vip शार्डमध्ये साठवले जातात आणि कोवनचे ब्लॉक्स प्राथमिक शार्डमध्ये साठवले जातात. मेननेट चेन दोन भिन्न प्रदाते वापरू शकते, तर कोव्हनमध्ये फक्त एक प्रदाता आहे.

[chains]
ingestor = "block_ingestor_node"
[chains.mainnet]
shard = "vip"
provider = [
  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
]
[chains.kovan]
shard = "primary"
provider = [ { label = "kovan", url = "http://..", features = [] } ]

प्रदाता कॉन्फिगरेशनबद्दल येथे अधिक वाचा.

पर्यावरण परिवर्तने

ग्राफ नोड पर्यावरणीय चलांच्या श्रेणीचे समर्थन करते जे वैशिष्ट्ये सक्षम करू शकतात किंवा ग्राफ नोड वर्तन बदलू शकतात. हे येथे दस्तऐवजीकरण केलेले आहेत.

सतत तैनाती

प्रगत कॉन्फिगरेशनसह स्केल केलेले इंडेक्सिंग सेटअप चालवणारे वापरकर्ते त्यांचे ग्राफ नोड्स Kubernetes सोबत व्यवस्थापित करण्याचा फायदा घेऊ शकतात.

The indexer repository has an example Kubernetes reference
Launchpad हे GraphOps द्वारे देखरेख केलेल्या Kubernetes वर ग्राफ प्रोटोकॉल इंडेक्सर चालवण्यासाठी टूलकिट आहे. हे ग्राफ नोड उपयोजन व्यवस्थापित करण्यासाठी हेल्म चार्ट आणि एक CLI प्रदान करते.

ग्राफ नोडचे व्यवस्थापन

चालू असलेला आलेख नोड (किंवा आलेख नोड्स!) दिल्यास, त्या नोड्सवर उपयोजित सबग्राफ व्यवस्थापित करण्याचे आव्हान आहे. उपग्राफ व्यवस्थापित करण्यात मदत करण्यासाठी ग्राफ नोड अनेक साधनांची श्रेणी तयार करतो.

लॉगिंग

ग्राफ नोडचे लॉग ग्राफ नोड आणि विशिष्ट सबग्राफच्या डीबगिंग आणि ऑप्टिमायझेशनसाठी उपयुक्त माहिती प्रदान करू शकतात. ग्राफ नोड GRAPH_LOG पर्यावरण व्हेरिएबलद्वारे विविध लॉग स्तरांना खालील स्तरांसह समर्थन देतो: त्रुटी, चेतावणी, माहिती, डीबग किंवा ट्रेस.

याव्यतिरिक्त gql वर GRAPH_LOG_QUERY_TIMING सेटिंग केल्याने GraphQL क्वेरी कशा चालत आहेत याबद्दल अधिक तपशील प्रदान करते (जरी हे मोठ्या प्रमाणात लॉग तयार करेल).

देखरेख & चेतावणी

ग्राफ नोड डिफॉल्टनुसार 8040 पोर्टवर प्रोमिथियस एंडपॉइंटद्वारे मेट्रिक्स प्रदान करतो. या मेट्रिक्सची कल्पना करण्यासाठी ग्राफानाचा वापर केला जाऊ शकतो.

The indexer repository provides an example Grafana configuration.

ग्राफमन

ग्राफमन हे ग्राफ नोडसाठी एक देखभाल साधन आहे, जे वेगवेगळ्या दैनंदिन आणि अपवादात्मक कार्यांचे निदान आणि निराकरण करण्यात मदत करते.

ग्राफमन कमांड अधिकृत कंटेनरमध्ये समाविष्ट केली आहे आणि ती चालवण्यासाठी तुम्ही तुमच्या ग्राफ-नोड कंटेनरमध्ये डॉकर एक्झी करू शकता. यासाठी config.toml फाइल आवश्यक आहे.

graphman आदेशांचे संपूर्ण दस्तऐवजीकरण ग्राफ नोड भांडारात उपलब्ध आहे. ग्राफ नोड /docs मध्ये [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) पहा

सबग्राफसह कार्य करणे

अनुक्रमणिका स्थिती API

डीफॉल्टनुसार पोर्ट 8030/graphql वर उपलब्ध, अनुक्रमणिका स्थिती API वेगवेगळ्या सबग्राफसाठी अनुक्रमणिका स्थिती तपासण्यासाठी, अनुक्रमणिकेचे पुरावे तपासण्यासाठी, सबग्राफ वैशिष्ट्यांचे निरीक्षण करण्यासाठी आणि बरेच काही करण्यासाठी पद्धतींची श्रेणी उघड करते.

संपूर्ण स्कीमा येथे उपलब्ध आहे.

अनुक्रमणिका कार्यप्रदर्शन

There are three separate parts of the indexing process:

प्रदात्याकडून स्वारस्यपूर्ण इव्हेंट आणत आहे
योग्य हँडलर्ससह इव्हेंट्सवर प्रक्रिया करणे (यामध्ये राज्यासाठी साखळी कॉल करणे आणि स्टोअरमधून डेटा आणणे समाविष्ट असू शकते)
परिणामी डेटा स्टोअरमध्ये लिहित आहे

हे टप्पे पाइपलाइन केलेले आहेत (म्हणजे ते समांतरपणे कार्यान्वित केले जाऊ शकतात), परंतु ते एकमेकांवर अवलंबून आहेत. जेथे सबग्राफ अनुक्रमणिकेसाठी मंद असतात, तेथे मूळ कारण विशिष्ट सबग्राफवर अवलंबून असेल.

अनुक्रमणिका मंद होण्याची सामान्य कारणे:

साखळीतून संबंधित इव्हेंट शोधण्यासाठी लागणारा वेळ (trace_filter वर अवलंबून राहिल्यामुळे कॉल हँडलर धीमे असू शकतात)
Making large numbers of eth_calls as part of handlers
A large amount of store interaction during execution
A large amount of data to save to the store
प्रक्रिया करण्यासाठी मोठ्या संख्येने इव्हेंट
गर्दीच्या नोड्ससाठी स्लो डेटाबेस कनेक्शन वेळ
प्रदाता स्वतः साखळी डोके मागे घसरण
Slowness in fetching new receipts at the chain head from the provider

सबग्राफ इंडेक्सिंग मेट्रिक्स इंडेक्सिंग मंदतेच्या मूळ कारणाचे निदान करण्यात मदत करू शकतात. काही प्रकरणांमध्ये, समस्या उपग्राफमध्येच असते, परंतु इतरांमध्ये, सुधारित नेटवर्क प्रदाते, कमी डेटाबेस विवाद आणि इतर कॉन्फिगरेशन सुधारणा अनुक्रमणिका कार्यप्रदर्शनात लक्षणीय सुधारणा करू शकतात.

अयशस्वी सबग्राफ

अनुक्रमणिका दरम्यान सबग्राफ अयशस्वी होऊ शकतात, त्यांना अनपेक्षित डेटा आढळल्यास, काही घटक अपेक्षेप्रमाणे कार्य करत नसल्यास किंवा इव्हेंट हँडलर किंवा कॉन्फिगरेशनमध्ये काही बग असल्यास. अपयशाचे दोन सामान्य प्रकार आहेत:

Deterministic failures: these are failures which will not be resolved with retries
नॉन-डिटरमिनिस्टिक अपयश: हे प्रदात्याशी संबंधित समस्या किंवा काही अनपेक्षित ग्राफ नोड त्रुटींमुळे असू शकतात. जेव्हा नॉन-डिटरमिनिस्टिक अपयश येते, तेव्हा ग्राफ नोड अयशस्वी हँडलरचा पुन्हा प्रयत्न करेल, कालांतराने बॅक ऑफ होईल.

काही प्रकरणांमध्ये इंडेक्सरद्वारे बिघाडाचे निराकरण केले जाऊ शकते (उदाहरणार्थ त्रुटी योग्य प्रकारचा प्रदाता नसल्यामुळे, आवश्यक प्रदाता जोडल्याने अनुक्रमणिका सुरू ठेवता येईल). तथापि, इतरांमध्ये, सबग्राफ कोडमध्ये बदल आवश्यक आहे.

निर्धारक अपयशांना "अंतिम" मानले जाते, अयशस्वी ब्लॉकसाठी अनुक्रमणिकेचा पुरावा व्युत्पन्न केला जातो, तर नॉन-डिटरमिनिस्टिक अपयश असे नसतात, कारण सबग्राफ "अनफल" आणि अनुक्रमणिका सुरू ठेवू शकतो. काही प्रकरणांमध्ये, नॉन-डिटरमिनिस्टिक लेबल चुकीचे आहे, आणि सबग्राफ कधीही त्रुटीवर मात करणार नाही; अशा अपयशांचा ग्राफ नोड रेपॉजिटरीवरील समस्या म्हणून अहवाल द्यावा.

ब्लॉक आणि कॉल कॅशे

प्रदात्याकडून रीफेचिंग जतन करण्यासाठी ग्राफ नोड स्टोअरमधील काही डेटा कॅश करतो. eth_calls च्या परिणामांप्रमाणेच ब्लॉक्स कॅशे केले जातात (नंतरचे विशिष्ट ब्लॉक म्हणून कॅश केले जातात). हे कॅशिंग थोड्याशा बदललेल्या सबग्राफच्या "रीसिंकिंग" दरम्यान अनुक्रमणिकेची गती नाटकीयरित्या वाढवू शकते.

However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use graphman to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.

If a block cache inconsistency is suspected, such as a tx receipt missing event:

graphman chain list to find the chain name.
ग्राफमन चेन चेक-ब्लॉक <CHAIN> बाय-नंबर <NUMBER> कॅशे केलेला ब्लॉक प्रदात्याशी जुळतो की नाही हे तपासेल आणि तसे नसल्यास कॅशेमधून ब्लॉक हटवेल.
1. If there is a difference, it may be safer to truncate the whole cache with graphman chain truncate <CHAIN>.
2. If the block matches the provider, then the issue can be debugged directly against the provider.

समस्या आणि त्रुटींची चौकशी करणे

एकदा सबग्राफ इंडेक्स केला गेला की, इंडेक्सर्स सबग्राफच्या समर्पित क्वेरी एंडपॉइंटद्वारे क्वेरी सर्व्ह करण्याची अपेक्षा करू शकतात. जर इंडेक्सर महत्त्वपूर्ण क्वेरी व्हॉल्यूम प्रदान करण्याची आशा करत असेल तर, समर्पित क्वेरी नोडची शिफारस केली जाते आणि खूप जास्त क्वेरी व्हॉल्यूम असल्यास, इंडेक्सर्स प्रतिकृती शार्ड्स कॉन्फिगर करू शकतात जेणेकरुन क्वेरींचा अनुक्रमणिका प्रक्रियेवर परिणाम होणार नाही.

However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.

There is not one "silver bullet", but a range of tools for preventing, diagnosing and dealing with slow queries.

क्वेरी कॅशिंग

ग्राफ नोड डीफॉल्टनुसार GraphQL क्वेरी कॅश करते, जे डेटाबेस लोड लक्षणीयरीत्या कमी करू शकते. हे पुढे GRAPH_QUERY_CACHE_BLOCKS आणि GRAPH_QUERY_CACHE_MAX_MEM सेटिंग्जसह कॉन्फिगर केले जाऊ शकते - येथे अधिक वाचा.

प्रश्नांचे विश्लेषण करत आहे

समस्याप्रधान क्वेरी बहुतेक वेळा दोनपैकी एका मार्गाने समोर येतात. काही प्रकरणांमध्ये, वापरकर्ते स्वतः तक्रार करतात की दिलेली क्वेरी धीमी आहे. अशावेळी मंदपणाच्या कारणाचे निदान करणे हे आव्हान असते - मग ती सामान्य समस्या असो, किंवा त्या सबग्राफ किंवा क्वेरीशी संबंधित असो. आणि मग नक्कीच, शक्य असल्यास, निराकरण करण्यासाठी.

इतर प्रकरणांमध्ये, ट्रिगर हा क्वेरी नोडवर उच्च मेमरी वापर असू शकतो, अशा परिस्थितीत समस्या निर्माण करणारी क्वेरी ओळखण्याचे आव्हान प्रथम आहे.

इंडेक्सर्स ग्राफ नोडच्या क्वेरी लॉगची प्रक्रिया आणि सारांश देण्यासाठी qlog वापरू शकतात. GRAPH_LOG_QUERY_TIMING मंद क्वेरी ओळखण्यात आणि डीबग करण्यात मदत करण्यासाठी देखील सक्षम केले जाऊ शकते.

धीमे क्वेरी दिल्यास, इंडेक्सर्सकडे काही पर्याय आहेत. समस्याप्रधान क्वेरी पाठविण्याच्या खर्चात लक्षणीय वाढ करण्यासाठी अर्थातच ते त्यांच्या किंमतीचे मॉडेल बदलू शकतात. यामुळे त्या क्वेरीची वारंवारता कमी होऊ शकते. तथापि, हे सहसा समस्येचे मूळ कारण सोडवत नाही.

खात्यासारखे ऑप्टिमायझेशन

डाटाबेस सारणी जे संस्था संग्रहित करतात ते साधारणपणे दोन प्रकारात येतात: 'व्यवहारासारखे', जेथे संस्था, एकदा तयार केल्या गेल्या, कधीही अद्यतनित केल्या जात नाहीत, म्हणजे, ते आर्थिक व्यवहारांच्या सूचीसारखे काहीतरी संग्रहित करतात आणि 'खाते-सारखे' जेथे संस्था बर्‍याचदा अपडेट केले जातात, म्हणजे, ते आर्थिक खात्यांसारखे काहीतरी संग्रहित करतात जे प्रत्येक वेळी व्यवहार रेकॉर्ड केल्यावर सुधारित केले जातात. खात्यासारख्या सारण्यांचे वैशिष्ट्य असे आहे की त्यामध्ये मोठ्या संख्येने अस्तित्व आवृत्त्या आहेत, परंतु तुलनेने काही वेगळे घटक आहेत. बर्‍याचदा, अशा सारण्यांमध्ये भिन्न घटकांची संख्या एकूण पंक्तींच्या 1% असते (संस्था आवृत्ती)

खात्यासारख्या सारण्यांसाठी, ग्राफ-नोड क्वेरी व्युत्पन्न करू शकतात जे पोस्टग्रेस एवढ्या उच्च बदलासह डेटा कसा संग्रहित करते याच्या तपशीलाचा फायदा घेतात, म्हणजे अलीकडील ब्लॉक्ससाठी सर्व आवृत्त्या आहेत. अशा सारणीसाठी एकूण स्टोरेजचा एक छोटा उपविभाग.

कमांड ग्राफमन आकडेवारी दाखवते <sgdNNNN> डिप्लॉयमेंटमधील प्रत्येक घटक प्रकार/सारणीसाठी, किती वेगळे घटक आणि प्रत्येक सारणीमध्ये किती घटक आवृत्त्या आहेत हे दाखवते. तो डेटा पोस्टग्रेस-अंतर्गत अंदाजांवर आधारित आहे, आणि त्यामुळे अपरिहार्यपणे अशुद्ध आहे, आणि परिमाणाच्या क्रमाने बंद होऊ शकतो. संस्था स्तंभातील -1 म्हणजे पोस्टग्रेसचा असा विश्वास आहे की सर्व पंक्तींमध्ये एक वेगळे अस्तित्व आहे.

सर्वसाधारणपणे, ज्या सारण्यांमध्ये भिन्न घटकांची संख्या एकूण पंक्ती/संस्थेच्या आवृत्त्यांच्या 1% पेक्षा कमी आहे ते खाते-समान ऑप्टिमायझेशनसाठी चांगले उमेदवार आहेत. जेव्हा ग्राफमन आकडेवारी दर्शविते चे आउटपुट सूचित करते की टेबलला या ऑप्टिमायझेशनचा फायदा होऊ शकतो, तेव्हा ग्राफमन आकडेवारी <sgdNNN> <table> सारणीची संपूर्ण गणना करेल - ते धीमे असू शकते, परंतु एकूण घटक आवृत्त्यांमधील भिन्न घटकांच्या गुणोत्तराचे अचूक माप देते.

एकदा टेबल खात्यासारखे असल्याचे निश्चित केले गेले की, ग्राफमन स्टॅट्स अकाउंट-समान <sgdNNN>.<table> चालवल्याने त्या टेबलवरील क्वेरींसाठी खाते-सारखे ऑप्टिमायझेशन चालू होईल. ऑप्टिमायझेशन graphman stats account-like --clear <sgdNNN>.<table> सह पुन्हा बंद केले जाऊ शकते हे ऑप्टिमायझेशन चालू केले आहे हे लक्षात येण्यासाठी क्वेरी नोड्ससाठी 5 मिनिटे लागतात किंवा बंद. ऑप्टिमायझेशन चालू केल्यानंतर, बदलामुळे त्या टेबलसाठी प्रश्नांची गती कमी होत नाही हे सत्यापित करणे आवश्यक आहे. तुम्ही पोस्टग्रेसचे निरीक्षण करण्यासाठी Grafana कॉन्फिगर केले असल्यास, स्लो क्वेरी pg_stat_activityमध्‍ये मोठ्या संख्येने दिसतील, काही सेकंद घेतील. अशा परिस्थितीत, ऑप्टिमायझेशन पुन्हा बंद करणे आवश्यक आहे.

युनिस्‍ॅप सारख्या सबग्राफसाठी, जोडी आणि टोकन सारण्या या ऑप्टिमायझेशनसाठी प्रमुख उमेदवार आहेत आणि डेटाबेस लोडवर नाटकीय प्रभाव टाकू शकतात.

सबग्राफ काढून टाकत आहे

This is new functionality, which will be available in Graph Node 0.29.x

काही ठिकाणी इंडेक्सरला दिलेला सबग्राफ काढायचा असेल. हे ग्राफमॅन ड्रॉप द्वारे सहजपणे केले जाऊ शकते, जे उपयोजन आणि सर्व अनुक्रमित डेटा हटवते. उपयोजन एकतर सबग्राफ नाव, IPFS हॅश Qm.. किंवा डेटाबेस नेमस्पेस sgdNNN म्हणून निर्दिष्ट केले जाऊ शकते. पुढील दस्तऐवजीकरण येथे उपलब्ध आहे.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

operating-graph-node.mdx

operating-graph-node.mdx

आलेख नोड

PostgreSQL डेटाबेस

नेटवर्क क्लायंट

आयपीएफएस नोड्स

प्रोमिथियस मेट्रिक्स सर्व्हर

Getting started from source

Install prerequisites

Setup

Kubernetes सह प्रारंभ करणे

बंदरे

प्रगत ग्राफ नोड कॉन्फिगरेशन

`config.toml`

एकाधिक ग्राफ नोड्स

डिप्लॉयमेंट नियम

समर्पित क्वेरी नोड्स

शार्डिंगद्वारे डेटाबेस स्केलिंग

समर्पित ब्लॉक अंतर्ग्रहण

एकाधिक नेटवर्क समर्थन

पर्यावरण परिवर्तने

सतत तैनाती

ग्राफ नोडचे व्यवस्थापन

लॉगिंग

देखरेख & चेतावणी

ग्राफमन

सबग्राफसह कार्य करणे

अनुक्रमणिका स्थिती API

अनुक्रमणिका कार्यप्रदर्शन

अयशस्वी सबग्राफ

ब्लॉक आणि कॉल कॅशे

समस्या आणि त्रुटींची चौकशी करणे

क्वेरी कॅशिंग

प्रश्नांचे विश्लेषण करत आहे

खात्यासारखे ऑप्टिमायझेशन

सबग्राफ काढून टाकत आहे

Files

operating-graph-node.mdx

Latest commit

History

operating-graph-node.mdx

File metadata and controls

आलेख नोड

PostgreSQL डेटाबेस

नेटवर्क क्लायंट

आयपीएफएस नोड्स

प्रोमिथियस मेट्रिक्स सर्व्हर

Getting started from source

Install prerequisites

Setup

Kubernetes सह प्रारंभ करणे

बंदरे

प्रगत ग्राफ नोड कॉन्फिगरेशन

config.toml

एकाधिक ग्राफ नोड्स

डिप्लॉयमेंट नियम

समर्पित क्वेरी नोड्स

शार्डिंगद्वारे डेटाबेस स्केलिंग

समर्पित ब्लॉक अंतर्ग्रहण

एकाधिक नेटवर्क समर्थन

पर्यावरण परिवर्तने

सतत तैनाती

ग्राफ नोडचे व्यवस्थापन

लॉगिंग

देखरेख & चेतावणी

ग्राफमन

सबग्राफसह कार्य करणे

अनुक्रमणिका स्थिती API

अनुक्रमणिका कार्यप्रदर्शन

अयशस्वी सबग्राफ

ब्लॉक आणि कॉल कॅशे

समस्या आणि त्रुटींची चौकशी करणे

क्वेरी कॅशिंग

प्रश्नांचे विश्लेषण करत आहे

खात्यासारखे ऑप्टिमायझेशन

सबग्राफ काढून टाकत आहे

`config.toml`