Graph Düğümü İşletme

Reading time: 13 min

Graph Düğümü, subgraphları indeksleyen ve sonuçta oluşan verileri GraphQL API aracılığıyla sorgulanabilir hale getiren bileşendir. Bu nedenle indeksleyici yığınının merkezi bir parçasıdır ve başarılı bir indeksleyici çalıştırmak için Graph Düğümü'nün doğru şekilde çalışması çok önemlidir.

Bu, Graph Düğümü hakkında bağlamsal bir genel bakış ve indeksleyiciler için mevcut olan daha gelişmiş seçenekler hakkında bilgi sağlar. Ayrıntılı belgeler ve talimatlar Graph Düğümü Github deposunda bulunabilir.

Graph Düğümü,Subgraph'ları Graph Ağı üzerinde endeksleme, blok zinciri istemcilerine bağlanma ve indekslenen verileri sorgulanabilir hale getirimek için referans uygulamasıdır.

Graph Düğümü(ve tüm endeksleyici yığını), bare metal veya bir bulut ortamında çalıştırılabilir. Bu merkezi indeksleme bileşeninin esnekliği, Graph Protokolü'nün dayanıklılığı için önemlidir. Benzer şekilde, Graph Düğümü kaynaktan oluşturulabilir veya indeksleyiciler sağlanan Docker Görüntülerinden birini kullanabilir.

Graph Düğümü'nün ana deposu, burada subgraph verileri yanı sıra subgraphlarla ilgili üst veriler ve blok önbelleği ve eth_call önbelleği gibi subgraphtan bağımsız ağ verileri saklanır.

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.

Subgraph dağıtım üst verilerini IPFS ağında depolanır. Graph düğümü, subgraph manifestini ve tüm bağlantılı dosyaları almak için subgraph dağıtımı sırasında öncelikle IPFS düğümüne erişir. Ağ indeksleyicilerinin kendi IPFS düğümlerini barındırmaları gerekmez. Ağ için bir IPFS düğümü https://ipfs.network.thegraph.com adresinde barındırılmaktadır.

İzleme ve raporlama etkinleştirmek için Graph Düğümü, metrikleri bir Prometheus metrik sunucusuna opsiyonel olarak kaydedebilir.

• Rust

• PostgreSQL

• IPFS

• Ubuntu kullanıcıları için Ek Gereksinimler - Ubuntu üzerinde bir Graph Düğümü çalıştırmak için birkaç ek paket gerekebilir.

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

1. Bir PostgreSQL veritabanı sunucusu başlatma

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

2. Graph Düğümü github deposunu klonlayın ve cargo build çalıştırarak kaynağı derleyin

3. Artık tüm bağımlılıklar ayarlandığına göre Graph Düğümü'nü başlatın:

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

Tam Kubernetes örnek yapılandırması indeksleyici Github deposunda bulunabilir.

Graph Düğümü çalışırken aşağıdaki portları açar:

En basit haliyle, Graph Düğümü tek bir Graph Düğüm örneği, bir PostgreSQL veritabanı, bir IPFS düğümü ve indekslenecek subgraphlar tarafından gerektirilen ağ istemcileri ile çalıştırılabilir.

Bu yapı birden fazla Graph Düğümü ekleyerek ve bu Graph Düğümlerini desteklemek için birden fazla veritabanı ekleyerek yatay olarak ölçeklenebilir. Gelişmiş kullanıcılar, config.toml dosyası ve Graph Düğümü ortam değişkenleri aracılığıyla bazı yatay ölçekleme yeteneklerinden ve daha gelişmiş yapılandırma seçeneklerinden faydalanmak isteyebilirler.

TOML yapılandırma dosyası, CLI'de sunulanlardan daha karmaşık yapılandırmaları ayarlamak için kullanılabilir. Dosyanın konumu --config komut satırı anahtar kelimesiyle iletilir.

Asgari bir config.toml dosyası sağlanabilir. Aşağıdaki dosya, --postgres-url komut satırı seçeneği kullanmakla eşdeğerdir:

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

config.toml'nin tam dökümantasyonu, Graph Düğümü belgelerinde bulunabilir.

Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different node_id on startup (e.g. in the Docker Compose file), which can then be used in the config.toml file to specify dedicated query nodes, block ingestors, and splitting subgraphs across nodes with deployment rules.

Birden fazla Graph Düğümü verildiğinde, aynı subgraph'ın çarpışmalara yol açacak şekilde iki farklı düğüm tarafından indekslenmesinin önüne geçmek için yeni subgraphlar'ın dağıtımını yönetmek gereklidir. Bu, veritabanı sharding kullanılıyorsa bir subgraph'ın verilerinin hangi shard'da saklanması gerektiğini de belirtebilen dağıtım kurallarını kullanılarak yapılabilir. Dağıtım kuralları, karar vermek için subgraph adı ve dağıtımın indekslediği ağ ile eşleşebilir.

Örnek dağıtım kuralı yapılandırması:

[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"
  ]

Dağıtım kuralları hakkında daha fazlasını buradan okuyun.

Düğümler, yapılandırma dosyasına aşağıdakini dahil ederek açıkça sorgu düğümleri olarak yapılandırılabilir:

[general]
query = "<regular expression>"

--node-id'si düzenli ifade ile eşleşen herhangi bir düğüm, sadece sorgulara yanıt vermek üzere ayarlanacaktır.

Çoğu kullanım durumu için, tek bir Postgres veritabanı bir graph-düğümü örneğini desteklemek için yeterlidir. Bir graph-düğümü örneği tek bir Postgres veritabanından daha büyük hale geldiğinde, bu graph düğümü verilerinin depolanmasını birden fazla Postgres veritabanına yaymak mümkündür. Tüm veritabanları birlikte, graph-düğümü örneğinin deposunu oluşturur. Her tekil veritabanına bir shard denir.

Shard'lar, subgraph dağıtımlarını birden çok veritabanına bölmek için kullanılabilir ve sorgu yükünü veritabanları arasında yaymak için replikaların kullanılmasına da izin verilebilir. Bu, her graph-düğümü'nün her veritabanı için bağlantı havuzunda ne kadar mevcut veritabanı bağlantısı olduğunu yapılandırmayı içerir ve daha fazla subgraph'ın indekslendiği durumlarda önem kazanır.

Sharding, Graph Düğümü'nün üzerine koyduğu yükü mevcut veritabanınıza koyamadığınızda ve veritabanı boyutunu artıramayacağınızda faydalı hale gelir.

Bağlantı yapılandırması açısından postgresql.conf'da max_connections değerinin 400 (veya belki de 200) olarak ayarlanması ve store_connection_wait_time_ms ve store_connection_checkout_count Prometheus metriklerine bakılması önerilir. Belirgin bekleme süreleri (5 milisaniye'nin üzerinde herhangi bir değer) yetersiz bağlantıların mevcut olduğunun bir işaretidir; yüksek bekleme süreleri veritabanının çok yoğun olması gibi sebeplerden de kaynaklanabilir. Ancak, veritabanı genel olarak stabil görünüyorsa, yüksek bekleme süreleri bağlantı sayısını arttırma ihtiyacını belirtir. Yapılandırmada her graph-düğümü örneğinin ne kadar bağlantı kullanabileceği bir üst sınırdır ve Graph Düğümü bunları gereksiz bulmadığı sürece açık tutmaz.

Depolama yapılandırması hakkında daha fazla bilgi için burayı okuyabilirsiniz.

Birden fazla düğüm yapılandırılmışsa yeni blokları işleme sorumluluğu olan bir düğüm belirtmek gerekecektir, böylece yapılandırılmış tüm dizin düğümleri zincir başını sorgulamaz. Bu, zincir (chains) ad alanının bir parçası olarak yapılır ve blok yüklemek için kullanılacak düğüm kimliği(node_id) belirtilir:

[chains]
ingestor = "block_ingestor_node"

Graph Protokolü, indeksleme ödülleri için desteklenen ağların sayısını arttırıyor ve bir indekleyicinin işlemek isteyebileceği desteklenmeyen ağları indeksleyen birçok subgraph mevcut. cconfig.toml dosyası şunlar gibi anlamlı ve esnek yapılandırmaları destekler:

• Birden fazla ağ
• Ağ başına birden fazla sağlayıcı (bu, yükü sağlayıcılar arasında bölme ve bir Graph Düğümü'nün deneyimsel Firehose desteği gibi daha ucuz sağlayıcıları tercih etmesi ile tam düğümlerin yanı sıra arşiv düğümlerinin yapılandırılmasına da izin verebilir).
• Özellikler, kimlik doğrulama ve sağlayıcı türü gibi ek sağlayıcı detayları (deneysel Firehose desteği için)

[chains] bölümü, graph-düğümü'nün bağlandığı ethereum sağlayıcılarını ve her zincir için blokların ve diğer üst verilerin nerede depolandığını kontrol eder. Aşağıdaki örnek, mainnet için blokların vip shard'da depolandığı ve kovan için blokların primary shard'da depolandığı olmak üzere iki zinciri, mainnet ve kovan'ı yapılandırır. Mainnet zinciri iki farklı sağlayıcı kullanabilirken, kovan yalnızca bir sağlayıcıya sahiptir.

[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 = [] } ]

Sağlayıcı yapılandırması hakkında daha fazla bilgi için burayı okuyabilirsiniz.

Graph Düğümü, özellikleri etkinleştirebilen veya Graph Düğümü davranışını değiştirebilen bir dizi çevre değişkeni destekler. Bunlar burada belgelenmiştir.

Gelişmiş yapılandırmaya sahip ölçeklendirilmiş bir dizinleme kurulumu işleten kullanıcılar, Graph Düğümler'ini Kubernetes ile yönetmekten faydalanabilirler.

• İndeksleyici github deposunda bir Kubernetes referansı örneği bulunmaktadır
• Launchpad, GraphOps tarafından yönetilen Kubernetes üzerinde Graph Protokol indeksleyicisi çalıştırmak için kullanılan bir araç setidir. Graph Düğümü dağıtımını yönetmek için bir dizi Helm şeması ve bir CLI sağlar.

Çalışan bir Graph Düğümüne (veya Graph Düğümlerine) sahip olunduktan sonra, dağıtılan subgraplar'ın bu düğümler üzerinde yönetilmesi zorluğu ortaya çıkar. Subgraphlar'ı yönetmeye yardımcı olmak için Graph Düğümü, bir dizi araç sunar.

Graph Düğümü'nün kayıtları, Graph Düğümü ve belirli subgraphlar'ın hata ayıklanması ve optimizasyonu için faydalı bilgiler sağlayabilir. Graph Düğümü, GRAPH_LOG ortam değişkeni aracılığıyla farklı kayıt seviyelerini destekler ve şu seviyeleri içerir: error, warn, info, debug veya trace.

Ek olarak, GRAPH_LOG_QUERY_TIMING gql olarak ayarlanması GraphQL sorgularının nasıl çalıştığı hakkında daha fazla ayrıntı sağlar (ancak bu, büyük bir kayıt hacmi oluşturacaktır).

Graph Düğümü, varsayılan olarak 8040 port'undaki Prometheus uç noktası aracılığıyla metrikleri sağlar. Ardından Grafana, bu metrikleri görselleştirmek için kullanılabilir.

İndeksleyici github deposu Grafana yapılandırmasına bir örnek sağlar.

graphman, Graph Düğümü'nün bakım aracıdır ve farklı günlük görevlerinin teşhis ve çözümüne yardımcı olur.

Graphman komutu, resmi konteynerlara dahil edilmiştir ve graph-düğümü konteynerınıza docker exec ile girerek çalıştırabilirsiniz. Bu bir config.toml dosyasına ihtiyaç duyar.

graphman komutlarının tam belgeleri Graph Düğümü github deposunda mevcuttur. Graph Düğümü /docs'da bulunan [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) bağlantısına bakın

Varsayılan olarak 8030/graphql port'unda mevcut olan indeksleme durumu API'si, farklı subgraphlar için indeksleme durumunu ve ispatlarını kontrol etmek, subgraph özelliklerini incelemek ve daha fazlasını yapmak için çeşitli yöntemler sunar.

Tam şema burada mevcut.

İndeksleme sürecinin üç ayrı parçası bulunmaktadır:

• Sağlayıcıdan ilgili olayları getirme
• Uygun işleyicilerle sırayla olayları işleme (bu, durumu sormak için zincire çağrı yapmayı ve depodan veri getirmeyi içerebilir)
• Elde edilen verileri depoya yazma

Bu aşamalar boru hattında (yani eşzamanlı olarak yürütülebilir), ancak birbirlerine bağımlıdırlar. Subgraphlar'ın indekslenmesi yavaş olduğunda, bunun altındaki neden spesifik subgraphlar'a bağlı olacaktır.

İndeksleme yavaşlığının yaygın nedenleri:

• Zincirdeki ilgili olayları bulmak için geçen süre (özellikle çağrı yönlendiricileri, trace_filter'a bağımlı oldukları için yavaş olabilir)
• İşleyicilerin bir parçası olarak çok fazla eth_calls yapmak
• Yürütme sırasında büyük miktarda depolama etkileşimi
• Depoya kaydedilecek büyük miktarda veri
• İşlenecek büyük miktarda olay
• Kalabalık düğümler için yavaş veritabanı bağlantı süresi
• Sağlayıcının zincir başından geriye düşmesi
• Sağlayıcıdan zincir başındaki yeni makbuzların alınmasındaki yavaşlık

Subgraph indeksleme metrikleri, indeksleme yavaşlığının temel nedenini teşhis etmede yardımcı olabilir. Bazı durumlarda, sorun subgraph'ın kendisiyle ilgilidir, ancak diğer durumlarda, geliştirilmiş ağ sağlayıcıları, azaltılmış veritabanı çekişmesi ve diğer yapılandırma iyileştirmeleri indeksleme performansını belirgin şekilde artırabilir.

İndekslemesi sırasında subgraphlar beklenmedik veri, beklendiği gibi çalışmayan bir bileşen veya olay işleyicilerinde veya yapılandırmada bir hata olması durumunda başarısız olabilir. İki genel başarısızlık türü mevcuttur:

• Deterministik başarısızlıklar: Bu, yeniden denemelerle çözülmeyecek hatalardır
• Deterministik olmayan başarısızlıklar: Bunlar, sağlayıcının sorunları veya beklenmedik bir Graph Düğüm hatası gibi nedenlere bağlı olabilir. Deterministik olmayan bir başarısızlık meydana geldiğinde Graph Düğümü, başarısız olan işleyicileri yeniden deneyecek ve zamanla geri çekilecektir.

Bazı durumlarda, başarısızlık indeksleyici tarafından çözülebilir (örneğin, hatanın doğru türde sağlayıcıya sahip olmamasından kaynaklanması durumunda, gerekli sağlayıcı eklenirse indeksleme devam ettirilebilir). Ancak diğer durumlarda, subgraph kodunda bir değişiklik gereklidir.

Graph Düğümü, sağlayıcıdan tekrar alma işlemini kaydetmek için depoda belirli verileri önbelleğe alır. Bloklar ve eth_calls sonuçları önbelleğe alınır (bu sonuncusu belirli bir bloktan itibaren önbelleğe alınır). Bu önbellekleme, azca değiştirilmiş bir subgraph'ın "yeniden senkronizasyonu" sırasında indeksleme hızını büyük ölçüde artırabilir.

Ancak bazı örneklerde, Ethereum düğümü bir süre boyunca yanlış veri sağlamışsa, bu önbelleğe girebilir ve yanlış verilere veya subgraphlar'ın başarısız olmasına neden olabilir. Bu durumda, indeksleyiciler zehirlenmiş önbelleği temizlemek için graphman kullanabilir ve etkilenen subgraphlar'ı geri sarabilir, böylece (umarız) sağlıklı sağlayıcıdan temiz verileri alabilirler.

Örneğin tx makbuzu etkinlik eksikliği gibi bir blok önbellek tutarsızlığı şüphesi varsa:

1. zincir ismini bulmak için graphman chain list.
2. graphman chain check-blocks <CHAIN> by-number <NUMBER>, önbelleğe alınan bloğun sağlayıcıyla eşleşip eşleşmediğini kontrol edecek ve eşleşmiyorsa bloğu önbellekten silecek.
   1. Bir fark varsa, tüm önbelleği graphman chain truncate <CHAIN> ile kesmek daha güvenli olabilir.
   2. Blok sağlayıcıyla eşleşirse, sorun doğrudan sağlayıcıya karşı hata ayıklanabilir.

Bir subgraph indekslendikten sonra, indeksleyiciler subgraph'ın ayrılmış sorgu son noktası aracılığıyla sorguları sunmayı bekleyebilirler. İndeksleyiciler önemli sorgu hacmi sunmayı umuyorlarsa, bunun için ayrılmış bir sorgu düğümü önerilir ve çok yüksek sorgu hacimleri durumunda indeksleyiciler sorguların indeksleme sürecini etkilememesi için replika shardlar yapılandırmak isteyebilirler.

Bununla birlikte, özel bir sorgu düğümü ve replikalarda bile, belirli sorguların yürütülmesi uzun zaman alabilir, bazı durumlarda bellek kullanımını artırabilir ve diğer kullanıcılar için sorgu süresini olumsuz etkileyebilir.

Tek bir "sihirli çözüm" yoktur, ancak yavaş sorguların önlenmesi, teşhisi ve işlenmesi için bir dizi araç bulunmaktadır.

Graph Düğümü, varsayılan olarak GraphQL sorgularını önbelleğe alarak veritabanı yükünü önemli ölçüde azaltabilir. Bu, GRAPH_QUERY_CACHE_BLOCKS ve GRAPH_QUERY_CACHE_MAX_MEM ayarları ile daha da yapılandırılabilir - buradan daha fazla bilgi edinin.

Sorunlu sorgular genellikle iki şekilde ortaya çıkar. Bazı durumlarda, kullanıcılar kendileri belirli bir sorgunun yavaş olduğunu bildirirler. Bu durumda zorluk, yavaşlığın nedenini teşhis etmektir - genel bir sorun mu, yoksa subgraph'a veya sorguya özgü mü olduğunu belirlemek ve tabii ki mümkünse sonra çözmek olacaktır.

Diğer durumlarda, tetikleyici sorgu düğümündee yüksek bellek kullanımı olabilir, bu durumda zorluk ilk olarak soruna neden olan sorguyu belirlemektir.

İndeksleyiciler qlog kullanarak Graph Düğümü'nün sorgu kayıtlarını işleyebilir ve özetleyebilir. Ayrıca GRAPH_LOG_QUERY_TIMING yavaş sorguların tanımlamak ve ayıklamak için etkinleştirilebilir.

Yavaş bir sorgu verildiğinde, indeksleyicilerin birkaç seçeneği vardır. Tabii ki, sorunlu sorgunun gönderilme maliyetini önemli ölçüde artırmak için maliyet modelini değiştirebilirler. Bu, o sorgunun sıklığında azalmaya neden olabilir. Ancak, genellikle sorunun temek nedenini çözmez.

Varlıkları depolayan veritabanı tablolarının genellikle iki çeşit olduğu görünmektedir: oluşturulduktan sonra hiçbir zaman güncellenmeyen mesela finansal işlemler listesine benzer şeyler saklayan olan 'işlemimsi' ve varlıkların çok sık güncellendiği, mesela her işlem kaydedildiğinde değiştirilen finansal hesaplar gibi şeyler saklayan 'hesabımsı'. Hesabımsı tablolar, birçok varlık sürümünü içermelerine rağmen, nispeten az sayıda farklı varlığa sahip olmasıyla bilinir. Çoğu durumda, böyle bir tabloda farklı varlık sayısı, toplam satır (varlık sürümleri) sayısının %1'ine eşittir

Hesabımsı tablolar için, graph-node, Postgres'in verileri nasıl bu kadar yüksek bir değişim oranıyla depolamaya başladığına dair ayrıntılardan yararlanan sorgular oluşturabilir, yani böyle bir tablo için son blokların tüm sürümleri genel depolamanın küçük bir alt bölümünde yer alır.

graphman stats show <sgdNNNN> komutu, bir dağıtımdaki her varlık türü/tablosu için kaç farklı varlık ve her tablonun kaç varlık sürümü içerdiğini gösterir. Bu veriler Postgres dahili tahminlerine dayanır ve bu nedenle doğruluğu kesin olmayabilir ve bir büyüklük sırasına nazaran yanıltıcı olabilir. entities sütununda -1, Postgres'un tüm satırların farklı bir varlık içerdiğine inandığını gösterir.

Genel olarak, farklı varlıkların sayısı toplam satır/varlık sürümü sayısının %1'inden az olan tablolar, hesap-tablo optimizasyonu için iyi adaylardır. graphman stats show çıktısı, bir tablonun bu optimizasyondan faydalanabileceğini gösteriyorsa, graphman stats show <sgdNNN> <table>'ı çalıştırmak, tablonun tam sayımını gerçekleştirir. - bu yavaş olabilir, ancak farklı varlıkların toplam varlık sürümlerine oranı kesin bir ölçüdür.

Bir tablonun hesabımsı olduğu belirlendikten sonra graphman stats account-like <sgdNNN>.<table>'ı çalıştırmak, bu tabloya karşı sorgular için hesabımsı optimizasyonu etkinleştirecektir. Optimizasyon, graphman stats account-like --clear <sgdNNN>.<table> ile tekrar kapatılabilir. Optimizasyonun etkinleştirildiğinin veya kapatıldığının sorgu düğümleri tarafından fark edilmesi için en fazla 5 dakika beklemek gereklidir. Optimizasyonu açtıktan sonra, değişikliğin söz konusu tablo için sorguları daha yavaş hale getirmediğinden emin olmak için doğrulama yapılması gerekir. Postgres'i izlemek için Grafana'yı yapılandırdıysanız, yavaş sorgular pg_stat_activity bölümünde büyük sayılarda ve birkaç saniye süren işlemler şeklinde görünecektir. Bu durumda, optimizasyon tekrar kapatılmalıdır.

Uniswapımsı subgraplar için, çift (pair) ve token tabloları bu optimizasyon için en uygun adaylardır ve veritabanı yükü üzerinde etkili bir etkiye sahip olabilirler.

Bir noktada indeksleyici, belirli bir subgraph'ı kaldırmak isteyebilir. Bu, tüm indekslenmiş verileri ve bir dağıtımı silen graphman drop komutuyla kolayca gerçekleştirilebilir. Dağıtım, subgraph adı, bir IPFS hash Qm.. veya veritabanı ad alanı sgdNNN olarak belirtilebilir. Daha fazla belgeye buradan erişilebilir.