У меня есть SQL Azure DB уровня B, запросы в основном с использованием STIntersect на основе минимальных полигонов (5 точек) и были ужасные проблемы с производительностью. Проверка на пересечение в таблице из 50 000 строк заняла почти минуту (пространственные индексы были на месте и намекались в запросе).
В конце концов, я настроил локальную тестовую БД, запустил тот же запрос и получил результат менее чем за секунду.
Я использовал самый низкий уровень SQL Azure, поэтому я обновился до S1, а затем до S2, с заметно лучшими результатами на S2, хотя это все еще занимает более 3 секунд). Проблема в том, что когда я запускаю один запрос, мой экземпляр S2 уже достигает 60% использования DTU, что заставляет меня предположить, что это вообще не подходит для производства, а это большие деньги за очень низкую производительность.
https://stackoverflow.com/a/27974549 год назад намекнул, что Azure SQL не подходит для пространственных задач, потому что география тип CLR убивает ЦП. Каков ваш опыт/рекомендация по текущим базам данных V12? Действительно ли мне нужно прибегать к (менее эффективным) ручным вычислениям широты и долготы при развертывании в Azure?
Спасибо, Филипп
--
Запрос:
DECLARE @g geography;
DECLARE @bfr geography;
set @g = geography::STPointFromText('POINT(8.7125158 47.5041406)', 4326)
set @bfr = @g.STBuffer(575000).Reduce(57500)
SELECT count(*)
FROM Locations st with(index(SPATIAL_LocationArea))
WHERE @bfr.STIntersects(st.LocationArea) = 1
Таблица:
CREATE TABLE [dbo].[Locations] (
[Id] INT IDENTITY (1, 1) NOT NULL,
[Location] [sys].[geography] NOT NULL,
[LocationArea] [sys].[geography] NOT NULL,
PRIMARY KEY CLUSTERED ([Id] ASC)
);
GO
CREATE SPATIAL INDEX [SPATIAL_Location]
ON [dbo].[Locations] ([Location]);
GO
CREATE SPATIAL INDEX [SPATIAL_LocationArea]
ON [dbo].[Locations] ([LocationArea]);
