プロトコルバッファ、どこで使用するのですか？

Question

私は最近についてprotocol buffers、

プロトコルバッファは、構造化されたデータをシリアル化する方法である記事を読みました。 ワイヤを介して、またはデータを格納するために、互いに通信するプログラムを開発するのに役立ちます。この方法は、いくつかのデータの構造を記述するインターフェース記述 言語と は私がしたい構造化データ

を表すバイトのストリームを生成または 解析するため、その説明からソースコードを生成するプログラムを含みます知っている、どこで使うの？シンプルなアドレス帳の例ではなく、実際の例がありますか？たとえば、データベースからのクエリ結果を事前にキャッシュするのに使用されていますか？

Answer 1

プロトコルバッファは、プログラムまたはコンピュータ間の通信であるRPCに特に使用されるデータ格納および交換形式です。

言語固有のシリアライズ（Javaシリアル化、Python picklesなど）、CSVやTSVなどの表形式、XMLやJSONなどの構造化テキスト形式、Apache Thriftなどのバイナリ形式があります。概念的には、これらはすべて構造化データを表現する異なる方法ですが、実際にはそれぞれ異なる長所と短所があります。

プロトコルバッファは、次のとおりです。

• スペース効率のよい、コンパクトにデータを表現するためにcustom formatに頼ります。
• 強力な型の安全クロスランゲージを提供します（特にJavaのような強く型付けされた言語ではありますが、Pythonでもそれは非常に有用です）。
• 後方互換性と前方互換性があるように設計されています。 protoを使用しているすべてのアプリケーションが同時に更新されることを保証することなく、プロトコルバッファの構造変更（通常は新しいフィールドの追加または古いフィールドの非推奨）を簡単に行うことができます。
• 手作業でやや面倒です。テキスト形式はありますが、プロトタイプを手動で検査して保存するのではなく、手作業で検査すると便利です。たとえばJSONは、人間が書いたり編集したりするのがずっと簡単です。したがって、protoは通常、プログラムによって書かれ、読み込まれます。
• .protoコンパイラに依存します。構造をデータプロトコルから分離することにより、バッファは痩せることができますが、関連する.protoファイルとそれを解析するコードを生成するためのprotocのようなツールがなければ、プロト形式の任意のデータは使用できません。これにより、.protoファイルを手に入れることができない他の人々にデータを送信するために、プロトスは貧弱な選択肢になります。

異なるフォーマットに関するいくつかの抜本的な一般化するには：

• CSV/TSV /など。人々やプログラムの間で決して伝達される必要のない人間が作成したデータに役立ちます。構築が簡単で解析が簡単ですが、複雑な構造を簡単に表現することはできません。
• picklesのような言語固有のシリアライゼーションは、短命のシリアライゼーションには便利ですが、すぐに下位互換性の問題に遭遇し、明らかに1つの言語に制限されます。非常に特殊なケースを除いて、protobufsは同じ目標をより安全でより良い未来矯正で達成します。
• JSONは、パブリックAPIなど、さまざまな関係者間でデータを送信するのに適しています。構造とコンテンツが一緒に伝達されるので、誰もがそれを理解することができ、すべての主要言語で解析するのは簡単です。今日、XMLのような他の構造化フォーマットを使用する理由はほとんどありません。
• プロトコルバッファーのようなバイナリー形式は、ほとんどすべての他のデータ直列化ユースケースに最適です。長期間および短期間のストレージ、プロセス間通信、プロセス内およびアプリケーション全体のキャッシングなどが含まれます。

Google有名人uses protocol buffers for practically everything they do。データを保存または送信する必要があると思われる場合は、おそらくプロトコルバッファで処理します。

Answer 2

私はそれらを使って金融取引システムを作成しました。理由は次のとおりです。

• 多くの言語のライブラリがあります。いくつかのものはC++にある必要があり、C＃では他のものが必要でした。そして、PythonやJavaなどにも拡張可能です。
• シリアライズ/デシリアライズとコンパクト化が高速になる必要がありました。これは、金融取引システムのスピード要件によるものです。メッセージは同等のテキストタイプのメッセージよりかなり短く、1つのネットワークパケットにそれらを適合させることは決して問題になりませんでした。
• ワイヤで読める必要はありませんでした。これまでは、システムにはデバッグに適したXMLが用意されていましたが、デバッグ出力を他の方法で取得し、実動環境でそれらをオフにすることができます。
• メッセージは自然な構造で、必要な部分を取得するためのAPIを提供します。カスタムを書くには、ヘルパー関数がバイナリから数を引き出し、コーナーケースとそのすべてを考慮する必要がありました。