Apache Thrift, Google Protokol Arabellekleri, MessagePack, ASN.1 ve Apache Avro arasındaki temel farklar nelerdir?


124

Bunların tümü ikili serileştirme, RPC çerçeveleri ve IDL sağlar. Bunlar ve özellikler arasındaki temel farklarla ilgileniyorum (performans, kullanım kolaylığı, programlama dilleri desteği).

Başka benzer teknolojiler biliyorsanız, lütfen bir cevapta belirtin.



@Zenikoder: Bu bağlantı, sorgulanan 5 formattan 2'si için herhangi bir bilgi içermiyor.
SADECE DOĞRU GÖRÜŞÜM


2
RPC'yi bilmeyenler için - Uzaktan Prodecure Çağrısı, IDL - Arayüz Tanımlama dili
garg10may

Yanıtlar:


97

ASN.1 , bir ISO / ISE standardıdır. Çok okunabilir bir kaynak dili ve hem ikili hem de insan tarafından okunabilen çeşitli arka uçları vardır. Uluslararası bir standart (ve bu konuda eski bir standart!) Olan kaynak dil, biraz mutfak havasıdır (Atlantik Okyanusu'nun biraz ıslak olmasıyla aynı şekilde), ancak son derece iyi belirlenmiş ve yeterli miktarda desteğe sahiptir. . (Yeterince kazarsanız ve FFI'larda kullanabileceğiniz iyi C dili kitaplıkları yoksa, adlandırdığınız herhangi bir dil için muhtemelen bir ASN.1 kitaplığı bulabilirsiniz.) Standartlaştırılmış bir dil olduğundan, saplantılı bir şekilde belgelendirilmiş ve birkaç iyi öğretici de mevcuttur.

Tasarruf bir standart değildir. Aslen Facebook'tandır ve daha sonra açık kaynaklı olmuştur ve şu anda üst düzey bir Apache projesidir. İyi belgelenmemiştir - özellikle öğretici seviyeler - ve (kuşkusuz kısaca) bakışım, diğer, önceki çabaların halihazırda yapmadığı (ve bazı durumlarda daha iyi) hiçbir şey eklemiyor gibi görünüyor. Adil olmak gerekirse, birkaç yüksek profilli ana akım olmayan diller de dahil olmak üzere kutudan çıkardığı oldukça etkileyici sayıda dile sahiptir. IDL ayrıca belli belirsiz bir şekilde C'ye benzer.

Protokol Tamponları bir standart değildir. Daha geniş topluluğa sunulan bir Google ürünüdür. Kutudan çıkar çıkmaz desteklenen diller açısından biraz sınırlıdır (yalnızca C ++, Python ve Java'yı destekler), ancak diğer diller için (oldukça değişken kalitede) çok sayıda üçüncü taraf desteğine sahiptir. Google hemen hemen tüm işlerini Protokol Tamponları kullanarak yapar, bu yüzden savaşta test edilmiş, savaşta sertleştirilmiş bir protokoldür (ASN.1 kadar sertleştirilmiş olmasa da. Thrift'ten çok daha iyi belgelere sahiptir, ancak Google ürünü, büyük olasılıkla kararsızdır (güvenilmez anlamında değil, sürekli değişme anlamında). IDL de C benzeri.

Yukarıdaki sistemlerin tümü, daha sonra kodlama ve kod çözmede kullanılan bir hedef dil için kod üretmek üzere bir tür IDL'de tanımlanan bir şema kullanır. Avro yapmaz. Avro'nun yazımı dinamiktir ve şema verileri çalışma zamanında doğrudan hem kodlamak hem de kod çözmek için kullanılır (bu, işlemede bazı bariz maliyetlere sahiptir, ancak dinamik diller açısından bazı bariz faydalar ve etiketleme türlerine ihtiyaç olmaması vb.) . Şeması, yeni bir dilde Avro'yu desteklemeyi, zaten bir JSON kitaplığı varsa yönetmeyi biraz daha kolaylaştıran JSON kullanır. Yine, çoğu tekerleği yeniden icat eden protokol tanımlama sistemlerinde olduğu gibi, Avro da standartlaştırılmamıştır.

Şahsen, onunla olan aşk / nefret ilişkime rağmen, muhtemelen ASN.1'i çoğu RPC ve mesaj iletimi için kullanırım, ancak gerçekten bir RPC yığını olmasa da (bir tane yapmanız gerekir, ancak IOC'ler bunu yapar yeterince basit).


3
Ayrıntılı açıklama için teşekkürler. Peki ya sürüm oluşturma hakkında, protobuf'un bunun üstesinden gelebileceğini duydum, peki ya diğer kitaplıklar ve ortak olarak nasıl kullanılabilir? Ayrıca, Avro artık JSON'a ek olarak C benzeri sözdizimine sahip IDL'ye sahip görünüyor.
andypopp

2
ASN.1, ...uzantı işaretçileri aracılığıyla manuel sürüm oluşturmayı veya EXTENSIBILITY IMPLIEDmodül başlığındaki otomatik olarak destekler . Protokol Tamponları, IIRC, manuel sürüm oluşturmayı destekler. Örtülü genişletilebilirlik gibi herhangi bir şeyi destekleyip desteklemediğini bilmiyorum (ve buna bakmak için çok tembelim). Thrift ayrıca bazı sürüm oluşturmayı da destekliyor, ancak yine de zımni genişletilebilirlik olmadan manuel bir süreç olarak beni etkiliyor.
SADECE

7
Kayıt için, Protokol Arabellekleri alanları her zaman açık bir şekilde sayılarla kodlar ve fazladan alanlar varsa kitaplık düzeyinde hiçbir zaman bir hata olmaz ve eksik alanlar isteğe bağlı veya açık olarak işaretlenmişse bir hata değildir. Bu nedenle, tüm protokol arabellek mesajları vardır EXTENSIBILITY IMPLIED.
Kevin Cathcart

IOCs ile - kontrolün tersine çevrilmesini mi kastediyorsunuz? PHP'deki RPC yığını için XML-RPC uzantısı gibi bir şey ne kullanılır? yoksa kendi başına bir şeyler mi yazmalı?
Stann

4
Avro daha esnektir çünkü tanımlanmış şema üzerinde dinamik olarak çalışmaya veya standart sınıflar oluşturmaya izin verir. Deneyimlerime göre çok güçlüdür: gücü, RPC oluşturucusu da dahil olmak üzere zengin özelliklerinde yatar (bu, Thrift ile ortak bir özelliktir).
Paolo Maresca

38

Az önce serileştiriciler üzerinde dahili bir çalışma yaptık, işte bazı sonuçlar (benim gelecekteki referansım için de!)

Thrift = serileştirme + RPC yığını

En büyük fark, Thrift'in sadece bir serileştirme protokolü olmaması, modern bir SOAP yığını gibi tam gelişmiş bir RPC yığını olmasıdır. Yani serileştirme sonra, nesneler olabilir (ama zorunlu) TCP / IP üzerinden makineler arasında gönderilecektir. SOAP'ta, mevcut hizmetleri (uzak yöntemler) ve beklenen bağımsız değişkenleri / nesneleri tam olarak açıklayan bir WSDL belgesiyle başladınız. Bu nesneler XML yoluyla gönderildi. Thrift'te .thrift dosyası, mevcut yöntemleri tam olarak açıklar, beklenen parametre nesneleri ve nesneler, mevcut serileştiricilerden biri aracılığıyla serileştirilir ( Compact Protocolüretimde en popüler olan verimli bir ikili protokol ile).

ASN.1 = Büyük baba

ASN.1, 80'lerde telekom çalışanları tarafından tasarlandı ve CompSci çalışanlarından çıkan son serileştiricilerle karşılaştırıldığında sınırlı kütüphane desteği nedeniyle kullanımı garip . DER (ikili) kodlama ve PEM (ascii) kodlaması olmak üzere iki varyant vardır. Her ikisi de hızlıdır, ancak DER daha hızlıdır ve ikisinden de daha verimlidir. Aslında ASN.1 DER, 30 yıl boyunca tasarlanmış serileştiricileri kolayca sürdürebilir (ve bazen yenebilir).kendinden sonra, iyi tasarlanmış tasarımının bir kanıtı. Çok kompakttır, Protocol Buffers ve Thrift'ten daha küçüktür, yalnızca Avro tarafından yenilir. Sorun, desteklenecek harika kitaplıklara sahip olmak ve şu anda Bouncy Castle, C # / Java için en iyisi gibi görünüyor. ASN.1, güvenlik ve kripto sistemlerinde kraldır ve ortadan kalkmayacaktır, bu nedenle 'geleceğe yönelik prova' konusunda endişelenmeyin. Sadece iyi bir kütüphane edinin ...

MessagePack = paketin ortası

Fena değil ama ne en hızlı, ne de en küçüğü ne de en iyi desteklenen. Onu seçmek için üretim nedeni yok.

Yaygın

Bunun ötesinde, oldukça benzerler. Çoğu, temel TLV: Type-Length-Valueilkenin varyantlarıdır .

Protokol Arabellekleri (Google kaynaklı), Avro (Apache tabanlı, Hadoop'ta kullanılıyor), Thrift (Facebook kaynaklı, şimdi Apache projesi) ve ASN.1 (Telekom kaynaklı), verilerinizi bir serileştiricide ilk olarak ifade ettiğiniz bir düzeyde kod üretmeyi içerir -özel biçim, ardından serileştirici "derleyici" code-genaşama aracılığıyla diliniz için kaynak kodu üretecektir . Uygulama kaynağınız daha sonra bu code-gensınıfları IO için kullanır . Bazı uygulamaların (ör. Microsoft'un Avro kitaplığı veya Marc Gavel'in ProtoBuf.NET) uygulama düzeyinde POCO / POJO nesnelerini doğrudan dekore etmenize izin verdiğini ve ardından kitaplığın herhangi bir kod geninin sınıfları yerine doğrudan bu dekore edilmiş sınıfları kullandığını unutmayın. Bunun bir nesne kopyalama aşamasını ortadan kaldırdığı için (uygulama düzeyinde POCO / POJO alanlarından kod oluşturma alanlarına kadar) performans artışı sunduğunu gördük.

Oynamak için bazı sonuçlar ve canlı bir proje

Bu proje ( https://github.com/sidshetye/SerializersCompare ) C # dünyasındaki önemli serileştiricileri karşılaştırır. Java halkının zaten benzer bir şeyi var .

1000 iterations per serializer, average times listed
Sorting result by size
Name                Bytes  Time (ms)
------------------------------------
Avro (cheating)       133     0.0142
Avro                  133     0.0568
Avro MSFT             141     0.0051
Thrift (cheating)     148     0.0069
Thrift                148     0.1470
ProtoBuf              155     0.0077
MessagePack           230     0.0296
ServiceStackJSV       258     0.0159
Json.NET BSON         286     0.0381
ServiceStackJson      290     0.0164
Json.NET              290     0.0333
XmlSerializer         571     0.1025
Binary Formatter      748     0.0344

Options: (T)est, (R)esults, s(O)rt order, (S)erializer output, (D)eserializer output (in JSON form), (E)xit

Serialized via ASN.1 DER encoding to 148 bytes in 0.0674ms (hacked experiment!)

3
ASN.1'de ayrıca BER (Temel Kodlama Kuralları), PER (Paketlenmiş Kodlama Kuralları) ve XER (XML Kodlama Kuralları) vardır. DER, her bir veri için benzersiz bir kodlamayı garanti ettiği için öncelikle kriptografi için kullanılan bir BER varyasyonudur. Hem BER hem de PER, DER'den daha verimli olabilir. Çoğu kütüphane DER'yi işler. Bazıları tüm BER yapılarını doğru şekilde işlemez. Daha fazlasını öğrenmek isteyenler için
Joe Steele

Ayrıca JER - JavaScript Nesne Gösterim Kodlama Kurallarına sahiptir. ECN (Encoding Control Notation) ile kendi kodlama kurallarınızı da tanımlayabilirsiniz. İndirme bağlantılarına sahip iyi özelliklerin listesi: oss.com/asn1/resources/standards-define-asn1.html
Dmitry

There are two variants, DER (binary) encoding and PEM (ascii) encoding. PEM'in, BEGIN END yorumlarının içinde yalnızca 64 tabanlı kodlanmış ikili veri olduğunu unutmayın. Bu ikili veri, DER kodlaması kullanılarak oluşturulmuş olabilir, bu nedenle PEM ve DER'yi karşılaştırmak garip.
RafalS

14

Performans perspektifine ek olarak Uber, kısa süre önce bu kitaplıklardan birkaçını mühendislik bloglarında değerlendirdi:

https://eng.uber.com/trip-data-squeeze/

Onlar için kazanan mı? Sıkıştırma için MessagePack + zlib

Amacımız, kodlama protokolü ve sıkıştırma algoritmasının kombinasyonunu, en kompakt sonucu en yüksek hızda bulmaktı. Uber New York City'den yapılan 2.219 sözde rastgele anonim yolculukta (JSON olarak bir metin dosyasına yerleştirilmiş) kodlama protokolü ve sıkıştırma algoritması kombinasyonlarını test ettik.

Buradaki ders, gereksinimlerinizin sizin için hangi kitaplığın doğru olduğunu belirlemesidir. Uber için, sahip oldukları mesaj geçişinin şemasız doğası nedeniyle IDL tabanlı bir protokol kullanamadılar. Bu, bir dizi seçeneği ortadan kaldırdı. Ayrıca onlar için işin içine giren sadece ham kodlama / kod çözme zamanı değil, aynı zamanda durmakta olan verilerin boyutu.

Boyut Sonuçları

Boyut Sonuçları

Hız Sonuçları

görüntü açıklamasını buraya girin


13

ASN.1 ile ilgili en büyük şey, ist'in uygulama için değil , spesifikasyon için tasarlanmış olmasıdır . Bu nedenle, herhangi bir "gerçek" programlama dilinde uygulama detaylarını gizlemek / görmezden gelmek çok iyidir.

ASN.1-Derleyicisinin görevi, Kodlama Kurallarını asn1 dosyasına uygulamak ve her ikisinden de çalıştırılabilir kod oluşturmaktır. Kodlama Kuralları Kodlama Notasyonunda (ECN) verilebilir veya BER / DER, PER, XER / EXER gibi standartlaştırılmış olanlardan biri olabilir. Yani ASN.1, Türler ve Yapılardır, Kodlama Kuralları kablo üzerinde kodlamayı tanımlar ve son olarak Derleyici bunu sizin programlama dilinize aktarır.

Ücretsiz Derleyiciler, bildiğim kadarıyla C, C ++, C #, Java ve Erlang'ı destekliyor. Ticari derleyiciler (çok pahalı ve patenti / lisanslı olanlar) çok yönlüdür, genellikle kesinlikle günceldir ve bazen daha fazla dili destekler, ancak sitelerine bakın (OSS Nokalva, Marben vb.).

Bu teknikleri kullanarak tamamen farklı programlama kültürlerinin tarafları (ör. "Yerleşik" kişiler ve "sunucu çiftçileri") arasında bir arayüz belirlemek şaşırtıcı derecede kolaydır: bir asn.1 dosyası, Kodlama kuralı, örneğin BER ve bir UML Etkileşim Şeması . Nasıl uygulandığını merak etmeyin, herkesin "kendi şeyini" kullanmasına izin verin! Benim için çok iyi çalıştı. Btw .: OSS Nokalva'nın sitesinde ASN.1 hakkında en az iki ücretsiz indirilebilir kitap bulabilirsiniz (biri Larmouth, diğeri Dubuisson).

IMHO diğer ürünlerin çoğu, serileştirme sorununa çok fazla hava pompalayarak, yalnızca başka bir RPC saplama üreteci olmaya çalışır. Birinin buna ihtiyacı varsa iyi olabilir. Ama bana göre, Sun-RPC'nin yeniden icatları gibi görünüyorlar (80'in sonlarından itibaren), ama hey, bu da işe yaradı.


7

Microsoft'un Bond'u ( https://github.com/Microsoft/bond ) performans, işlevler ve belgeler açısından çok etkileyicidir. Ancak şu an itibariyle (13 Şubat 2015) pek çok hedef platformu desteklemiyor. Sadece bunun çok yeni olduğu için olduğunu varsayabilirim. şu anda python, c # ve c ++ 'yı destekler. MS tarafından her yerde kullanılıyor. Ben bunu denedim, bence ac # geliştirici olarak bond kullanmak protobuf kullanmaktan daha iyidir, ancak ben de tasarruf kullandım, karşılaştığım tek sorun dokümantasyondu, işlerin nasıl yapıldığını anlamak için birçok şey denemek zorunda kaldım.

Bond hakkında birkaç kaynak aşağıdaki gibidir ( https://news.ycombinator.com/item?id=8866694 , https://news.ycombinator.com/item?id=8866848 , https://microsoft.github.io/ bond / why_bond.html )


5

Performans için bir veri noktası jvm-serileştiriciler karşılaştırmasıdır - oldukça spesifik, küçük mesajlardır, ancak Java platformundaysanız yardımcı olabilir. Genel olarak performansın çoğu zaman en önemli fark olmayacağını düşünüyorum. Ayrıca: Yazarların sözlerini ASLA müjde olarak almayın; reklamı yapılan iddiaların çoğu sahte (örneğin, msgpack sitesi bazı şüpheli iddialar içeriyor; hızlı olabilir, ancak bilgi çok kabataslak, kullanım durumu çok gerçekçi değil).

Bir büyük fark, bir şemanın kullanılması gerekip gerekmediğidir (en azından PB, Thrift; Avro isteğe bağlı olabilir; ASN.1 ayrıca düşünüyorum; MsgPack, zorunlu olarak değil).

Ayrıca: bence katmanlı, modüler tasarımı kullanabilmek iyi; yani, RPC katmanı veri formatını, serileştirmeyi dikte etmemelidir. Maalesef çoğu aday bunları sıkıca paketliyor.

Son olarak, veri formatını seçerken, günümüzün performansı metin formatlarının kullanımını engellemiyor. Çok hızlı JSON ayrıştırıcıları (ve oldukça hızlı akışlı xml ayrıştırıcıları) vardır; ve komut dosyası dillerinden birlikte çalışabilirlik ve kullanım kolaylığı düşünüldüğünde, ikili formatlar ve protokoller en iyi seçim olmayabilir.


Deneyimlerinizi paylaştığınız için teşekkür ederiz, ancak yine de ikili biçime ihtiyacım olduğunu düşünüyorum (gerçekten çok miktarda veriye sahibim) ve muhtemelen Avro'ya bağlı kalacağım.
andreypopp

Evet o zaman mantıklı olabilir. Hangi formatta kullanılırsa kullanılsın sıkıştırmayı herhangi bir oranda kullanmak isteyebilirsiniz (LZF, gzip / deflate ile karşılaştırıldığında sıkıştırması / sıkıştırması çok hızlı olduğu için iyidir).
StaxMan
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.