3

私は、多くの地理空間データを含むデータベースを持っています...基本的に、何万人もの人々に関する情報であり、それぞれの座標があります。

座標は現在、緯度と経度の 2 つの float として格納されています。関数を使用して、そのレコード内の座標と渡す座標の間の距離を決定します。基本的には、取得した結果を距離で並べ替えて制限します。これは、大まかに関数で使用されるコードです。

DECLARE @earthSphereRadiusKilometers as float
DECLARE @kilometerConversionToMilesFactor as float
SELECT @earthSphereRadiusKilometers = 6366.707019
SELECT @kilometerConversionToMilesFactor = .621371

-- convert degrees to radians
DECLARE @lat1Radians float
DECLARE @lon1Radians float
DECLARE @lat2Radians float
DECLARE @lon2Radians float
SELECT @lat1Radians = (@lat1Degrees / 180) * PI()
SELECT @lon1Radians = (@lon1Degrees / 180) * PI()
SELECT @lat2Radians = (@lat2Degrees / 180) * PI()
SELECT @lon2Radians = (@lon2Degrees / 180) * PI()

-- formula for distance from [lat1,lon1] to [lat2,lon2]
RETURN ROUND(2 * ASIN(SQRT(POWER(SIN((@lat1Radians - @lat2Radians) / 2) ,2) + COS(@lat1Radians) * COS(@lat2Radians) * POWER(SIN((@lon1Radians - @lon2Radians) / 2), 2))) * (@earthSphereRadiusKilometers * @kilometerConversionToMilesFactor), 4)

ストアド プロシージャの実行に 4 ～ 5 秒かかります。

SQL Azure がジオメトリ データ型をサポートするようになったことに気付きました (データベースを作成したときはサポートしていませんでした)。

私の質問は...ストアド プロシージャの実行速度が大幅に向上し、ジオメトリ データ型を使用するように変更するのにかかる時間を投資する価値があるでしょうか?

ありがとう！

スティーブン

4

3 に答える 3

4

あなたの質問「ジオメトリ データ型を使用するように変更することで、速度が大幅に向上しますか?」専用の空間データ型を使用すると実際に速度が低下する可能性を無視しているように見えました。しかし、いくつかの理由から、これは実際に当てはまる可能性があります。

まず、geometry と geography のデータ型はポイントだけでなく、ラインストリングとポリゴンもサポートしていることを思い出してください。それらがサポートする追加の複雑さは、単純なポイントツーポイント距離計算を必ずしも使用しないことを意味します。また、これらの型でより広範な組み込み関数をサポートしているため、ポイントのシリアル化された値は、単なる緯度経度座標のセットよりも複雑です。これは、ジオメトリ/地理ポイント値の取得とクエリが、生の浮動座標データの同等の列よりも遅くなる可能性があることを意味します。

2 番目のより重要な要素は、距離計算が実行される精度に関連しています。

1.) 投影座標 (つまり、UTM、National Grid、または State Plane) がある場合、座標値は平面上の直線 (x、y) 単位で測定されます。したがって、基本的な三角法を使用して 2 点間の距離を計算するのは簡単です: Dist(xy) = SQRT( (x2 - x1)2 + (y2 - y1)2 )これを自分で実装するか、ジオメトリ データ型を使用するかによって、パフォーマンスが異なります。

2.) 地理座標 (緯度/経度) がある場合、これらは楕円体の角度単位で測定されます。最も一般的には、これは WGS84 システムで使用される WGS84 楕円体です。多くの場合、ストアド プロシージャで行うように、代わりに単純な球面計算を使用して、楕円体上の 2 点間の距離の十分な近似値を得ることができます。ただし、地球の形状は、押しつぶされた球によく似ています。赤道では、極までの高さよりも幅が広く、計算では地球のこの平坦化は考慮されていません。geography データ型は、提供された SRID の楕円体モデルに基づく楕円体計算を使用します。これは必然的により複雑になりますが、より正確な結果が得られます。

したがって、空間データの精度と機能を向上させたい場合は、空間データ型に移行することをお勧めしますが、パフォーマンス上の理由からではありません。

于 2010-11-23T16:59:19.253 に答える
0

新しい空間データ型の使用経験もないため、探しているはい/いいえの答えを出すことはできません。

しかし、私があなたに与えることができるのは、いくつかの指針です。

まず、SPは地理データを変換しているようです。SQL Server 2008には、新しい地理データ型を使用してそれを実行するメソッドがあります。MSDN geographyDataTypeリファレンスのGeographyインスタンスのOGCメソッドを参照してください。したがって、新しい方法では、少なくともカプセル化のメリットが得られます。 特に興味深いのは、（STDistance（geography Data Type））メソッドです。これは、SPがlat1、lon1からlat2、lon2までの距離を計算して実際に行っているように見えるためです。組み込み関数は自作関数よりも速いと思いますが、テストしないとわかりません。
STDistance

MSの流行語を使用すると、空間データ型の大きなプラスは空間インデックスを持つことです。大量の空間データを含むデータベースがある場合（SPはいくつかのパラメーターを変換するだけです）、空間インデックスを使用するとパフォーマンスが向上します。または、空間データホワイトペーパーからの引用：

SQL Server 2008に空間インデックスのサポートが含まれているため、空間データに対するクエリのパフォーマンスがさらに向上します。SQLServerデータベースエンジンに統合されている適応型マルチレベルグリッドインデックスを使用して、空間データにインデックスを付けることができます。

そして、通常のインデックスに対して空間的にインデックス付けされた（それは単語ですか？）データのパフォーマンスが優れていることを示唆する記事がいくつかあります。

パフォーマンスは確かに向上しています... （SQL Server 2008 Spatial Index Performanceから）

そして、パフォーマンスの面で、さまざまな種類の保持空間データを相互に比較するいくつかの素晴らしいグラフがあります。SQLServer 2008 Spatial-データベース呼び出しのパフォーマンス？

したがって、これを要約すると、空間インデックスを使用すると、パフォーマンスが向上します。事前定義された空間メソッドを使用すると、パフォーマンスが大幅に向上するかどうかはわかりません。

ボーナス：地理データ型を使い始めるために、多くの例を含むこのブログ投稿を読むことをお勧めします：SQLServer2008での空間サポートの謎を解き明かします。

于 2010-10-19T14:06:39.940 に答える
0

SQL Server 2008 で実行される新しい空間プロジェクトを開始しようとしています。アプリケーションは Lat Lng (WGS 84) でポイント データを取得し、そのデータを操作してラインとポリゴンを生成し、最終的にメルカトル図法で表示する必要があります。長方形のシステムであるマップ (EPSG:900913 の OSM)。

全世界 (ヨーロッパの一部のみ) のデータを受信するわけではないので、日付変更線について心配する必要はありません。EPSG:900913 のジオメトリ データ型にすべてを保存するという考えに傾いています。そうしないと、マップが描画されるたびに、すべてのポイント、ライン、およびポリゴンをディスプレイ座標系に変換する必要があります (多くの描画を行っています)。マップの）。

正直なところ、私は SQL Server 空間を初めて使用します。私の経験は Oracle でした。私が言っているのは、座標系またはジオメトリ タイプの選択は、データで何をしているかに依存するということだと思います。座標系間で大量のデータを変換する必要がある場合 (距離計算で効果的に行っていること)、適切な座標系にデータを格納する方が高速であると考えられます。

質問は、moontear が言及したネイティブの距離機能に切り替えましたか?もしそうなら、Microsoft はどのようにそれを実装しましたか? 結局、長方形のシステムでは距離の計算がはるかに簡単になるはずですか、それとも私は混乱していますか?

于 2010-11-18T06:07:31.180 に答える