6
  1. それらのそれぞれが一意のキー（外部キーイングシステムによって生成および適用される）を持つことが保証されている場合、どのマップ実装が私に適していますか？これは同時ルックアップのみに最適化する必要があると想定します（データはアプリケーションの起動時に1回初期化されます）。
  2. この3億の一意のキーは、バケット化/衝突にプラスまたはマイナスの影響を及ぼしますか？
  3. 他に何か提案はありますか？

私の地図は次のようになります

Map<String, <boolean, boolean, boolean, boolean>>
4

4 に答える 4

3

私は地図を使用しません、これは多くのメモリを必要とします。特にあなたの場合。値を1つのデータ配列に格納し、キーをソートされたインデックス配列に格納します。ソートされた配列で、binSearchを使用してdata[]内のキーの位置を検索します。

トリッキーな部分は、メモリを使い果たすことなく、アレイを構築することです。

データから読み取るだけなので、同意を考慮する必要はありません

さらに、文字列をキーとして使用しないようにしてください。それらをlongに変換してみてください。
このソリューションの利点：検索時間はlognを超えないことが保証されています。キーがハッシュコードに問題を起こす最悪の場合でも

于 2013-01-26T16:37:07.223 に答える
3

他の提案？あなたは賭けます。

適切なKey-Valueストアを使用してください。Redisが最初に思い浮かぶオプションです。確かにそれは別のプロセスと依存関係ですが、適切なシステム設計に関しては大きな時間を稼ぐことができます。

たとえそれが一時的であっても、ビジネスロジックを同じプロセスメモリ内の複数のギグのデータと結合したいという非常に正当な理由があるはずです。私はこれを数回試しましたが、常に間違っていることが証明されました。

于 2013-01-26T16:49:29.243 に答える
0

ソートされた構造のため、データ検索TreeMapができるので、簡単に使用できるように思えます。O(log(n))さらに、あなたが言ったように、すべてのデータが起動時にロードされるので、それは適格な方法です。

于 2013-01-26T16:54:28.333 に答える
0

すべてをメモリに保持する必要がある場合は、巨大なコレクションなど、これらの量の要素で使用することを目的としたライブラリを使用する必要があります。その上、書き込みの数が多くなる場合は、ノンブロッキングハッシュマップのようないくつかのより洗練されたソリューションについても考える必要があります

于 2013-01-26T17:13:34.603 に答える