原文：http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html
翻訳：Jia Lu
Googleでは我々のタスクは全世界のインフォメーションを集めること。
我々は千・万種類を超えるデータフォーマットでサーバ間のネットワーク情報を記述し、
保存したデータ・スペースデータセットでインデックスを生成している。さらに、
殆どのフォーマットは構造化されて、フラットなデータではない。
これで一つの問題が生じた：どうエンコードすれば良いのか？
XML？いいえ、だめだ。XMLは悪くないが、この規模のデータを処理するには効率悪すぎる。
あなたの全ての機器の負荷とネットワーク負荷が最大値に達した時、XMLはとても重い
ソリューションとなった。言うことも無く、コーディングしてDOMツリーを解析するのは
どんなに重い処理なのか。
では、メモリのデータ構造の生バイトをネットワークで送信する？いいえ、それは良くない。
我々は新たにサーバを導入する場合、古いサーバとの通信も考えないといけない。なので、
新サーバは旧サーバデータを読み書きする機能が必要だ。逆に、一つの言葉だけ追加もしくは
削除され、ディスクのデータ間リンクされている場合、更に重要になってくる。なお、
我々の一部のコードはJavaもしくはPythonでコーディングされ、ポータブルなソリューションが
求められている。
データ構造毎に解析とシリアライズをコーディングする？ええ、我々は過去こういうこと
やってたが、永久的なソリューションではない。あなたのコードライブラリに万単位の各種構造
とシリアライズに応じたフォーマットが存在した場合、そんなに簡単にコーディングできるものではない。
なので、我々はProtocol Buffersの開発に着手した。Protocol Buffersは特別な定義言語で
簡単にデータ構造を定義し、必要な開発言語クラスにコンパイルし、データ構造を表している。
これらのクラスは深度パフォーマンス改良され、とても密度の高いフォーマットでシリアライズ
を行う。なにより、これらの使用はとても簡単：フィールド毎にget、setメソッドが存在し、
一つのメソッドを利用するだけで、全てをバイト配列もしくはI/Oストリームにシリアライズされたり、
解析されたりする。
OK、あなたはこう考えているでしょう：「ただのIDLの一種？」はい、言えると思う。ただし、
殆どのIDLは一つ悪名がある：複雑で直すようもない。だが、Protocol Buffersを設計した時
の主な目標としては簡単であること。簡単のlists-and-recordsモデルで殆どの問題を解決、
しかも追跡減少回帰（chase diminishing returns）と抵抗できる。我々はパワーフルかつ複雑
でないツールを開発したと信じている。そして、そうだ、非常に速いーーXMLより桁数違いの速さ
現在、我々はProtocol Buffersをコミュニティに公開する。特定のプロジェクトには、
Protocol Buffersはどんなに良いソリューションなのか、我々はみんなに使ってもらい、
そのメリットを享受してほしいのだ。
