🤵🏽 👊 👩‍❤️‍👨 データのシリアル化または通信弁証法：単純なシリアル化 🧓🏾 🏂🏾 🤘🏾

こんにちはこの記事では、最も一般的なデータシリアル化形式を調べ、それらを使用していくつかのテストを行います。これはデータシリアル化のトピックに関する最初の記事であり、開発者がコードを大幅に変更して統合する必要のない単純なシリアライザーについて検討します。

遅かれ早かれ、しかし、あなたは私たちの会社のように、あなたの製品で使用されるサービスの数が劇的に増加する状況に遭遇するかもしれません。これが今日の「誇大広告」マイクロサービスアーキテクチャへの移行が原因で起こったのか、それとも小規模な改善の注文を受けて、それを一連のサービスで実装したのかは問題ではありません。重要なことは、この瞬間から、製品に2つの新しい問題が発生したことです。別々のサービス間でデータ量が増えた場合の対処方法、および多数のサービスの開発とサポートにおける混乱を防ぐ方法です。 2番目の問題について少し説明しましょう。サービスの数が数百以上になると、1つの開発チームがサービスを開発およびサポートできなくなるため、サービスのバンドルを異なるチームに配布します。ここで重要なのは、これらすべてのチームがRPCに同じ形式を使用していることです。そうしないと、一方のチームが他方のサービスをサポートできない場合や、松葉杖とのジャンクションを十分に圧縮しないと2つのサービスだけが合わない場合に、このような古典的な問題が発生します。しかし、これについては別の記事で説明し、今日はデータの増加という最初の問題に注意を払い、それについて何ができるかを考えます。そして、正統派の怠lazのために、私たちは何もしたくありませんが、一般的なコードに数行を追加して、すぐに利益を得たいと思っています。この記事では、これから始めます。つまり、シリアライザを検討します。シリアライザの埋め込みには、美しいRPCでの大きな変更は必要ありません。

実際、現在の製品ではxml形式を使用してコンポーネント間で情報を交換しているため、形式の問題は当社にとってかなり苦痛です。いいえ、私たちはマゾヒストではありません。データ交換にxmlを使用するのは10年前に価値があったことを理解していますが、これがまさにその理由です。製品はすでに10年前で、。少し検討し、ホリバリブした後、データの保存と送信にJSONを使用することにしましたが、送信されたデータのサイズが重要であるため、JSONパッケージングオプションを選択する必要があります（その理由を以下で説明します）。

私たちは私たちに合った形式を選択する基準のリストをまとめました：

データ圧縮の有効性。当社の製品は、さまざまなソースからの膨大な数の入力イベントを処理します。各イベントは、何らかのユーザーアクションによってトリガーされます。基本的に、イベントは小さく、何が起こっているかに関するメタ情報を含んでいます-手紙を送ったり、Facebookで何かをチャットしたりなど。 -しかし、データを含むこともあり、かなり大きなサイズです。さらに、このようなイベントの数は非常に多く、1日に数十TBを簡単に送信できるため、イベントのサイズを節約することが重要です。
異なる言語で作業する能力。新しいプロジェクトはC ++、PHP、およびJSを使用して記述されているため、これらの言語のサポートにのみ関心がありましたが、マイクロサービスアーキテクチャにより異種開発環境が可能になるため、追加の言語のサポートが役立ちます。 goは私たちにとって非常に興味深いものであり、いくつかのサービスが実装される可能性があるとしましょう。
バージョン管理/進化するデータ構造のサポート。当社の製品は顧客から更新されることなく長期間存続するため（更新プロセスはまったく単純ではありません）、ある時点でサポートに多すぎるバージョンが存在し、互換性を失うことなくストレージフォーマットを簡単に開発できることが重要です既にパックされたデータ。
使いやすさ。 Thriftプロトコルを使用してコンポーネント間の通信を構築した経験があります。正直なところ、開発者がRPCがどのように機能し、古いコードを壊すことなく既存のコードに何かを追加する方法を理解することは必ずしも容易ではありません。したがって、シリアル化形式を使用する方が簡単であるほど、C ++開発者とJS開発者のレベルは完全に異なるため、より優れています:)
データをランダムに読み取る機能（ランダムアクセス読み取り/書き込み）。また、データストレージに選択された形式を使用することを意味するため、データ全体の読み取りを行わないようにデータの部分的な逆シリアル化の可能性をサポートすることは素晴らしいことです。データの読み取りに加えて、大きなプラスは、すべてのコンテンツを差し引くことなくデータを変更できることです。

適切な数のオプションを分析した後、次の候補を選択しました。

ジョンソン
BSON
メッセージパック
Cbor

これらの形式では、送信データのIDLスキームの説明は必要ありませんが、データスキームが含まれています。これにより作業が大幅に簡素化され、ほとんどの場合、10行以下のコードを記述するだけでサポートを追加できます。

また、プロトコルまたはシリアライザーのいくつかの要因がその実装に大きく依存していることも十分に認識しています。 C ++でうまく機能するものは、Javascriptではうまく機能しない可能性があります。したがって、実験では、JSとGoの実装を使用し、テストを実行します。ブラウザとnodejsの忠実性のためにJS実装を推進します。

それでは、検討に移りましょう。

ジョンソン

検討中の最も単純な相互作用形式。他の形式を比較するときは、現在のプロジェクトでその効果を示し、すべての欠点を示したため、参照として使用します。

長所：

必要なほぼすべてのデータ型をサポートします。バイナリデータがサポートされていないことに不満を言うかもしれませんが、ここではbase64を省くことができます。
人が読みやすいため、デバッグが簡単
たくさんの言語でサポートされています（ただし、GoでJSONを使用した人は、ここでunningしていることを理解します）
JSONスキームを介してバージョン管理を実装できます

短所：

JSONはxmlと比較してコンパクトであるにもかかわらず、1日にギガバイトのデータが送信されるプロジェクトでは、チャネルとその中にデータを保存するのは依然としてかなり無駄です。ネイティブJSONの唯一のプラスは、ストレージにPostgreSQLを使用することだけです（jsobを操作する機能を備えています）。
部分的なデータの逆シリアル化はサポートされていません。 JSONファイルの途中から何かを取得するには、最初に目的のフィールドの前にあるすべてをデシリアライズする必要があります。また、これにより、ストリーム処理にフォーマットを使用できなくなります。これは、ネットワーク通信に役立つ場合があります。

パフォーマンスで何が得られるか見てみましょう。検討する際には、すぐにJSONのサイズの不足を考慮に入れ、zlibを使用してJSONパッキングでテストを行います。テストでは、次のライブラリを使用します。

http://nodeca.github.io/pako/-JSで JSONをパッケージ化するため
http://github.com/klauspost/compress-Goで JSONをパックするため
http://github.com/pquerna/ffjson-GoのJSONシリアライザーとして

ソースとすべてのテスト結果は、次のリンクにあります。

Go- https://github.com/KyKyPy3/serialization-tests

JS（ノード） -https://github.com/KyKyPy3/js-serialization-tests

JS（ブラウザ） -http://jsperv.com/serialization-benchmarks/5

経験的に、異なるテストデータでのテスト結果は劇的に異なるため、テストのデータは実際のデータにできるだけ近づける必要があることがわかりました。そのため、形式を見逃さないことが重要な場合は、常に現実に最も近いデータでテストしてください。現実に近いデータでテストします。テストソースでそれらを見ることができます。

JSONで得られたものは次のとおりです。以下は、各言語のベンチマーク結果です。

JS（ノード）
JSONエンコード	21,507 ops /秒（86回のサンプリング）
JSONデコード	9,039 ops /秒（89回の実行がサンプリングされました）
ジョンソン往復	6.090 ops /秒（93回のサンプル実行）
JSON圧縮エンコード	1,168 ops /秒（84回の実行をサンプリング）
JSON圧縮デコード	2,980 ops /秒（93回の実行サンプリング）
Json Compres往復	874 ops /秒（86回のサンプル実行）

JS（ブラウザ）
ジョンソン往復	5,754 ops /秒
Json Compres往復	890 ops /秒

行く
JSONエンコード	5000	391100 ns / op	24.37 MB /秒	54520 B / op	1478 allocs / op
JSONデコード	3000	392785 ns / op	24.27 MB /秒	76634 B / op	1430割り当て/ op
ジョンソン往復	2000年	796115 ns / op	11.97 MB / s	131150 B / op	2908 allocs / op
JSON圧縮エンコード	3000	422254 ns / op	0.00 MB /秒	54790 B / op	1478 allocs / op
JSON圧縮デコード	3000	464569 ns / op	4.50 MB /秒	117206 B / op	1446 allocs / op
Json Compres往復	2000年	881305 ns / op	0.00 MB /秒	171795 B / op	2915 allocs / op

そして、データサイズに関しては次のようになりました。

JS（ノード）
ジョンソン	9482バイト
圧縮されたJSON	1872バイト

JS（ブラウザ）
ジョンソン	9482バイト
圧縮されたJSON	1872バイト

この段階で、JSON圧縮は優れた結果をもたらしますが、処理速度の低下は単に悲惨であると結論付けることができます。別の結論：JSはJSONで正常に機能しますが、たとえばgoについては言えません。他の言語でJSONを処理すると、JSに匹敵しない結果が表示される可能性があります。とりあえず、JSONの結果を脇に置き、他の形式でどのようになるかを確認してください。

BSON

このデータ形式はMongoDbからのものであり、積極的に推進しています。このフォーマットはもともとデータストレージ用に開発されたもので、ネットワーク経由での送信を目的としていませんでした。正直なところ、インターネットで簡単に検索した結果、BSONを内部で使用する深刻な製品は1つも見つかりませんでした。しかし、このフォーマットが私たちに何をもたらすかを見てみましょう。

長所：

追加のデータ型のサポート。

仕様によると、BSON形式は、JSON形式の標準データ型に加えて、Date、 ObjectId 、Null、Binaryデータなどの型もサポートしています。それらのいくつか（たとえば、ObjectId）は、MongoDbでより頻繁に使用され、他の人にとっては必ずしも役立つとは限りません。ただし、いくつかの追加のデータ型には、次のボーナスがあります。オブジェクトに日付を保存する場合、JSON形式の場合、保存オプションは1つだけです。これはISO-8601オプションの1つであり、文字列表現です。同時に、日付によってJSONオブジェクトのコレクションをフィルター処理する場合、処理中に文字列を日付形式に変換してから、それらを相互に比較する必要があります。一方、BSONはすべての日付を（日付型と同様に）Int64として保存し、日付形式でのすべてのシリアル化/逆シリアル化作業を処理します。したがって、デシリアライズなしで日付を比較できます-数字のように、クラシックJSONを使用したバージョンより明らかに高速です。この利点は、MongoDbで積極的に使用されています。
BSONは、データへのいわゆるランダム読み取り/書き込みをサポートしています。

BSONは文字列とバイナリデータの長さを保存するため、興味のない属性をスキップできます。 JSONはデータをシーケンシャルに読み取り、最後まで値を読み取らない限り、要素を見逃すことはできません。したがって、フォーマット内に大量のバイナリデータを格納する場合、この機能は重要な役割を果たすことができます。

短所：

データのサイズ。

最終的なファイルのサイズに関しては、すべてがあいまいです。状況によっては、オブジェクトのサイズが小さくなり、場合によっては、オブジェクトのBson内にあるものに依存します。なぜそうなのでしょうか？オブジェクトの要素へのアクセス速度のために、フォーマットは大きな要素のデータサイズなどの追加情報を保存するという仕様があります。

たとえば、JSONオブジェクト

{«hello": "world»}

これになります：

 \x16\x00\x00\x00 // total document size \x02 // 0x02 = type String hello\x00 // field name \x06\x00\x00\x00world\x00 // field value \x00 // 0x00 = type EOO ('end of object')

仕様では、少なくともInt型として数値を格納し、文字列からの解析に時間を無駄にしないという事実により、BSONは高速シリアル化/逆シリアル化を備えた形式として開発されたと述べています。見てみましょう。テストのために、次のライブラリを使用しました。

JS（ノードおよびブラウザー） -https://github.com/mongodb/js-bson
Go- https://github.com/go-mgo/mgo/tree/v2

そして、ここに得られた結果があります（わかりやすくするために、JSONの結果も追加しました）。

JS（ノード）
JSONエンコード	21,507 ops /秒（86回のサンプリング）
JSONデコード	9,039 ops /秒（89回の実行がサンプリングされました）
ジョンソン往復	6.090 ops /秒（93回のサンプル実行）
JSON圧縮エンコード	1,168 ops /秒（84回の実行をサンプリング）
JSON圧縮デコード	2,980 ops /秒（93回の実行サンプリング）
Json Compres往復	874 ops /秒（86回のサンプル実行）
Bsonエンコード	93.21 ops /秒（サンプリング数76回）
Bsonデコード	242 ops /秒（84回のサンプリングを実行）
Bson往復	65.24 ops /秒（65回の実行サンプリング）

JS（ブラウザ）
ジョンソン往復	5,754 ops /秒
Json Compres往復	890 ops /秒
Bson往復	374 ops /秒

行く
JSONエンコード	5000	391100 ns / op	24.37 MB /秒	54520 B / op	1478 allocs / op
JSONデコード	3000	392785 ns / op	24.27 MB /秒	76634 B / op	1430割り当て/ op
ジョンソン往復	2000年	796115 ns / op	11.97 MB / s	131150 B / op	2908 allocs / op
JSON圧縮エンコード	3000	422254 ns / op	0.00 MB /秒	54790 B / op	1478 allocs / op
JSON圧縮デコード	3000	464569 ns / op	4.50 MB /秒	117206 B / op	1446 allocs / op
Json Compres往復	2000年	881305 ns / op	0.00 MB /秒	171795 B / op	2915 allocs / op
Bsonエンコード	10,000	249024 ns / op	40.42 MB /秒	70085 B / op	982 allocs / op
Bsonデコード	3000	524408 ns / op	19.19 MB /秒	124777 B / op	3580割り当て/ op
Bson往復	2000年	712524 ns / op	14.13 MB / s	195334 B / op	4562 allocs / op

そして、データサイズに関しては次のようになりました。

JS（ノード）
ジョンソン	9482バイト
圧縮されたJSON	1872バイト
ブソン	112710バイト

JS（ブラウザ）
ジョンソン	9482バイト
圧縮されたJSON	1872バイト
ブソン	9618バイト

BSONは追加のデータ型の可能性を提供しますが、最も重要なのはデータを部分的に読み取り/変更する機能ですが、データ圧縮に関しては非常に残念であるため、さらに検索を続ける必要があります。

メッセージパック

次の表は、メッセージパックです。この形式は最近非常に人気があり、私はタランツールを選んでいたときに個人的にそれを知りました。

フォーマットWebサイトを見ると、次のことができます。

このフォーマットは、redisやfluentdなどの製品で積極的に使用されており、自信を持っていることがわかります。
大声で碑文を参照してください。これはJSONのようなものです。でも速くて小さい

これがどの程度真実かを確認する必要がありますが、最初に、この形式が提供するものを見てみましょう。

伝統的に、長所から始めましょう：

形式はJSONと完全に互換性があります

データをMessagePackからJSONに変換するとき、データが失われることはありません。たとえば、BSON形式については言えません。確かに、さまざまなデータ型には多くの制限があります。
1. 整数型の値は-（263）〜（264）–1に制限されています。
2. バイナリオブジェクトの最大長は（232）-1です。
3. 行の最大バイトサイズ（232）–1。
4. 配列内の要素の最大数は（232）-1以下です。
5. 連想配列の要素の最大数は（232）-1以下です。
データを揺さぶるのが得意です。

たとえば、{"a"：1、 "b"：2}は、JSONで13バイト、BSONで19バイト、MessagePackでわずか7バイトを占めています。
サポートされているデータ型を拡張できます。

MsgPackでは、独自の型システムを拡張できます。 MsgPackの型は数値でエンコードされ、-1〜-128の値は形式によって予約されているため（これは形式の仕様に記載されています）、0〜127の値を使用できます。データ。
膨大な数の言語でサポートされています。
RPCパッケージがあります（ただし、これは私たちにとってそれほど重要ではありません）。
ストリーミングAPIを使用できます。

短所：

部分的なデータ変更はサポートしていません。

BSON形式とは対照的に、MsgPackが各フィールドのサイズを保存していても、その中のデータの部分的な変更は失敗します。 JSON {"a"：1、 "b"：2}のシリアル化された表現があるとします。 Bsonは5バイトを使用して 'a'キーの値を格納します。これにより、値を1から2000（3バイトかかります）に問題なく変更できます。しかし、MessagePackはストレージに1バイトを使用し、2000は3バイトを使用するため、「b」パラメーターに関するデータをシフトせずに、「a」パラメーターの値を変更することはできません。

それでは、どれほど生産的で、データをどのように圧縮するかを見てみましょう。次のライブラリがテストに使用されました。

得られた結果は次のとおりです。

JS（ノード）
JSONエンコード	21,507 ops /秒（86回のサンプリング）
JSONデコード	9,039 ops /秒（89回の実行がサンプリングされました）
ジョンソン往復	6.090 ops /秒（93回のサンプル実行）
JSON圧縮エンコード	1,168 ops /秒（84回の実行をサンプリング）
JSON圧縮デコード	2,980 ops /秒（93回の実行サンプリング）
Json Compres往復	874 ops /秒（86回のサンプル実行）
Bsonエンコード	93.21 ops /秒（サンプリング数76回）
Bsonデコード	242 ops /秒（84回のサンプリングを実行）
Bson往復	65.24 ops /秒（65回の実行サンプリング）
Msgpackエンコード	4,758 ops /秒（79回のサンプリングをサンプリング）
Msgpackデコード	2,632 ops /秒（サンプリング91回）
Msgpack往復	1,692 ops /秒（91回の実行サンプリング）

JS（ブラウザ）
ジョンソン往復	5,754 ops /秒
Json Compres往復	890 ops /秒
Bson往復	374 ops /秒
Msgpack往復	1,048 ops /秒

行く
JSONエンコード	5000	391100 ns / op	24.37 MB /秒	54520 B / op	1478 allocs / op
JSONデコード	3000	392785 ns / op	24.27 MB /秒	76634 B / op	1430割り当て/ op
ジョンソン往復	2000年	796115 ns / op	11.97 MB / s	131150 B / op	2908 allocs / op
JSON圧縮エンコード	3000	422254 ns / op	0.00 MB /秒	54790 B / op	1478 allocs / op
JSON圧縮デコード	3000	464569 ns / op	4.50 MB /秒	117206 B / op	1446 allocs / op
Json Compres往復	2000年	881305 ns / op	0.00 MB /秒	171795 B / op	2915 allocs / op
Bsonエンコード	10,000	249024 ns / op	40.42 MB /秒	70085 B / op	982 allocs / op
Bsonデコード	3000	524408 ns / op	19.19 MB /秒	124777 B / op	3580割り当て/ op
Bson往復	2000年	712524 ns / op	14.13 MB / s	195334 B / op	4562 allocs / op
Msgpackエンコード	5000	306260 ns / op	27.36 MB /秒	49907 B / op	968 allocs / op
Msgpackデコード	10,000	214967 ns / op	38.98 MB / s	59649 B / op	1690割り当て/ op
Msgpack往復	3000	547434 ns / op	15.31 MB / s	109754 B / op	2658 allocs / op

そして、データサイズに関しては次のようになりました。

JS（ノード）
ジョンソン	9482バイト
圧縮されたJSON	1872バイト
ブソン	112710バイト
Msgpack	7628バイト

JS（ブラウザ）
ジョンソン	9482バイト
圧縮されたJSON	1872バイト
ブソン	9618バイト
Msgpack	7628バイト

もちろん、MessagePackは私たちが望むほどクールにデータを圧縮しませんが、少なくともJSとGoの両方で非常に安定して動作します。おそらく現時点では、これが私たちの仕事の最も魅力的な候補ですが、最後の患者を考慮することは残っています。

Cbor

正直なところ、この形式はその機能がMessagePackに非常に似ており、この形式はMessagePackの代わりとして開発されたようです。また、データ型拡張機能のサポートと完全なJSON互換性も備えています。違いの中で、私は任意の長さの配列/文字列のサポートのみに気付きましたが、私の意見では、これは非常に奇妙な機能です。この形式について詳しく知りたい場合は、Habr-habrahabr.ru/ post/208690に優れた記事があります。さて、Cborがどのようにパフォーマンスとデータ圧縮を備えているかを見ていきます。

次のライブラリがテストに使用されました。

そして、もちろん、考慮されるすべての形式を考慮した、テストの最終結果は次のとおりです。

JS（ノード）
JSONエンコード	21,507 ops /秒±1.01％（86回のサンプリング）
JSONデコード	9.039 ops /秒±0.90％（89回のサンプリング）
ジョンソン往復	6.090 ops /秒±0.62％（93回のサンプリング）
JSON圧縮エンコード	1,168 ops /秒±1.20％（サンプリング84回）
JSON圧縮デコード	2,980 ops /秒±0.43％（93回のサンプリング）
Json Compres往復	874 ops /秒±0.91％（86回のサンプリング）
Bsonエンコード	93.21 ops /秒±0.64％（サンプリング回数76回）
Bsonデコード	242 ops / sec±0.63％（サンプリング84回）
Bson往復	65.24 ops /秒±1.27％（65回のサンプリング）
Msgpackエンコード	4,758 ops /秒±1.13％（79回のサンプリング）
Msgpackデコード	2.632 ops /秒±0.90％（91回の実行サンプリング）
Msgpack往復	1,692 ops /秒±0.83％（サンプリング91回）
Cborエンコード	1,529 ops /秒±4.13％（89回のサンプリング）
Cborデコード	1.198 ops /秒±0.97％（88回のサンプリング）
Cbor往復	351 ops /秒±3.28％（77回の実行サンプリング）

JS（ブラウザ）
ジョンソン往復	5.754 ops /秒±0.63％
Json Compres往復	890 ops /秒±1.72％
Bson往復	374 ops /秒±2.22％
Msgpack往復	1,048 ops /秒±5.40％
Cbor往復	859 ops /秒±4.19％

行く
JSONエンコード	5000	391100 ns / op	24.37 MB /秒	54520 B / op	1478 allocs / op
JSONデコード	3000	392785 ns / op	24.27 MB /秒	76634 B / op	1430割り当て/ op
ジョンソン往復	2000年	796115 ns / op	11.97 MB / s	131150 B / op	2908 allocs / op
JSON圧縮エンコード	3000	422254 ns / op	0.00 MB /秒	54790 B / op	1478 allocs / op
JSON圧縮デコード	3000	464569 ns / op	4.50 MB /秒	117206 B / op	1446 allocs / op
Json Compres往復	2000年	881305 ns / op	0.00 MB /秒	171795 B / op	2915 allocs / op
Bsonエンコード	10,000	249024 ns / op	40.42 MB /秒	70085 B / op	982 allocs / op
Bsonデコード	3000	524408 ns / op	19.19 MB /秒	124777 B / op	3580割り当て/ op
Bson往復	2000年	712524 ns / op	14.13 MB / s	195334 B / op	4562 allocs / op
Msgpackエンコード	5000	306260 ns / op	27.36 MB /秒	49907 B / op	968 allocs / op
Msgpackデコード	10,000	214967 ns / op	38.98 MB / s	59649 B / op	1690割り当て/ op
Msgpack往復	3000	547434 ns / op	15.31 MB / s	109754 B / op	2658 allocs / op
Cborエンコード	20000	71203 ns / op	117.48 MB / s	32944 B / op	12割り当て/ op
Cborデコード	3000	432,005 ns / op	19.36 MB /秒	40216 B / op	2159 allocs / op
Cbor往復	3000	531434 ns / op	15.74 MB / s	73160 B / op	2171 allocs / op

そして、データサイズに関しては次のようになりました。

JS（ノード）
ジョンソン	9482バイト
圧縮されたJSON	1872バイト
ブソン	112710バイト
Msgpack	7628バイト
Cbor	7617バイト

JS（ブラウザ）
ジョンソン	9482バイト
圧縮されたJSON	1872バイト
ブソン	9618バイト
Msgpack	7628バイト
Cbor	7617バイト

コメントは、ここでは冗長であり、結果からすべてがはっきりと見えると思います-CBorは最も遅い形式であることが判明しました。

結論

この比較からどのような結論を導き出しましたか？少し考えて結果を見てみると、どの形式にも満足していないという結論に達しました。はい、MsgPackは非常に優れたオプションであることがわかりました：使いやすく非常に安定していますが、同僚と相談した後、JSONに基づいていない他のバイナリデータ形式（Protobuf、FlatBuffers、Cap'n proto、avro）を新たに見ることにしました。次の記事では、何をしたか、最終的に何を選んだかについて説明します。

投稿者：Roman Efremenko KyKyPy3uK

データのシリアル化または通信弁証法：単純なシリアル化

ジョンソン

BSON

メッセージパック

Cbor

結論

More articles: