Perbedaan terbesar dari Penghemat vs Protokol Buffer?


Jawaban:


159

Keduanya menawarkan banyak fitur yang sama; Namun, ada beberapa perbedaan:

  • Hemat mendukung 'pengecualian'
  • Protokol Buffer memiliki dokumentasi / contoh yang jauh lebih baik
  • Hemat memiliki Settipe bawaan
  • Protokol Buffer memungkinkan "ekstensi" - Anda dapat memperluas proto eksternal untuk menambahkan bidang tambahan, sementara masih memungkinkan kode eksternal untuk beroperasi pada nilai-nilai. Tidak ada cara untuk melakukan ini di Thrift
  • Saya menemukan Protokol Buffer lebih mudah dibaca

Pada dasarnya, mereka cukup setara (dengan Protokol Buffer sedikit lebih efisien dari apa yang saya baca).


16
Presentasi ini menjelaskannya dengan baik pada 2013 slideshare.net/IgorAnishchenko/pb-vs-thrift-vs-avro
BAR

13
barang bekas mendukung seperti 10 bahasa lainnya
Elijah Saounkine

1
Untuk beberapa bahasa Anda dapat menambahkan ekstensi. Sebagai contoh, Thrift menghasilkan kelas parsial untuk C # yang mudah diperluas. Namun, itu bukan aturan umum, itu benar.
JensG

grpc 1.0 (proto3) mapjuga mendukung
KindDragon

85

Perbedaan penting lainnya adalah bahasa yang didukung secara default.

  • Buffer Protokol: Java, Android Java, C ++, Python, Ruby, C #, Go, Objective-C, Node.js
  • Hemat: Java, C ++, Python, Ruby, C #, Go, Objective-C, JavaScript, Node.js, Erlang, PHP, Perl, Haskell, Smalltalk, OCaml, Delphi, D, Haxe

Keduanya dapat diperluas ke platform lain, tetapi ini adalah binding bahasa yang tersedia di luar kotak.


16
protobuf memiliki dukungan ruby ​​yang sangat baik github.com/macks/ruby-protobuf dan code.google.com/p/ruby-protobuf . Saya menggunakan protobuf dari C # (3.5) dan Ruby, C # membuat serial data, dan ketika diperlukan, deserializing Ruby dan mengerjakan tugas.
Bryan Bailliache

6
code.google.com/p/protobuf/wiki/ThirdPartyAddOns mencantumkan PHP, Ruby, Erlang, Perl, Haskell, C #, OCaml plus Actiona Script, Common Lisp, Go, Lua, Mathlab, Visual Basic, Scala. Kupikir ini semua adalah implementasi pihak ketiga.
Igor Gatis

Anda dapat langsung menggunakan protobuf C ++ file dalam tujuan c (untuk iOS dan OS X) periksa qn ini
Tushar Koul

Saya melihat code.google.com/p/protobuf-net sering disebut sebagai port protobuf untuk C #, tetapi itu tidak sepenuhnya benar. Salah satu fitur penting Protobuf dan Thrift adalah definisi struktur eksternal, sehingga definisi yang sama dapat digunakan oleh berbagai bahasa. protobuf-net tidak mendukung fitur ini karena menyertakan definisi struktur di dalam kode C #.
Andriy Tylychko

@AndyT: Itu bisa diperdebatkan - itu tergantung pada apakah itu keuntungan bahwa definisi struktur EKSTERNAL untuk semua bahasa yang ingin Anda dukung. Dengan protobuf-net Anda menentukan struktur data Anda dalam C #, dan menghasilkan file .proto dari itu, yang kemudian dapat digunakan untuk membuat dukungan dalam bahasa lain. Saya menganggap ini sebagai keuntungan, karena saya sangat C #-sentris dan sedang dalam proses mengintegrasikan Android / Java dengan aplikasi .Net yang ada. Jadi saya ingin terus menganggap kelas C # saya sebagai definisi struktur definitif.
RenniePet

73

RPC adalah perbedaan utama lainnya. Thrift menghasilkan kode untuk mengimplementasikan klien RPC dan server di mana Protokol Buffer tampaknya sebagian besar dirancang sebagai format pertukaran data saja.


9
Itu tidak benar. Protokol buffer mendefinisikan api layanan RPC dan ada beberapa perpustakaan yang tersedia untuk mengimplementasikan pesan yang lewat.
Stephen

7
Saya tidak mengatakan Protobuf tidak memiliki RPC yang ditentukan, hanya saja sepertinya itu tidak dirancang untuk itu, setidaknya bukan rilis eksternal yang dapat diakses semua orang. Baca komentar insinyur Google ini di sini
saidimu apale

9
Lebih penting lagi, Thrift memiliki dukungan RPC bawaan. Protobuf saat ini bergantung pada perpustakaan pihak ketiga, yang berarti lebih sedikit mata, lebih sedikit pengujian, kode kurang dapat diandalkan.
Alec Thomas

2
Bagi saya, ini poin bagus tentang ProtoBuf. Jika Anda hanya perlu membuat cerita bersambung, Anda tidak perlu menambahkan kode yang tidak berguna. Dan jika di masa depan, Anda perlu mengirimkannya dengan RPC, tidak masalah, itu bisa berfungsi. Saya menggunakan Netty untuk jaringan, dan Protobuf terintegrasi dengan sempurna, jadi tidak ada masalah, tidak ada tes, dan memaksimalkan kinerja.
Kikiwa

14
Protobuf sebenarnya dirancang dengan mempertimbangkan RPC. Google baru saja membuka-sumber komponen itu dengan cukup baru - grpc.io
andybons

57
  • Objek serial Protobuf adalah sekitar 30% lebih kecil dari Thrift.
  • Sebagian besar tindakan yang Anda mungkin ingin lakukan dengan objek protobuf (membuat, membuat serial, deserialize) jauh lebih lambat daripada penghematan kecuali Anda menghidupkan option optimize_for = SPEED.
  • Hemat memiliki struktur data yang lebih kaya (Peta, Set)
  • Protobuf API terlihat lebih bersih, meskipun kelas yang dihasilkan semuanya dikemas sebagai kelas dalam yang tidak begitu baik.
  • Hemat enum bukan Java Enums asli, yaitu mereka hanya int. Protobuf memiliki enum Java nyata.

Untuk melihat lebih dekat perbedaannya, lihat perbedaan kode sumber di proyek sumber terbuka ini .


1
Saran cepat: akan rapi jika ada format non-biner lain (xml atau json?) Yang digunakan sebagai baseline. Belum ada tes bagus yang menunjukkan tren umum - anggapan bahwa PB dan Thrift lebih efisien, tetapi jika dan seberapa banyak jika demikian, sebagian besar merupakan pertanyaan terbuka.
StaxMan

4
0,02 detik ?! Saya tidak punya waktu luang semacam itu
Chris S

1
Sekarang Thrift memiliki banyak protokol (termasuk TCompactProtocol), saya pikir peluru pertama tidak berlaku lagi.
Janus Troelsen

13
Opsi optimisasi untuk kecepatan sekarang menjadi default untuk buffer protokol ( code.google.com/apis/protocolbuffers/docs/proto.html )
Willem

5
Apakah kita mendapatkan objek 30% lebih kecil dengan set "optim_for = speed"? Atau itu dikompromikan?
Prashant Sharma

56

Seperti yang saya katakan sebagai topik "Hemat vs Protokol" :

Mengacu pada perbandingan Thrift vs Protobuf vs JSON :

Selain itu, ada banyak alat tambahan menarik yang tersedia untuk solusi tersebut, yang mungkin memutuskan. Berikut adalah contoh untuk Protobuf: Protobuf-wireshark , protobufeditor .


10
Sekarang ini adalah lingkaran penuh. Anda telah memposting jawaban yang sama persis untuk tiga (serupa) pertanyaan yang selalu menghubungkan kembali ke salah satu atau. Saya merasa seperti saya bermain Zelda dan melewatkan tanda.
ChrisR

+ ChrisR heh, saya tidak ingat bagaimana itu bisa terjadi. Meskipun ada beberapa pertanyaan serupa, mungkin saya harus membuat tiga struktur seperti bukan siklus. Suatu hari ... Ini pertanyaan yang sangat lama dan sekarang saya membalas dari telepon. Bagaimanapun, terima kasih atas tangkapannya!
Grzegorz Wierzowiecki

6
"Barang bekas dilengkapi dengan tutorial yang bagus" - betapa lucu. Ini adalah tutorial paling tidak lengkap yang pernah saya lihat. Segera setelah Anda ingin melakukan sesuatu di samping TSimpleServer, Anda terjebak di sana
Marian Klühspies

Thrift juga memiliki plugin Wireshark: github.com/andrewcox/wireshark-with-thrift-plugin
CCoder

8

Protokol Buffer tampaknya memiliki representasi yang lebih ringkas, tetapi itu hanya kesan yang saya dapatkan dari membaca whitepaper Thrift. Dengan kata-kata mereka sendiri:

Kami memutuskan terhadap beberapa optimisasi penyimpanan ekstrem (yaitu mengemas integer kecil ke ASCII atau menggunakan format kelanjutan 7-bit) demi kesederhanaan dan kejelasan dalam kode. Perubahan ini dapat dengan mudah dilakukan jika dan ketika kita menemukan kasus penggunaan kritis yang menuntut mereka.

Juga, mungkin hanya kesan saya, tetapi Protokol Buffer tampaknya memiliki beberapa abstraksi lebih tebal di sekitar versi struct. Thrift memang memiliki beberapa dukungan versi, tetapi butuh sedikit usaha untuk mewujudkannya.


1
Mengapa fakta bahwa Thrift mengaku tidak sekompleks mungkin membuat Anda percaya pada Protokol Buffer?
Michael Mior

1
Buffer protokol menggunakan pengkodean integer panjang variabel, baik untuk nilai dan untuk pengidentifikasi bidang. Jadi kasus yang sangat umum mengirim bidang int dengan nilai kecil adalah dua byte, bukan int16 dan int32.
poolie

"Protokol buffer menggunakan kode integer panjang variabel" - begitu juga TCompactProtocol
JensG


7

Satu hal yang jelas belum disebutkan adalah bahwa dapat berupa pro atau kontra (dan sama untuk keduanya) adalah bahwa mereka adalah protokol biner. Hal ini memungkinkan untuk representasi yang lebih kompak dan mungkin lebih banyak kinerja (pro), tetapi dengan keterbacaan berkurang (atau lebih tepatnya, debuggability), sebuah con.

Juga, keduanya memiliki sedikit dukungan alat kurang dari format standar seperti xml (dan mungkin bahkan json).

(EDIT) Berikut ini adalah perbandingan menarik yang menangani perbedaan ukuran & kinerja, dan termasuk angka untuk beberapa format lain (xml, json) juga.


3
Ini sepele untuk menghasilkan buffer protokol ke representasi teks yang jauh lebih dapat dibaca manusia daripada XML: my_proto.DebugString (). Sebagai contoh, lihat code.google.com/apis/protocolbuffers/docs/overview.html
SuperElectric

Tentu saja, ditto untuk semua format biner - tetapi itu tidak membuatnya mudah dibaca (debug on the wire). Lebih buruk lagi, untuk protobuf, Anda benar-benar membutuhkan skema skema untuk mengetahui nama bidang.
StaxMan

Hemat mendukung protokol yang berbeda, bahkan yang ditentukan pengguna. Anda dapat menggunakan biner, kompak, json, atau sesuatu yang Anda temukan minggu lalu.
JensG

6

Dan menurut wiki runtime penghematan tidak berjalan di Windows.


5
Saya menjalankan Hemat pada Windows dengan sukses. Gunakan fork windows di github.com/aubonbeurre/thrift
Sergey Podobry

20
Cabang utama resmi sekarang memiliki dukungan Windows juga.
Janus Troelsen

5
@dalle - Alex P menambahkan dukungan thread Peningkatan di Thrift. Sekarang ini adalah threading default untuk Windows. * NIX default ke pthreads. Dan untuk mengkonfirmasi Janus T, Thrift sekarang sepenuhnya mendukung Windows.
pmont

21
Ini adalah Informasi yang sudah ketinggalan zaman. Hemat berjalan sempurna di Windows untuk waktu yang lama sekarang.
JensG


4

Saya pikir sebagian besar poin ini telah melewatkan fakta dasar bahwa Thrift adalah kerangka kerja RPC, yang kebetulan memiliki kemampuan untuk membuat serialisasi data menggunakan berbagai metode (biner, XML, dll).

Protokol Buffer dirancang murni untuk serialisasi, ini bukan kerangka kerja seperti Thrift.


3
Apa yang Anda maksud dengan kerangka kerja RPC dan apa bedanya dengan gRPC protobuf ?
marcelocra

gRPC tidak dikemas bersama dengan protobuf. Ini dikembangkan seperti 10 tahun setelahnya. Thrift dikemas dengan kerangka kerja RPC lengkap. Itu dibuat bersama.
trilogi


0

Ada beberapa poin yang sangat bagus di sini dan saya akan menambahkan satu lagi kalau-kalau jalur seseorang melintasi sini.

Thrift memberi Anda opsi untuk memilih antara serialer hemat-biner dan hemat-kompak (de), penghematan-biner akan memiliki kinerja luar biasa tetapi ukuran paket lebih besar, sedangkan hemat-kompak akan memberi Anda kompresi yang baik tetapi membutuhkan daya pemrosesan lebih. Ini berguna karena Anda selalu dapat beralih di antara dua mode ini semudah mengubah sebaris kode (heck, bahkan membuatnya dapat dikonfigurasi). Jadi, jika Anda tidak yakin berapa banyak aplikasi Anda harus dioptimalkan untuk ukuran paket atau kekuatan pemrosesan, penghematan bisa menjadi pilihan yang menarik.

PS: Lihat proyek tolok ukur yang sangat baik ini thekvsyang membandingkan banyak serializer termasuk penghematan-biner, hemat-kompak, dan protobuf: https://github.com/thekvs/cpp-serializers

PS: Ada serializer lain bernama YASyang memberikan opsi ini juga tetapi kurang skema lihat tautan di atas.


0

Penting juga untuk dicatat bahwa tidak semua bahasa yang didukung kompatibel secara konsisten dengan penghematan atau protobuf. Pada titik ini adalah masalah implementasi modul di samping serialisasi yang mendasarinya. Berhati-hatilah untuk memeriksa tolok ukur untuk bahasa apa pun yang Anda rencanakan untuk digunakan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.