LINUX.ORG.RU

Литература по проектированию систем мониторинга в реальном времени.

 , ,


1

4

Здравствуйте, уважаемые форумчане. В недалеком будущем планируется рефакторинг системы GPS трекинга транспорта.

Задача такая:

Есть худо-бедно работающая система с 2 пользователями. У каждого пользователя есть порядка 100 автомобилей с установленными GPS трекерами. Координаты автомобилей хранятся в БД. В личном кабинете пользователя есть возможность отображения на карте пройденного пути некоторой машины. + Есть возможность составления отчетов (сколько было стоянок на маршруте, средняя скорость движения и т.д.)

В недалеком будущем планируется перепроектировать систему таким образом, что бы ей могли пользоваться до 100 пользователей (у каждого пользователя до 100 автомобилей). Территориально пользователи находятся в Москве и МО.

С учетом новых требований я выделил основные сложные моменты:

Стремительный рост хранимых данных.
За пол года у 2 пользователей накопилось около 100 млн координат автомобилей. А в идеале планируем вытянуть 100 пользователей. Более того, планируем хранить не только координаты автомобилей, но и значения, передаваемые различными датчиками.

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

Составление статистических расчетов для логистов.
Отчеты по средней скорости движения на участке N, общее количество стоянок и т.д.

Подскажите, пожалуйста ответы на следующие вопросы:

Существует ли литература (книги, статьи из журналов и т.д.) по проектированию систем подобного рода ? Какой стек технологий лучше использовать для данной системы ?

Заранее спасибо.

А Вы изучали какие узкие места сейчас в системе? Предположу, что это БД и нужно разделить работу с оперативными данными и данными для статистических отчетов.

four_str_sam ()
Ответ на: комментарий от four_str_sam

Вы абсолютно правы. Сейчас самое узкое место это БД. Банальная выборка координат 1 машины за 1 день занимает не малое время.

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

Есть еще один момент. Предположим у нас будет 100 пользователей по 100 машин у каждого. Предположим, на каждой машине будет только по одному устройству. Итого получается 10 000 устройств, которые отправляют на сервер по 1 запросу раз в 5 мин.

Хотелось бы снизить нагрузку на жесткий диск. Т.е. писать в базу не по принципу пришел 1 запрос, сделали запись, а составить очередь, скажем из 20 запросов (очередь храним в оперативной памяти), после этого записали пачкой. В то же время эти 20 запросов из очереди должны участвовать при отображении текущего местоположения автомобиля.

user1001 ()

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

Как переходный вариант, между текущей моделью и распределённой, рекомендую посмотреть в сторону PostgreSQL[-XL]

pon4ik ★★★★★ ()
Ответ на: комментарий от user1001

Насчет литературы не подскажу, но вообще задача схожа с тем что используется в телекоме для биллинга.
Есть центры авторизации, которые принимают на себя радиус/диаметр трафик, возвращают результат. И периодически синхронизируются с основным ядром системы. В ядре лежит вся информация, в центре авторизации только та которая нужна ему для авторизации и аккаунтинга.

four_str_sam ()
Ответ на: комментарий от four_str_sam

four_str_sam, спасибо за идею про биллинг. Вот только я никак не могу найти статей в которых с технической точки зрения рассматриваются основные подходы и технологии, применяемые в телекомах. Буду очень благодарен за ссылки.

user1001 ()
Ответ на: комментарий от four_str_sam

Спасибо. Как раз читаю. =) Если найду еще интересные статьи, выложу в эту тему. Никто не будет против ?

user1001 ()

вообще не в теме, но подписался.
neo4j прикольная тема. жаль что в 2015 году всё ещё пытаются сохранять gps в SQL базы.
было бы круто посмотреть ваш доклад на какой нибудь конференции когда будете рассказывать что наконец откинули эти предрассудки и храните треки как графы.
или как адреса с ФИАС UID

system-root ★★★★★ ()
Ответ на: комментарий от system-root

system-root, спасибо за ссылку. Обязательно поэкспериментирую. До конференции еще далеко. Но если будут появляться интересные заметки, могу выкладывать в эту тему. Если сообщество не против.

user1001 ()

Стремительный рост хранимых данных.
Составление статистических расчетов для логистов.

Вот в этих двух пунктах я не вижу требования, чтобы все данные были постоянно доступны. Обычная практика - партиционирование. Можно делать это разными способами: средствами СУБД или на уровне приложения. Грубо говоря, оперативные данные, которыми реально кто-то пользуется (для составления маршрутов, отчетов) хранятся в том же месте, где и сейчас, устаревшие данные архивируются в отдельные партиции, таблицы или даже базы. Это не значит, что данные становятся недоступными, просто доступ к ним затрудняется, что сказывается на скорости получения этих данных, зато с оперативными данными работаете, как и раньше.

Оперативная обработка поступающих данных.

Нужно более детально изучать, но первая пришедшая мысль: система подразумевает, что часть данных может теряться (проблемы со связью, например). Первым делом поднял бы такую бд-кэш (кто сказал монго?), в которую поступали бы оперативные данные и в фоне обрабатывались бы и перекладывались в БД приложения (кто сказал постгрес?). Заодно обработчики данных и принимали бы решение о необходимости различных уведомлений.

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

winlook38 ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.