1

空間インデックス

空間インデックスが与えられると、インデックスユーティリティ、つまりインデックスの全体的なパフォーマンスが、全体的なジオメトリと同じくらい良くなります。

たとえば、100万のジオメトリデータ型を取得してテーブルに挿入し、それらの相対点が互いに密に配置されるようにした場合、このインデックスは、相対位置が大幅にまばらになる可能性がある同一のジオメトリ形状に対してパフォーマンスが向上しますか？ 。

質問1

たとえば、これら2つのジオメトリ形状を考えてみましょう。

状況1

LINESTRING(0 0,1 1,2 2)
LINESTRING(1 1,2 2,3 3)

幾何学的には同じですが、座標が1点ずれています。これが100万回繰り返されたと想像してみてください。

今、この状況を取ります、

状況2

LINESTRING(0 0,1 1,2 2)
LINESTRING(1000000 1000000,1000001 10000001,1000002 1000002)
LINESTRING(2000000 2000000,2000001 20000001,2000002 2000002)
LINESTRING(3000000 3000000,3000001 30000001,3000002 3000002)

上記の例では：

  • 線の寸法は状況1と同じです。
  • 線は同じ数の点です
  • 線のサイズは同じです。

でも、

  • 違いは、線が大幅に離れていることです。

なぜこれが私にとって重要なのですか？

この質問をする理由は、入力ジオメトリから可能な限り精度を削除し、アプリケーションが精度を失うことなく提供できる限り、それらの密度と近接性を減らす必要があるかどうかを知りたいからです。

質問2

この質問は最初の質問に似ていますが、別のジオメトリシェイプに空間的に近いのではなく、シェイプ自体を可能な限り小さな形状に縮小して、アプリケーションに必要なものを説明する必要があります。

たとえば、ジオメトリデータ型でSPATIALインデックスを使用して、日付に関するデータを提供する場合です。2つの日付の日付範囲を保存したい場合は、mysqlで日時データ型を使用できます。ただし、ジオメトリタイプを使用したい場合はどうすればよいでしょうか。そのため、個々の日付を取得してunix_timestamp（）に変換することにより、日付範囲を伝達します。

例えば：

 Date("1st January 2011") to Timestamp =  1293861600
 Date("31st January 2011") to Timestamp =  1296453600

これで、これら2つの整数に基づいてLINESTRINGを作成できました。

 LINESTRING(1293861600 0,1296453600 1)

アプリケーションが実際には日数のみを考慮し、秒数が日付範囲にとってまったく重要ではない場合、必要なものを満たすためにジオメトリを可能な限り最小のサイズに縮小するようにジオメトリをリファクタリングする必要があります。

そのため、「1293861600」の代わりに「1293861600」/（3600 * 24）を使用します。これはたまたま「14975.25」です。

誰かがこれらのギャップを埋めるのを手伝ってもらえますか？

4

1 に答える 1

1

新しいエントリを挿入するとき、エンジンはMBR最小限に拡張されるエントリを選択します。

「最小限に拡張された」とは、エンジンは「領域拡張」または「境界拡張」のいずれかを意味し、前者はデフォルトでMySQL。

これは、ノードの面積がゼロ以外である限り、それらの絶対サイズは重要ではないことを意味します。大きい方MBRは大きいまま、小さい方は小さいままであり、最終的にはすべてのノードが同じになりますMBR。

これらの記事はあなたに興味があるかもしれません：

密度については、MBRページ分割で再計算されるため、メインクラスターから離れすぎているすべてのポイントが最初の分割で独自のポイントに移動する可能性が高くなりますMBR。それは大きくなりますが、数回の反復ですべての未解決のポイントの親になります。

これにより、未処理のポイントの検索時間が短縮され、クラスターポイントの検索時間が1ページシーク増加します。

于 2011-03-30T13:02:31.193 に答える