Kryo は非常に新しくて興味深いJavaシリアライゼーションライブラリであり、 thrift-protobuf ベンチマークで最速のライブラリの1つです。 Kryoを使用しましたが、実稼働コードでそれを試すのに十分な成熟度にすでに達していますか?
更新(2010/10/27):Kryoを使用していますが、まだ本番環境にはありません。詳細については、以下の私の回答を参照してください。
更新(2011年3月9日):最新のJacksonおよびKryoライブラリに更新すると、JacksonのバイナリSmileシリアル化がかなり競争力があることが示されます。
バグレポート と ディスカッションスレッド があります。 Kryoに付属するDateSerializerは、SOに掲載されているSimpleSerializer実装よりもサイズが効率的です。これは、正の値用に最適化されたLongSerializerを使用するためです。
編集:元の質問に答えるのを忘れました。 Kryoは少なくともいくつかの生産システムで使用されていると思います。この記事でそれについて言及しています Jive SBSキャッシュの再設計:パート 。 Destroy All Humans プロジェクトでは、Kryoを使用してAndroidロボットの脳として機能する電話( ビデオはこちら )と通信します。
直接的な回答ではありませんが、 Kryo source または javadocs を参照できます。 Kryoクラスのread *メソッドとwrite *メソッドを確認してから、Serializerクラスを確認してください。これは本当にライブラリの中核です。
私は自分の質問に答えようとします(Kyroはまだ非常に新しいです!)。
Restletフレームワーク を使用して実装された約120の異なるWebサービスのセットがあります。これらは、通常Restletベースのクライアントライブラリの上に構築されたWebサービスクライアントによって使用されます。サーバーとクライアントの間でやり取りされる表現には、XML( XStreamシリアル化ライブラリ を使用)、JSON( Jackson を使用)、 XHTML、 Java Object Serialization 、そして昨日現在、 Kryo 。ですから、しっかりと並べて比較することができます。
Kryo 1.0.1はかなり安定しているようです。 APIの使用方法を実際に読んだ後、私が見つけた唯一の本当の問題は、デフォルトのJava.util.Dateシリアライザーが過去数ヶ月の日付を歪めているように見えることでした。私は自分のオーバーライドを提供する必要がありました:
kryo.register(Date.class,
new SimpleSerializer<Date>() {
@Override public void write (ByteBuffer b, Date d) { b.putLong(d.getTime()); }
@Override public Date read (ByteBuffer b) { return new Date(b.getLong()); }
});
しかし、それが私がこれまでに見つけた唯一の可能な問題でした。 String、Float、Integer、Long、Date、Boolean、およびListフィールドを持つJavaBeansのセットがあります。
大まかなベンチマークは次のとおりです。最初に、1つのテレビ番組を記述するオブジェクト階層の10万回のシリアル化と逆シリアル化を行いました(つまり、100,000の深いコピーを作成しました)。速度は:
XStream XML: 360/sec
Java Object Serialization: 1,570/sec
Jackson JSON: 5,000/sec
Kryo: 8,100/sec
次に、2,000のテレビ番組の説明とカウントされたバイトのカタログもシリアル化しました。
XStream XML: 6,837,851 bytes
Jackson JSON: 3,656,654 bytes
Kryo: 1,124,048 bytes
また、シリアライザの登録が非常に重要であることもわかりました。
kryo.register(List.class);
kryo.register(ArrayList.class);
// ...
kryo.register(Program.class);
kryo.register(Catalog.class);
// ...
それを行わなかった場合、シリアル化のサイズはほぼ2倍になり、速度はおそらく40%遅くなりました。
また、これらの4つのシリアル化方法のそれぞれを使用して、いくつかのWebサービスの完全なエンドツーエンドテストを実行し、Kryoが他の方法よりも高速に実行されていることも示しました。
したがって、要約すると、Kryoはかなり堅牢なようです。私はコードベースでそれをサポートし続けるつもりであり、それを経験するにつれて、それをより多くの場所で使用したいと思っています。 Kryoチームへの称賛!
更新(2011年3月9日):最後に、@ StaxManの提案に従って、Jackson 1.6のバイナリ「Smile」シリアライザを試してみました。 Jackson 1.6とKryo 1.04を使用して、やや異なるTV番組オブジェクト階層の100,000ディープコピー(シリアル化/逆シリアル化)を実行しました。
XStream XML: 429/sec 5,189 bytes
Jackson JSON: 4,474/sec 2,657 bytes
Kryo: 4,539/sec 1,066 bytes
Jackson Smile: 5,040/sec 1,689 bytes
このテストは、マクロレベルのテストと一致しませんでした。RESTこれらのオブジェクトの多くを提供するWebサービスでさまざまなシリアライザーを試しました。全体的なシステムスループットは、パフォーマンスに関する@StaxManの直感をサポートしています:
Jackson JSON: 92 requests/sec
Jackson Smile 97 requests/sec
Kryo: 108 requests/sec
KryoはYahooのS4(Simple Scalable Streaming System)プロジェクトの一部です。 S4は、私が知る限り、まだプロダクションではありません。
上記のJim Ferransの応答とコメントを利用して、このページでKryoの日付のシリアル化の問題に関する詳細な説明を見つけました: http://groups.google。 com/group/kryo-users/browse_thread/thread/91969c6f48a45bdf / およびKryoのDateSerializer()の使用方法:
kryo.register(Date.class、new DateSerializer());
これが他の人の役に立つことを願っています。
Kryoの最新バージョンには、極端な場合にいくつかの競合状態があり、Javaからns-3へのシミュレータインターフェイスで実行されます。問題がなければ、私の変更の一部をコミットするように開発者に依頼するかもしれません。
Apache Stormは、メッセージをあるタスクから別のタスクに渡す前に serialization に使用します。
ですから、ストームは いくつかの巨大企業 、つまりTwitterやSpotifyで使用されているため、非常に安定している必要があります。
Kryo 2.xはMule ESBでも使用されており、生産で広く使用されています。
Kryoサイトには Kryoを使用した本番環境のプロジェクト に関するセクションがあります。
2017年の更新:
KryoはFlinkで使用されます。つまり、Flinkフレームワークを使用しているものはすべて、Kryoに依存しています。リファレンス: https://ci.Apache.org/projects/flink/flink-docs-release-0.8/programming_guide.html#specifying-keys