Повторно отправьте вопрос о переполнении стека, когда было высказано предположение, что это будет лучший форум.
Я пытаюсь провести небольшой эксперимент с использованием набора данных, который не является геопространственным, но подходит ему достаточно хорошо, и результаты меня несколько тревожат. Набор данных является геномными данными, например, Человеческий Геном, где у нас есть область ДНК, где такие элементы, как гены, занимают определенные начальные и конечные координаты (наша ось X). У нас есть несколько областей ДНК (хромосом), которые занимают ось Y. Цель состоит в том, чтобы вернуть все элементы, которые пересекают две координаты X вдоль одной координаты Y, например LineString (START 1, END 2).
Теория казалась здравой, поэтому я внедрил ее в существующий геномный проект на базе MySQL и придумал структуру таблицы, например:
CREATE TABLE `spatial_feature` (
`spatial_feature_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`external_id` int(10) unsigned NOT NULL,
`external_type` int(3) unsigned NOT NULL,
`location` geometry NOT NULL,
PRIMARY KEY (`spatial_feature_id`),
SPATIAL KEY `sf_location_idx` (`location`)
) ENGINE=MyISAM;
external_id
представляет идентификатор объекта, который мы закодировали в этой таблице, и external_type
кодирует его источник. Все выглядело хорошо, и я добавил некоторые предварительные данные (30 000 строк), которые, казалось, работали хорошо. Когда это число превысило отметку в 3 миллиона строк, MySQL отказался использовать пространственный индекс и стал медленнее, когда его заставили его использовать (40 секунд против 5 секунд при полном сканировании таблицы). Когда было добавлено больше данных, индекс начал использоваться, но снижение производительности сохранялось. При принудительном отключении индекса запрос сократился до 8 секунд. Используемый мной запрос выглядит так:
select count(*)
from spatial_feature
where MBRIntersects(GeomFromText('LineString(7420023 1, 7420023 1)'), location);
Данные, входящие в этот список, будут очень плотными по измерениям Y (представьте себе, что вы записали положение каждого здания, телефонной будки, почтового ящика и голубя на очень длинной дороге). Я провел тесты того, как R-индексы ведут себя с этими данными в Java, а также другие специалисты в этой области успешно применили их к форматам плоских файлов. Однако никто не применил их к базам данных AFAIK, что является целью этого теста.
Кто-нибудь видел подобное поведение при добавлении больших объемов данных в пространственную модель, которая не очень разнородна по определенной оси? Проблема сохраняется, если я переверну использование координат. Я запускаю следующую настройку, если это является причиной
- MacOS 10.6.6
- MySQL 5.1.46
Что-то должно быть не так с вашей установкой mysql или настройками .ini. Только что проверил геопространственный индекс на моем старом Mac (10.6.8 / MySQL 5.2). Эта конфигурация похожа на вашу, и я протестировал большой дамп геоданных ( 9 миллионов записей ). Я сделал этот запрос:
Это заняло всего 0,0336 сек.
Я использую приведенный выше запрос, например, для сравнения таблиц, в которых таблица, из которой взяты только значения широты / долготы для @center, имеет простой INDEX из city_latitude / city_longitude и 9-12 Mio. Таблица от geonames.org имеет геопространственный индекс.
И я просто хотел добавить, что когда кто-нибудь вставляет большие данные в таблицу, было бы более целесообразно добавить индекс после INSERT. Если нет, это займет больше времени для каждой строки, которую вы добавляете ... [но это не важно]
источник
Задумывались ли вы о том, чтобы разбить его на два 1D столбца вместо одного 2D столбца?
Оптимизатор может задушить все подобные данные, и может помочь наличие двух столбцов с большим разнообразием.
То, что вы также можете проверить, это порядок, в котором элементы проверяются. У меня была проблема в Oracle Spatial, где я искал по Фамилии и фильтру IN_REGION. Oracle решила, что самым быстрым способом будет использовать фамилию, а затем выполнить проверку региона. Позвольте мне сказать вам, что проверка всех Робинсонов в Кливленде в регионе идет медленно . Я помню, что мне пришлось передать специфический аргумент Oracle, чтобы сначала он использовал пространственный индекс.
источник