Пространственный индекс 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

Является ли использование ЦП на SQL или на демо-карте?

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

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

-

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

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

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

Answer 2

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

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

Answer 3

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

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

Как правило, вы также можете оптимизировать запросы, выполняемые с сервером, но при использовании MapGuide у вас немного меньше возможностей; возможно, MapGuide задает вопросы таким образом, что SQL Server оптимизирован для оптимизации. Если вы обнаружите, что это так, пожалуйста, enter a ticket in the MapGuide Trac system