Apa perbedaan utama antara Apache Thrift, Google Protocol Buffer, MessagePack, ASN.1, dan Apache Avro?

124

Semua ini menyediakan serialisasi biner, kerangka kerja RPC, dan IDL. Saya tertarik pada perbedaan utama antara mereka dan karakteristik (kinerja, kemudahan penggunaan, dukungan bahasa pemrograman).

Jika Anda mengetahui teknologi serupa lainnya, sebutkan dalam jawaban.

andreypopp
sumber
@Zenikoder: Tautan tersebut tidak memiliki informasi untuk 2 dari 5 format yang ditanyakan.
HANYA PENDAPAT SAYA yang benar
2
bagi mereka yang tidak tahu RPC - Remote Prodecure Call, IDL - Bahasa Definisi Antarmuka
garg10may

Jawaban:

97

ASN.1 adalah standar ISO / ISE. Ini memiliki bahasa sumber yang sangat mudah dibaca dan beragam ujung belakang, baik biner maupun yang dapat dibaca manusia. Menjadi standar internasional (dan yang lama!) Bahasa sumbernya agak tenggelam di dapur (dengan cara yang hampir sama dengan Samudra Atlantik yang sedikit basah) tetapi sangat ditentukan dengan baik dan memiliki jumlah dukungan yang layak . (Anda mungkin dapat menemukan pustaka ASN.1 untuk bahasa apa pun yang Anda namai jika Anda menggali cukup keras, dan jika tidak, tersedia pustaka bahasa C yang bagus yang dapat Anda gunakan di FFI.) Ini, menjadi bahasa standar, didokumentasikan secara obsesif dan memiliki beberapa tutorial bagus juga tersedia.

Penghematan bukanlah standar. Ini awalnya dari Facebook dan kemudian bersumber terbuka dan saat ini merupakan proyek Apache tingkat atas. Itu tidak terdokumentasi dengan baik - terutama level tutorial - dan untuk pandangan saya (yang memang singkat) tampaknya tidak menambahkan apa pun yang lain, upaya sebelumnya belum dilakukan (dan dalam beberapa kasus lebih baik). Agar adil, ia memiliki jumlah bahasa yang cukup mengesankan yang didukungnya di luar kotak termasuk beberapa bahasa non-arus utama dengan profil tinggi. IDL juga samar-samar mirip dengan C.

Protocol Buffer bukan standar. Ini adalah produk Google yang dirilis ke komunitas yang lebih luas. Ini agak terbatas dalam hal bahasa yang didukung di luar kotak (hanya mendukung C ++, Python dan Java) tetapi memang memiliki banyak dukungan pihak ketiga untuk bahasa lain (dengan kualitas yang sangat bervariasi). Google melakukan hampir semua pekerjaan mereka menggunakan Protocol Buffer, jadi ini adalah protokol yang teruji dalam pertempuran dan diperkuat pertempuran (meskipun tidak sekeras ASN.1. Dokumentasi ini jauh lebih baik daripada Thrift, tetapi, menjadi Produk Google, sangat mungkin tidak stabil (dalam arti selalu berubah, bukan dalam arti tidak dapat diandalkan). IDL juga seperti C.

Semua sistem di atas menggunakan skema yang ditentukan dalam beberapa jenis IDL untuk menghasilkan kode untuk bahasa target yang kemudian digunakan dalam encoding dan decoding. Avro tidak. Pengetikan Avro bersifat dinamis dan data skemanya digunakan pada waktu proses secara langsung untuk menyandikan dan mendekode (yang memiliki beberapa biaya yang jelas dalam pemrosesan, tetapi juga beberapa manfaat yang jelas terkait dengan bahasa dinamis dan kurangnya kebutuhan untuk jenis penandaan, dll.) . Skemanya menggunakan JSON yang membuat dukungan Avro dalam bahasa baru sedikit lebih mudah dikelola jika sudah ada pustaka JSON. Sekali lagi, seperti kebanyakan sistem deskripsi protokol yang menciptakan kembali roda, Avro juga tidak standar.

Secara pribadi, terlepas dari hubungan cinta / benci saya dengannya, saya mungkin akan menggunakan ASN.1 untuk sebagian besar RPC dan tujuan transmisi pesan, meskipun tidak benar-benar memiliki tumpukan RPC (Anda harus membuatnya, tetapi IOC membuatnya cukup sederhana).

HANYA PENDAPAT SAYA yang benar
sumber
3
Terima kasih atas penjelasan rinci. Tapi bagaimana dengan versi, saya dengar protobuf bisa mengatasinya, bagaimana dengan perpustakaan lain dan bagaimana itu bisa digunakan secara umum? Juga, sepertinya Avro sekarang memiliki IDL dengan sintaks mirip C selain JSON.
andreypopp
2
ASN.1 mendukung pembuatan versi manual melalui ...penanda ekstensi atau otomatis melalui EXTENSIBILITY IMPLIEDheader modul. Protocol Buffer, IIRC, mendukung pembuatan versi manual. Saya tidak tahu apakah itu mendukung sesuatu seperti ekstensibilitas tersirat (dan saya terlalu malas untuk mencarinya). Thrift juga mendukung beberapa versi, tetapi sekali lagi menurut saya sebagai proses manual tanpa ekstensibilitas yang tersirat.
HANYA PENDAPAT SAYA yang benar
7
Sebagai catatan, Protocol Buffer selalu secara eksplisit mengkodekan bidang dengan angka, dan tidak pernah terjadi kesalahan di tingkat perpustakaan jika ada bidang tambahan, dan bidang yang hilang bukan kesalahan jika ditandai opsional atau eksplisit. Jadi semua pesan buffer protokol memiliki EXTENSIBILITY IMPLIED.
Kevin Cathcart
oleh IOC - maksud Anda pembalikan kendali? apa yang akan digunakan untuk tumpukan RPC di PHP, seperti ekstensi XML-RPC? atau seseorang harus menulis sesuatu sendiri?
Stann
4
Avro lebih fleksibel karena memungkinkan untuk bekerja secara dinamis pada skema yang ditentukan, atau untuk menghasilkan kelas boilerplate. Dari pengalaman saya, ini sangat kuat: kekuatannya terletak pada rangkaian fiturnya yang kaya, termasuk generator RPC (ini adalah fitur umum pada Thrift).
Paolo Maresca
38

Kami baru saja melakukan studi internal tentang serializers, berikut beberapa hasilnya (untuk referensi saya di masa mendatang juga!)

Hemat = serialisasi + tumpukan RPC

Perbedaan terbesar adalah bahwa Hemat bukan hanya protokol serialisasi, ini adalah tumpukan RPC lengkap yang seperti tumpukan SOAP modern. Jadi setelah serialisasi, objek bisa (tapi tidak diamanatkan) dikirim antar mesin melalui TCP / IP. Dalam SOAP, Anda mulai dengan dokumen WSDL yang sepenuhnya menjelaskan layanan yang tersedia (metode jarak jauh) dan argumen / objek yang diharapkan. Objek tersebut dikirim melalui XML. Di Thrift, file .thrift menjelaskan sepenuhnya metode yang tersedia, objek parameter yang diharapkan, dan objek diserialkan melalui salah satu serializers yang tersedia (dengan Compact Protocol, protokol biner yang efisien, yang paling populer dalam produksi).

ASN.1 = Kakek

ASN.1 dirancang oleh orang-orang telekomunikasi di tahun 80-an dan sulit digunakan karena dukungan perpustakaan yang terbatas dibandingkan dengan serializer terbaru yang muncul dari orang-orang CompSci. Ada dua varian, pengkodean DER (biner) dan pengkodean PEM (ascii). Keduanya cepat, tetapi DER lebih cepat dan ukuran keduanya lebih efisien. Sebenarnya ASN.1 DER dapat dengan mudah mengikuti (dan terkadang mengalahkan) serializers yang dirancang selama 30 tahunsetelah itu sendiri, bukti desainnya yang direkayasa dengan baik. Ini sangat kompak, lebih kecil dari Protocol Buffer dan Thrift, hanya dikalahkan oleh Avro. Masalahnya adalah memiliki perpustakaan yang bagus untuk didukung dan saat ini Bouncy Castle tampaknya menjadi yang terbaik untuk C # / Java. ASN.1 adalah raja dalam keamanan dan sistem crypto dan tidak akan hilang, jadi jangan khawatir tentang 'pemeriksaan di masa depan'. Dapatkan perpustakaan yang bagus ...

MessagePack = tengah paket

Ini tidak buruk tetapi bukan yang tercepat, atau yang terkecil atau yang terbaik yang didukung. Tidak ada alasan produksi untuk memilihnya.

Umum

Di luar itu, mereka cukup mirip. Kebanyakan varian dari TLV: Type-Length-Valueprinsip dasar .

Protocol Buffer (berasal dari Google), Avro (berbasis Apache, digunakan di Hadoop), Thrift (berasal dari Facebook, sekarang proyek Apache) dan ASN.1 (berasal dari Telecom) semuanya melibatkan beberapa tingkat pembuatan kode di mana Anda pertama kali mengekspresikan data Anda dalam serializer format -specific, maka serializer "compiler" akan menghasilkan kode sumber untuk bahasa Anda melalui code-genfase. Sumber aplikasi Anda kemudian menggunakan code-genkelas ini untuk IO. Perhatikan bahwa implementasi tertentu (misalnya: perpustakaan Avro Microsoft atau ProtoBuf.NET Marc Gavel) memungkinkan Anda secara langsung menghias objek POCO / POJO tingkat aplikasi Anda dan kemudian perpustakaan secara langsung menggunakan kelas-kelas yang didekorasi itu alih-alih kelas-kelas gen kode. Kami telah melihat penawaran ini meningkatkan kinerja karena menghilangkan tahap penyalinan objek (dari bidang POCO / POJO tingkat aplikasi ke bidang kode-gen).

Beberapa hasil dan proyek langsung untuk dimainkan

Proyek ini ( https://github.com/sidshetye/SerializersCompare ) membandingkan pembuat serial penting di dunia C #. Orang-orang Java sudah memiliki sesuatu yang serupa .

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!)
DeepSpace101
sumber
3
ASN.1 juga memiliki BER (Basic Encoding Rules), PER (Packed Encoding Rules) dan XER (XML Encoding Rules). DER adalah variasi BER yang digunakan terutama untuk kriptografi karena menjamin pengkodean unik untuk setiap datum. Baik BER dan PER bisa lebih efisien daripada DER. Sebagian besar perpustakaan memproses DER. Beberapa tidak menangani semua konstruksi BER dengan benar. Bagi mereka yang tertarik untuk mengetahui lebih lanjut: luca.ntop.org/Teaching/Appunti/asn1.html
Joe Steele
Ia juga memiliki JER - Aturan Pengkodean Notasi Objek JavaScript. Anda juga dapat menentukan aturan encoding Anda sendiri dengan ECN (Encoding Control Notation). Daftar spesifikasi yang bagus dengan tautan unduhan: oss.com/asn1/resources/standards-define-asn1.html
Dmitry
There are two variants, DER (binary) encoding and PEM (ascii) encoding. Perlu diingat bahwa PEM hanyalah data biner berenkode base-64 di dalam komentar BEGIN END. Data biner ini mungkin dibuat menggunakan pengkodean DER, jadi aneh membandingkan PEM dan DER.
RafalS
14

Menambah perspektif kinerja, Uber baru-baru ini mengevaluasi beberapa perpustakaan ini di blog teknik mereka:

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

Pemenang untuk mereka? MessagePack + zlib untuk kompresi

Tujuan kami adalah menemukan kombinasi protokol encoding dan algoritma kompresi dengan hasil paling ringkas pada kecepatan tertinggi. Kami menguji kombinasi protokol encoding dan algoritme kompresi pada 2.219 perjalanan anonim pseudorandom dari Uber New York City (dimasukkan ke dalam file teks sebagai JSON).

Pelajarannya di sini adalah bahwa persyaratan Anda menentukan perpustakaan mana yang tepat untuk Anda. Untuk Uber, mereka tidak dapat menggunakan protokol berbasis IDL karena sifat pengiriman pesan tanpa skema yang mereka miliki. Ini menghilangkan banyak opsi. Juga bagi mereka, bukan hanya waktu encoding / decoding mentah yang ikut bermain, tetapi ukuran data saat istirahat.

Hasil Ukuran

Hasil Ukuran

Hasil Kecepatan

masukkan deskripsi gambar di sini

Avner
sumber
13

Satu hal besar tentang ASN.1 adalah, yang pertama dirancang untuk spesifikasi bukan implementasi. Oleh karena itu, sangat bagus untuk menyembunyikan / mengabaikan detail implementasi dalam bahasa pemrograman "sebenarnya".

Tugas ASN.1-Compiler untuk menerapkan Aturan Pengkodean ke file asn1 dan menghasilkan dari keduanya kode yang dapat dieksekusi. Aturan Pengkodean mungkin diberikan dalam Notasi Enkode (ECN) atau mungkin salah satu yang terstandarisasi seperti BER / DER, PER, XER / EXER. Itu ASN.1 adalah Jenis dan Struktur, Aturan Pengkodean menentukan pengkodean on the wire, dan terakhir tetapi tidak kalah pentingnya, Kompilator mentransfernya ke bahasa pemrograman Anda.

Compiler gratis mendukung C, C ++, C #, Java, dan Erlang sepengetahuan saya. Kompiler komersial (yang mahal dan paten / lisensi) sangat serbaguna, biasanya benar-benar mutakhir dan terkadang mendukung lebih banyak bahasa, tetapi lihat situs mereka (OSS Nokalva, Marben dll.).

Sangat mudah untuk menentukan antarmuka antara pihak-pihak dari budaya pemrograman yang sama sekali berbeda (misalnya orang "tertanam" dan "petani server") menggunakan teknik ini: file asn.1, aturan Encoding misalnya BER dan misalnya Diagram Interaksi UML . No Khawatir bagaimana ini diterapkan, biarkan semua orang menggunakan "barang mereka"! Bagi saya ini berhasil dengan sangat baik. Btw .: Di situs OSS Nokalva, Anda dapat menemukan setidaknya dua buku yang dapat diunduh gratis tentang ASN.1 (satu oleh Larmouth yang lain oleh Dubuisson).

IMHO sebagian besar produk lain mencoba hanya menjadi generator RPC-rintisan lain, memompa banyak udara ke dalam masalah serialisasi. Nah, jika seseorang membutuhkan itu, dia mungkin baik-baik saja. Tapi bagi saya, mereka terlihat seperti penemuan kembali Sun-RPC (dari akhir 80-an), tapi, hei, itu bekerja dengan baik juga.

njimko
sumber
7

Microsoft's Bond ( https://github.com/Microsoft/bond ) sangat mengesankan dengan kinerja, fungsionalitas, dan dokumentasi. Namun itu tidak mendukung banyak platform target seperti sekarang (13 Februari 2015). Saya hanya bisa berasumsi karena ini sangat baru. saat ini mendukung python, c # dan c ++. Ini digunakan oleh MS di mana-mana. Saya mencobanya, bagi saya sebagai ac # developer menggunakan bond lebih baik daripada menggunakan protobuf, namun saya juga sudah menggunakan thrift, satu-satunya masalah yang saya hadapi adalah dengan dokumentasi, saya harus mencoba banyak hal untuk memahami bagaimana hal-hal dilakukan.

Beberapa sumber daya tentang Bond adalah sebagai berikut ( https://news.ycombinator.com/item?id=8866694 , https://news.ycombinator.com/item?id=8866848 , https://microsoft.github.io/ bond / why_bond.html )

Srivathsa Harish Venkataramana
sumber
5

Untuk kinerja, satu titik data adalah jvm-serializers benchmark - ini cukup spesifik, pesan kecil, tetapi mungkin membantu jika Anda menggunakan platform Java. Saya pikir kinerja secara umum seringkali bukan perbedaan yang paling penting. Juga: JANGAN PERNAH menganggap kata-kata penulis sebagai Injil; banyak klaim yang diiklankan adalah palsu (situs msgpack misalnya memiliki beberapa klaim yang meragukan; mungkin cepat, tetapi informasinya sangat samar, kasus penggunaan tidak terlalu realistis).

Satu perbedaan besar adalah apakah skema harus digunakan (PB, Hemat setidaknya; Avro mungkin opsional; ASN.1 Saya pikir juga; MsgPack, belum tentu).

Juga: menurut pendapat saya, sebaiknya bisa menggunakan desain modular berlapis; Artinya, lapisan RPC tidak boleh menentukan format data, serialisasi. Sayangnya sebagian besar kandidat melakukannya dengan ketat.

Terakhir, ketika memilih format data, kinerja saat ini tidak menghalangi penggunaan format tekstual. Ada pengurai JSON yang sangat cepat (dan pengurai xml streaming yang cukup cepat); dan ketika mempertimbangkan interoperabilitas dari bahasa skrip dan kemudahan penggunaan, format biner dan protokol mungkin bukan pilihan terbaik.

StaxMan
sumber
Terima kasih telah berbagi pengalaman, tetapi saya rasa saya masih membutuhkan format biner (saya memiliki jumlah data yang sangat besar) dan mungkin akan tetap menggunakan Avro.
andreypopp
Ya mungkin masuk akal kalau begitu. Anda mungkin ingin menggunakan kompresi dengan kecepatan berapa pun, apa pun format yang digunakan (LZF bagus karena sangat cepat untuk dikompres / dibuka, dibandingkan dengan gzip / deflate).
StaxMan