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

[metaclass]

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

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

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

Comments

[plumqqz.livejournal.com]

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

[theiced.livejournal.com]

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

[theiced.livejournal.com]

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

ну и будет учитывать то что когда я в 9 утра начал заниматься этой проблемой - то я уже не спал более суток ;]

[theiced.livejournal.com]

для статистики - у них уже с десятком лямов всё умирало к хуям.

[metaclass.livejournal.com]

Насколько я помню из обсуждений, Оракл там в бюджет не вписывается, проще немного пошаманить над postgresql или использовать вуду-эрланговую мнезию.

[plumqqz.livejournal.com]

Не получилось бы. Постгрес не умеет партиции, IOT и компрессию индексов (да и данных тоже).

[plumqqz.livejournal.com]

Ну что ж делать, раз не вписывается. Тады, конечно, ой.

[theiced.livejournal.com]

(посмотрел на партиции) точно не умеет?

эксперты такие эксперты...

[metaclass.livejournal.com]

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

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

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

[plumqqz.livejournal.com]

То, что в постгресе называют партициями, не партиции, но всего лишь неумелая подделка под оные. (Нет нормального секционирования индексов, не работают параметры). Внимательней овладевайте документацией.

Настоятельно рекомендую прочитать про партиции в Оракле и партиции и MDC в DB2.

[plumqqz.livejournal.com]

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

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


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

[plumqqz.livejournal.com]

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

[theiced.livejournal.com]

ок. в итоге проблема была успешно решена перманентно сонным мной за рабочий день. великие оракель эксперты всё ещё ставили бы оракель.

[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]

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

[dmzlj.livejournal.com]

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

[dmzlj.livejournal.com]

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

[vp.livejournal.com]

было бы в 1000 раз меньше геморроя если бы заказчика били по рукам на этапе постановки. Ваши 40.000 точек в день нахер никому не упали. У нас самый требовательный к качеству трека транспорт генерит не более 3.000 точек в сутки. И это при круглосуточной работе.

Сразу отметается постановка геморозадачи.

[dmzlj.livejournal.com]

28800. Я что-то не догоняю, откуда 40 взялось. Но на этапе постановки задачи тем более были неясны все вот эти вот нюансы, которые сейчас повылазили.

И ваще, с глубоким партиционированием даже мнезия работает ok. У нас так и есть, собственно.

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

[metaclass.livejournal.com]

Я подозреваю, там что-нибудь из соображений "следить за сверхскоростным поездами". Особо это радует в контексте точности GPS-приемников и скорости выдачи ими результатов :)

[dmzlj.livejournal.com]

Главным образом потому, что они сами не понимают чего хотят, но исходят из того, что если попросят раз в полсекунды, то им будет в случае чего не так худо, как если попросят раз в полминуты. Ну типа они считают, что если что, то из полсекунды полминуты они сделают как-нибудь, а вот наоборот --- никак.

И убедить их врядли в чем-то можно, потому что что такое РЖД и что такое мы.

[max-posedon.livejournal.com]

5k$ за процессор, и это за базовый oracle, не RAC. На простой 4х процессорный сервер(по 2 ядра на каждом). это уже 20k$ + специально-обученный-мальчик-oracle-вод минимум на месяц, ещё 5k$ = 25k$, в России такие дорогие почки, или я таки уже на 3-4 почки насчитал?)