Apache Fory Rust – JSON/Protobuf'tan 10–20 kat daha hızlı bir serileştirme çerçevesi

• Apache Fory Rust, ultra yüksek hızlı serileştirme performansı ve otomatik referans yönetimi sunan çapraz dilli bir serileştirme çerçevesidir
• Rust'ın zero-copy teknolojisi ve tip güvenliği temeli üzerinde, döngüsel referanslar·trait nesneleri·şema evrimini otomatik olarak işler
• IDL dosyaları veya kod üretimi olmadan Rust, Python, Java, Go gibi çeşitli diller arasında veri alışverişini destekler
• Benchmark sonuçlarına göre JSON ve Protobuf'a kıyasla 10–20 kat veya daha yüksek işlem hızı sunar
• Mikroservisler·veri boru hatları·gerçek zamanlı sistemler gibi yüksek performanslı ortamlarda kullanım değeri yüksektir

---

Serileştirmenin ikilemi ve Apache Fory Rust'ın ortaya çıkışı

• Mevcut serileştirme yaklaşımlarında hız·esneklik·dil uyumluluğu üçlüsünden birinden vazgeçme sınırı vardı
  • El yapımı ikili formatlar hızlıdır ama şema değişikliklerine karşı kırılgandır
  • JSON/Protobuf esnektir ama 10 katı aşan performans ek yükü getirir
  • Mevcut çözümler, dillere özgü özellikleri desteklemekte yetersiz kalır
• Apache Fory Rust, performans ve esnekliği aynı anda sağlar ve IDL·manuel şema yönetimi gerektirmez

Başlıca özellikler

• 1. Gerçek çapraz dil desteği

  • Aynı ikili protokol Java, Python, C++, Go ve diğer diller arasında paylaşılır
  • Rust'ta serileştirilen veri Python'da doğrudan deserialize edilebilir
  • Şema dosyası·kod üretimi·sürüm uyumsuzluğu sorunu yoktur; çok dilli mikroservisler arasında veri alışverişini basitleştirir

• 2. Otomatik döngüsel ve paylaşımlı referans işleme

  • Çoğu çerçevenin başaramadığı döngüsel referans yapılarını otomatik olarak izler ve korur
  • Aynı nesneye birden fazla kez referans verilse bile yalnızca bir kez serileştirir ve referans kimliğini korur
  • Graf veritabanları·ORM·karmaşık alan modelleri için uygundur

• 3. Trait nesnesi serileştirme

  • Rust'ın Box gibi trait nesnesi serileştirmesini destekler
  • register_trait_type! makrosuyla polimorfik tipler kaydedilebilir
  • Box, Rc, Arc, dyn Any gibi çeşitli biçimleri destekler
  • Eklenti sistemleri·heterojen koleksiyonlar·genişletilebilir mimariler kurulabilir

• 4. Şema evrimi (uyumluluk modu)

  • Compatible modu ile servis sürümleri arasında şema değişikliklerine izin verir
    • Alan ekleme·silme·sıra değiştirme·opsiyonel tip dönüşümü mümkündür
    • Tip değişikliği mümkün değildir
  • Kesintisiz dağıtım ve bağımsız mikroservis evrimi için faydalıdır

Teknik temel

• Protokol tasarımı

  • Yapı: | fory header | reference meta | type meta | value data |
  • Değişken uzunluklu tamsayılar·sıkıştırılmış metadata·referans takibi·little-endian düzeni kullanılır
  • Paylaşılan nesnelerde tekrarın giderilmesi ve tip metadata sıkıştırması ile performans artırılır

• Derleme zamanında kod üretimi

  • Reflection yerine makro tabanlı kod üretimi ile çalışma zamanı ek yükü kaldırılır
  • #[derive(ForyObject)] makrosu serileştirme·deserialize fonksiyonlarını otomatik üretir
  • Tip güvenliği sağlar, ikili boyutu en aza indirir, IDE otomatik tamamlama desteği sunar

• Mimari yapı

  • fory/: yüksek seviye API
  • fory-core/: serileştirme motoru (buffer I/O, tip kaydı, metadata sıkıştırma vb.)
  • fory-derive/: prosedürel makro tanımları
  • Modüler yapı ile bakım kolaylığı ve genişletilebilirlik sağlanır

Benchmark sonuçları

• JSON ve Protobuf'a kıyasla 10–20 kat veya daha hızlı işlem performansı
• Örnekler:
  • simple_struct(small) → Fory 35,729,598 TPS / JSON 10,167,045 / Protobuf 8,633,342
  • person(medium) → Fory 3,839,656 TPS / JSON 337,610 / Protobuf 369,031
• Tüm test senaryolarında Fory en yüksek performansı kaydetti

Kullanım senaryoları

• Uygun kullanım alanları

  • Çok dilli mikroservisler: şema dosyası olmadan veri alışverişi
  • Yüksek performanslı veri boru hatları: saniyede milyonlarca kayıt işleme
  • Karmaşık alan modelleri: döngüsel referans ve polimorfik yapı desteği
  • Gerçek zamanlı sistemler: 1 ms altı gecikme, zero-copy deserialize

• Alternatiflerin değerlendirilmesi

  • İnsan tarafından okunabilir format gerekirse → JSON/YAML
  • Uzun süreli saklama formatı gerekirse → Parquet
  • Basit veri yapıları → serde + bincode

Başlangıç

• Kurulum

  • Cargo.toml içine ekleyin:

    [dependencies]  
    fory = "0.13"  
    

• Temel serileştirme örneği

  • Yapıyı #[derive(ForyObject)] ile kaydettikten sonra serialize() / deserialize() kullanın
  • Tip ID kaydı ile veri tutarlılığı korunur

• Çapraz dil serileştirme

  • compatible(true).xlang(true) ayarıyla çok dilli uyumluluk modu etkinleştirilir
  • ID veya isim tabanlı kayıt (register_by_namespace, register_by_name) desteklenir

Desteklenen tipler

• Temel tipler: bool, tamsayılar, kayan noktalı sayılar, String
• Koleksiyonlar: Vec, HashMap, BTreeMap, HashSet, Option
• Akıllı işaretçiler: Box, Rc, Arc, RcWeak, ArcWeak, RefCell, Mutex
• Tarih/saat: chrono tipleri
• Kullanıcı tanımlı nesneler: ForyObject, ForyRow
• Trait nesneleri: Box/Rc/Arc, Rc/Arc

Yol haritası

• v0.13 ile sunulanlar

  • Statik kod üretimi, zero-copy Row formatı, döngüsel referans takibi, trait nesnesi serileştirme, şema uyumluluk modu

• Planlanan özellikler

  • Çapraz dil referans serileştirmesi, kısmi Row güncellemesi

Prodüksiyon değerlendirmeleri

• Thread safety: kayıt tamamlandıktan sonra Arc ile paylaşılabilir (Send + Sync)
• Hata işleme: Result tabanlıdır; tip uyumsuzluğu, yetersiz buffer gibi hatalar açıkça ayrıştırılır

Dokümantasyon ve topluluk

• Resmî dokümantasyon: fory.apache.org/docs
• API dokümantasyonu: docs.rs/fory
• Topluluk: GitHub, Slack, Issue Tracker
• Apache License 2.0 tabanlı açık kaynak

Sonuç

• Apache Fory Rust, performans·esneklik·dil uyumluluğu arasındaki ödünleşimi ortadan kaldıran yeni nesil bir serileştirme çerçevesidir
• Makro tabanlı otomasyon, trait nesnesi desteği ve döngüsel referans işleme ile geliştirme verimliliğini en üst düzeye çıkarır
• Mikroservisler·veri boru hatları·gerçek zamanlı sistemlerde hemen kullanılabilir

[qlghwp123]

Bu performans mantıklı mı?

[GN⁺]

Hacker News yorumları

• Yeni bir format oluşturmaktansa W3C EXI (Binary XML) gibi mevcut teknolojilerin araç ekosistemini iyileştirmeye odaklanılsaydı daha iyi olurdu
  Sadece hızlı olması yetmez; Aeron/SBE gibi etrafında ekosistem olmayan formatların yayılması zordur. XML ise bu ekosisteme zaten sahip

  • Binary XML kodlaması bazı durumlarda faydalıdır, ancak modern ikili serileştirme formatları kadar verimli değildir
    Ayrıca paylaşılan referanslar veya döngüsel referanslar gibi karmaşık nesne grafiklerini doğal biçimde ifade edemez
    Fory formatı, bu sorunları çözerken aynı zamanda diller arası uyumluluk ve şema evrimini desteklemek üzere en baştan tasarlanmıştır
  • W3C EXI ile ASN.1 BER arasında hangisinin daha iyi olduğunu bilmiyorum, ancak DOP (veri odaklı tasarım) yaklaşımının doğru olduğunu düşünüyorum
    Yani önce kodlamayı tasarlayıp sonra bunu dillere ya da istemcilere doğru geriye genişletmek daha sağlıklı bir yaklaşım

• Benchmark'ın adil olup olmadığından şüpheliyim
  Kod bağlantısına bakınca, Fory yapısı olmayan durumlarda serileştirme sürecine to/from dönüşümü de dahil edilmiş
  Bu dönüşüm sırasında string kopyalama veya dizi yeniden tahsisi meydana geliyor
  Gerçek sistemlerde tonic 8KB buffer sağladığı için, bu yaklaşım basit bir Vec::default() kullanımından daha verimli olacaktır

  • Bu benchmark adil değil
    Xeon Gold 6136 CPU üzerinde 10 kat iyileşme varmış gibi görünüyor, ancak to/from dönüşümü ve Vec kopyalaması kaldırılıp 8KB buffer önceden ayrıldığında gerçekte yaklaşık 3 kat seviyesinde kalıyor
    Benchmark, Fory'ye özgü hiçbir kod içermeyen bir tower service/codec tarzında yeniden yazılmalı
    Fory test sırasında writer pool kullanıyor
    İlgili kod burada

• Uzun vadede diller arası uyumluluğu korumak için IDL tabanlı, açıkça tanımlanmış bir sözleşme gerektiğini düşünüyorum
  Dilden serileştirmeye doğru başlayan yaklaşım ilk başta rahat olabilir, ama zamanla dil çalışma zamanındaki değişikliklere karşı kırılgan hale gelir

  • Dil sayısı arttıkça resmî şema daha da önemli hale geliyor
    Tek dilli projeler IDL olmadan da basit kalabilir, ancak üç veya daha fazla dil olduğunda IDL tek doğru kaynak işlevi görür
    Apache Fory isteğe bağlı olarak IDL desteği eklemeyi planlıyor; böylece ekipler durumlarına göre dil öncelikli veya şema öncelikli yaklaşımı seçebilecek

• Şema olmadan diller arası paylaşılan tiplerin nasıl korunduğunu merak ediyorum

  • Bir tip eşleme tablosu mevcut
    Tipli dillerde sınıf tanımlarından şema çıkarılıyor, tipsiz dillerde ise doğrudan koda notlar ekleniyor
    Python örneği burada görülebilir
  • Çok dilli (polyglot) ekipleri başlıca kullanım senaryosu olarak öne çıkarırken şema dosyası gerekmiyor denmesi kafa karıştırıcı
    İlgili blog yazısı burada
  • Bu yaklaşımın uzun vadede ne kadar iyi işleyeceği konusunda şüpheliyim
  • Gerçek üretim ortamlarında ne kadar kullanıldığına dair açıklama yetersiz olduğu için güven vermiyor

• CapnProto veya Flatbuffers gibi serileştirmesiz formatlar yerine neden Fory kullanılmalı, merak ediyorum
  Sıkıştırma gerekiyorsa zstd kullanılabilir
  Yine de Fory'nin geniş dil desteği ve kullanım kolaylığı etkileyici
  Python tarafında ise hâlâ dill tercih ediyorum — çünkü kod nesnelerini bile serileştirebiliyor
  dill bağlantısı

  • dill ile karşılaştırılan benchmark sonuçlarında Fory'nin 20–40 kat daha hızlı olduğu ve 7 kata kadar daha yüksek sıkıştırma oranı sunduğu görülüyor
    Benchmark kodu burada
  • Apache Fory, pickle/cloudpickle için bir alternatif olarak da kullanılabiliyor ve yerel fonksiyonlar ya da sınıflar gibi kod nesnelerinin serileştirilmesini destekliyor
    Örnek bağlantı
    pyfory, cloudpickle'a kıyasla 3 kat daha yüksek sıkıştırma oranı gösteriyor ve güvenlik denetimi özelliği ile kötü amaçlı deserialize saldırılarını engelliyor

• Benchmark bağlantısı 404 veriyordu ama çalışan bağlantıyı buldum

• İsmin “Fury”den “Fory”ye değiştirilmiş olması üzücü
  Fury, hızlı bir serileştirme çatısı için tam yerinde bir isimdi

  • “Fury” aslında benim koyduğum isimdi, bu yüzden ona ayrı bir bağlılığım vardı; ama mecburen değiştirilmesi gerekti

• Çoğu ikili protokol veri boyutunu küçültmeye çalışır
  Protobuf, tamsayı sıkıştırması için varint ve zigzag kullanır
  Sadece TPS karşılaştırılırsa, C struct'larını olduğu gibi gönderen “do nothing” yaklaşımı her zaman kazanacaktır

  • Fory de tamsayı sıkıştırmasını destekliyor ve Protobuf ile neredeyse aynı veri boyutuna ulaşıyor
    Farklı veri kümeleri için karşılaştırma tablosu sunulmuş
  • İki adet şema uyumluluğu modu var, ancak küçük sürümler arasında ikili uyumluluk garantisi bulunmuyor

• Fory'nin 4096 tip sınırının yeterli olup olmadığını merak ediyorum
  İlgili kod burada

  • Her durum için yeterli olmayabilir, ama gerekirse genişletilebilir
    Gerçekte 4096'dan fazla protokol mesajı tanımlanan bir örneğe neredeyse hiç rastlamadım

• Rust benchmark bağlantısı 404 hatası veriyor
  Doküman kökünde benchmark dizini bulunamıyor

  • Muhtemelen bu bağlantılar, Rust serileştirme rehberi ilgili içeriğe karşılık geliyor