@solana arşiv yöntemlerimiz piyasadaki diğer her şeyden 20 kat daha hızlı. Tüm yığını açık kaynak olarak kullandık. Bunu yer imlerine ekleyin 🔖 Solana'daki arşiv sorguları ünlü şekilde yavaş ve güvenilmezdir: eksik bloklar, gecikmeli yanıtlar, düşen veriler. İşte nasıl düzelttiğimiz 🧵

Standart Solana arşiv yığını (Bigtable + validator RPC düğümleri) dağıtması kolaydır ancak ölçeklendirmesi zordur. CPU yoğun, bellek tüketiyor ve büyük toplu isteklerle zorlanıyor. Gecikmenin en çok vurduğu yer tarihsel verilerdir.

Bigtable'ı optimize etmeye çalıştık. Özel masalar ekledim, sorguları ayarladım, mümkün olduğunca ileri gitti. Ama her değişiklik tam düğüm yeniden başlatmayı gerektiriyordu. Her seferinde 30 dakika ile birkaç saat arasında. Bu yüzden onu iptal ettik ve her şeyi yeniden inşa ettik: alım, depolama ve RPC sunucusu.

Yeni yığın: → ArchivalRPC: saatlerde değil, saniyelerde döner. 200K RPS'ye ölçekleniyor. → Özel içici: maliyetleri ve arıza noktalarını azaltmak için seçici tüketim. → HBase Bigtable üzerinde: kendi kendine barındırılan, ortak konumda, neredeyse sıfır gecikme.

Veri yanlışsa hızın hiçbir anlamı yok. Üç kez doğrulanmış bir alım sistemi oluşturduk: her kayıt iki kez yazılır, programatik olarak doğrulanır ve sürekli taranır. Bir boşluk tespit edilirse, kendi kendini iyileştiren boru hatları otomatik olarak onu yeniden alır ve onarır.

Bölge bazında sonuç: • getTransaction için 100.000 RPS • getSignaturesForAddress için 50.000 RPS • getBlock için 2.000 RPS Piyasadaki diğer çözümlerden 20 katına kadar hızlı.