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

[metaclass]

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

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

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

Comments

[plumqqz.livejournal.com]

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

[theiced.livejournal.com]

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

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

[plumqqz.livejournal.com]

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

[theiced.livejournal.com]

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

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

[metaclass.livejournal.com]

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

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

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

[metaclass.livejournal.com]

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

[plumqqz.livejournal.com]

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

[dmzlj.livejournal.com]

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

[theiced.livejournal.com]

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

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

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

Кстати

[plumqqz.livejournal.com]

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

[dmzlj.livejournal.com]

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

[vp.livejournal.com]

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

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

[dmzlj.livejournal.com]

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

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

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

[metaclass.livejournal.com]

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

[vp.livejournal.com]

Нельзя идти на поводу у заказчика. И в предметную область надо глубоко залазить, чтоб потом их фейсом об тейбл бить. Это как бы заправка хотела чтоб мы им считали расход топлива в километрах. Вот хотят и все тут, ну что ты будешь делать? Или вопросы недостижимой точности. Всегда есть возможность переубедить заказчика на ранней стадии.
Потому что априори ЗАКАЗЧИК - НЕ СПЕЦИАЛИСТ в области автоматизации, которую он затевает. Это мы специалисты, а он что-то по вершкам схватил и кричит об этом.

[denisioru.livejournal.com]

40 тыщ в сутки это и правда дофига. Это в среднем одна запись в 2 секунды, куда столько? Вот выдержка по живому трекеру по количеству записей:

2010.03.19 5213
2010.03.20 3031
2010.03.21 3109
2010.03.22 2636
2010.03.23 2232
2010.03.24 2548
2010.03.25 2908

Сюда включено всё - стоянки, повороты, движение.

[denisioru.livejournal.com]

Коль скоро тут GPS-навигации тред, то спрошу - как народ борется со сменой спутников при длительных стоянках? Выбросы +- хренова туча метров. Причем отличить такие выбросы от штатного движения порой не совсем просто.

[dmzlj.livejournal.com]

Выбором приемника GPS и акселерометром.

[vp.livejournal.com]

У нас задача вообще обобщенная. Мы делаем софт. Потому сразу считаем, что все приборы разные, есть глупые, есть очень глупые и т.п. Потому все алгоритмы - "наверху".
С выбросами боремся тучей алгоритмов.
1. Если стоянка, то координата усредняется
2. изменения координат фильтруются вариацией на тему медианного фильтра
3. скорость постоянно пересчитывается вручную (есть недоверие к тому, что насчитывают приборы)
4. скользящими окнами высчитываются 2е производные на предмет "а не уплющило ли от такого скачка там водителя насмерть", и по таким критериям бракуются скачки как невозможные.

Вот пример картинки эффективности выбранных алгоритмов.

ЗЫ Конечно, когда имеет место залочка на приборы одного типа и они НОРМАЛЬНЫЕ, масса подобных мер не нужна :)