4

さて、問題の質問を説明するには...

数
百万のエントリで満たされた 1 つの Big DB テーブル (各エントリには「n」個の列がある場合があります)。

コンセプト：

Web インターフェイスに 2 つのリスト (例: "利用可能" と "選択済み") を表示したいと考えています。ユーザーがエントリをあるリストから別のリストに移動するとき、エントリの一意の ID (文字列の種類) をサーバーの「選択済み」という名前の「不明なデータ構造」に一時的に保存する必要があり、ユーザーが最後に送信をクリックしたときこのリストをさらに別のアプリケーションに渡します。

並べ替えとフィルタリングが DB に行われ、データの全量 (チャンク単位) が Java にロードされます。次に、すべてのエントリが選択されているかどうかがチェックされ、次に表示されるリストに追加されます。ウェブインターフェース。

for each entry{
  if(selected.contains(currentEntry.ID)){
    selectedList.add(currentEntry)
  }else{
    availableList.add(currentEntry)
  }
}

リスト selectedList と availableList は数百のエントリ (ユーザーに表示されるもの、最大 100 ～ 200 のエントリを持つページ) しか保持しないため、タイプ「エントリ」のリストで十分であり、私の並べ替えを保持します。

問題:
「選択された」構造は、何千もの ID を保持する必要があります (数百万に達する場合もあります)。

必要性:
ID が存在するかどうか (structure.contains(id)) を見つけるために高速アクセスが必要なので、確実にハッシュ構造を使用します。最小限のメモリ リソースを使用する構造が必要です。

不要:
削除時の優れたパフォーマンスは必要ありません。並べ替えは不要です。

4

5 に答える 5

1

多くのテストの後、すべてのハッシュ構造 (HashSet、LinkedHashMap など) がほぼ同じように機能することがわかりました。

200.000 要素を超えたときに、テストシステムへのオーバーフローの問題に直面し始めました (もちろん、ハードウェアなどに関係しています)。

DBテーブルを使用して選択したIDを保持し、結合を使用してDBから直接データを取得するソリューションに行く可能性があります（ソートとフィルタリングにdbを使用する方法のいずれか）

@DariusX に感謝します。「勝った」提案と、他のすべての人たちの助けに感謝します。

于 2013-05-03T12:26:35.557 に答える
1

HashSetのように高速にアクセスできるものです。

于 2013-04-26T12:24:42.530 に答える
1

を使用できますTreeSet。javadoc は、「基本的な操作 (追加、削除、および含む) に保証された log(n) 時間コストを提供する」と述べており 、ID に何かをリンクする必要がある場合は、HashMap

于 2013-04-26T12:25:43.437 に答える
0

HashSet高速アクセスを提供する必要があり、ほとんどの場合は一定時間アクセスになりますが、可能であれば、サンプル テストを実行して、数百万のエントリとデータセットの性質のために衝突が高すぎるかどうかを確認できます。

これは確かに最適なメモリ要件に対応していません。Java メモリに何百万ものエントリを保持すると予想されるサイズはどれくらいですか? フットプリントが非常に大きい場合 (数千 MB など)、分散キャッシュを検討するか、インデックス作成のアプローチを検討する必要があるかもしれません。

于 2013-04-26T12:48:51.353 に答える