web-dev-qa-db-ja.com

ThriftとProtocol Buffersの最大の違いは?

Apache Thrift vs GoogleのProtocol Buffers の最大の長所と短所は何ですか?

272
Bob

どちらも同じ機能の多くを提供します。ただし、いくつかの違いがあります。

  • Thriftは「例外」をサポートしています
  • プロトコルバッファには、より優れたドキュメント/例があります
  • ThriftにはSetタイプが組み込まれています
  • プロトコルバッファは「拡張」を許可します-外部コードを値に作用させながら、外部プロトコルを拡張してフィールドを追加できます。 Thriftでこれを行う方法はありません
  • プロトコルバッファーの方が読みやすい

基本的に、それらはほぼ同等です(プロトコルバッファは、私が読んだものよりもわずかに効率的です)。

154
hazzen

もう1つの重要な違いは、デフォルトでサポートされている言語です。

  • プロトコルバッファー:Java、Android Java、C++、Python、Ruby、C#、Go、Objective-C、Node.js
  • Thrift:Java、C++、Python、Ruby、C#、Go、Objective-C、JavaScript、Node.js、Erlang、PHP、Perl、Haskell、Smalltalk、OCaml、Delphi、D、Haxe

両方を他のプラットフォームに拡張することもできますが、これらはすぐに使用できる言語バインディングです。

83
Mike Gray

RPCはもう1つの重要な違いです。 Thriftは、プロトコルバッファがほとんどデータ交換フォーマットとしてのみ設計されているように見えるRPCクライアントとサーバーを実装するコードを生成します。

71
saidimu apale
  • Protobufシリアル化オブジェクトは、Thriftよりも約30%小さくなります。
  • Protobufオブジェクトを使用して実行するほとんどのアクション(作成、シリアライズ、デシリアライズ)は、 option optimize_for = SPEED をオンにしない限り thriftよりもはるかに遅い です。
  • Thriftには豊富なデータ構造(マップ、セット)があります
  • Protobuf APIはよりきれいに見えますが、生成されたクラスはすべて内部クラスとしてパックされていますが、あまり良くありません。
  • Thrift列挙型は実際のJava列挙型ではありません。つまり、単なるintです。 Protobufには実際のJava列挙型があります。

違いを詳しく見るには、 このオープンソースプロジェクト のソースコードの差分を確認してください。

57
eishay

"Thrift vs Protocol buffers" topicと言ったように:

Thrift対Protobuf対JSON比較 を参照:

さらに、これらのソリューションに使用できる興味深い追加ツールがたくさんあり、それらが決定する可能性があります。 Protobufの例を次に示します。 Protobuf-wiresharkprotobufeditor

55

Pythonのprotobuffと比較して、テキストベースのプロトコルでより良いパフォーマンスを得ることができました。ただし、protobuffが提供する型チェックやその他の凝ったutf8変換などはありません。

したがって、シリアル化/逆シリアル化が必要な場合は、おそらく他の何かを使用できます。

http://dhruvbird.blogspot.com/2010/05/protocol-buffers-vs-http.html

8
dhruvbird

まだ言及されていない明らかなことの1つは、賛否両論(両方とも同じ)になる可能性があるということです。これは、それらがバイナリプロトコルであることです。これにより、表現がよりコンパクトになり、パフォーマンスが向上する可能性がありますが(長所)、読みやすさ(またはデバッグ可能性)は低下します。

また、両方ともxmlなどの標準形式(およびjsonでさえ)よりもツールサポートが少し少ない.

(編集)ここに 興味深い比較 があります。これはサイズとパフォーマンスの両方の違いに取り組み、他のいくつかの形式(xml、json)の数値も含みます。

7
StaxMan

Protocol Buffersはよりコンパクトな表現を持っているようですが、それは私がThriftホワイトペーパーを読んで得た印象に過ぎません。彼ら自身の言葉で:

コードの単純さと明瞭さのために、いくつかの極端なストレージの最適化(つまり、小さな整数をASCIIにパックするか、7ビットの継続形式を使用する)に反対しました。これらの変更は、パフォーマンスを重視するユースケースが必要な場合に簡単に行うことができます。

また、それは私の印象にすぎないかもしれませんが、プロトコルバッファは、構造体のバージョン管理に関するいくつかのより厚い抽象化を持っているようです。 Thriftはバージョン管理をサポートしていますが、それを実現するには少し手間がかかります。

7
Daniel Spiewak

ProtocolBuffersはより高速です。
ここに素敵なベンチマークがあります:
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

Avroはさらに高速であるため、Avroを調べることもできます。
Microsoftのパッケージは次のとおりです。
http://www.nuget.org/packages/Microsoft.Hadoop.Avro

ちなみに、私が今まで見た中で最速は Cap'nProto ;
C#実装は Marc GravellのGithub-repository で見つけることができます。

6
Stefan Steiger

wiki によれば、ThriftランタイムはWindowsでは実行されません。

6
hplbsh

たとえば、protobufは完全なRPC実装ではありません。それには、gRPCのようなものが必要です。

gPRCはThriftと比較して非常に遅い:

http://szelei.me/rpc-benchmark-part1/

3
trilogy

これらのポイントのほとんどは、ThriftがRPCフレームワークであり、さまざまな方法(バイナリ、XMLなど)を使用してデータをシリアル化できるという基本的な事実を逃したと思います。

プロトコルバッファは純粋にシリアル化のために設計されており、Thriftのようなフレームワークではありません。

3

サポートされているすべての言語がthriftまたはprotobufに一貫して対応しているわけではないことに注意することも重要です。この時点では、基礎となるシリアル化に加えて、モジュールの実装の問題です。使用する予定の言語のベンチマークを確認してください。

0
JSON

ここにはいくつかの優れた点がありますが、誰かのパスがここを横断する場合に備えて、別の点を追加します。

Thriftには、thrift-binaryとthrift-compact(de)serializerのいずれかを選択するオプションがあります。thrift-binaryは優れたパフォーマンスを発揮しますが、パケットサイズが大きくなります。一方、thrift-compactは優れた圧縮を提供しますが、より多くの処理能力が必要です。これは、コードの行を変更するのと同じくらい簡単にこれら2つのモードをいつでも切り替えることができるので便利です。したがって、パケットサイズまたは処理能力に関してアプリケーションをどれだけ最適化する必要があるかわからない場合は、節約をお勧めします。

PS:thrift-binary、thrift-compact、protobufなどの多くのシリアライザーを比較するthekvsによるこの優れたベンチマークプロジェクトを参照してください。 https://github.com/thekvs/cpp-serializers

PS:このオプションも提供するYASという別のシリアライザーがありますが、スキーマなしで上記のリンクを参照してください。

0
Sinapse