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

[metaclass]

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

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

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

Comments

[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 которые в индексе есть - т.е. к данным нормальный сервер вообще не полезет

[theiced.livejournal.com]

индекс он тоже... того... не совсем маленький, да. где то в 1/4 данных.

[madeveloper.livejournal.com]

т.е. индексы тоже спартицировали?

[madeveloper.livejournal.com]

А, вижу. Судя по появившиеся наверху постам апослягря к нормальным серверам не относится...

[metaclass.livejournal.com]

Лезет к данным. Если я правильно понял комментарий выше - то это следствие версионной архитектуры - лезет проверять версию записи, похоже.

Кстати

[plumqqz.livejournal.com]

Попробуйте pg_reorg на это дело натравить. По id, потом по дате.