Распределенный Postgresql срач
Mar. 25th, 2010 07:18 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassВ итоге, в разборки насчет использования ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
dmzlj postgresql под приличной нагрузкой в системе GPS-мониторинга подключили всех до кого смогли дотянутся, вплоть до разработчиков postgresql.
Я потерял нить обсуждения где-то в конце, но судя по результатам, ключевой аспект шизы был в двух вещах: фрагментированность данных и индекса (условно говоря - на каждую интересующую нас запись нужно было читать целую страницу данных, в которой все остальное нас не касалось) и нехватка памяти для кэша, в результате чего все начинало тормозить.
В качестве решения проблемы в итоге предложили какое-то хитрое двухуровневное партиционирование, которое должно устранить проблему фрагментации - сначала партиционировать сильно актуальные данные (текущий день(неделя, месяц)) по hash id объекта, затем переносить данные в партиции по времени кусками с одинаковыми id чтобы избежать фрагментации.
dmzlj postgresql под приличной нагрузкой в системе GPS-мониторинга подключили всех до кого смогли дотянутся, вплоть до разработчиков postgresql.Я потерял нить обсуждения где-то в конце, но судя по результатам, ключевой аспект шизы был в двух вещах: фрагментированность данных и индекса (условно говоря - на каждую интересующую нас запись нужно было читать целую страницу данных, в которой все остальное нас не касалось) и нехватка памяти для кэша, в результате чего все начинало тормозить.
В качестве решения проблемы в итоге предложили какое-то хитрое двухуровневное партиционирование, которое должно устранить проблему фрагментации - сначала партиционировать сильно актуальные данные (текущий день(неделя, месяц)) по hash id объекта, затем переносить данные в партиции по времени кусками с одинаковыми id чтобы избежать фрагментации.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-03-26 08:02 am (UTC)no subject
Date: 2010-03-26 08:09 am (UTC)no subject
Date: 2010-03-26 08:20 am (UTC)Это неправильная постанвока вопроса.
Критерий - трек должен быть адаптивным, то есть отрисовка должна быть по критериям поворотов на заданный угол, ускорения и замедления. Плюс гарантированный минимальный период передачи.
У нас по опыту любая специфичная бизнес-логика отрабатывает на настройках 60 минут 15 градусов. Передача идет всегда, и во время стоянок, и ночью. В результате получается с самой психопатической техники типа карьерного самосвала, который ишачит в 3 смены, не более 3000 точек в день, из которых мы можем сделать что угодно.
Хинт: да, бывает неприятная ситуация, когда наша точка интереса находится на пути трека, но по критерию передачи в этой точке не было. У нас на такие случаи отрабатываются механизмы "виртуальных точек". Считается геометрическое пересечение и в этой точке "придумывается" как будто была передача.
no subject
Date: 2010-03-26 08:28 am (UTC)no subject
Date: 2010-03-26 08:45 am (UTC)Причина: превращается в тыкву как только автобус выедет за город и понесется быстро. :)
Есть интересный критерий, который я видел в Автографах: там частота передачи обратно пропорциональная скорости. Весьма интересные результаты. Особенно подходит когда начинается какое-то маневрирование и т.п. Но там тупо нет критерия по углу, а без него это тоже работает плохо.
no subject
Date: 2010-03-26 08:53 am (UTC)no subject
Date: 2010-03-26 09:03 am (UTC)А в особо гуманных есть и магнитный компас и акселерометры и прочая шиза.
no subject
Date: 2010-03-26 09:08 am (UTC)no subject
Date: 2010-03-26 09:14 am (UTC)no subject
Date: 2010-03-26 09:04 am (UTC)no subject
Date: 2010-03-26 09:07 am (UTC)no subject
Date: 2010-03-26 09:15 am (UTC)