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

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.

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).

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!)

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 Kecepatan

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.

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 )

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.