Распределенный Postgresql срач
Mar. 25th, 2010 07:18 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassВ итоге, в разборки насчет использования ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
dmzlj postgresql под приличной нагрузкой в системе GPS-мониторинга подключили всех до кого смогли дотянутся, вплоть до разработчиков postgresql.
Я потерял нить обсуждения где-то в конце, но судя по результатам, ключевой аспект шизы был в двух вещах: фрагментированность данных и индекса (условно говоря - на каждую интересующую нас запись нужно было читать целую страницу данных, в которой все остальное нас не касалось) и нехватка памяти для кэша, в результате чего все начинало тормозить.
В качестве решения проблемы в итоге предложили какое-то хитрое двухуровневное партиционирование, которое должно устранить проблему фрагментации - сначала партиционировать сильно актуальные данные (текущий день(неделя, месяц)) по hash id объекта, затем переносить данные в партиции по времени кусками с одинаковыми id чтобы избежать фрагментации.
dmzlj postgresql под приличной нагрузкой в системе GPS-мониторинга подключили всех до кого смогли дотянутся, вплоть до разработчиков postgresql.Я потерял нить обсуждения где-то в конце, но судя по результатам, ключевой аспект шизы был в двух вещах: фрагментированность данных и индекса (условно говоря - на каждую интересующую нас запись нужно было читать целую страницу данных, в которой все остальное нас не касалось) и нехватка памяти для кэша, в результате чего все начинало тормозить.
В качестве решения проблемы в итоге предложили какое-то хитрое двухуровневное партиционирование, которое должно устранить проблему фрагментации - сначала партиционировать сильно актуальные данные (текущий день(неделя, месяц)) по hash id объекта, затем переносить данные в партиции по времени кусками с одинаковыми id чтобы избежать фрагментации.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-03-25 07:39 pm (UTC)no subject
Date: 2010-03-25 07:42 pm (UTC)ну и будет учитывать то что когда я в 9 утра начал заниматься этой проблемой - то я уже не спал более суток ;]
no subject
Date: 2010-03-25 07:45 pm (UTC)no subject
Date: 2010-03-25 07:49 pm (UTC)эксперты такие эксперты...
(no subject)
From:(no subject)
From:(no subject)
From: (Anonymous) - Date: 2010-03-26 04:16 am (UTC) - Expandno subject
Date: 2010-03-25 07:51 pm (UTC)IOT вроде не умеет и читать данные только из индексов, если их хватает для запроса, судя по сегодняшним тестам - тоже.
А компрессия индексов (префиксная что ли?) это видимо тут бы помогло прилично, да.
(no subject)
From:(no subject)
From:no subject
Date: 2010-03-25 07:45 pm (UTC)no subject
Date: 2010-03-25 07:47 pm (UTC)no subject
Date: 2010-03-25 08:59 pm (UTC)(no subject)
From:(no subject)
From: (Anonymous) - Date: 2010-03-26 04:14 am (UTC) - Expand(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From: (Anonymous) - Date: 2010-03-27 04:50 pm (UTC) - Expandno subject
Date: 2010-03-25 07:41 pm (UTC)no subject
Date: 2010-03-25 07:43 pm (UTC)no subject
Date: 2010-03-25 08:03 pm (UTC)2. Если селективность по дате (судя по запросам это сутки) сопоставима с селективностью по id (если id в пределах тысячи, то за три года селективность будет аналогичная), то "event_id_dt" btree (id, dt) -> "event_dt_id" btree (dt, id) - записи в индексе меньше фрагментироваться будут и тогда event_id_idx можно оставить
3. непонимаю, как помогло партицирование данных, если в запросе выбирается id и dt которые в индексе есть - т.е. к данным нормальный сервер вообще не полезет
no subject
Date: 2010-03-25 08:05 pm (UTC)no subject
Date: 2010-03-25 08:08 pm (UTC)no subject
Date: 2010-03-25 08:07 pm (UTC)no subject
Date: 2010-03-25 08:09 pm (UTC)Кстати
Date: 2010-03-26 04:27 am (UTC)no subject
Date: 2010-03-25 08:54 pm (UTC)no subject
Date: 2010-03-25 09:01 pm (UTC)Сразу отметается постановка геморозадачи.
no subject
Date: 2010-03-25 09:05 pm (UTC)И ваще, с глубоким партиционированием даже мнезия работает ok. У нас так и есть, собственно.
А вот сумасшедшие железнодорожники хотят ваще скважность полсекунды. К вопросу о. У них, правда паровозов не так много.
no subject
Date: 2010-03-25 09:10 pm (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2010-03-26 08:01 am (UTC)Потому что априори ЗАКАЗЧИК - НЕ СПЕЦИАЛИСТ в области автоматизации, которую он затевает. Это мы специалисты, а он что-то по вершкам схватил и кричит об этом.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2010-03-26 05:54 am (UTC)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
Сюда включено всё - стоянки, повороты, движение.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2010-03-26 09:50 am (UTC)no subject
Date: 2010-03-26 10:10 am (UTC)no subject
Date: 2010-03-26 10:28 am (UTC)С выбросами боремся тучей алгоритмов.
1. Если стоянка, то координата усредняется
2. изменения координат фильтруются вариацией на тему медианного фильтра
3. скорость постоянно пересчитывается вручную (есть недоверие к тому, что насчитывают приборы)
4. скользящими окнами высчитываются 2е производные на предмет "а не уплющило ли от такого скачка там водителя насмерть", и по таким критериям бракуются скачки как невозможные.
Вот пример картинки эффективности выбранных алгоритмов.
ЗЫ Конечно, когда имеет место залочка на приборы одного типа и они НОРМАЛЬНЫЕ, масса подобных мер не нужна :)
(no subject)
From:(no subject)
From:(no subject)
From: