Распределенный Postgresql срач

[metaclass]

В итоге, в разборки насчет использования dmzlj postgresql под приличной нагрузкой в системе GPS-мониторинга подключили всех до кого смогли дотянутся, вплоть до разработчиков postgresql.

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

В качестве решения проблемы в итоге предложили какое-то хитрое двухуровневное партиционирование, которое должно устранить проблему фрагментации - сначала партиционировать сильно актуальные данные (текущий день(неделя, месяц)) по hash id объекта, затем переносить данные в партиции по времени кусками с одинаковыми id чтобы избежать фрагментации.

Comments

[plumqqz.livejournal.com]

Забавно, что в случае оракла при минимальном применении головы это получилось бы автоматически.

[theiced.livejournal.com]

В итоге - 350 лямов записей на моём девтопе.

[madeveloper.livejournal.com]

1. event_id_idx - долой
2. Если селективность по дате (судя по запросам это сутки) сопоставима с селективностью по id (если id в пределах тысячи, то за три года селективность будет аналогичная), то "event_id_dt" btree (id, dt) -> "event_dt_id" btree (dt, id) - записи в индексе меньше фрагментироваться будут и тогда event_id_idx можно оставить
3. непонимаю, как помогло партицирование данных, если в запросе выбирается id и dt которые в индексе есть - т.е. к данным нормальный сервер вообще не полезет

[dmzlj.livejournal.com]

И что-то это такой все гиморой в итоге, что я уже не рад, что ввязался.

[denisioru.livejournal.com]

Коль скоро тут GPS-навигации тред, то спрошу - как народ борется со сменой спутников при длительных стоянках? Выбросы +- хренова туча метров. Причем отличить такие выбросы от штатного движения порой не совсем просто.