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

[metaclass]

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

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

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

Comments

[vp.livejournal.com]

Потому что кластер из двух серверов - это достаточно дорогое, слабо тиражируемое решение. Если ты придешь в совхоз имени Фаины Каплан, и скажешь, что в качестве бекграунда тебе надо к системе мониторинга купить за 30 штук 2 сервера, тебя пошлют. То есть решение получается в силу заложенной архитектуры нетиражируемое в массы.
Плюс расход трафика.
Простая арифметика. У тебя парк из 300 единиц техники. Одно дело, когда за 300 SIM карт ты заплатишь по 1 баксу в месяц за трафик при низкой плотности, или по 10 баксов. Для предприятия 300 уе и 3000 уе в месяц - это огромная разница.
Короче, тут чистый маркетинг.

[dmzlj.livejournal.com]

Это ви мине будете рассказывать, что failover кластер из двух нод --- дорогое и сложноые решение?!

300 единиц мы с одной головы легко потянем. В общем, во всем этом пока не прослеживается место для оракла, даже на тупо постгресе сегодня уже обнадеживающие результаты. ПО итогам вчерашнего дня.