Comments 11
Есть ощущение, что ST_Distance в постгисе побыстрее работает
Спасибо, за хороший обзор!
Было бы интересно увидеть в сравнительной таблицы couchdb и mysql (движок желательно именно MyISAM, он проще и быстрее).
Насколько я знаю, mysql не имеет ни нативной поддержки вычисления кратчайшего расстояния между двумя точками по их географическим координатам, ни аналога ST_DWithin из PostgreSQL (поправьте, если я не прав, желательно аргументировав ссылками на соответствующие разделы документации). В связи с этим использовать mysql для поиска «соседей», расстояние до которых менее заданного, накладывает дополнительные ограничения:
Второе ограничение можно обойти при помощи различных упрощений (например, заменив окружность квадратом, который, в зависимости от условий задачи вписан в нее/описан около нее и построить другой индекс), однако, сравнение будет некорректно, так как эти же упрощения можно применить и к другим средствам.
- необходимо самостоятельно реализовать расчет расстояния(не сложно, но требует поддержки дополнительного кода)
- собственная реализация скорее всего не будет оптимально использовать индекс
Второе ограничение можно обойти при помощи различных упрощений (например, заменив окружность квадратом, который, в зависимости от условий задачи вписан в нее/описан около нее и построить другой индекс), однако, сравнение будет некорректно, так как эти же упрощения можно применить и к другим средствам.
По поводу couchdb — я не имею достаточное экспертизы по этому инструменту, но все же постараюсь ответить.
Во-первых — Вы имеете ввиду именно couchdb(http://couchdb.apache.org) или ответвившийся couchbase(http://www.couchbase.com)? — первая, как я понял из документации, по умолчанию вообще не имеет нативной поддержки геопоиска, вторая — на уровне bounding box, то есть решение поставленной в статье задачи по дефолту так же невозможно, только с хаками, описанными для mysql
Во-вторых, как я опять же понял из документации, couchdb by design не предназначена для частых обновлений — подробнее здесь, здесь и в документации. Следовательно, этот инструмент нельзя для сервисов вроде заказа такси, каршеринга и других подобных, где обновление координат выполняется часто. Данные могут быть неактуальны, так как приведенные статьи опубликованы довольно давно.
P.S. интересно будет услышать по этому вопросу мнение людей, которые использовали couchdb в бою, например, от 1999 — автора одной из приведенных статей
Во-первых — Вы имеете ввиду именно couchdb(http://couchdb.apache.org) или ответвившийся couchbase(http://www.couchbase.com)? — первая, как я понял из документации, по умолчанию вообще не имеет нативной поддержки геопоиска, вторая — на уровне bounding box, то есть решение поставленной в статье задачи по дефолту так же невозможно, только с хаками, описанными для mysql
Во-вторых, как я опять же понял из документации, couchdb by design не предназначена для частых обновлений — подробнее здесь, здесь и в документации. Следовательно, этот инструмент нельзя для сервисов вроде заказа такси, каршеринга и других подобных, где обновление координат выполняется часто. Данные могут быть неактуальны, так как приведенные статьи опубликованы довольно давно.
P.S. интересно будет услышать по этому вопросу мнение людей, которые использовали couchdb в бою, например, от 1999 — автора одной из приведенных статей
Для Mysql можно декларировать функцию (подробнее). Несложной манипуляцией можно создать необходимые индексы.
CouchDB примитивен, затрагивает отдельный уровень обработки данных. Скорость работы couchdb обусловлена в том числе и его простотой. Хранение данных можно настроить другими средствами (хранить полностью в озу, или настроить репликации на жесткий диск), так что частые обновления — тут совсем не фактор. Предложенные Вами статьи 4-5 летней давности. Для обработки гео-данных есть geocouch.
CouchDB примитивен, затрагивает отдельный уровень обработки данных. Скорость работы couchdb обусловлена в том числе и его простотой. Хранение данных можно настроить другими средствами (хранить полностью в озу, или настроить репликации на жесткий диск), так что частые обновления — тут совсем не фактор. Предложенные Вами статьи 4-5 летней давности. Для обработки гео-данных есть geocouch.
Я к чему это все?! Суть в том, что там, где важна скорость, часто выгоднее использовать простые решения, чем оптимизированные мега-комбайны.
Поведаю коротенькую историю. Около 10 лет назад устроился на работу в среднюю организацию. На тот момент были офисы в четырех городах: Москва (~40 человек), Питер (5 человек), Киев и Минск (~по 10 человек). Информационные задачи обслуживала самописная CRM на php, которая в свое время модернизировалась из CRM на основе Microsoft Office. Как раз в период времени пока работал там, она переписывалась с устаревшей php4 на php5. Обслуживал все это хозяйство сервер на Windows Server 2000 (или 2003 — уже не вспомню). Руководство получило от меня инициативу, помимо перехода на новый php, обновить и СУБД. На тот момент БД управляла mysql3. Вся СУБД со всеми зависимостями умещалась в один файл mysqld-max.exe, на моей памяти, весом чуть больше 1мб. В итоге, мне было предложено найти что-нибудь стабильней/быстрей. По скорости, с этой версией даже близко не могли сравниться ни 4я, ни 5я, ни даже 6я бета версии mysql. По итогу, позже перешли на MS SQL-сервер (это уже не по моей инициативе, по-моему, были какие-то требования для MS BizTalk), а после моего ухода компания перешла на какую-то несамописную расширяемую CRM (тоже уже не могу вспомнить какую).
Поведаю коротенькую историю. Около 10 лет назад устроился на работу в среднюю организацию. На тот момент были офисы в четырех городах: Москва (~40 человек), Питер (5 человек), Киев и Минск (~по 10 человек). Информационные задачи обслуживала самописная CRM на php, которая в свое время модернизировалась из CRM на основе Microsoft Office. Как раз в период времени пока работал там, она переписывалась с устаревшей php4 на php5. Обслуживал все это хозяйство сервер на Windows Server 2000 (или 2003 — уже не вспомню). Руководство получило от меня инициативу, помимо перехода на новый php, обновить и СУБД. На тот момент БД управляла mysql3. Вся СУБД со всеми зависимостями умещалась в один файл mysqld-max.exe, на моей памяти, весом чуть больше 1мб. В итоге, мне было предложено найти что-нибудь стабильней/быстрей. По скорости, с этой версией даже близко не могли сравниться ни 4я, ни 5я, ни даже 6я бета версии mysql. По итогу, позже перешли на MS SQL-сервер (это уже не по моей инициативе, по-моему, были какие-то требования для MS BizTalk), а после моего ухода компания перешла на какую-то несамописную расширяемую CRM (тоже уже не могу вспомнить какую).
(ошибся веткой)
Интересно какие результаты покажет elasticsearch.
Sign up to leave a comment.
Как найти ближайшее кафе, достопримечательность, свободное такси глазами программиста