PastVu
K-means в алгоритме кластеризации
Сейчас кластеризация строится классическим способом - карта разбивается на сетку кластеров, с заведением соответствующей таблицы. У этого способа хорошо прогнозируемая скорость работы, но не идеальное качество результата.
В идеале надо на лету строить кластеры с помощью математических алгоритмов, например, K-means. Такие способы дают лучший результат, но надо будет проверить скорость их работы, так как считают они на лету для каждого запроса.
Ссылки: https://groups.google.com/forum/?fromgroups=#!topic/mongodb-user/ZU4fTlWjJfE http://horicky.blogspot.ru/2011/04/k-means-clustering-in-map-reduce.html http://stackoverflow.com/questions/14305402/geospatial-clustering-mongodb
я правильно понимаю, что прогнозировать какую нагрузку на сервер сгенерирует более умный алгоритм кластеризации спрогнозировать невозможно? если бы у нас не было шкалы времени можно было бы кластеры заранее заготовить для всех уровне зума и обновлять их не очень часто (хоть раз в час), но со шкалой времени это становится невозможно. думаю что нужно оставить старый алгоритм, а эксперемнтировать с более продвинутыми уже после запуска под реальной нагрузкой
Jan 15, 2013, в 1:56 PM, klimashkin [email protected] написал(а):
Сейчас кластеризация строится классическим способом - карта разбивается на сетку кластеров, с заведением соответствующей таблицы. У этого способа хорошо прогнозируемая скорость работы, но не идеальное качество результата.
В идеале надо на лету строить кластеры с помощью математических алгоритмов, например, K-means. Такие способы дают лучший результат, но надо будет проверить скорость их работы, так как считают они на лету для каждого запроса.
Ссылки: https://groups.google.com/forum/?fromgroups=#!topic/mongodb-user/ZU4fTlWjJfE http://horicky.blogspot.ru/2011/04/k-means-clustering-in-map-reduce.html http://stackoverflow.com/questions/14305402/geospatial-clustering-mongodb
— Reply to this email directly or view it on GitHub.
Конечно, это надо пробовать после запуска с полными данными. Для таких кейсов я завел Milestone: v.Future
Что касается фильтрации на карте по любым полям (год, тег и т.д.), то конечно это на порядок увеличивает сложность (время) запроса при схеме когда есть готовые кластеры по сетке (как сейчас). Интересно то, что такая фильтрация наоборот - уменьшает сложность при динамической выборке на каждом запросе (например, k-means), потому-что запрос начинается с другой стороны - сначала выбор фотографий, который становится меньше после фильтрации (перед тем как их сагрегировать)
надо конечно как-то статистику собрать, но у меня сейчас ощущение, что фильтрация исползуется довольно нечасто, хотя именно в ней вся сила Jan 15, 2013, в 3:46 PM, klimashkin [email protected] написал(а):
Конечно, это надо пробовать после запуска с полными данными. Для таких кейсов я завел Milestone: v.Future
Что касается фильтрации на карте по любым полям (год, тег и т.д.), то конечно это на порядок увеличивает сложность (время) запроса при схеме когда есть готовые кластеры по сетке (как сейчас). Интересно то, что такая фильтрация наоборот - уменьшает сложность при динамической выборке на каждом запросе (например, k-means), потому-что запрос начинается с другой стороны - сначала выбор фотографий, который становится меньше после фильтрации (перед тем как их сагрегировать)
— Reply to this email directly or view it on GitHub.
Сейчас еще фильтрация по годам ошибается, из-за ошибок валидации того что вводит пользователь Например, на карте поставить интервал 1835 - 1850.
Ну там всего несколько фоток таких - я уже поправил там даты теперь все ок
Jan 15, 2013, в 4:40 PM, klimashkin [email protected] написал(а):
Сейчас еще фильтрация по годам ошибается, из-за ошибок валидации того что вводит пользователь Например, на карте поставить интервал 1835 - 1850.
— Reply to this email directly or view it on GitHub.