ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Проектирование системы сбора геолокационных данных
13 сообщений из 38, страница 2 из 2
  2  все
Проектирование системы сбора геолокационных данных
    #39935580
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Разведка - боем. Почитал про Mongo. Да. Действительно добавили поддержку географических типов и
вроде-бы даже spatial-index поддерживается.

В своих докладах главный постгресщик Бартунов постоянно хвастается что дескыть PG обгоняет
Mongo на поисковых операциях по BSON объектам. Интересно догадался ли он поддержать
спецификацию GeoJSON.
...
Рейтинг: 0 / 0
08.03.2020, 17:04
| Ответить | Цитировать | Написать  
Проектирование системы сбора геолокационных данных
    #39935605
Дмитрий Мух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Мух
Участник
mayton
Разведка - боем. Почитал про Mongo. Да. Действительно добавили поддержку географических типов

Добавили? Ещё в версии 2.
...
Рейтинг: 0 / 0
08.03.2020, 22:39
| Ответить | Цитировать | Написать  
Проектирование системы сбора геолокационных данных
    #39935606
Дмитрий Мух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Мух
Участник
mayton
В своих докладах главный постгресщик Бартунов постоянно хвастается что дескыть PG обгоняет
Mongo на поисковых операциях по BSON объектам.

О да, только никогда не говорит о том, какой движок Mongo они там обгоняют :)
...
Рейтинг: 0 / 0
08.03.2020, 22:41
| Ответить | Цитировать | Написать  
Проектирование системы сбора геолокационных данных
    #39935613
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Где то тут видел. Ближе к концу.

[spoiler]
YouTube Video
YouTube Video
...
Рейтинг: 0 / 0
09.03.2020, 00:02
| Ответить | Цитировать | Написать  
Проектирование системы сбора геолокационных данных
    #39935631
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
mayton
Лохматый чел. приводит табличку где написано Postgresql 9.4 vs Mongo 2.6.0.
Возможно это главенствующие на тот момент (2017 год) версии? Кто знает - подтвердите.

2.6 - это 2014-й год
3.2 - это 2015-й
3.4 - это 2017-й

Вообщем Бартунов кросавчег. Новая версия постгреса обгоняет устаревшую версию монги.
И ведь не поспоришь :)

P. S.: помимо версий у MongoDB есть ещё и различные движки (DB engines).
...
Рейтинг: 0 / 0
09.03.2020, 08:17
| Ответить | Цитировать | Написать  
Проектирование системы сбора геолокационных данных
    #39935632
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
В плане сравнения MongoDB с PostgreSQL, лучше за исследованиями ребят из Percona следить.
...
Рейтинг: 0 / 0
09.03.2020, 08:30
| Ответить | Цитировать | Написать  
Проектирование системы сбора геолокационных данных
    #39935655
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Сейчас посмотрел вот этот документ https://www.percona.com/live/e17/sites/default/files/slides/High Performance JSON - PostgreSQL vs. MongoDB - FileId - 115573.pdf

На ихних тестовых конфигурациях на операции

SELECT
12 ms - Mongo
3 ms - PG

INSERT
13 ms - Mongo
4 ms - PG

Но эти данные все равно сейчас никак не натягиваются на постановку автора. КМК ему все равно как грузить.
С лагом в 10 мс или в 1000. Это ни на что не влияет. Операции - рассеянные. Рандомные.

А выборки ему надо делать по срезу ID-устройства и диапазону времени. Это совсем не тот тип транзакций которые
меряет percona. Там - скорее всего гоняют точечные OLTP выборки по 1 атрибуту.

Поэтому - макет и еще раз макет.
...
Рейтинг: 0 / 0
09.03.2020, 13:40
| Ответить | Цитировать | Написать  
Проектирование системы сбора геолокационных данных
    #39935659
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
mayton
Сейчас посмотрел вот этот документ (подозрительная ссылка!) https://www.percona.com/live/e17/sites/default/files/slides/High Performance JSON - PostgreSQL vs. MongoDB - FileId - 115573.pdf

На ихних тестовых конфигурациях на операции

SELECT
12 ms - Mongo
3 ms - PG

INSERT
13 ms - Mongo
4 ms - PG

Но эти данные все равно сейчас никак не натягиваются на постановку автора. КМК ему все равно как грузить.
С лагом в 10 мс или в 1000. Это ни на что не влияет. Операции - рассеянные. Рандомные.

А выборки ему надо делать по срезу ID-устройства и диапазону времени. Это совсем не тот тип транзакций которые
меряет percona. Там - скорее всего гоняют точечные OLTP выборки по 1 атрибуту.

Поэтому - макет и еще раз макет.

Этот документ надо полностью читать.
Там есть пара-тройка важных нюансов, типа MongoDB из коробки быстро заработала, а PostrgeSQL нам пришлось тюнить...

И выводы в конце о том, почему они таки используют MongoDB.
...
Рейтинг: 0 / 0
09.03.2020, 14:03
| Ответить | Цитировать | Написать  
Проектирование системы сбора геолокационных данных
    #39935661
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Да читал я до конца. Постргесщик должен быть рукастым админом вобщем-то.
Смысл теста я увидел в том что величины ОДНОГО порядка. Хотя бы не в 10 и не в 100 раз
отличаются.
...
Рейтинг: 0 / 0
09.03.2020, 14:15
| Ответить | Цитировать | Написать  
Проектирование системы сбора геолокационных данных
    #39935663
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
mayton
Да читал я до конца. Постргесщик должен быть рукастым админом вобщем-то.
Смысл теста я увидел в том что величины ОДНОГО порядка. Хотя бы не в 10 и не в 100 раз
отличаются.

И сам тест таков:

Insert / Update / Select comparison
Preloaded 10,000,000 records in the table
- No padding - records are ~320 bytes

3 clients running different workloads
- 50 workers inserting
- 50 workers updating
- 50 workers performing a range over partial index

Both databases become CPU bound
- Database server is under maximum load
- Typically avoided in a production environment
- Always good to know your maximum numbers

При этом перед этим расписано, что чисто вставка 10 000 000 записей в монгу прошла быстрее.

А у ТС-а походу как раз в основном вставка и будет.
И с учётом того, что с постгресом он не знаком, а в монге поддержка геоданных из коробки, и тьюнить её не надо.
Я бы таки выбрал MongoDB.
...
Рейтинг: 0 / 0
09.03.2020, 14:26
| Ответить | Цитировать | Написать  
Проектирование системы сбора геолокационных данных
    #39935670
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
mayton
Дизайн подсистемы хранения исторических
данных точняк должен отличатся от дизайна данных оперативных.

Оперативные данные вообще в хранении не нуждаются. По определению их потеря будет автоматически восполнена через пару секунд.
...
Рейтинг: 0 / 0
09.03.2020, 14:41
| Ответить | Цитировать | Написать  
Проектирование системы сбора геолокационных данных
    #39935771
bluestreak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bluestreak
Гость
Areostar
Задача такова

у фирмы много работников, транспорта и т.п. у каждого работника есть смартфон. на этих сматфонах будет размещаться ПО отсылающая на сервер данные их песто положения каждые скажем 5-10 секунд. сервер принемает инфу. Сохраняет.

и отсылает обработанные данные на смартфоны глав групп работников и т.д

Воросы

Какую субд порекомендуете? Я так думаю нужна NOSQL? MongoDB или ещё чего оассмотреть следует

Использовать запросы или сокеты?

если можете посоветовать материалы и примеры то теме, буду благодарен!


Можно предложить вот такую архитектуру:

Смартфон может сохранять данные локально на случай потери сигнала. Когда сигнал появляется то дельта отправляется на сервер. Желательно в формате который серверу не нужно парзить. Т.е. одна и тоже база на клиенте и сервере которая может делать синхронизацию.

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

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

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

Если данные не влазят на один сервер — нагрузка переносится на систему запросов. Нужно объединить тайм серии на разных серверах в одну виртуальную таблицу.
...
Рейтинг: 0 / 0
10.03.2020, 02:08
| Ответить | Цитировать | Написать  
Проектирование системы сбора геолокационных данных
    #39940306
Фотография Areostar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Areostar
Участник
bluestreak,

Спасибо за предложение ))
...
Рейтинг: 0 / 0
23.03.2020, 16:41
| Ответить | Цитировать | Написать  
13 сообщений из 38, страница 2 из 2
  2  все
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Проектирование системы сбора геолокационных данных
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=16&gotonew=1&tid=1339814]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 138ms
get topic data:
 11ms
get first new msg:
 8ms
get forum data:
 2ms
get page messages:
 57ms
get tp. blocked users:
 1ms
others: 11ms
total:  257ms
созд. / загр.: 257ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]