Где искать информацию о методах реализации сервиса GPS-мониторинга?

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

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

Сейчас я уже дописал серверный python-демон по сборке данных с трекеров, их парсингу и выводу в БД. Демон проходит все круги ада в тестировании и допиливании. Тут проблем вроде как нету. Зато есть проблемы в дизайне будущей БД, потому как по предварительным прикидкам, в сутки БД будет увеличиваться на ~1.5 млн. записей. Пока что есть мысль хранить распарсенные "сырые" данные за 8 часов, остальное ежечасно "архивировать" и складывать в другую таблицу, где они будут лежать еще месяц. Все же что старше месяца уезжает в долгосрочный архив до лучших времен.

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

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

ЗЫ.

- ОС сервера - Ubuntu 12.04 Srv x64
- сборщик данных - python-демон под 2.7 версию
- база - MySQL 5.x (возможно не лучшее решение для этой задачи)
- фронтэнд - PHP + JQuery + Apache

Может что-то упустил в повествовании пока писал, ну дык я уточню.
  • Вопрос задан
  • 2981 просмотр
Пригласить эксперта
Ответы на вопрос 3
begemot_sun
@begemot_sun
Программист в душе.
MySQL по моему не лучшее решение в лоб. Наверное существуют более адекватные БД которые:
1. производят архивацию данных
2. осуществляют доступ к данным по времени
3. осуществляют доступ к данным по местоположению (такое надо ? )

Вообще какие запросы вы планируете обрабатывать в будущем ?

за GPS не скажу, но ваша задача родственна задаче хранения сырых архивов с биржи (посмотрите тут), или хранения статистики (например модифицированное решение приведенное выше - см здесь, или тут большой список БД, может выудите что оттуда ). Там правда выборка возможно только по временному периоду, но наверное большинству это и надо.

В конце концов, почему не написать это самому ? Попробуем ? ;)
Ответ написан
@emakarov
А какие сервисы вы рассматривали?
Мы в cloud.doroga.tv уже много чего решили... и с точки зрения сбора данных, хранения, аналитики и веб интерфейсов...
пишите если есть интерес
Ответ написан
Комментировать
@leclecovich
Попробуйте собирать сырые данные в RRD - кольцевая БД фиксированного размера, для сбора метрик подходит идеально. Есть биндер для Python. После этого данные Вы можете консолидировать/архивировать, к примеру, раз в час/сутки, и хранить их уже в NoSQL хранилище.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы