Пространственный индекс SQL Server 2008 и загрузка ЦП с MapGuide Open Source 2.1

Question

У меня есть таблица SQL Server с сотнями тысяч участков типа геометрии. Я сделал индексы для них, пробуя различные комбинации плотности и объектов для каждой ячейки. До сих пор я устанавливал для LOW, LOW, MEDIUM, MEDIUM и 16 объектов на ячейку, и я сделал SP, который устанавливает ограничивающий прямоугольник в соответствии с экстентами сущностей в таблице.

Невероятный прирост производительности благодаря запросам, занимающим почти минуты без индекса, но менее секунды, он становится быстрее, когда масштаб ближе, поэтому меньше объектов отображается.

Тем не менее загрузка ЦП достигает 100% при запросе функций, даже если сами запросы выполняются быстро. Я волнуюсь, что это не полетит в производственной среде.

Я использую MapGuide Open Source 2.1 для этого проекта, но я уверен, что загрузка процессора вызвана SQL Server.

Интересно, правильно ли установлены мои индексы. Я не нашел четкой документации о том, как правильно их настроить. Каждая статья, которую я прочитал, в основном говорит «это зависит ...», но ничего конкретного. Есть ли у вас какие-либо рекомендации для меня, в том числе книги, статьи?

Спасибо.

Answer 1

простой ответ - обобщить ваши данные, поэтому они оптимизированы для отображения

т.е. создайте несколько дополнительных таблиц, которые имеют меньше деталей и менее плотны

Answer 2

Каждый раз, когда у вас возникает такой вопрос, пора вытащить SQL Profiler и посмотреть, какие запросы выполняются. Затем выполните их через планировщик запросов, чтобы увидеть узкие места.

Вы также можете быть ленивым (как я) и просто записать типичную загрузку, используя шаблон настройки, и запустить его с помощью помощника по настройке ядра СУБД, чтобы узнать, где, по его мнению, можно добавить индексы для повышения производительности.

Обычно вы также можете оптимизировать запросы, выполняемые на сервере, но у вас немного не хватает параметров, когда дело доходит до MapGuide; возможно, MapGuide задает вопросы так, что SQL Server трудно оптимизировать. Если вы считаете, что это так, пожалуйста, введите билет в системе MapGuide Trac

Answer 3

Используется ли загрузка ЦП в SQL или в демоне mapguide?

Одна из проблем, с которой мы столкнулись, заключается в том, что картограф не настолько умён в написании запросов. Если вы используете максимальное масштабирование и отображаете небольшое подмножество легенды (скажем, только передачу с этим уровнем масштабирования), оно будет запрашивать каждый объект в области просмотра без применения какого-либо другого фильтра. Затем он просматривает тысячи записей и применяет тему (которая использует отдельный фильтр).

То, что вы могли бы попытаться сделать, это написать слои для разных уровней масштабирования и использовать фильтр запросов, чтобы ограничить объем данных, возвращаемых из SQL (что, вероятно, занимает так много процессорного времени). Это уменьшило время начальной загрузки наших линий передачи и распределения (единственное, что имеет смысл отображать на этом уровне) до нескольких миллисекунд по сравнению с 20+ секундами.

-

Я говорил только о том, что вы запрашиваете только те данные, которые нужны слою. Допустим, вы отображаете идентификаторы 1, 2, 3 и 4.

Скажем, у вас есть дисплей 1 и 2 в масштабах 0 -> бесконечность. В то время как 3 и 4 только начинают, скажем, 20000 футов. По умолчанию mapguide в основном делает select * с ограничительной рамкой области просмотра. Затем он будет перебирать все данные, относящиеся к теме.

Так, скажем, на 30 000 футов он будет запрашивать все данные, но все равно должен пройти через них.