3

SQL Server 2008 にデータベースがあり、そのすべてに緯度、経度、および対応する地理フィールドが含まれる約 120 億行があります。最近、地理フィールドを照会する機能を追加する必要がありました。4 TB 以上のデータを処理するのに 6 日かかった空間インデックスを追加しました。

CREATE SPATIAL INDEX IX_Location_Geo ON Location
(
    Geo
) USING  GEOGRAPHY_GRID 
WITH (
    GRIDS =(LEVEL_1 = MEDIUM,LEVEL_2 = MEDIUM,LEVEL_3 = MEDIUM,LEVEL_4 = MEDIUM), 
    CELLS_PER_OBJECT = 16, PAD_INDEX  = OFF, SORT_IN_TEMPDB = OFF, 
    DROP_EXISTING = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON PRIMARY
GO

そのようなクエリを使用して意図的に追加...

SELECT TOP 100 
    ci.LocationID, ci.Geo.STDistance(@g)  
FROM Location ci WITH(INDEX(IX_Location_Geo))
WHERE ci.Geo.Filter(@region) = 1 
ORDER BY ci.Geo.STDistance(@g)

お見積り実施プランはこちら・・・

実行計画

このクエリを 1 億行のサンプル セットでテストしたところ、見事に機能しました。しかし、請求行が 12 行ある場合、クエリは約 4 時間後に応答せず、最終的にディスク書き込みエラーで失敗します。

Msg 1101, Level 17, State 10, Line 4 Could not allocate a new page 
for database 'TEMPDB' because of insufficient disk space in filegroup 
'DEFAULT'. Create the necessary space by dropping objects in the filegroup, 
adding additional files to the filegroup, or setting autogrowth on for 
existing files in the filegroup.

私の側の明らかな見落としに気付くかもしれない誰かがいることを願っています. 本当にありがとう！

4

2 に答える 2

1

垂直方向のスケーラビリティ (メモリ、CPU、ハード ドライブの容量を追加して、単一の強力なマシンを作成する)を使用する代わりに、水平方向のスケーラビリティ (多くのコモディティ サーバー間で負荷を分割する) を使用することを検討してください。どんな操作にも時間とスペースが必要です。Big-O 表記は、 よりも時間がかかる計算については、そのようなボリュームをまったくO(N)計算する運命にあることを示しています。これが、大まかに見ると、エラーが発生し、クエリが完了するまでに膨大な時間がかかる理由です。

考えられる解決策

データ アクセスのパターンを変更します。シャーディングを使用 - データを小さなチャンクに分割します。WHERE句を広範囲に使用し、Skip/Takeページネーション パターンを使用します (T-SQL の適切な構文についてはわかりません)。Map-Reduceバズるパターンもあります。つまり、そのボリュームで垂直方向のスケーリングを停止します。

于 2012-10-07T19:36:59.083 に答える
0

あなたが投稿したエラー メッセージはtempdb、メイン データベースではなく のディスク容量が不足していることを示しています。そのため、使用可能なスペースを確保できますが、SQL Server はそもそもそれだけ多くを消費するはずです! したがって、それは解決策ではありません。

推定実行計画を投稿してください（実際の実行計画を取得することはできません）。計画に関する私の考えでこの回答を更新します。

一般的なコメントとして: 実行時に SQL Server が何をするかがわかるため、通常、クエリのパフォーマンスの問題のデバッグは計画から始まります。

于 2012-10-08T10:47:01.143 に答える