Помогите решить задачку



Всем приветЕсть 1кк заказов, у заазов есть обычные параметры(длина, вес, объем и т.д) есть гео-параметры(откуда-куда)Надо - быстро найти подходящие заказы - как по фасетам так и по гео. Используется mysql 5.7. К сожалению одновременный поиск по bree & rtree не работает ( точнее работает очень медленно, т.к. выбирается выбирается только один из индексов). Вопрос - кто что может подсказать в этом направлении. Сфинкс, эластик? может у кого была похожая задача?UPD: Перефразирую вопрос в чем проблема, опустим доп условия (вес, габарит и прочее), проблема в геоНеобходимо выбрать заказы у которых пункт "откуда" входит в область "откуда" и пункт "куда" входит в область "куда"-----есть таблица `geo_polygons`id int...polygon MULTIPOLYGONиндекс на polygon SPATIAL----------Есть талблица `address`id int...location POINTиндекс на location SPATIAL-----ЗапросSELECT o.idFROM `orders` as oJOIN `address` AS ao ON `o`.`address_id_from` = `ao`.`id`JOIN `address` AS at ON `o`.`address_id_to` = `at`.`id`JOIN vvGeo.geo_polygons as pfJOIN vvGeo.geo_polygons as ptWHERE pf.id = 1 AND pt.id = 2 AND ST_Contains(pf.polygon, `ao`.`location`) AND ST_Contains(pt.polygon, `at`.`location`)LIMIT 30;план1 SIMPLE pf const PRIMARY,ix_polygon PRIMARY 4 const 1 100 1 SIMPLE pt const PRIMARY,ix_polygon PRIMARY 4 const 1 100 1 SIMPLE o range afrom,ato,address address 5 189044 50 Using where; Using index1 SIMPLE ao eq_ref PRIMARY,ix_location PRIMARY 4 vvUserBD.o.address_id_from 1 70.16 Using where1 SIMPLE at eq_ref PRIMARY,ix_location PRIMARY 4 vvUserBD.o.address_id_to 1 93.48 Using whereВремя выполнения:[2016-10-11 12:31:29] 30 rows retrieved starting from 1 in 2m 0s 547ms (execution: 2m 0s 544ms, fetching: 3ms)причем если вместо `ao`.`location` записать константой как GeomFromText('POINT(43 55)') - все работает хорошо (это проверка для одного заказа)
952   25  

Comments

  1. Alexey Rybak
    Alexey Rybak 5 лет назад
    Очень много вопросов. 1кк это всего миллион, почему "очень медленно"? Какие запросы, какие эксплейны, насколько медленно? Что такое подходящие заказы? В некотором интервале в 5-мерном пространстве (3d + geo)?
    • Logachev Nikita
      Logachev Nikita 5 лет назад
      Да, извиняюсь - чуть более подробнее распишу
    • Logachev Nikita
      Logachev Nikita 5 лет назад
      обновил пост
    • Alexey Rybak
      Alexey Rybak 5 лет назад
      Почему работает хорошо для одного заказа - очевидно: вместо миллиона проверок делаете одну. Я бы думал в двух направлениях. (1) Во-первых до сих пор непонятно, почему скан orders с джйонами так долго проверяется через sp-функции, и что тут можно ускорить. Здесь надо изучать - я не работал с sp, но выглядит как бред. (2) Во-вторых, если там объективно есть тормоза, то можно придумать какой-то способ ограничить выборку так, чтобы скан шел не по всем orders а сначала выбирал так, чтобы было отсечено всё что "точно не попадает". Например, есть какая-то глобальная сетка и каждый заказ помечен в сетке и можно точно через where по индексу отсечь всё что не попадает не прибегая к пост-фильтрации geo-функциями. Но начинать надо с п (1).
    • Logachev Nikita
      Logachev Nikita 5 лет назад
      На самом деле мы и пошли по п.(2)Просто как раз интересен п(1) из вашего комментария - может у кого-то был опыт в решении этой проблемы.
  2. Andrey Shetukhin
    Andrey Shetukhin 5 лет назад
    >Есть 1кк заказов,
    • Марко Кевац
      Марко Кевац 5 лет назад
      Число 200 тоже помещается в память, а подсчет 200го число фибоначи банальным алгоритмом никогда не закончится.
    • Andrey Shetukhin
      Andrey Shetukhin 5 лет назад
      Ну, если автор считает числа Фибоначчи - то да, таки не закончится.
    • Илья Есин
      Илья Есин 5 лет назад
      Andrey Shetukhin ты забыл написать, что числа фибоначи он должен считать на SQL.
    • Andrey Shetukhin
      Andrey Shetukhin 5 лет назад
      Ilya Yesin Да, для полноты картины этого не хватает, согласен.
  3. Константин Герасименко
    Константин Герасименко 5 лет назад
    Postgres не предлагать ?
    • Andrey Shetukhin
      Andrey Shetukhin 5 лет назад
      Нет, не предлагать. Потому что без понимания, почему тормозит, любой совет идёт только во вред.
    • Константин Герасименко
      Константин Герасименко 5 лет назад
      Ну если уже стоят перед выбором мускуля эластика или сфикса ... То почему туда постгрес не добавить ??? Или перед постгрестом нужно проблему найти обязательно ?
    • Andrey Shetukhin
      Andrey Shetukhin 5 лет назад
      > Ну если уже стоят перед выбором мускуля эластика или сфикса
    • Константин Герасименко
      Константин Герасименко 5 лет назад
      Отлично , теперь топикстартер знает ещо одно модное слово )))
    • Илья Есин
      Илья Есин 5 лет назад
      Konstantin Gerasimenko лучше бы он знал точные условия и критерии. Ну или рассказал бы нам, если знает.
    • Антон Герасимов
      Антон Герасимов 5 лет назад
      Всенепременно предлагать. Обязательно с полнотекстовым поиском и наследованиями 1М фасетного поиска - это не повод менять шило на мыло!
  4. Роман Ивлиев
    Роман Ивлиев 5 лет назад
    Подпишусь
  5. Андрей Ковбович
    Андрей Ковбович 5 лет назад
    поменять тип таблицы на MYISAM?
    • Logachev Nikita
      Logachev Nikita 5 лет назад
      ? и?
  6. Владимир Кольцов
    Владимир Кольцов 5 лет назад
    в системах, где нет типа координата, расстояние не сложно посчитать по формуле прямо в запросе
  7. Alexander Lisachenko
    Alexander Lisachenko 5 лет назад
    Интересно, как это будет летать, если добавить на все виртуальные индексы по функциям и потом собрать один составной виртуальный индекс конкретно под этот ваш запрос. Имхо, функциональный индекс здесь вам как раз подойдет с учётом того, что 5.7 MySQL
  8. Евгений Кирдей
    Евгений Кирдей 5 лет назад
    мы использовали sphinx, причем скормили ему все данные, поэтому мускуль использовали только как исходное, надежное хранилище. Все данные получаем и обрабатываем в RT индексах.
    • Logachev Nikita
      Logachev Nikita 5 лет назад
      Именно для гео?
    • Евгений Кирдей
      Евгений Кирдей 5 лет назад
      да, вот для этого проекта https://r.onliner.by/pk/