問題タブ [chronicle-map]

本当に簡単な質問です。Chronicle Map 3X が一部の機能をエンジン製品に移行しているようです。ただし、エンジン自体は Map 2X に依存しています。どうすればそれらを一緒に使用できますか？私は何かが欠けていると思いますが、正確にはわかりません。

ChronicleMap のマルチマップに関するChronicleMap の GitHubには、間違いなく免責事項があります。

クロニクル マップは...

... 副次索引はありません。

マルチマップ。ChronicleMap<K, Collection<V>>as multimapを使用することは技術的には可能ですが、多くの場合、問題が発生します...

残念ながら、これは私の使用例の 1 つであり、(ChronicleMap を使用して) オフヒープ ストレージを使用するのが最も簡単な方法です。

ピザに関する私の問題を説明してみましょう。100,000 種類のピザがあります。各ピザには ID があり、さまざまなトッピングとクラストがたくさんあります。3 つのアクセス パターンがあります。

• IDでピザをくれ。
• 特定のトッピングのピザをすべて教えてください。
• 特定のクラストを持つすべてのピザを教えてください。

を使用してピザを簡単に保存できますChronicleMap<UUID,Pizza>。しかし、それは 1 つのアクセス パターンにすぎません。トッピングやクラストが一致するピザを見つけるために、すべてのピザを繰り返し処理する必要はありません。だから、私はのようなものを保存したいと思いChronicleMap<Topping,Collection<UUID>>ますChronicleMap<Crust,Collection<UUID>>。

次に、誰かがペパロニを含むすべてのピザを求めてきたら、トッピングの ChronicleMap を検索して一致するピザの UUID を取得し、次にメインのピザ マップを検索します。

しかし、上で引用した文書は私を怖がらせます。そのようなことがしばしばもたらすこれらの「問題」が何であるかを誰かが知っていますか? 私にとってはうまくいっているように見えますが、なぜこれを行うべきではないのでしょうか? ChronicleMap がシリアル化されたオブジェクト、特にコレクションを格納する方法と関係がありますか?

潜在的な質問に対するいくつかの追加メモ:

1. コレクションの更新も必要になるピザを後で追加する可能性があります。
2. 多くのプロセスがこれらの操作を実行しようとしているため、基本的な ConcurrentMap ではなく、ChronicleMap を介してマップを共有する必要があります。

次のようなものがあるとします。

この場合、長い[]が使用できないように見えるため

（field type class [Lnet.openhft.chronicle.core.values.LongValue; is not supported: not a primitive, enum, CharSequence or another value interface例外が発生しています）

奇妙に聞こえますが、私はsmthを見逃していますか? そのようなオブジェクトを操作するための最良のアプローチは何ですか? 独自のシリアル化を実装しますか?

間違っていたら訂正してください。しかし、同じパッケージ名のために同じプロジェクトで Map3 と Engine を使用しようとすると、問題が発生するように見えますか? それを行う方法はありますか？

PS サイド ノート - 依存関係の問題により、エンジン マスター ブランチ (少なくとも「デモ」モジュール) を現在コンパイルできないように見えますか?

これまでのところ、使いたいと思っていたことのほとんどに使用して成功してChronicleMapおり、ほとんどのデータセットは問題なく機能しています。私たちが持っているユースケースの 1 つは、それをマルチマップとして使用することで、そうすることでほとんどの問題をカバーします。Map<String,Set<Integer>>この場合は特にとして使用しています。ただし、いくつかの興味深い JVM クラッシュが発生しており、決定論的なパターンを見つけるのに苦労しているため、それらを回避できます。

したがって、すべてを に入れる前に、Set<Integer>全体ChronicleMapを JVM に持っているので、断片化を減らすために一度に書き込みます。完全にメモリ内にあるため、最大サイズと平均サイズを判断でき、を使用して適切なSet<Integer>サイズを簡単に設定できます。ほとんどの場合、これで問題なく動作します。ChronicleMapChronicleMapBuilder.averageValueSize

ただし、場合によっては、 のサイズがSet<Integer>平均から大きく外れると、JVM がクラッシュします。たとえば、平均サイズが 400 であっても、20,000 個の整数を含む外れ値セットが存在する可能性があります。400 個の整数のセットのシリアル化された平均サイズを使用してマップのサイズを変更することもできますChronicleMap。非常に大きなサイズのリストに到達するまで、問題なくデータが取り込まれ始めます。

問題は、平均からどれだけ逸脱できるかをどのように把握すればよいかということです。平均が実際に平均であることを望んでいましたが、それを超えるとJVMが停止する最大値があるようです。

大きなセットを小さなセットに分割するアルゴリズムを考案しました (たとえば、キーが AAA の場合、キーは AAA:1、AAA:2、... AAA:n になります)。分割セットのサイズは、平均サイズの 10 倍でした。つまり、平均サイズが 500 で、セットが 20,000 の場合、それを 4 つの 5,000 (500 * 10) 要素セットに分割します。

これはほとんどの場合うまくいきましたが、別の興味深いケースに遭遇し、この分割でさえ十分ではありませんでした。係数を平均サイズの 5 倍に減らしたところ、再び機能するようになりました...しかし、それが十分に小さいことをどのように確認できますか? ソースの問題を知ること、またはその原因を正確に特定する方法が最善の方法だと思いますが、残念ながら、なぜChronicleMapここで苦労しているのかわかりません。

また、FWIW、古いバージョンの 2.1.17 を使用しています。これが新しいバージョンで修正されたバグである場合、バグについて少し詳しく知りたいのですが、独自の手段 (セットを分割するなど) で回避できるかどうかを知りたいのですが、引き続き 2.1.17 を使用します (後でアップグレードします; ボートをあまり揺さぶりたくないだけです)。