72

パフォーマンスの問題...

地理位置情報データ (経度と緯度) を持つ家屋のデータベースがあります。

私がやりたいことは、InnoDB データベース エンジンを使用して MySQL (v5.0.24a) に位置データを格納する最良の方法を見つけて、間にあるすべてのホーム レコードを返す多くのクエリを実行できるようにすることです。 x1 と x2latitudeと y1 と y2 longitude.

現在、私のデータベーススキーマは

---------------------
Homes   
---------------------
geolat - Float (10,6)
geolng - Float (10,6)
---------------------

そして、私のクエリは次のとおりです。

SELECT ... 
WHERE geolat BETWEEN x1 AND x2
AND geolng BETWEEN y1 AND y2
  • 上記で説明したことは、緯度と経度のデータを Float (10,6) を使用して MySQL に保存し、経度/緯度を分離する最良の方法ですか? そうでない場合、何ですか？データ型として、Float、Decimal、さらには Spatial が存在します。
  • これは、パフォーマンスの観点から SQL を実行する最良の方法ですか? そうでない場合、何ですか？
  • 別の MySQL データベース エンジンを使用する意味はありますか?

更新: まだ回答がありません

以下に3つの異なる答えがあります。一人が使うと言うFloat。ある人は を使うと言いますINT。ある人は を使うと言いますSpatial。

というわけで、MySQLの「EXPLAIN」ステートメントを使ってSQLの実行速度を計測してみました。経度と緯度のデータ型を使用してINTも、使用しても、SQL の実行 (結果セットのフェッチ) にまったく違いはないようです。FLOAT

また、" " ステートメントを使用すると、" " または " " SQL ステートメントBETWEENを使用するよりも大幅に高速になるようです。" " と " " ステートメントを使用するよりも、" " を使用する方が約 3 倍高速です。><BETWEEN><

そうは言っても、Spatial を使用した場合のパフォーマンスへの影響についてはまだ不明です。これは、実行中の MySQL のバージョン (v5.0.24) でサポートされているかどうか、またサポートされている場合に有効にする方法が不明であるためです。 .

どんな助けでも大歓迎です

4

8 に答える 8

29

float(10,6) は問題ありません。

他の複雑なストレージ スキームでは、より多くの変換が必要になりますが、浮動小数点演算は十分に高速です。

于 2009-09-02T21:58:03.040 に答える
11

MySQL について質問されていることは承知していますが、ビジネスにとって空間データが重要な場合は、再検討することをお勧めします。PostgreSQL + PostGISもフリー ソフトウェアであり、空間データと地理データを効率的に管理することで定評があります。多くの人が PostGIS のためだけに PostgreSQL を使用しています。

ただし、MySQL の空間システムについてはよく知らないので、おそらくあなたのユースケースでは十分に機能します。

于 2009-09-03T16:37:42.133 に答える
6

ここで「空間」以外のデータ型を使用する場合の問題は、「長方形の選択」の種類が (通常、これは DBMS の明るさによって異なります。また、MySQL は一般的に最も明るいわけではありません) 最適化できるのは 1 つのみです。一次元。

システムは、経度インデックスまたは緯度インデックスのいずれかを選択し、それを使用して検査する行のセットを減らすことができます。ただし、それが完了した後は、(a) 見つかったすべての行をフェッチし、それらをスキャンして「他の次元」をテストするか、(b) 「他の次元」で同様のプロセスを実行してから後で行うかの選択肢があります。これら 2 つの結果セットを照合して、両方に表示される行を確認します。この後者のオプションは、特定の DBMS エンジンではそのままでは実装されない場合があります。

空間インデックスは後者を「自動的に」実行するため、空間インデックスはどのような場合でも最高のパフォーマンスを発揮すると言っても安全だと思いますが、他のソリューションよりもパフォーマンスが大幅に優れていない場合もあります。わざわざする価値がないということです。これは、実際のデータの量や分布など、あらゆる種類のものに依存します。

確かに、フロート (ツリー) インデックスは必然的に整数インデックスよりも遅くなります。これは、通常、整数よりもフロートで '>' を実行するのに時間がかかるためです。しかし、この効果が実際に顕著であったとしたら、私は驚くだろう.

于 2009-09-03T13:45:14.300 に答える
4

int1/1,000,000 度で表される整数 ( 、4 バイト) として格納します。これにより、数インチの解像度が得られます。

MySQL に固有の空間データ型はないと思います。

于 2009-09-02T21:33:51.403 に答える
4

フロート (10,6)

緯度または経度 5555.123456 はどこですか?

代わりに Float(9,6) を意味しませんか?

于 2010-11-10T16:39:00.243 に答える
2

私はまったく同じスキーマ (float(10,6)) とクエリ (四角形内で選択) を持っていますが、db エンジンを innoDB から myisam に切り替えると、テーブル内の「四角形ルックアップのポイント」の速度が 2 倍になることがわかりました。 780,000 件のレコードがあります。

さらに、すべての lng/lat 値をデカルト整数 (x、y) に変換し、x、y に 2 列のインデックスを作成したところ、同じルックアップで速度が ~27 ミリ秒から 1.3 ミリ秒になりました。

于 2014-04-22T17:08:58.073 に答える
0

それは本当にあなたがデータをどのように使っているかに依存します。しかし、事実を大幅に単純化しすぎると、小数は高速になりますが、近似では精度が低下します。詳細はこちら：

http://msdn.microsoft.com/en-us/library/aa223970(SQL.80).aspx

また、GPS座標の標準はISO6709で指定されています。

http://en.wikipedia.org/wiki/ISO_6709

于 2009-09-02T21:37:58.213 に答える