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

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

В итоге, в разборки насчет использования

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

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

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

Flat | Top-Level Comments Only

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

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

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

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

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

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

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

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

Я так подозреваю, что скорее отслеживать момент отбытия составов. Там, в общем-то, посекундная точность может быть оправдана.

В смысле, на ЖД несмотря на размеры график надо выдерживать точно. А то торможение за 15 секунд, впаяешься в спину - пред. состава - не отмоешь.

Э-э-э... РЖД хочет заменить машинистов роботами?

Оно всегда хочет. Машинист нужен для исполнения команд диспетчера и форсмажоров. БОльшую часть времени его действия подчинены строгому алгоритму и проходу между блокирующей автоматикой.

Я подозреваю что N-секунд будут лицезреть состав кторый стоит :))

Секунд? Они будут сутками мониторить стоящие составы. А особенно, спецсоставы, которые стоят годами, ну раз в месяц на учения съездят.

Ну для них то точно надо полусекундный апдейт, а то вдруг сопрут!

(no subject)

dmzlj.livejournal.com - 2010-03-26 10:05 (UTC) - Expand

Да вроде же сняли скальпели с вооружения :)

(no subject)

dmzlj.livejournal.com - 2010-03-26 19:45 (UTC) - Expand

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

Это верно когда со стороны заказчика выступает не разработчик. А это именно они, с собственной ГИС РЖД.

И ваще. Я не вижу, почему бы с кластера из двух достаточно мощных серверов не получать 4000 RPS и не держать данные для 10K за полгода.

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

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

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

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

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

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

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

Ну вот и нахера такая плотность? Кто мне объяснит? :)

Это немного же. В средем одна точка каждые 30-34 сек. Где-то чаще, где-то реже. Это для объектов по городу, дабы трек рисовался поточнее.

А давайте одну запись записывать в базу не 1 раз, а 5? Будет еще плотнее.
Это неправильная постанвока вопроса.
Критерий - трек должен быть адаптивным, то есть отрисовка должна быть по критериям поворотов на заданный угол, ускорения и замедления. Плюс гарантированный минимальный период передачи.
У нас по опыту любая специфичная бизнес-логика отрабатывает на настройках 60 минут 15 градусов. Передача идет всегда, и во время стоянок, и ночью. В результате получается с самой психопатической техники типа карьерного самосвала, который ишачит в 3 смены, не более 3000 точек в день, из которых мы можем сделать что угодно.
Хинт: да, бывает неприятная ситуация, когда наша точка интереса находится на пути трека, но по критерию передачи в этой точке не было. У нас на такие случаи отрабатываются механизмы "виртуальных точек". Считается геометрическое пересечение и в этой точке "придумывается" как будто была передача.

Я почему и упомянул слова "стоянки", "движение". Эту интеллектуальную работу выполняет трекер: при движении показания снимаются раз в 15 секунд, но не реже каждых 100 метров, при повороте более чем на 7 градусов - раз в секунду, при стоянке - раз в минуту.

критерий передачи по расстоянию - очень мутная и спорная вещь. Мы от него отказались.
Причина: превращается в тыкву как только автобус выедет за город и понесется быстро. :)

Есть интересный критерий, который я видел в Автографах: там частота передачи обратно пропорциональная скорости. Весьма интересные результаты. Особенно подходит когда начинается какое-то маневрирование и т.п. Но там тупо нет критерия по углу, а без него это тоже работает плохо.