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

[metaclass]

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

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

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

Comments

[metaclass.livejournal.com]

Потому что оракл не вписывается в бюджет, очевидно :)
Кстати, насчет партиционирования pg - я бы входные очереди по id сделал бы не в RDBMS. Хоть плоские файлы, хоть мнезия. А вот архивы за прошлые периоды(или по мере надобности) - в RDBMS, так анализировать проще, ад хок запросами.

[dmzlj.livejournal.com]

Оно на PG сейчас жрет 30K/в секунду с партиционированием на ноутбуке.
С селектами смотрим, 8.6M мгновенно, сейчас посмотрим как на 86M будет