PHP, MySQL, пространственные данные и дизайн - PullRequest
Новая
       24

PHP, MySQL, пространственные данные и дизайн

5 голосов
/ 01 июля 2010

Я создаю приложение, в котором координаты транспортных средств регистрируются с помощью GPS. Для начала я хочу реализовать несколько функций, таких как:

  • отслеживание транспортных средств в реальном времени
  • история отслеживания транспортных средств
  • хранение мест и областей для учета клиентов

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

  • Как можно решить ORM для геометрии? Например: местоположение будет преобразовано в класс SpatialPoint, где область будет преобразована в класс SpatialPolygon
  • Как сохранить поток данных, поступающий с транспортных средств? Я думаю о таблице, в которой хранятся последние данные (для данных в реальном времени), и пакетном анализе этих данных в PolyLines в отдельной таблице для целей истории (одна строка на смену сотрудника на транспортном средстве).
  • Mysql, вероятно, не лучший выбор для этого, но я планирую использовать Solr в качестве индекса для быстрого поиска по местоположению. Хотя нам нужно сделать расчет расстояния в реальном времени, например, какое транспортное средство находится ближе всего к клиенту X. Есть мысли?

Ответы [ 3 ]

4 голосов
/ 02 июля 2010

Я могу помочь вам в одном, безусловно, mysql - это лучший выбор, я много раз шел по тому же пути, что и вы, и пространственное расширение mysql просто фантастическое, хотя оно удивительно быстрое даже в течениетаблицы с 5 миллионами + строк пространственных данных, все это в индексе.Пространственное расширение является одним из наиболее хорошо хранимых секретов mysql, которые мало кто использует;)

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

RE массивный поток данных, либо используйте его в режиме реального времени и сохраняйте только каждую десятую запись, либо просто вставьте все это в одну таблицу - это не повлияетскорость из-за того, как таблица индексируется, но соображения размера могут стоить учитывать.

Для альтернативы, исходящей из PHP, вы можете попробовать postgis на postgresql, но я всегда предпочитал mysql для простоты использования, нативныйподдержка и круговая скорость.

Удачи!

3 голосов
/ 06 июля 2010

Да, я рекомендую использовать Solr.Текущая версия 1.4.Это невероятно хорошо работает для этой проблемы.

  1. ORM - Вам может понадобиться sfSolrPlugin с Doctrine ORM, чтобы связать PHP с Solr, см. Статью из LucidWorks под названием Buildingпоисковое приложение за 15 человеко-дней

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

  3. Геопространственный поиск - я использую Плагин пространственного поиска для Apache Solr .Возможности Gs могут быть включены в Solr 1.5.Я считаю, что уже есть некоторая элементарная поддержка gs, без использования плагина.

0 голосов
/ 14 июня 2012

О том, «как обрабатывать / хранить множество точек, поступающих от транспортных средств»:

Я работаю над очень похожим проектом.Я решил эту проблему, поддерживая 2 таблицы (используя MySQL, но это справедливо для любой другой БД):

  • одна для отслеживания объектов (транспортных средств, пользователей и т.д.)

    эта таблица будет иметь идентификатор объекта в качестве первичного ключа, и любые обновления, которые нарушают ограничение первичного ключа, будут обновлять данные, хранящиеся для этого ключа.Это может быть легко достигнуто с помощью «ON DUPLICATE KEY UPDATE». Это делает поиск чрезвычайно быстрым для отслеживания и сохраняет только один экземпляр данных / объекта о местоположении.Я также реализовал серверную логику для удаления записей устаревших данных (по истечении определенного количества времени эти данные должны быть удалены, если на них не было получено никаких обновлений)

  • единица для истории / поискацели

    эта таблица будет иметь идентификатор объекта и метку времени в качестве составного первичного ключа.Таблица может быть разбита на столбец отметки времени.

Любое обновление местоположения объекта будет вставлено в обе таблицы.

Надеюсь, это поможет.

...