大規模なデータセット (SQL から C#)、長いロード時間の修正
-
22-08-2019 - |
質問
私が構築しているサイトは、いくつかのユーザー設定に基づいて (多かれ少なかれ...) 差し込み印刷を作成するアプリケーションです。デカルト結合に相当するデータを問題なく生成できますが、企業のニーズが生じて作業が少し難しくなります...
リモートの従業員の郵便番号を確認した後、その従業員からメディア ターゲットまでの距離に基づいて、メディア ターゲットへの電子メールを作成するアプリケーションを構築する必要があります。たとえば、従業員が働いている場所で有名なボランティアであるとします。企業は、これらの従業員から半径 8 マイル以内のメディアに、従業員が行っている仕事に関するメッセージを電子メールで送信したいと考えています。ここで事態は混乱します...ここにはいくつかの選択肢がありますが、その試みと失敗の概要を説明します。
最大半径は20マイルです。私は、米国内のすべての郵便番号の記録を保持するデータベース テーブルを作成し、その郵便番号から 20 マイル以内のすべての郵便番号に結合します。データセットは次のようになります (名前は異なりますが、これは議論のためです)。
sourcezip] | [都市] | [状態] | [closezip] | [都市] | [状態] | [距離
失敗:例として、ニューヨーク州には上記のデータセットからの 350,000 件のレコードがあります (他の州はさらに悪いです!)。そのページの平均読み込み時間は?6分…起きていません。ブレークポイントを設定してこれを確認しました。切断が発生するのは dataadapter.fill() 段階です。(これは物流上の問題により実装されませんでした) 各従業員の zip からメディア ターゲットの zip へのデータベース接続を x 以下の距離で作成します。ただし、ソース ファイルとメディア ターゲットを組み合わせると、個別の電子メールが 34,000 件を超える可能性があります。34k DB接続?郵便番号検索を再利用する方法を考案できたとしても、DB でいくつかのテスト チェックを行ったところ、従業員が勤務するニューヨークには 500 の異なる郵便番号があることがわかりました。500db接続?それがうまくいくとは思えませんが、驚かれるかもしれません。
この問題を回避するための私の最新の計画は、次のように新しいデータセットを取得することで、Web サーバーが .net データセット オブジェクトよりも優れたゲームを実行することを期待することです。
zip] | [経度] | [緯度
次に、距離の式を実行して、データが機能するかどうかを確認します。これは、Web サーバー上のプロセッサに大きく依存します。これは価値のあるギャンブルですか? それとも、この試みでも同じロード時間のダメージが発生するでしょうか?もっと良い方法はありますか?
たとえそれがこのプロジェクトに対する私の懸念を裏付けるものであっても、あらゆる意見に感謝します。 ただ機能しないかもしれない.
その他の注意事項:私はサーバーを制御できず、SQL2k を実行しています:(。Visual Studio 2005、Framework 2.0 でサイトをプログラミングしています。ただし、今後数か月以内に SQL2005 および VS2008 にアップグレードされる可能性があります。
解決
は、あなたが一緒に3つのテーブルを結合し、時間のビットを節約することがあります...
SELECT *
FROM Employees_List
INNER JOIN
(Media_List INNER JOIN Distance_List ON Media_List.Zip = Distance_List.Target_Zip)
ON Employees_List.Zip = Distance_List.Source_Zip
WHERE distance_Miles <=5
あなたは距離を使用して従業員とメディアとの関係を設定します。 この方法
他のヒント
経度/緯度座標を含む郵便番号データベースがある場合は、Haversine 関数を使用してその場で距離を計算できます (私の記事を参照してください)。 この質問に対する答え).
これは、米国の郵便番号データ全体を含む Web アプリで非常にうまく機能します。
クエリは次のようになります。
select * from zip where
dbo.udf_Haversine(zip.lat,zip.long, @lat, @lon) < 20 -- (miles)
これを各受信者のアドレスに適用するのではなく、まず半径内の郵便番号を (ネストされたクエリまたは CTE を使用して) 決定し、次にメールの送信先となるすべてのアドレスを結合します。
編集 調査した結果、Haversine 関数を使用した答えが私が取るルートです...これは、データベースが使用する関数ほど集中的ではありません (これは修正される予定です:))
あなたがすべき ない 毎回距離を計算するのは、経度/緯度から経度/緯度までの大変な計算ですが、複数回実行する場合は不要です。
そうは言っても、なぜあなたがすでに選択肢 #2 を取り消したのか私にはわかりません。私たちは実際にこれと同じようなことを行っています。おそらく私は数字に混乱しているかもしれませんが、あなたが言及していることはSQL2kにとって汗をかくようなことではないはずです。
米国の zip から zip までの距離をオフラインで計算したとしても、行数は約 20 億行しかありません。はい、量は多いですが、ほぼ静的であり、遅い場合はシャーディングされる可能性があります。
350K行(NYためのあなたの一例)のSELECTは、MySQLに()SOURCEZIP(BY ORDER .. ALTER TABLEの)6分かかりません。それだけでALTERは長い時間がかかります(または、あなたはその順番でテーブルを作成することができます)... 2番目の分数を取るべきである - それは、静的なテーブルですので、それは何も価値があるだろう。
。あなたはSQL 2008を使用していますか?その場合は、新しい空間データ機能は、あなたがここに探しているだけで何であるかもしれません。あなたは、文字列の「LIKE」比較を使用するように簡単に他の範囲内の座標を見つけることができます。
http://www.microsoft.com/sqlserver /2008/en/us/spatial-data.aspxする