Thriftとプロトコルバッファーの最大の違いは？

Apache ThriftとGoogleのプロトコルバッファーの最大の長所と短所は何ですか？

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

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

基本的に、それらはかなり同等です（私が読んだものよりもプロトコルバッファーの方が少し効率的です）。

もう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

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

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

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

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

「Thrift vs Protocol buffers」トピックとして言ったように：

参照すると、JSONの比較対いるProtobuf対スリフト：

• Thriftは、そのままでAS3、C ++、C＃、D、Delphi、Go、Graphviz、Haxe、Haskell、Java、Javascript、Node.js、OCaml、Smalltalk、Typescript、Perl、PHP、Python、Rubyなどをサポートしています...
• C ++、Python、Java-Protobufのインボックスサポート
• 他の言語（Lua、Matlab、Ruby、Perl、R、Php、OCaml、Mercury、Erlang、Go、D、Lispなど）のProtobufサポートは、サードパーティのアドオンとして利用できます（ところで、SWI-Prologのサポートはこちらです）。
• Protobufには、はるかに優れたドキュメントと多くの例があります。
• Thriftには優れたチュートリアルが付属しています
• Protobufオブジェクトは小さい
• 「optimize_for = SPEED」構成を使用すると、Protobufがより高速になります。
• ThriftはRPC実装を統合していますが、Protobuf RPCソリューションは分離されていますが、利用可能です（Zeroc ICEなど）。
• ProtobufはBSDスタイルのライセンスでリリースされています
• ThriftはApache 2ライセンスでリリースされています

さらに、これらのソリューションで利用できる興味深い追加のツールがたくさんあります。Protobufの例を以下に示します：Protobuf-wireshark、protobufeditor。

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

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

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

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

したがって、シリアライゼーション/デシリアライゼーションが必要な場合は、おそらく他のものを使用できます。

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

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

また、どちらのツールも、xml（およびおそらくjson）のような標準形式よりもツールサポートが少し少なくなっています。

（編集）これは、サイズとパフォーマンスの違いの両方に取り組む興味深い比較であり、他のいくつかのフォーマット（xml、json）の数値も含まれています。

ウィキによると、ThriftランタイムはWindowsでは動作しません。

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

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

ちなみに、今まで見た中で最速はCap'nProtoです。
AC＃の実装は、Marc GravellのGithub-repositoryにあります。

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

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

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

gPRCは、Thriftに比べて非常に低速です。

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

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

Thriftは、thrift-binaryとthrift-compact（de）シリアライザーのどちらかを選択するオプションを提供します。thrift-binaryは、優れたパフォーマンスを提供しますが、パケットサイズは大きくなります。一方、thrift-compactは、優れた圧縮を提供しますが、より多くの処理能力を必要とします。これは、コードの行を変更するのと同じくらい簡単に、これら2つのモードをいつでも切り替えることができるので便利です（実際には、構成可能にすることもできます）。そのため、アプリケーションをパケットサイズまたは処理能力でどの程度最適化する必要があるかわからない場合、リサイクルは興味深い選択肢になる可能性があります。

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

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

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