0

私は次のように動作するアプリケーションに取り組んでいます:

  1. 多くのソースからデータをフェッチし、約 500,000 ～ 1,500,000 レコードのプールを生成します (時間/日によって異なります)。
  2. データが解析されます
  3. データの一部は、既存のデータと比較する方法で処理され (データベースから読み取られます)、計算が行われ、データベースに保存されます。ただし、データベースに格納する必要がある結果のデータセットは、(元のデータ セットと比較して) サイズがはるかに小さく、5,000 ～ 50,000 レコードの範囲です。このプロセスでは、ほとんどの場合、既存のデータが更新されます。おそらく、さらにいくつかのレコードが追加されます。
  4. 次に、ステップ 2 のデータを何らかの形で、どこかに保持する必要があります。そうすれば、次回データがフェッチされたときに、データベース内の既存のデータに触れることなく、計算を実行するために使用できるデータ セットが存在します。このデータは失われる可能性があり、かけがえのないものではありません (必要に応じて重要な情報をデータベースから読み取ることができます) が、次回のプロセスが高速化されることを指摘しておく必要があります。

アプリケーション コンポーネントは、(同じネットワーク内の) 異なるコンピューターから実行できます (そして実行される予定です)。そのため、ストレージは複数のホストから到達可能である必要があります。

memcached の使用を検討しましたが、1 レコードは通常 200 バイト以上であり、1,500,000 レコードがある場合、300 MB 以上の memcached キャッシュになると推測されるため、そうすべきかどうかはよくわかりません。 ..しかし、それは私にはスケーラブルではないようです-データがその量の5倍だったらどうなるでしょうか? 反復間でデータを保持するためだけに 1 ～ 2 GB のキャッシュを消費する場合 (これは簡単に発生する可能性があります)?

問題は、この種の処理に最も適した一時ストレージ メカニズムはどれかということです。mysql 一時テーブルを使用することは考えていません。それらがセッション間で保持され、ネットワーク内の他のホストによって使用されるかどうかわからないためです...他の提案はありますか? 考慮すべきことはありますか？

4

1 に答える 1

1

これは非常に古風に聞こえるかもしれませんが、SAN 上の一時ファイルは簡単で安価です。

各実行の開始時に 300M のファイルをロードすることは、常に 300M のキャッシュを消費することに比べれば簡単です。

また、データベース キーから再作成できる場合は、その部分を記述してテストし、一時ファイルが利用できない場合に情報がキーからマイニングされて再作成されるように自動化することをお勧めします。

于 2011-01-05T20:50:35.350 に答える