あまりにも多くのメモリを使用せずに検索キャッシュを高速化

Question

私は380,000エントリのデータベースにアクセスする必要があります。私はDBへの書き込みアクセスを持っていない、私はそれを読むことができます。私はfirstnameでユーザーを検索するためにマップを使って検索機能を作った。 1 - DBのすべてをロードする 2 - すべてをMap<Charactere, ArrayList<User>>に保存します。アルファ文字を使用して、ファーストネームの最初の文字に従ってユーザーを格納します。

<A> {Alba, jessica, Alliah jane, etc ...} 
<B> {Birsmben bani, etc ...} 

誰かがユーザーを検索すると、私はすべてのユーザーを見つけるために、ArrayListの上で反復その後、FIRSTNAMEのfirstletterがタイプ取るとmap.get(firstletter)を使用しています。

地図私は推測するメモリ（380,000ユーザオブジェクト）に大きなスペースをとります。私はヒープサイズを大きくしなければならなかった 私はそれをより速くしたいです。より速くするために、firstnameをキーのキーとして使用します（同じファーストネームを持つ多くの人がいます）。

1 - Still use a map with firstname as key (increasing the heap size again?) 
2 - Use files on the disk instead of Map (Alba.dat will contain all Alba for example) and open the right file for each search. No need to incease the heap size, but are there any side effects? 

より良いものです：

私は2つの心の中で解決策を持っていますか？ （長所と短所）

Update with more info 

これは電話で私たちの顧客サービスを呼び出す顧客のデータベースです。電話を受ける人は、顧客名（通常は名字と姓）を使用して検索する必要があります。 Dbを使用すると検索が遅すぎます。私が実装した解決策は既にかなり速いです（dbを使って1/2秒対26秒）が、それを改善したいのです。

Answer 1

IMHO、私は多分、あなたがメモリ内のすべてのエントリをキャッシュする必要があると思いますが、それらの一部ではありません：

• 多分ちょうどリングバッファを使用するか、または
• より複雑な、とLFUキャッシュを実装するのが理にかなっています.LFUキャッシュは、最も頻繁にアクセスされるN個のアイテムを保持します。このようなキャッシュを実装するヒントについては、this questionを参照してください。

Answer 2

あなたのアプローチにはいくつかの問題があります。

• これは、ユーザーが番号が変更されないことを意味し、優れたアプリケーション設計では、ソフトウェアを変更することなく、任意の数のユーザで動作します
• それ現在の問題が唯一の問題であることを意味しています。実装が必要な次の要件が「発信者IDで検索」または「郵便番号で検索」の場合はどうなりますか？
それは、車輪の再発明され、現在のデータベース、インデックスまたは情報検索ソリューションを書き始めている
• （あなたはそれに名前を付けたいが）ゼロ
から

行うには正しいことは、ユーザーのデータをエクスポートすることです適切な検索機能を提供するデータベースエンジンに変換します。変更のタイムスタンプがある場合や、更新を傍受して検索インデックスに再適用できる場合は、エクスポート/抽出を高速化することができます。

検索に使用するものはあまり重要ではありませんが、現代のシステム上の単純なデータベースは十分に速いです。ほとんどの場合、検索のスピードを上げるためのインデックス機能も備えています。あなたのアプリケーションに埋め込むことができ、検索に特化して上記の問題を解決したいものがあれば、Luceneの使用をお勧めします。