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

Question

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

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

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

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

Answer 1

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

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

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

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

Удачи!

Answer 2

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

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

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

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

Answer 3

На "Как обрабатывать / хранить много точек, поступающих от транспортных средств":

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

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

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

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

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

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

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