MySQL Postgresql / PostGIS - PullRequest
       40

MySQL Postgresql / PostGIS

11 голосов
/ 14 марта 2012

У меня есть координаты широта / долгота в разбитой на 400 миллионов строк таблице MySQL Таблица увеличивается на 2000 записей в минуту, а старые данные сбрасываются каждые несколько недель. Я изучаю способы проведения пространственного анализа этих данных по мере поступления.

Большая часть анализа требует выяснения, находится ли точка в определенном многоугольнике широты или долготы или какие многоугольники содержат эту точку.

Я вижу следующие способы решения проблемы точки в многоугольнике (PIP):

  1. Создайте функцию mysql, которая принимает точку и геометрию и возвращает логическое значение. Просто, но не уверен, как Геометрия может быть использована для выполнения операций с координатами широта / долгота, поскольку геометрия предполагает плоские поверхности, а не сферы

  2. Создание функции mysql, которая принимает точку и идентификатор пользовательской структуры данных и возвращает логическое значение. Вершины многоугольника могут быть сохранены в таблице, и функция может вычислить PIP, используя сферическую математику. Большое количество точек многоугольника может привести к огромной таблице и медленным запросам.

  3. Оставьте данные точек в mysql и сохраните данные многоугольников в PostGIS и используйте сервер приложений для запуска запроса PIP в PostGIS путем поиска точки в качестве параметра.

  4. Перенести приложение из MySQL в Postgresql / PostGIS. Это потребует больших усилий при переписывании запросов и процедур. Я все еще могу это сделать, но насколько хорош Postgresql для обработки 400 миллионов строк. Быстрый поиск в Google "mysql 1 млрд строк" возвращает много результатов. тот же запрос для Postgres не возвращает релевантных результатов.

Хотелось бы услышать некоторые мысли и предложения.

Ответы [ 2 ]

4 голосов
/ 19 сентября 2012

Несколько мыслей.

Во-первых, PostgreSQL и MySQL - совершенно разные звери, когда дело доходит до настройки производительности. Поэтому, если вы идете по пути переноса, будьте готовы пересмотреть свои стратегии индексации. PostgreSQL не только обладает гораздо более гибкой индексацией, чем MySQL, но и табличные подходы также сильно отличаются, что означает, что соответствующие стратегии индексации так же различны, как и тактика. К сожалению, это означает, что вы можете немного побороться. Если бы я мог дать совет, я бы предложил сначала удалить все неключевые индексы, а затем экономно добавлять их обратно по мере необходимости.

Второй момент заключается в том, что никто здесь не может дать вам огромное количество практических советов на данный момент, потому что мы не знаем внутренностей вашей программы. В PostgreSQL лучше всего индексировать только то, что вам нужно, но вы можете индексировать выходные данные функций (что действительно полезно в подобных случаях) и индексировать только часть таблицы.

Я скорее парень из PostgreSQL, чем парень из MySQL, так что, конечно, я думаю, что вы должны использовать PostgreSQL. Однако вместо того, чтобы объяснять вам, почему и т. Д., И чтобы вы боролись в таких масштабах, я расскажу вам несколько вещей, на которые я бы посмотрел, если бы попытался это сделать.

  • Функциональные показатели
  • Напишите мои собственные функции для индексов для связанного анализа
  • PostGIS довольно удивительный и очень гибкий

В конце концов, переключение дБ на этом томе станет кривой обучения, и вы должны быть к этому готовы. Однако PostgreSQL прекрасно справляется с объемом.

2 голосов
/ 22 марта 2012

Количество строк здесь не имеет значения. Вопрос в том, какую часть работы в многоугольнике можно выполнить с помощью индекса.

Ответ на этот вопрос зависит от размера полигонов.

PostGIS очень быстро находит все точки в ограничительной рамке многоугольника. Затем требуется больше усилий, чтобы выяснить, действительно ли точка находится внутри многоугольника.

Если ваши полигоны маленькие (маленькие ограничивающие рамки), запрос будет эффективным. Если ваши полигоны большие или имеют форму, которая ограничивает ограничивающий прямоугольник, то это будет менее эффективно.

Если ваши полигоны более или менее статичны, есть обходные пути. Вы можете разделить свои полигоны на более мелкие полигоны и воссоздать idnex. Тогда индекс будет более эффективным.

Если ваши полигоны на самом деле являются мультиполигонами, первый шаг - разделить мультиполигоны на полигоны с помощью ST_Dump и воссоздать и построить индекс по результату.

НТН

Никлас

...