Docs
⌘ K

4 dakika

Subgraph Örnek Uygulama 3 - Değişmez Varlıklar ve Byte'ları Kimlik Olarak Kullanarak Endeksleme ve Sorgu Performansını İyileştirin

Özet

schema.graphql dosyamızda Kimlikler için Değişmez Varlıklar ve Byte’lar kullanmak endeksleme hızını ve sorgu performansını önemli ölçüde arttırır.

Değişmez Varlıklar

Bir varlığı değişmez hale getirmek için, varlığa (immutable: true) ekleriz.

type Transfer @entity(immutable: true) {  id: Bytes!  from: Bytes!  to: Bytes!  value: BigInt!}

Transfer varlığını değişmez hale getirerek, graph-node’un varlığı daha verimli bir şekilde işlemesini sağlayabiliriz. Bu da endeksleme hızını ve sorgu yanıt verebilirliğini artırır.

Değişmez Varlıkların yapıları gelecekte değişmeyecektir. “Değişmez Varlık” haline getirilecek ideal bir varlık, doğrudan zincir üstü olay verilerini kaydeden bir varlık, (örneğin bir Transfer olayının Transfer varlığı olarak kaydedilmesi) gibi olabilir.

Detaylı İnceleme

Değişebilir varlıkların geçerliliklerini belirten bir ‘blok aralığı’ bulunur. Bu varlıkları güncellemek, Graph Düğümü’nün önceki versiyonların blok aralığını ayarlamasını gerektirir. Bu da veritabanı iş yükünü artırır. Sorguların da yalnızca canlı ögeleri bulmak için filtrelenmesi gerekir. Değişmez ögeler daha hızlıdır. Çünkü hepsi canlıdır ve değişmeyeceklerinden dolayı, yazma sırasında herhangi bir kontrol veya güncellemeye gerek yoktur. Ayrıca, sorgular sırasında herhangi bir filtrelemeye de gerek kalmaz.

Değişmez Varlıklar ne zaman kullanmamalı

Eğer zamanla değiştirilmesi gereken status gibi bir alanınız varsa, varlığı değişmez yapmamalısınız. Bunun dışında mümkünse değişmez varlıklar kullanmalısınız.

ID (Kimlik Numarası) Olarak Bytes

Her varlığın bir ID’si olmalıdır. Önceki örnekte, ID’nin zaten Bytes türünde olduğunu görebiliriz.

type Transfer @entity(immutable: true) {  id: Bytes!  from: Bytes!  to: Bytes!  value: BigInt!}

ID’ler için String ve Int8 gibi başka türler kullanmak mümkün olsa da, tüm ID’ler için Bytes türünün kullanılması önerilir. Çünkü karakter dizileri ikili (binary) verileri saklamak için Bayt dizilerinden iki kat fazla yer kaplar. Ayrıca, UTF-8 karakter dizilerinin karşılaştırmaları, yerel ayarı hesaba katması gerekliliğinden ötürü, Bayt dizilerinin karşılaştırmalarında kullanılan bayt temelli (bytewise) karşılaştırmalardan çok daha maliyetlidir.

ID Olarak Bytes Kullanmama Nedenleri

  1. Eğer varlık ID’leri otomatik artırılan sayısal ID’ler veya okunabilir dizeler gibi insan tarafından okunabilir olmalıysa, ID için Bytes kullanılmamalıdır.
  2. If integrating a Subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
  3. Endeksleme ve sorgulama gibi performans iyileştirmeleri istenmiyorsa.

ID Olarak Bytes’ı Başka Bir Özellikle Birleştirme

It is a common practice in many Subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using event.transaction.hash.toHex() + "-" + event.logIndex.toString(). However, as this returns a string, this significantly impedes Subgraph indexing and querying performance.

Bunun yerine, olay özelliklerini birleştirmek için concatI32() metodunu kullanmalıyız. Bu strateji, çok daha iyi çalışan bir Bytes ID ile sonuçlanır.

export function handleTransfer(event: TransferEvent): void {  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))  entity.from = event.params.from  entity.to = event.params.to  entity.value = event.params.value  entity.blockNumber = event.block.number  entity.blockTimestamp = event.block.timestamp  entity.transactionHash = event.transaction.hash  entity.save()}

Bytes’ı ID Olarak Kullanarak Sıralama

Bytes’ı ID olarak kullanarak sıralama yapmak, bu örnek sorgu ve yanıtında gördüğümüz gibi ideal değildir.

Sorgu:

{  transfers(first: 3, orderBy: id) {    id    from    to    value  }}

Sorgu yanıtı:

{  "data": {    "transfers": [      {        "id": "0x00010000",        "from": "0xabcd...",        "to": "0x1234...",        "value": "256"      },      {        "id": "0x00020000",        "from": "0xefgh...",        "to": "0x5678...",        "value": "512"      },      {        "id": "0x01000000",        "from": "0xijkl...",        "to": "0x9abc...",        "value": "1"      }    ]  }}

ID’ler onaltılık (hex) olarak döndürülür.

Sıralamayı geliştirmek için varlık üzerinde BigInt türünde başka bir alan oluşturmalıyız.

type Transfer @entity {  id: Bytes!  from: Bytes! # address  to: Bytes! # address  value: BigInt! # unit256  tokenId: BigInt! # uint256}

Bu alanı oluşturmak, sıralamanın ardışık olarak optimize edilmesine olanak tanıyacaktır.

Sorgu:

{  transfers(first: 3, orderBy: tokenId) {    id    tokenId  }}

Sorgu Yanıtı:

{  "data": {    "transfers": [      {        "id": "0x…",        "tokenId": "1"      },      {        "id": "0x…",        "tokenId": "2"      },      {        "id": "0x…",        "tokenId": "3"      }    ]  }}

Sonuç

Using both Immutable Entities and Bytes as IDs has been shown to markedly improve Subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.

Değişmez Varlıkları ve ID olarak Bytes kullanmak hakkında daha fazla bilgiyi Edge & Node’da Yazılım Mühendisi olan David Lutterkort’un bu blog yazısında bulabilirsiniz: İki Basit Subgraph Performans İyileştirmesi.

Subgraph Örnek Uygulamalar 1-6

  1. Improve Query Speed with Subgraph Pruning

  2. Improve Indexing and Query Responsiveness by Using @derivedFrom

  3. Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs

  4. Improve Indexing Speed by Avoiding eth_calls

  5. Simplify and Optimize with Timeseries and Aggregations

  6. Use Grafting for Quick Hotfix Deployment