私は現在、オプション シンボルを取得し、キャッシュから簡単に検索できるようにして、Web ベースと Windows ベースのさまざまなアプリケーションから高速に検索できるようにするタスクを抱えています。結果を返す WFC サービスを作成することにしました。
キャッシュに必要なレコードは約 500k です。これを行うと、Trie オブジェクトを使用した場合のメモリ フットプリントは約 400 MB になります。小さくするように言われました。
オプション記号は、私たちの世界では次のように見えますROOT:DATESTRING:PRICE:TYPE。IBM:130119:215.0:C
だから私は、これにはたくさんの重複があるので、完成したときにメモリ使用量が約30 MBになる各部分のTrieを構築できると考えていました。
したがって、私のジレンマは、それらをリンクして、検索用に1つの連続したTrieとして表示されるようにすることです。Price の親が Date であり、その ROOT または Type に対して発生しない価格を持つ可能性があるため、単純な親子を実行すると、誤った結果になる可能性があります。私たちの現在のアプローチは、データベースの結合テーブルに似たリンク オブジェクトである別のオブジェクトを使用することです。各最終ノードに UniqueID を設定し、適切な関係を構築します。これはまだ非常に高速であり、大量のメモリを必要としませんが、これらのアイテムをより効率的な方法でリンクする方法として他の人が何を提案しているのか疑問に思っていました.
追加情報: したがって、現在の実装のオプション シンボルの各部分は、独自の個別のトライです。したがって、次のオプションがある場合: IBM:130119:215.0:C APPL:130119:215.0:C APPL:130119:600.0:C A:130119:31:0:C IBM:130119:220.0:C IBM:130119:215.0: P 次に、次のようにルートのトライを作成します。ノード構造の一部として終了値があり、どこで終了したかを知ることができます。
ルート 日付 価格 OptType
/ \ | / \ \ / \
AI 1 2 3 6 パソコン
/ \ | | | / \ | | |
AB 3 2 1 1 0
| | | | | | | | | | | | | |
PM 0 0 5 . 0
| | | | | | | | | | | |
Ｌ１．. 0 .
| | | | | | | | | |
10000
| |
9
したがって、これらのそれぞれをリンクする方法がないと、Parent Child を使用するだけで多くの誤検知が発生する可能性があります。Date の子は Price であるため。私は、すべての親子ピースをルートに置き、それを特別なタイプの NODE にして、不要な他のもののためにたくさんの null データが存在しないようにすることを考えていました。しかし、リンクテーブルに落ち着きましたが、それはまったくうまくいきません。これが正しい実装であるとは言えませんが、呼び出しの数と頻度のために、これらのレコードをすべて CACHE する必要があります。