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 がシリアル化されたオブジェクト、特にコレクションを格納する方法と関係がありますか?
潜在的な質問に対するいくつかの追加メモ:
- コレクションの更新も必要になるピザを後で追加する可能性があります。
- 多くのプロセスがこれらの操作を実行しようとしているため、基本的な ConcurrentMap ではなく、ChronicleMap を介してマップを共有する必要があります。