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

[metaclass]

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

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

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

Comments

[metaclass.livejournal.com]

partitioning как-то умеет: http://www.postgresql.org/docs/8.4/interactive/ddl-partitioning.html

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

А компрессия индексов (префиксная что ли?) это видимо тут бы помогло прилично, да.

[plumqqz.livejournal.com]

Именно что как-то.

У постгреса довольно ракообразная версионность и он всегда вынужден лазить в таблицу, дабы убедится, жива ли запись или как. Т.е. покрытие индексом в нем не работает. В данном случае это было как серпом по гонадам.


Угу, префиксная. Ну можно и собственно данные пожать.

[plumqqz.livejournal.com]

А, еще маленькое "но". У постгреса оверхед в 26 байт на запись, кроме заголовка страницы, который тоже немаленький. У оракла - два байта, что ли.