Google、内部で使用しているデータバッファリング＆交換プロトコルをオープンソース化

hylom 曰く、

Googleが、Googleのさまざまなシステムで使用している、データバッファリング＆交換プロトコル「Protocol Buffers」をオープンソース化した （PC Worldの記事）。

Googleの内部では、サーバー間で様々なデータが交換されており、さらにそれらのデータはフラットではなく構造化されているそうだ。このようなデータを受け渡すフォーマットとしてXMLがよく使われているが、Googleのデータ共有システムで使用するにはXMLは「コストが高すぎる」ため、Googleは独自のプロトコルを開発したそうだ。

Protocol Buffersを利用することで、さまざまな構造化データをさまざまな言語で容易に扱えるようになり、さらに通信量の削減や通信速度の高速化も期待できる。Googleによると、XMLを利用する場合と比べてデータ量は3～10分の1程度で、さらに速度は20～100倍高速とのことだ。

CNETでも記事が出ている。

何に使う？

[cyber205 (4374)]

個人的にはP2Pデータ交換システムに応用できるような気がします。
大規模な情報共有と、強力な検索機能はP2Pシステムの要ですから、
そのへんに、このプロトコルは使えるんじゃないかな。

Re:何に使う？

[rxk14007 (9967)]

> 個人的にはP2Pデータ交換システムに応用できるような気がします。
P2Pのデータって動画や音楽などのbinaryデータがほとんどだから、難しいと思うよ。
XMLに代わるデータ交換フォーマットとして、企業でのデータ連携・同期処理などの用途が向いているのでは。

--
I'm out of my mind, but feel free to leave a comment.

大切なのはメタデータだから

[Livingdead (18685)]

P2P型のシステムで重要なのはデータそのものの交換よりも、
オーバーレイネットワークの形成と検索なので、
オーバーヘッドの少ない半構造化データの表現には使い道があるかと。

JSONもかなりその用途には使えると思いますが、自己記述性に乏しい。
いや、その自己記述性の乏しさというか、データそのものにスリム化した点がJSONはいいわけですが。

一方あやふやなスキーマじゃいやだってことならがちがちに独自のスキーマでXML書くか、
逆にもっと柔軟にRDFのトリプルで書いていくか・・・結局のところ用途に応じて
乱立するというのはこれからも変わらないんだろうなぁ。

＃さぁ、いろんなデータ表現のパーサを再実装する作業に戻るんだ！

--
屍体メモ [windy.cx]

Re:何に使う？

[Anonymous Coward]

>XMLに代わるデータ交換フォーマットとして、企業でのデータ連携・同期処理などの用途が向いているのでは。

データ交換を社内で頻繁に行うような企業では、元々簡単なテキストか独自のフォーマットで行ってきたわけです。
結局、XMLに移行しているのは変換コストは高いけど、社外・社内システム間(XMLを簡単に取り扱える製品が増えた)
でやり取りできる標準性を重視したからです。

この手のデータフォーマットは変換コストよりもそういった汎用性と標準性が選択の基準に重点が移っているので、
敢えてXMLからの更なる移行を検討するような企業はそう多くないと思うんですけどね。

結局Google並みの大規模・大量データがやり取りされるようなシステムくらい？

Re:何に使う？

[SteppingWind (2654)]

結局Google並みの大規模・大量データがやり取りされるようなシステムくらい？

あるいは資源に乏しい組み込み機器間の通信システムとか.

Re:何に使う？

[Anonymous Coward]

そもそも仕様自体が結構でかいのと、C++のライブラリが巨大で複雑すぎて常人には手に負えないようになってる。オブジェクトコードも多分巨大になるし、組み込み用途なら自分でそれっぽいの書いた方がいいと思う。

Re:

[Anonymous Coward]

CSVで十分なケースも多いし...

Re:

[Anonymous Coward]

ウチではXMLはiniファイルやconfigファイルの代替です

Re:

[Anonymous Coward]

それなんてStruts？

＃に限らずJavaプログラムでそういうの多いよね。

Re:

[Anonymous Coward]

複雑な構造をスキーマでかっちり決められる利点は何者にも代え難い。

Re:

[Anonymous Coward]

そのコストは無闇に高い気はするけどね。

Re:

[Anonymous Coward]

>P2Pのデータって動画や音楽などのbinaryデータがほとんどだから

P2Pと聞いてWinnyやShareしか思い浮かばない人は消えて下さいまし。

Re:何に使う？

[Anonymous Coward]

ではBitTorrentはbinaryのやり取りが少ないと?
Skypeの音声やビデオはテキストにエンコードして通信ですか?

元コメの例の挙げ方は確かに半端だが否定するほどのものでもない

Re:

[Anonymous Coward]

Wikipediaの記述にもあるので、別に問題ないと思うけど。

http://ja.wikipedia.org/wiki/P2P#.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.... [wikipedia.org]

P2Pネットワークで最も一般的に共有されているファイルは人気のある音楽のmp3ファイルと映画のDivXコーデックを使ったAVIファイルである。 このような利用の実態から、P2Pネットワーク上の

Re:何に使う？

[Anonymous Coward]

P2P=ファイル共有ソフト じゃないって言ってるんじゃないの？

そのWikipediaの項目にも

> 一方、P2Pとして、WinMXやWinny、Napsterなど、インターネットにつながった
> コンピュータ間で自由に、そしてある程度匿名的にファイルを転送できる機能を
> 持ったファイル共有ソフトによるネットワークを指していう誤用も見受けられる。

と言う記述もあるし

P2Pネットワークで最も一般的に共有されているうんぬんってのは
「ファイル共有ネットワークの法的問題」っていう
ファイル共有ネットワークについてだけに言及した部分だよね？

Re:

[Anonymous Coward]

xmlとかのtree構造のデーターは複数のテーブルを結合した結果を返却する場合に有効。
p2pのクエリと結果なんてテーブル一個程度のシンプルなモノだと思うんだけど。
（ライブラリで楽チンする以外ならばcsvの仕事だと思う）

binaryデーターと言うより、ペイロードが大きいからオーバーヘッドが相対的に小さくなるって話だよね？

科学関係のひとも注目しているようです

[chibaz (35131)]

Google Open-Sources Protocol Buffers: High-Performance Data Serialization | MacResearch [macresearch.org]

Obviously, Google didn't have science in mind when they created Protocol Buffers, but it sounds like it could be an interesting option for working with scientific data. It would be nice to eventually see support for Fortran and other scientific languages, but for the time being Protocol Buffers can generate C++, Python, and Java.

「コストが高すぎる」？

[Anonymous Coward]

データが多いと特許料とかも高くなるの？

Re:「コストが高すぎる」？

[Anonymous Coward]

XMLは書くのはともかく読むのは重い処理なんだよ。

流行っちゃったから皆仕方なく使ってるけど別に効率が良い訳でも筋が良い訳でもない。データ形式界のWindowsみたいなもんだ。

Re:

[Anonymous Coward]

Windows以外だとコストが下がるの？

Re:「コストが高すぎる」？

[vn (10720)]

違いがあるとしてもせいぜい iPhone 3G と Willcom D4 の違い程度でしかないから、
気にならない人は同一視しても構わない。

Re:

[Anonymous Coward]

>違いがあるとしてもせいぜい iPhone 3G と Willcom D4 の違い程度でしかないから、
>気にならない人は同一視しても構わない。

マークパンサーが何か言いたそう [fc2.com]にvn氏をみている！

Re:「コストが高すぎる」？

[oltio (3848)]

「計算コスト」(計算にかかる時間)とか「通信コスト」(通信にかかる時間など)とか、金銭じゃないコストもいろいろあるのよ。世間一般ではともかく、計算機や通信の世界ではよくある表現。

Re:「コストが高すぎる」？

[Anonymous Coward]

ここで言うコストというのは金銭的なものではなくて、処理するために必要な計算リソースという意味でしょう。XMLだと、やりたいことに対して必要なリソース(CPUやメモリ, 通信量など)が大きすぎると。
普段デスクトップパソコンを使ってるようなシチュエーションではXML処理にかけているリソースというのはあまり意識しませんが、Googleが行っているような大量のデータをやり取りするような用途では XMLを使うことがボトルネックになってくるのでしょう(そういう用途では、必要なサーバが増えたりなどといった金銭的なコストもかかってくるかも知れません)。
自分が経験した範囲では、携帯電話向けアプリの開発で当初XMLでデータを渡してたのですが、データ量が多くなるとパース処理が重たくて使い物にならないということで急遽簡単なフォーマットに変換して渡すように仕様変更したりとかあります。
＃使ってたXMLパーサの品質が悪いからってのもあるんでしょうが、XMLパーサの品質改良には
＃それこそコストがかかりそうだったので。

＃ネタなのでAC

何がやりたいんだろう？

[Anonymous Coward]

誰かが「これ、ほしいからオープンソースにして」といった？
ニーズが無いところへの提供・提案だとしたら、
Googleにとっての狙い・メリットは何だろう？

Re:何がやりたいんだろう？

[vn (10720)]

• 我が社の高い技術力を世間にアピールする。

というありがちな動機は Google の場合にはあまり働かないと考えられるので、

• タダ乗りと批判されないように OSS コミュニティに成果を還元する。
• 補完的なソフトウェアを書いてくれる社外の開発者を歓迎する。あるいは採用するかも知れない。
• もしかしたら協業のため技術開示したい相手がいて、NDA やら何やら考えるよりもオープンソースにする方がメリットが大きいと考えた(かも知れない。)

Re:何がやりたいんだろう？

[yamajaki (13288)]

「この技術を使ったイケてる企業が誕生した場合,買収後の移行作業が楽になるから．」

ってのはありそうです.

Re:

[Anonymous Coward]

ぱっと思いつくのは、Googleとやり取りするデータフォーマットをこのフォーマットにできるとか。
(Googleとしては、XMLによるゲートウェイを用意しなくていい)

Re:

[Anonymous Coward]

特許かなあ。

取得済みなのかも。

XMLのコストが高いのはわかるが

[Anonymous Coward]

こういうのはもうお腹いっぱい

Re:

[Anonymous Coward]

> こういうのはもうお腹いっぱい

君のお腹が一杯になると、何か解決するの？
君の許容量が低いだけ？

恐らく、こういったのはシステム全体を含めた上手い解決策がでるまで、
何回でも何年でもやり続ける作業だと思います。
その解決策が使えるのは、せいぜい数年かもしれませんが…

Re:XMLのコストが高いのはわかるが

[Anonymous Coward]

しかし，似たようなものがたくさん出てきても前に進んでいる気がしないんだよね．
YAML や JSON じゃだめなの？ 正直，XDR とか ASN でもいいと思うんだけど…

XML 対 非XML という対比については分かりやすいのだけど，非 XML 同士では流派の
違いというか，審美観の問題になっている気がするです．

Re:XMLのコストが高いのはわかるが

[deleted user (18918)]

エンコードを見ると目からうろこが落ちるかもよ？
プロトコルバッファはVariant型でデータ長を持たない可変長の符号化を行ってる点で他のどれよりも短いデータ長になるから、データが１バイトでも短いとスループットが大きく変わるくらい流量の多いシステムではかなりコスト減につながってると思うぜ。
符号化・復号化時の速度低下も小さそうだし、このあたりはうまいね。
他のじゃこうはいかない。どれもデータかライブラリか仕様が太ってる。

Re:XMLのコストが高いのはわかるが

[Stealth (5277)]

このエンコード方法だとデータサイズが 7 * 32bit や 7 * 64bit などを超えた段階で「他のどれよりも短いデータ長」と言うのは無理が出てきませんか? 単純に長さの情報 + バイナリ列の方がトータルサイズが短くなってしまいます。

ある程度のサイズになると、同じ方式で「データバイト長を」エンコードして、その後実データをバイナリ列で付加した方が全データ長は短くなるように思えるのですが。

もちろん、データの性格 (流すデータの各フィールド長が短いものがどれだけ多いか等) で総データ長に差が出てくるので、小さいデータが大半を占める場合にはトータルで短くなると思いますが。

Re:XMLのコストが高いのはわかるが

[deleted user (18918)]

> このエンコード方法だとデータサイズが 7 * 32bit や 7 * 64bit などを超えた段階で「他のどれよりも短いデータ長」と言うのは無理が出てきませんか?

そもそも64ビットを超えません。ただ「どれよりもは」ちょっと言いすぎだったかもね。サイズの面ではASN.1のPERではメッセージの定義しだいで一長一短だし。
でも速度サイズ比ではプロトコルバッファが優勢じゃないかな。サイズでASN.1 PERが勝つ場合はビット操作の回数がかなり多そうだ。

Re:

[Anonymous Coward]

> プロトコルバッファはVariant型でデータ長を持たない可変長の符号化を行ってる点で

Varintな

XMLもコンパイルなり前処理して受け渡しすれば軽くもなりそうだが…

Re:

[Anonymous Coward]

もしかして: Variant

Re:XMLのコストが高いのはわかるが

[Anonymous Coward]

何を言っているのかよくわからんのだが、用語としてはvarintが正しい。

To understand your simple protocol buffer encoding, you first need to understand varints. Varints are a method of serializing integers using one or more bytes. Smaller numbers take a smaller number of bytes. [google.com]

まとめとくと

• データ型は可変長整数のvarint、固定長の整数と浮動小数、可変長の文字列だけ。
• varintはデータ7ビットと終端フラグ1ビットを1バイトにエンコードしたものの繰り返し。データ長は持たない。
• 文字列はデータ長もエンコードする。
• フィールド番号もエンコードする。あとから追加されて自分の知らないフィールドは無視できる。
• データの解釈はスタブジェネレータにお任せ。

Re:XMLのコストが高いのはわかるが

[fcp (32783)]

Protocol buffers は拡張性を持った方法でデータを小さく高速に符号化するための方式です。 YAML [yaml.org] の目的は拡張性と可読性、 JSON [ietf.org] の目的は JavaScript の式として解釈できることで、どちらも目的が違います。端的な違いとして、 YAML や JSON では符号化後のデータがテキストですが、 protocol buffers では符号化後のデータがバイナリーです。

XDR とか ASN.1 とかは名前しか知りません。誰か protocol buffers がこれらと比較してどうなのか教えてください。

Re:XMLのコストが高いのはわかるが

[Anonymous Coward]

> XDR とか ASN.1 とかは名前しか知りません。誰か protocol buffers がこれらと比較してどうなのか教えてください。

どちらもCで使われるデータ構造(struct含む)に毛が生えたようなものをそのままシリアライズしているので、
スキーマが存在しません。
それでだめだったんでしょう。

Re:XMLのコストが高いのはわかるが

[fcp (32783)]

どちらもCで使われるデータ構造(struct含む)に毛が生えたようなものをそのままシリアライズしているので、
スキーマが存在しません。
それでだめだったんでしょう。

もしよければ、「スキーマが存在しないので駄目」というのをもう少し詳しく教えてもらえないでしょうか。

protocol buffers は、プログラムのバージョンが上がって新しい形式のデータと古い形式のデータを話すプログラムが混在しても大丈夫なように設計されているようです。 XDR や ASN.1 はそうなっていないという意味でしょうか。

Re:XMLのコストが高いのはわかるが

[fcp (32783)]

説明ありがとうございます。よくわかりました。スキーマと聞いてフィールド名や型の情報を連想してしまい、そんなの protocol buffers でも送信されないよなあ、もしかして .proto ファイルのことか? などと少し混乱しかけていました。

スキーマというほどのものではないですが、protocol buffersではすべてのデータにはフィールド番号がついていますので、
フィールドが変更されても「知らないフィールドは素通しする」で互換性は取れると思います。

たしかにそうですね。

いずれにしろ8ビット機時代を思わせる原始的なフォーマットですが、十分実用的で高性能というのはなかなか気の利いた話で、
Googleのような影響力のあるところが公開したのは喜ばしいことだと思います。

今までも小型で高性能で拡張性のあるシリアライズ方式が必要な場面ではあちこちで似たようなシリアライズ方式が考案されコードが書かれてきたのでしょうから、 protocol buffers の方式とコードが公開されてすぐに何かに活用されるかどうかはわかりませんが、方式やコードを自前で用意する代わりに公開されているものを採用するという選択肢が増えるのは良いことだと思います。

Re:XMLのコストが高いのはわかるが

[deleted user (18918)]

> 私の記憶が確かならば、XDRやASN.1は構造体のフィールド名などは保持せず、ただのシリアライズだったはずです。
これではフィールドが変更されると互換性がなくなるでしょう。

ASN.1では抽象構文自体にメッセージの将来的拡張の可能性を明記するので、拡張後のデコーダなら拡張前とはデータに互換性があり、逆の場合は非互換です。

> protocol buffersではすべてのデータにはフィールド番号がついていますので、
フィールドが変更されても「知らないフィールドは素通しする」で互換性は取れると思います。

プロトコルバッファのプロトコル定義構文からはフィールド番号を指定できないので、メッセージ中の追加フィールド挿入位置により、それより後ろの既存フィールドのフィールド番号が必ずずれると考えていいので、フィールド番号は互換性維持に使えないと思っていいんじゃないかな。メッセージ番号が存在しないのでフィールド番号はどのメッセージのデータかを判別するために使用する物だと思うよ。
（公開されているジェネレータを使わずにエンコードだけ借りるなら話は別だけど）

Re:XMLのコストが高いのはわかるが

[fcp (32783)]

protocol buffers のドキュメントを斜め読みしてみました。

> protocol buffersではすべてのデータにはフィールド番号がついていますので、
フィールドが変更されても「知らないフィールドは素通しする」で互換性は取れると思います。

プロトコルバッファのプロトコル定義構文からはフィールド番号を指定できないので、メッセージ中の追加フィールド挿入位置により、それより後ろの既存フィールドのフィールド番号が必ずずれると考えていいので、フィールド番号は互換性維持に使えないと思っていいんじゃないかな。メッセージ番号が存在しないのでフィールド番号はどのメッセージのデータかを判別するために使用する物だと思うよ。

何か誤解しているように思います。 .proto ファイルの language guide [google.com] によれば、 .proto ファイルでは各フィールドに明示的にタグ (メッセージ中のフィールドを識別する番号) を指定します。 #1383160 [srad.jp] の人が「フィールド番号」と呼んでいるものは protocol buffers のタグと同一だと思います。デコーダーは符号化されたデータの中のタグを見て、自分の知らないタグが付いたフィールドをスキップするようで、これによって将来フィールドが追加された場合に新しいデータを古いデコーダーに読ませても大丈夫になっているようです。

また、 protocol buffers のタグは一つのメッセージの中でしか一意でないので、タグを見てメッセージを判別することはできません。デコーダーを呼び出す前に、これから復号しようとするメッセージの型を知っている必要があります。

Re:

[Anonymous Coward]

> JSON [ietf.org] の目的は JavaScript の式として解釈できる

ホントにそれが目的？
そうか！JavaScript なら eval すればオブジェクトのデコードができるものね。
すごいねっ

Re:XMLのコストが高いのはわかるが

[fcp (32783)]

> JSON [ietf.org] の目的は JavaScript の式として解釈できる

ホントにそれが目的？
そうか！JavaScript なら eval すればオブジェクトのデコードができるものね。

はい。

すごいねっ

まあ、 JavaScript はスクリプト言語なので、それくらいのことはできて当然というのが僕の印象ですが……。

Re:

[Anonymous Coward]

ごめん、皮肉のつもりだったんだ…

Re:

[Anonymous Coward]

皮肉るのはかまわないんだけど、ちゃんと問題点だけは指摘してほしいな。

設問が難問なほど、皮肉ってのは生きるものだよ？

Re:eval

[fcp (32783)]

信頼できないデータを eval するのはセキュリティー上問題があるというのはもちろんですが、僕の元コメント (#1382507) [srad.jp] に対する批判としては的外れです。 #1382507 では、リンクを張った RFC 4627 の 1 節にも書いてある「JSON の design goal は JavaScript のサブセットにすること」という事実を書いただけなので。ただ、 design goal を「目的」と訳したのは不適切だったかもしれません。

RFC 4627 の 1 節より:

JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript.

また、 RFC 4627 の 6 節を読めば JSON の設計において eval を使って復号できることが意図されていることがわかります。

A JSON text can be safely passed into JavaScript's eval() function (which compiles and executes a string) if all the characters not enclosed in strings are in the set of characters that form JSON tokens. This can be quickly determined in JavaScript with two regular expressions and calls to the test and replace methods.

var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
       text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
   eval('(' + text + ')');

個人的な好みを書けば、僕は eval が嫌いなので、データが信頼できてもできなくても eval で復号するのは嫌いです。また、信頼できないデータについては、 6 節に書いてあるようなテストで JavaScript の将来のバージョンにわたって安全性が保証されるとも思えませんし。

Re:eval

[fcp (32783)]

> Protocol buffers は拡張性を持った方法でデータを小さく高速に符号化するための方式です。
> ... JSON の目的は JavaScript の式として解釈できることで、どちらも目的が違います。

> JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript.

JSON の目的として「minimal, portable, textual」という事実はなかったことに？
比較するときに，明らかに違うところだけに目を向けてもあまり意味がないのでは…

誤解です。 #1382507 [srad.jp] の書き方が少しわかりにくかったのは認めます。 #1382507 の

YAML [yaml.org] の目的は拡張性と可読性、 JSON [ietf.org] の目的は JavaScript の式として解釈できることで、どちらも目的が違います。

の部分を以下のように訂正すれば満足していただけるでしょうか。

YAML [yaml.org] は設計上の目標の一つに可読性を、 JSON [ietf.org] は設計上の目標の一つに JavaScript の式として解釈できることを掲げており、どちらも protocol buffers とは設計上の目標が違います。

でも、 #1382507 の当該部分が #1382417 [srad.jp] の

YAML や JSON じゃだめなの？

を受けて書かれていることは理解可能だと思うので、多少わかりにくかったという事実を前提としても、なぜこれほどまで誤解されるのか、よくわからなかったりします。