Graph Node

Graph Node वह घटक है जो सबग्राफ को अनुक्रमित करता है, और परिणामी डेटा को GraphQL API के माध्यम से क्वेरी करने के लिए उपलब्ध कराता है। इसलिए, यह Indexer स्टैक के लिए केंद्रीय है, और ग्राफ-नोड का सही संचालन एक सफल Indexer चलाने के लिए अत्यंत महत्वपूर्ण है।

ग्राफ-नोड का संदर्भ और indexers के लिए उपलब्ध कुछ उन्नत विकल्पों का परिचय प्रदान करता है। विस्तृत दस्तावेज़ और निर्देश Graph Node repository⁠ में पाए जा सकते हैं।

Graph Node

Graph Node⁠ The Graph Network पर सबग्राफ को indexing करने के लिए संदर्भ कार्यान्वयन है, जो ब्लॉकचेन क्लाइंट्स से जुड़ता है, सबग्राफ को indexing करता है और अनुक्रमित डेटा को क्वेरी करने के लिए उपलब्ध कराता है।

Graph Node (और पूरा indexer stack) को bare metal पर या एक cloud environment में चलाया जा सकता है। The Graph Protocol की मजबूती के लिए केंद्रीय indexing घटक की यह लचीलापन बहुत महत्वपूर्ण है। इसी तरह, ग्राफ-नोड को साधन से बनाया जा सकता⁠ है, या indexers प्रदत्त Docker Images⁠ में से एक का उपयोग कर सकते हैं।

पोस्टग्रेएसक्यूएल डेटाबेस

ग्राफ नोड The Graph नेटवर्क पर सबग्राफ को Indexing करने के लिए एक संदर्भ कार्यान्वयन है, जो ब्लॉकचेन क्लाइंट से जुड़ता है, सबग्राफ को Indexing करता है और इंडेक्स किए गए डेटा को क्वेरी के लिए उपलब्ध कराता है।

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

किसी नेटवर्क को इंडेक्स करने के लिए, ग्राफ़ नोड को एथेरियम-संगत JSON-RPC के माध्यम से नेटवर्क क्लाइंट तक पहुंच की आवश्यकता होती है। यह आरपीसी एक एथेरियम क्लाइंट से जुड़ सकता है या यह एक अधिक जटिल सेटअप हो सकता है जो कई में संतुलन लोड करता है।

कुछ सबग्राफ को केवल एक पूर्ण नोड की आवश्यकता हो सकती है, जबकि कुछ में अतिरिक्त RPC कार्यक्षमता की आवश्यकता होती है जो indexing सुविधाओं के लिए आवश्यक होती है। विशेष रूप से, ऐसे सबग्राफ जो indexing के हिस्से के रूप में eth_calls करते हैं, उन्हें एक आर्काइव नोड की आवश्यकता होगी जो EIP-1898⁠ का समर्थन करता है, और ऐसे सबग्राफ जिनमें callHandlers या blockHandlers हैं जिनमें call फ़िल्टर है, उन्हें trace_filter समर्थन की आवश्यकता होती है (यहाँ ट्रेस मॉड्यूल दस्तावेज़ देखें⁠).

नेटवर्क फायरहोज़ - फायरहोज़ एक gRPC सेवा है जो ब्लॉक्स का क्रमबद्ध, फिर भी फोर्क-अवेयर स्ट्रीम प्रदान करती है। इसे The Graph के कोर डेवलपर्स द्वारा बड़े पैमाने पर प्रभावी indexing का समर्थन करने के लिए विकसित किया गया है। यह वर्तमान में Indexer के लिए अनिवार्य नहीं है, लेकिन Indexers को इस तकनीक से परिचित होने के लिए प्रोत्साहित किया जाता है ताकि वे नेटवर्क के पूर्ण समर्थन के लिए तैयार रहें। फायरहोज़ के बारे में अधिक जानें यहां⁠।

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

सबग्राफ तैनाती मेटाडेटा IPFS नेटवर्क पर संग्रहीत होता है। ग्राफ नोड मुख्य रूप से सबग्राफ तैनाती के दौरान IPFS नोड तक पहुँचता है ताकि सबग्राफ मैनिफेस्ट और सभी लिंक किए गए फ़ाइलों को प्राप्त कर सके। नेटवर्क Indexer को अपने स्वयं के IPFS नोड की मेज़बानी करने की आवश्यकता नहीं है। नेटवर्क के लिए एक IPFS नोड यहाँ होस्ट किया गया है: https://ipfs.thegraph.com⁠.

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

Monitoring and reporting को enable करने के लिए, Graph Node optionally रूप से metrics को Prometheus metrics server पर log कर सकता है।

सोर्स से शुरू करना

आवश्यक पूर्वापेक्षाएँ स्थापित करें

• Rust

• PostgreSQL

• IPFS

• उबंटू उपयोगकर्ताओं के लिए अतिरिक्त आवश्यकताएँ - उबंटू पर एक ग्राफ-नोड चलाने के लिए कुछ अतिरिक्त पैकेजों की आवश्यकता हो सकती है।

1sudo apt-get install -y clang libpq-dev libssl-dev pkg-config

सेटअप

1. PostgreSQL डेटाबेस सर्वर शुरू करें

1initdb -D .postgres2pg_ctl -D .postgres -l logfile start3createdb graph-node

2. ग्राफ-नोड⁠ रिपोजिटरी को क्लोन करें और स्रोत को बनाने के लिए cargo build कमांड चलाएँ।

3. अब जब सभी डिपेंडेंसीज़ सेटअप हो गई हैं, तो ग्राफ नोड शुरू करें:

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

Kubernetes के साथ शुरुआत करना

Kubernetes का एक पूर्ण उदाहरण कॉन्फ़िगरेशन indexer repository⁠ में पाया जा सकता है।

Ports

जब यह चल रहा होता है तो Graph Node following port को expose करता है:

Advanced Graph Node configuration

At its simplest, ग्राफ-नोड को एकल Graph Node instance, एकल PostgreSQL database, एक IPFS node, और नेटवर्क क्लाइंट्स की आवश्यकता होती है, जैसा कि सबग्राफ द्वारा अनुक्रमण के लिए आवश्यक होता है।

इस सेटअप को क्षैतिज रूप से स्केल किया जा सकता है, कई Graph नोड और उन Graph नोड को समर्थन देने के लिए कई डेटाबेस जोड़कर। उन्नत उपयोगकर्ता ग्राफ-नोड की कुछ क्षैतिज स्केलिंग क्षमताओं का लाभ उठाना चाह सकते हैं, साथ ही कुछ अधिक उन्नत कॉन्फ़िगरेशन विकल्पों का भी, config.toml फ़ाइल और ग्राफ-नोड के पर्यावरण वेरिएबल्स के माध्यम से।

config.toml

A TOML⁠ कॉन्फ़िगरेशन फ़ाइल का उपयोग CLI में उजागर किए गए अधिक जटिल कॉन्फ़िगरेशन सेट करने के लिए किया जा सकता है। फ़ाइल का स्थान —config कमांड लाइन स्विच के साथ पास किया जाता है।

एक न्यूनतम config.toml फ़ाइल प्रदान की जा सकती है; निम्नलिखित फ़ाइल का उपयोग —postgres-url कमांड लाइन विकल्प के समान है:

1[store]2[store.primary]3connection="<.. postgres-url argument ..>"4[deployment]5[[deployment.rule]]6indexers = [ "<.. list of all indexing nodes ..>" ]

config.toml की पूरी डॉक्यूमेंटेशन Graph Node docs⁠ में मिल सकती है।

Multiple Graph Nodes

ग्राफ नोड indexing क्षैतिज रूप से स्केल कर सकता है, विभिन्न नोड्स पर indexing और क्वेरी को विभाजित करने के लिए ग्राफ नोड के कई उदाहरण चलाते हुए। यह सरलता से किया जा सकता है, जब ग्राफ नोड्स को स्टार्टअप पर विभिन्न node_id के साथ कॉन्फ़िगर किया जाता है (जैसे, डॉकर कंपोज़ फ़ाइल में), जिसे फिर config.toml फ़ाइल में dedicated query nodes, block ingestors, और deployment rules के साथ नोड्स के बीच सबग्राफ विभाजित करने के लिए उपयोग किया जा सकता है।

Deployment rules

कई Graph नोड को देखते हुए, नए सबग्राफ की तैनाती का प्रबंधन करना आवश्यक है ताकि एक ही सबग्राफ दो अलग-अलग नोड्स द्वारा अनुक्रमित न किया जाए, जिससे टकराव हो सकता है। इसे तैनाती नियमों का उपयोग करके किया जा सकता है, जो यह भी निर्दिष्ट कर सकते हैं कि यदि डेटाबेस शार्डिंग का उपयोग किया जा रहा है, तो एक सबग्राफ के डेटा को किस shard में संग्रहीत किया जाना चाहिए। तैनाती नियम सबग्राफ के नाम और उस नेटवर्क पर मेल खा सकते हैं जिसमें तैनाती indexing हो रही है ताकि निर्णय लिया जा सके।

उदाहरण deployment rule configuration:

1[deployment]2[[deployment.rule]]3match = { name = "(vip|important)/.*" }4shard = "vip"5indexers = [ "index_node_vip_0", "index_node_vip_1" ]6[[deployment.rule]]7match = { network = "kovan" }8# No shard, so we use the default shard called 'primary'9indexers = [ "index_node_kovan_0" ]10[[deployment.rule]]11match = { network = [ "xdai", "poa-core" ] }12indexers = [ "index_node_other_0" ]13[[deployment.rule]]14# There's no 'match', so any Subgraph matches15shards = [ "sharda", "shardb" ]16indexers = [17    "index_node_community_0",18    "index_node_community_1",19    "index_node_community_2",20    "index_node_community_3",21    "index_node_community_4",22    "index_node_community_5"23  ]

डिप्लॉयमेंट नियमों के बारे में अधिक पढ़ें यहां⁠।

Dedicated query nodes

Configuration file में following को शामिल करके Nodes को explicitly रूप से query nodes होने के लिए configure किया जा सकता है:

1[general]2query = "<regular expression>"

कोई भी node जिसका —node-id regular expression से mail खाता है, केवल प्रश्नों का जवाब देने के लिए set किया जाएगा।

Sharding के माध्यम से Database scaling

For most use cases, एक एकल Postgres database graph-node उदाहरण का support करने के लिए sufficient है। जब एक graph-node उदाहरण single Postgres database से आगे निकल जाता है, तो graph-node के data के भंडारण को कई Postgres databases में split करना possible है। सभी database मिलकर graph-node instance का store बनाते हैं। प्रत्येक personal database को shard कहा जाता है।

Shards का उपयोग कई डेटाबेस में सबग्राफ डिप्लॉयमेंट को विभाजित करने के लिए किया जा सकता है, और साथ ही प्रतिकृतियों (replicas) का उपयोग करके क्वेरी लोड को डेटाबेस में वितरित करने के लिए भी किया जा सकता है। इसमें प्रत्येक graph-node के लिए प्रत्येक डेटाबेस में कनेक्शन पूल में रखे जाने वाले उपलब्ध डेटाबेस कनेक्शनों की संख्या को कॉन्फ़िगर करना शामिल है, जो कि जैसे-जैसे अधिक सबग्राफ इंडेक्स किए जा रहे हैं, उतना ही महत्वपूर्ण हो जाता है।

शेयरिंग तब उपयोगी हो जाती है जब आपका मौजूदा डेटाबेस ग्राफ़ नोड द्वारा डाले गए भार के साथ नहीं रह सकता है, और जब डेटाबेस का आकार बढ़ाना संभव नहीं होता है।

Configuring connections करने के मामले में, postgresql.conf में max_connections से 400 (or maybe even 200) पर set करें और store_connection_wait_time_ms और store_connection_checkout_count Prometheus metrics देखें। ध्यान देने Noticeable wait times (anything above 5ms) एक संकेत है कि बहुत कम connection उपलब्ध हैं; high wait times database बहुत busy होने (like high CPU load) के कारण भी होगा। हालाँकि यदि database otherwise stable लगता है, तो high wait times indicate की संख्या connection बढ़ाने की आवश्यकता का संकेत देता है। configuration में, प्रत्येक graph-node उदाहरण कितने connection का उपयोग कर सकता है, यह एक upper limit है, और Graph Node को connections खुला नहीं रखेगा यदि इसकी आवश्यकता नहीं है।

यहाँ⁠ स्टोर कॉन्फ़िगरेशन के बारे में और पढ़ें।

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

यदि कई नोड्स कॉन्फ़िगर किए गए हैं, तो यह आवश्यक होगा कि एक नोड निर्दिष्ट किया जाए जो नए ब्लॉक्स के इनजेशन के लिए जिम्मेदार हो, ताकि सभी कॉन्फ़िगर किए गए इंडेक्स नोड्स chain हेड को बार-बार पूछताछ न करें। इसे chains नेमस्पेस के हिस्से के रूप में किया जाता है, जहां ब्लॉक इनजेशन के लिए उपयोग किए जाने वाले node_id को निर्दिष्ट किया जाता है:

1[chains]2ingestor = "block_ingestor_node"

कई network का Supporting करना

The Graph Protocol उन नेटवर्क की संख्या बढ़ा रहा है जिन्हें Indexing पुरस्कारों के लिए समर्थित किया गया है, और कई सबग्राफ मौजूद हैं जो असमर्थित नेटवर्क को Indexers द्वारा संसाधित करने के लिए Indexing कर रहे हैं। config.toml फ़ाइल अभिव्यंजक और लचीले विन्यास की अनुमति देती है:

• Multiple networks
• Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
• Additional provider details, जैसे सुविधाएँ, authentication और provider का प्रकार (for experimental Firehose support)

[chains] अनुभाग उन Ethereum प्रदाताओं को नियंत्रित करता है जिनसे ग्राफ-नोड कनेक्ट होता है और जहाँ प्रत्येक chain के लिए ब्लॉक और अन्य मेटाडेटा संग्रहीत होते हैं। निम्नलिखित उदाहरण दो chain, mainnet और kovan को कॉन्फ़िगर करता है, जहाँ mainnet के लिए ब्लॉक vip shard में संग्रहीत होते हैं और kovan के लिए ब्लॉक primary shard में संग्रहीत होते हैं। mainnet chain दो अलग-अलग प्रदाताओं का उपयोग कर सकती है, जबकि kovan के पास केवल एक प्रदाता है।

1[chains]2ingestor = "block_ingestor_node"3[chains.mainnet]4shard = "vip"5provider = [6  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },7  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }8]9[chains.kovan]10shard = "primary"11provider = [ { label = "kovan", url = "http://..", features = [] } ]

एथेरियम प्रदाताओं की कॉन्फ़िगरेशन के बारे में अधिक जानकारी यहाँ⁠ पढ़ें।

Environment variables

ग्राफ-नोड कई environment variables का समर्थन करता है, जो सुविधाओं को सक्षम कर सकते हैं या ग्राफ-नोड के व्यवहार को बदल सकते हैं। इन्हें यहाँ⁠ प्रलेखित किया गया है।

Continuous deployment

जो उपयोगकर्ता उन्नत कॉन्फ़िगरेशन के साथ एक स्केल्ड इंडेक्सिंग सेटअप का संचालन कर रहे हैं, वे कुबेरनेट्स के साथ अपने ग्राफ़ नोड्स को प्रबंधित करने से लाभान्वित हो सकते हैं।

• Indexer रिपॉजिटरी में एक example Kubernetes reference⁠ उपलब्ध है।
• Launchpad⁠ एक टूलकिट है जो Kubernetes पर Graph Protocol Indexer को चलाने के लिए GraphOps द्वारा मेंटेन किया जाता है। यह Helm चार्ट्स और एक CLI का सेट प्रदान करता है जो ग्राफ-नोड डिप्लॉयमेंट को प्रबंधित करने के लिए उपयोग किया जाता है।

Managing Graph Node

एक चालू Graph Node (या कई Graph Nodes!) को चलाने के बाद, अगली चुनौती उन Graph Nodes पर तैनात किए गए सबग्राफ को प्रबंधित करने की होती है। ग्राफ-नोड विभिन्न टूल्स प्रदान करता है जो सबग्राफ के प्रबंधन में मदद करते हैं।

लॉगिंग

ग्राफ-नोड के लॉग्स ग्राफ-नोड और विशिष्ट सबग्राफ की डिबगिंग और ऑप्टिमाइज़ेशन के लिए उपयोगी जानकारी प्रदान कर सकते हैं। ग्राफ-नोड GRAPH_LOG एनवायरमेंट वेरिएबल के माध्यम से विभिन्न लॉग स्तरों का समर्थन करता है, जिनमें निम्नलिखित स्तर शामिल हैं: error, warn, info, debug या trace।

GraphQL queries कैसे चल रही हैं, इस बारे में अधिक विवरण प्राप्त करने के लिए GRAPH_LOG_QUERY_TIMING को gql पर सेट करना उपयोगी हो सकता है (हालांकि इससे बड़ी मात्रा में लॉग उत्पन्न होंगे)।

निगरानी और सतर्कता

ग्राफ़ नोड डिफ़ॉल्ट रूप से 8040 पोर्ट पर प्रोमेथियस एंडपॉइंट के माध्यम से मेट्रिक्स प्रदान करता है। इन मेट्रिक्स की कल्पना करने के लिए ग्राफाना का उपयोग किया जा सकता है।

Indexer रिपॉजिटरी एक example Grafana configuration⁠ प्रदान करती है।

Graphman

graphman एक maintenance टूल है ग्राफ-नोड के लिए, जो विभिन्न दैनिक और असाधारण कार्यों के निदान और समाधान में मदद करता है।

The graphman कमांड आधिकारिक कंटेनरों में शामिल है, और आप अपने ग्राफ-नोड कंटेनर में docker exec कमांड का उपयोग करके इसे चला सकते हैं। इसके लिए एक config.toml फ़ाइल की आवश्यकता होती है।

graphman कमांड्स का पूरा दस्तावेज़ ग्राफ नोड रिपॉजिटरी में उपलब्ध है। ग्राफ नोड /docs में /docs/graphman.md⁠ देखें।

Subgraph के साथ कार्य करना

अनुक्रमण स्थिति एपीआई

डिफ़ॉल्ट रूप से पोर्ट 8030/graphql पर उपलब्ध, indexing स्थिति API विभिन्न सबग्राफ के लिए indexing स्थिति की जाँच करने, proofs of indexing की जाँच करने, सबग्राफ सुविधाओं का निरीक्षण करने और अधिक के लिए कई तरीकों को उजागर करता है।

पूर्ण स्कीमा यहां⁠ उपलब्ध है।

Indexing performance

Indexing process के तीन अलग-अलग भाग हैं:

• Provider से रुचि के event लाए जा रहे हैं
• उपयुक्त संचालकों के साथ घटनाओं को संसाधित करना (इसमें राज्य के लिए श्रृंखला को कॉल करना और स्टोर से डेटा प्राप्त करना शामिल हो सकता है)
• Resulting data को store पर लिखना

ये चरण पाइपलाइन किए गए हैं (अर्थात वे समानांतर रूप से निष्पादित किए जा सकते हैं), लेकिन वे एक-दूसरे पर निर्भर हैं। जहाँ सबग्राफ को इंडेक्स करने में धीमापन होता है, वहाँ इसकी मूल वजह विशिष्ट सबग्राफ पर निर्भर करेगी।

Common causes of indexing slowness:

• Chain से प्रासंगिक आयोजन खोजने में लगने वाला समय (विशेष रूप से कॉल handler धीमे हो सकते हैं, क्योंकि ये trace_filter पर निर्भर करते हैं)।
• Handler के हिस्से के रूप में बड़ी संख्या में eth_calls करना।
• Execution के दौरान बड़ी मात्रा में store interaction
• Store में सहेजने के लिए बड़ी मात्रा में data
• Process करने के लिए बड़ी संख्या में events
• भीड़भाड़ वाले nodes के लिए Slow database connection समय
• Provider itself chain head के पीछे पड़ रहा है
• Provider से chain head पर नई receipt प्राप्त करने में Slowness

सबग्राफ Indexing मैट्रिक्स Indexing की धीमी गति के मूल कारण का निदान करने में मदद कर सकते हैं। कुछ मामलों में, समस्या स्वयं सबग्राफ में होती है, लेकिन अन्य मामलों में, बेहतर नेटवर्क प्रदाता, कम डेटाबेस प्रतिस्पर्धा और अन्य कॉन्फ़िगरेशन सुधार Indexing प्रदर्शन को उल्लेखनीय रूप से बेहतर बना सकते हैं।

असफल Subgraph

Indexing के दौरान Subgraph असफल हो सकते हैं, यदि उन्हें अप्रत्याशित डेटा मिलता है, कोई घटक अपेक्षित रूप से कार्य नहीं कर रहा हो, या यदि event handlers या configuration में कोई बग हो। असफलता के दो सामान्य प्रकार हैं:

• Deterministic failures: ये ऐसी failures हैं जिन्हें resolved से हल नहीं किया जा सकता है
• गैर-नियतात्मक विफलताएँ: ये प्रदाता के साथ समस्याओं या कुछ अप्रत्याशित ग्राफ़ नोड त्रुटि के कारण हो सकती हैं। जब एक गैर-नियतात्मक विफलता होती है, तो ग्राफ़ नोड समय के साथ पीछे हटते हुए विफल हैंडलर को फिर से प्रयास करेगा।

कुछ मामलों में, विफलता को Indexer द्वारा हल किया जा सकता है (उदाहरण के लिए, यदि त्रुटि सही प्रकार के provider की अनुपस्थिति के कारण है, तो आवश्यक provider जोड़ने से Indexing जारी रह सकती है)। हालाँकि, अन्य मामलों में, सबग्राफ कोड में परिवर्तन आवश्यक होता है।

कैश को ब्लॉक और कॉल करें

ग्राफ-नोड कुछ डेटा को स्टोर में कैश करता है ताकि प्रोवाइडर से पुनः प्राप्त करने से बचा जा सके। ब्लॉक्स को कैश किया जाता है, जैसे कि eth_calls के परिणाम (जिसे एक विशिष्ट ब्लॉक के रूप में कैश किया जाता है)। यह कैशिंग “resyncing” के दौरान थोड़ा बदले हुए सबग्राफ की indexing स्पीड को नाटकीय रूप से बढ़ा सकती है।

हालांकि, कुछ मामलों में, यदि कोई Ethereum नोड कुछ समय के लिए गलत डेटा प्रदान करता है, तो वह कैश में आ सकता है, जिससे गलत डेटा या असफल सबग्राफ हो सकते हैं। इस स्थिति में, Indexers graphman का उपयोग करके दूषित कैश को साफ कर सकते हैं और फिर प्रभावित सबग्राफको पुनः पीछे ले जा सकते हैं, जिससे वे (उम्मीद है) स्वस्थ प्रदाता से नया डेटा प्राप्त कर सकें।

यदि एक block cache inconsistency का संदेह है, जैसे कि tx receipt missing event:

1. graphman chain list का उपयोग करके chain का नाम पता करें।
2. graphman chain check-blocks <CHAIN> by-number <NUMBER> यह जांच करेगा कि क्या कैश किया हुआ ब्लॉक प्रदाता से मेल खाता है, और यदि यह मेल नहीं खाता है तो ब्लॉक को कैश से हटा देगा।
   1. यदि कोई अंतर है, तो पूरे कैश को graphman chain truncate <CHAIN> के साथ हटाना अधिक सुरक्षित हो सकता है।
   2. यदि ब्लॉक प्रदाता से मेल खाता है, तो समस्या को सीधे प्रदाता के विरुद्ध डिबग किया जा सकता है।

Issues और errors को query करना

एक बार जब सबग्राफ को इंडेक्स कर लिया जाता है, तो Indexers इससे जुड़े समर्पित क्वेरी एंडपॉइंट के माध्यम से क्वेरी प्रदान करने की उम्मीद कर सकते हैं। यदि Indexer महत्वपूर्ण मात्रा में क्वेरी सर्व करना चाहता है, तो एक समर्पित क्वेरी नोड की सिफारिश की जाती है, और बहुत अधिक क्वेरी वॉल्यूम के मामले में, Indexers को प्रतिकृति shard कॉन्फ़िगर करने पर विचार करना चाहिए ताकि क्वेरीज़ Indexing प्रक्रिया को प्रभावित न करें।

हालाँकि, एक समर्पित क्वेरी नोड और प्रतिकृतियों के साथ भी, कुछ प्रश्नों को निष्पादित करने में लंबा समय लग सकता है, और कुछ मामलों में मेमोरी उपयोग में वृद्धि होती है और अन्य उपयोगकर्ताओं के लिए क्वेरी समय को नकारात्मक रूप से प्रभावित करती है।

एक “सिल्वर बुलेट” नहीं है, लेकिन धीमे प्रश्नों को रोकने, निदान करने और निपटने के लिए उपकरणों की एक श्रृंखला है।

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

ग्राफ-नोड डिफ़ॉल्ट रूप से GraphQL queries को कैश करता है, जिससे डेटाबेस लोड को काफी हद तक कम किया जा सकता है। इसे GRAPH_QUERY_CACHE_BLOCKS और GRAPH_QUERY_CACHE_MAX_MEM सेटिंग्स के साथ और अधिक कॉन्फ़िगर किया जा सकता है - अधिक पढ़ें here⁠।

Analysing queries

समस्याग्रस्त क्वेरीज़ अक्सर दो तरीकों से सामने आती हैं। कुछ मामलों में, उपयोगकर्ता स्वयं रिपोर्ट करते हैं कि कोई विशेष क्वेरी धीमी है। ऐसे में चुनौती यह होती है कि धीमेपन के कारण का निदान किया जाए - यह पता लगाया जाए कि यह कोई सामान्य समस्या है या किसी विशेष सबग्राफ या क्वेरी से संबंधित है। और फिर, यदि संभव हो, तो इसे हल किया जाए।

अन्य मामलों में, क्वेरी नोड पर ट्रिगर उच्च मेमोरी उपयोग हो सकता है, इस मामले में सबसे पहले समस्या उत्पन्न करने वाली क्वेरी की पहचान करना चुनौती है।

Indexers qlog⁠ का उपयोग करके ग्राफ-नोड के query logs को प्रोसेस और सारांशित कर सकते हैं। धीमे queries की पहचान और डिबग करने में मदद के लिए GRAPH_LOG_QUERY_TIMING को भी सक्षम किया जा सकता है।

Given a slow query, indexer के पास कुछ options होते हैं. Of course they can alter their cost model, problematic query भेजने की लागत में काफी increase कर सकते हैं। इसके result उस query की frequency में कमी हो सकती है। हालाँकि यह अक्सर issue के मूल कारण को हल नहीं करता है।

Account-like optimisation

Database tables that store entities seem to generally come in two varieties: ‘transaction-like’, आम तौर पर दो तरह में आती हैं: ‘transaction-like’, जहाँ संस्थाएँ, एक बार बनने के बाद, कभी-कभी updated नहीं होती हैं, यानी, वे financial transactions की सूची के तरह कुछ store करते हैं, और ‘account-like’ जहां संस्थाएं बार-बार updated होती हैं, यानी, वे financial accounts की सूची के तरह कुछ store करते हैं जो every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. बारंबार, ऐसे विद्वानों में अलग-अलग टुकड़ों की संख्या, कुल संख्या (entity versions) का 1% होती है

अकाउंट-जैसी तालिकाओं के लिए, ग्राफ-नोड ऐसे queries जनरेट कर सकता है जो इस विवरण का लाभ उठाते हैं कि Postgres इतनी तेज़ दर पर डेटा स्टोर करते समय इसे कैसे प्रबंधित करता है। खासतौर पर, हाल के ब्लॉक्स के सभी संस्करण ऐसी तालिका के कुल स्टोरेज के एक छोटे से हिस्से में होते हैं।

कमांड graphman stats show <sgdNNNN> प्रत्येक डिप्लॉयमेंट में मौजूद entities प्रकार/टेबल के लिए यह दिखाता है कि प्रत्येक टेबल में कितनी अलग-अलग entities और कितने entities वर्ज़न हैं। यह डेटा Postgres के आंतरिक अनुमानों पर आधारित होता है, और इसलिए यह अनिवार्य रूप से सटीक नहीं होता है और इसमें एक ऑर्डर ऑफ मैग्निट्यूड तक का अंतर हो सकता है। entities कॉलम में -1 का मतलब है कि Postgres मानता है कि सभी पंक्तियां एक अलग entities को शामिल करती हैं।

सामान्यतः, वे तालिकाएँ जहाँ विशिष्ट entities की संख्या कुल पंक्तियों/entities संस्करणों की संख्या का 1% से कम हो, वे खाता-जैसा अनुकूलन के लिए अच्छे उम्मीदवार होती हैं। जब graphman stats show का आउटपुट यह दर्शाता है कि कोई तालिका इस optimization से लाभ उठा सकती है, तो graphman stats show <sgdNNN> <table> चलाने पर तालिका की पूरी गणना की जाती है - यह धीमा हो सकता है, लेकिन विशिष्ट entities और कुल entities संस्करणों के अनुपात का सटीक माप प्रदान करता है।

एक बार जब यह तय कर लिया जाता है कि एक तालिका खाता जैसी है, तो graphman stats account-like <sgdNNN>.<table> चलाने से उस तालिका के खिलाफ queries के लिए खाता जैसी अनुकूलन सक्षम हो जाएगा। इस अनुकूलन को फिर से बंद किया जा सकता है graphman stats account-like --clear <sgdNNN>.<table> के साथ। queries नोड्स को यह नोटिस करने में 5 मिनट तक का समय लग सकता है कि अनुकूलन को चालू या बंद किया गया है। अनुकूलन को चालू करने के बाद, यह सत्यापित करना आवश्यक है कि बदलाव वास्तव में उस तालिका के लिए queries को धीमा नहीं कर रहा है। यदि आपने Grafana को Postgres की निगरानी के लिए कॉन्फ़िगर किया है, तो धीमी queries pg_stat_activity में बड़ी संख्या में दिखाई देंगी, जो कई सेकंड ले रही हैं। ऐसे में, अनुकूलन को फिर से बंद करने की आवश्यकता होती है।

Uniswap जैसी Subgraphs के लिए, pair और token टेबल इस ऑप्टिमाइज़ेशन के लिए प्रमुख उम्मीदवार हैं, और डेटाबेस लोड पर इसका नाटकीय प्रभाव पड़ सकता है।

सबग्राफ हटाना

At some point, एक Indexer किसी दिए गए Subgraph को हटाना चाह सकता है। यह आसानी से graphman drop के माध्यम से किया जा सकता है, जो एक deployment और उसके सभी indexed डेटा को हटा देता है। Deployment को या तो सबग्राफ नाम, एक IPFS हैश Qm.., या डेटाबेस namespace sgdNNN के रूप में निर्दिष्ट किया जा सकता है। आगे का दस्तावेज़ यहाँ⁠ उपलब्ध है।