0

私は次のことを行うスクリプトを持っています..

  • db から 1 つのレコードを取得します
  • （インターネット上の他のサーバーから）外部APIを呼び出し、データを取得します
  • 更新されたSQLデータベースのデータを読み取ります（いくつかの列の値が更新されたほぼ同じレコード）

だから、

  • * は使用せず、必要な列のみをクエリします
  • オフピーク時にスクリプトを実行しています
  • 私の環境は、現在のバージョンの WAMP で実行されている LocalHost です。
  • 私はサーバー マシンを手に入れましたが、問題ありません。

私の問題は、

毎日更新する必要がある 14,000 を超えるレコードで構成される大きなデータベースがあります (一部の製品については、コストと数量を更新する必要があります)。スクリプトを実行すると、何時間も実行され、その後も 14,000 件のレコードが完了することはなく、約 8,000 件のレコードの更新で停止します。

  • このタイプのデータベース操作を管理するにはどうすればよいですか?
  • データベース操作を 2 つの部分 / スレッドに分割して、各部分 / スレッドが他の部分と並行して実行されるようにするにはどうすればよいですか。このようにして、時間を半分に短縮できます。それが私の主な関心事です。
  • このような場合におすすめは何ですか？
4

2 に答える 2

2

ほとんどの場合、DB 時間は問題ではありません。毎回新しい (準備されていない) ステートメントを使用する場合でも、14,000 レコードは時間の問題ではありません (ルックアップ用のインデックスが存在すると仮定します)。

(ただし、もちろん、db 実行時間も確認 (測定) する必要があります。もちろん、準備済みステートメントを使用する必要があります。)

ただし、外部 Web サービスを 14,000 回呼び出すと、明らかにかなりの時間がかかります。外部サービスはバッチ API を提供しますか? そうでない場合は、ネットワークの待ち時間を短縮するために、サーバーにさらなるリクエストを問い合わせる際に、HTTP 接続を開いた (生きている) 状態にしておくことをお勧めします。

最後の最適化として、DB からフェッチした行を並行して処理する一連のワーカー プロセス (またはスレッド) を生成できます。

于 2013-11-09T22:05:16.473 に答える
1
  • レコードのさまざまなセクションを並行して更新するために、db クライアント側でかなりの数のスレッド/サブプロセス (たとえば 20 または 50) を作成します。クライアントとサーバーの両方で CPU、IO、メモリを監視し、使用されているリソースの量を確認し、問題がなければ数値を増やします。
  • db クライアント側でバッチ コミットします。たとえば、100 行が更新されるたびにのみコミットします。
  • キー列が db サーバー側でインデックス化されていることを確認してください。
  • 大量のデータ レコードを扱うときは、常にバッチ処理を考えてください。これは、データベース操作、Web サービス、残りなどに適用されます。
  • ビジネス ロジックがよくわからない場合は、Web サービスの読み取りとデータベースの更新を並行して実行することもできます。つまり、一部のスレッドが一部の外部をフェッチしている間に、他のスレッドがデータを db に書き込んでいます。
  • はい、1 つの SQL ステートメントが繰り返し実行される場合は、準備済みステートメントを使用する方がはるかに優れています。
  • また、コース全体でデータ参照整合性などを無効にすることを検討したり、commit コマンドが発行されたときにそれを強制するようにデータベースを設定したりすることもできます。バッチ コミットと組み合わせると、db サーバー側で多くの時間を節約できます。
于 2013-11-09T22:20:37.980 に答える