Приветствую SQL сообщество! :)

Работаю на данный момент над такой задачкой:

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

Вопрос: как произвести быструю, посекундную агрегацию данных исходя из того что, они поступают несколько раз за секунду?

Произвел решение при помощи триггера на Insert, Udate - generate_series - под количество секунд, но оно очень долгое. А мне как бы надо on the fly как говорится, ну понятно что с отставанием получится, ну и что т.к. данные не всегда льются большим потоком, бывают и моменты затухания. Обработанные данные выгружаю в отдельную таблицу, уже по секундно.

Буду рад вдруг кто подскажет решение или направит куда копать!

V&N,

у меня же Postgresе все данные хранятся, куда я уже без него денусь :) CREATE MATERIALIZED VIEW этим не пользовался ни разу. можно подробнее? как мне это может помочь?

V&N,

в каком виде данные выложить? если просто в пост засунуть тут за секунду 2000 строк :)

триггер на апдейт только есть, его смысл в том что он берет из таблицы, в которую поступают данные, скидывает в новую таблицу по событиям update, он не тормозит скидывает как надо без глюков.

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

V&N,

данные выгрузил в csv.

V&N Рома НК, несколько запутанно получается ...
- insert
- не понятно (на агрегированной таблице), что провоцирует апдейт?

1) как заливаются данные из источника построчно или пакетом?
2) на исходной таблице индексы и триггеры есть?
для ускорения понадобится индекс, а возможно и триггер. (тормознет вставку)
3) пример агрегированной таблицы (структуру и ожидаемый результат на основе csv).
4) "задним" числом из источника данные прийти могут?

Да наверное я запутал все, иногда сложно объяснить что тут к чему...

Есть поставщик данных в виде сторонней проги, она кидает мне в БД, использует изначально Insert (проверял если таблица пустая), потом Update, данные в виде 40 строк, когда попадают мне в таблицу, срабатывает мой триггер на insert\update, который полученные и обновленные данные скидывает в другую таблицу, в которой они копятся т.к. я подумал что пока буду скидывать, а потом придумаю как их обрабатывать. по идее их надо обработать за миллисекунду и результаты посекундно записать в новую таблицу, по которым в дальнейшем будет проводиться анализ, это уже другая задача. последовательность что выше описал это все как-бы по моей идеи, хотя не исключаю что можно и по другому реализовать.

1. данные льются пакетом сразу 40 строк, за такт обновления, как видно на практике могут быть разрывы по времени в миллисекундах, но всегда по 40!
2. триггер только на той таблице что принимает эти 40 строк, его задача перекинуть эти 40 строк за такт в другую таблицу, чтобы там их аккумулировать для дальнейших вычислений, т.к. в новом такте этих данных уже не будет, прилетят новые 40 строк. пока без индекса, тут ускорять пока нечего еще :)
3. над примером работаю, еще не готово, но уже кажется что с агрегацией как таковой я погорячился, скорее надо делать вычисления, которые будут следить за изменениями потока данных, сегодня доделаю как должны быть на выходе результаты. скину.
4. задним не могут прийти, я так понял что пришло то пришло, разрывы могут быть по времени за такт, но целостность 40 строк всегда присутствует, т.е. если вдруг за какой-то такт данные по какой-то причине не дошли, то ничего не обновляется, а как приходят то сразу на 40 строк, по другому не бывает, если скажем 10 строк пришли, а другие 30 нет, всегда по 40 или вообще нет. недостаток данных несколько раз за миллисекунду на информативность не влияют, и такая погрешность не значительна, тут сама концепция работать с тем что пришло, т.е. пришло 40 строк за 1 такт - накопили за 1 сек - провели вычисления в пределах 1 сек - записали результат - проанализировали.

[quot LeXa NalBat]Рома НКв оригинальном виде, без ваших триггеров, система работает, данные обновляются, постгрес успевает?

вы хотите залогировать изменения, верно? делайте это тригером AFTER UPDATE, проверяйте, изменилось ли хотя бы одно поле в строке, и тогда записывайте INSERT-ом строку NEW.* в дополнительную лог-таблицу. у неё такие же поля, как у целовой и дополнительно еще текущее время.

да постгрес успевает обрабатывать все что приходит. проблем с записью в новую таблицу пакетных данных нет, вся проблема в том, что надо проводить вычисления по поступающим данным, за 1 секунду данные успевают обновиться 2000-3000 строк, как быстро посчитать изменения и результаты записать для дальнейшего анализа вот вопрос, дело в том, что надо учесть еще и масштабируемостью.

скоро доделаю пример на выходе и выложу, если интересно посмотрите.

V&N Рома НК , заархивируйте - попробуйте на сайт.
боюсь, что MATERIALIZED VIEW вам не подойдут, хотя ...
Materialized Views] http://wiki.postgresql.org/wiki/Materialized_Views

Добрый день. сегодня добил MATERIALIZED VIEW, точно не подойдут мне :) зато узнал что-то новое, попробую применить где-нибудь. :)


При использовании сложных запросов с группировками и объединениями таблиц при построении материализованных представлений, может образоваться огромное количество блокировок, приводящих к катострофическим потерям производительности. Поэтому рекомендуется не строить синхронные материализованные представления с использованием сложных запросов, или, если необходимо это сделать, использовать асинхронные материализованные представления с типом обновления COMPLETE, т.к. они используют блокировки строк только на момент своего обновления.

еще и в дальнейшем можно на блокировки попасть, что мне наверное не надо, так что отложил в сторону.