Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Что быстрее, триггер или процедура?
|
|||
|---|---|---|---|
|
#18+
Приветствую многоуважаемый all. Ситуация следующая: в БД непрерывным потоком (~ 30 записей/сек) льются данные, которые необходимо оперативно обрабатывать. Обработка связана с функционированием realtime-сервисов. Так как данные приходят из различных источников, а бизнес-логика их обработки весьма нестационарна и нетривиальна, пришлось весь функционал обработки переложить на СУБД (благо Postgres позволяет :)). Обработка в общем сводится к следующему: данные валидируются, обсчитываются, сами данные + результаты сохраняются в таблице. В связи с этим возник вопрос: что будет работать быстрее? 1) Процедура, вызываемая сторонними приложениями. 2) Триггер, который вешается на inset. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2005, 17:32 |
|
||
|
Что быстрее, триггер или процедура?
|
|||
|---|---|---|---|
|
#18+
я придерживаюсь такой логикой: если обсчет достаточно тяжелый то лучще 1 вариант.. можно хоть как то "рулить" нагрузкой и тормозить вставка не будет. если же обсчет легкий и не лезет активно в другие таблицы базы то разумнее конечно вариант 2. при этом insert заменить на копу... у меня достаточно шустро работает схема Copy $TABLE->Trigger Before Insert ( update $TABLE ;if update_rows=NULL then return new; else return null; endif;) и гораздо быстрее просто while () { update $TABLE; if update_rows=NULL then inser $TABLE'; } в твоем случае видимо стоит выбирать 1) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 10:26 |
|
||
|
Что быстрее, триггер или процедура?
|
|||
|---|---|---|---|
|
#18+
Считаются (биллуются) телефонные логи. Обсчет тяжеловат в том смысле, что приходится лезть во многие таблицы + производить некие выисления и после всего этого инсертить/апдейтить несколько таблиц. Если реализовывать 1-й вариант (с вызываемой процедурой), то как в этом случае можно будет "рулить" нагрузкой? Кстати, в пиковые моменты может быть до 50 запросов/сек, с чем процедура пока не справляется :( И можно поподробнее, плиз, о приведенной схеме. Я в некотором роде чайник в sql-программировании =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 10:55 |
|
||
|
Что быстрее, триггер или процедура?
|
|||
|---|---|---|---|
|
#18+
И еще такая мысль. Повесить триггер на After Insert, и пускай он обсчитывает лог. Таблица ведь лочиться не будет, а при следующей вставке просто породится другой процесс. Правильно ли я мыслю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 11:07 |
|
||
|
Что быстрее, триггер или процедура?
|
|||
|---|---|---|---|
|
#18+
1) Процедура, вызываемая сторонними приложениями. как я понял в этом случае между вставкой строчки и обновлением поля "результаты" может проходить достаточно большое время. и соответственно запуск приложения можно передвинуть на более выгодный момент с точки зрения производительности(например на ноч) это я и имел ввиду под "рулением" тригер afret Insert по скорости почит тожесамое что и тригер before insert... и так же затормозит инсерт.. >Таблица ведь лочиться не будет, а при следующей вставке просто породится другой процесс. 1 конект - 1 процес >И можно поподробнее, плиз, о приведенной схеме. задавай вопросы...подробнее только исходники которые почти не отличаются от того что я написал. >Кстати, в пиковые моменты может быть до 50 запросов/сек, с чем процедура пока не справляется :( индексы, хранимые процедуры на С 50 запросов/сек это мало... что то ты не так написал... подкрудка посгреса в настройках...или у тебя там вселенная общитывается? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 15:20 |
|
||
|
Что быстрее, триггер или процедура?
|
|||
|---|---|---|---|
|
#18+
Я все-таки не пойму, чем по скорости будет отличаться вызов хранимой процедуры (ХП) от срабатывания триггера? Постараюсь описать систему подробнее. Основных путей поступления данных (логов) два. 1) В память форкается демон, который является socket-сервером. На сокет данные приходят с частотой 50 логов/сек. Как только приходит лог, создается отдельный поток , который коннектится к СУБД, "переваривает" этот лог и отдает постгресу. Вот на этой стадии как раз и интересует, как постгре лучше принять эти данные, через вызов ХП или обработать триггером после инсерта? 2) Логи читаются из файла, перевариваются в нужный формат и скармливаются постргесу. Тут, я думаю, имеет смысл создавать какой-нибудь временный файл с инсертами либо вызовом ХП и отдавать его psql. Опять же, что быстрее отработает, ХП или триггер? Первый вариант поступления данных существенно превалирует над вторым и является основным в приложении. Сама процедура/триггер биллует лог телфонного разговора и апдейтит служебные таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 20:35 |
|
||
|
Что быстрее, триггер или процедура?
|
|||
|---|---|---|---|
|
#18+
Если можно, по простому - без триггеров, процедур, AFTER, BEFORE и прочей SQL-лабуды (почти :) ). Имеем лавку с торговым залом и складом. Приходит товар (телефонные логи). Мы и говорим поставщику (процедуре или триггеру) - а ты мил человек распакуй-ка ящички, рассортируй по кучечкам, разложи по полочкам в торговом зале да поналепи бирочки (другими словами тяжелая обработка ввода). Чтоб наш клиент не парился, а бросил взгляд и выбрал чего ему надо, а мы ему еще и кофейку предложим (простой и быстрый пользовательский запрос). Все прекрасно, пока поставщики не налетели как мухи на ... И вот пока одни раскладывают да любуются, у других товар протухает. Чего делать? А вот чего. Сделаем большой холодильник с крышкой кверху, чтоб самосвал принимал (таблицы необработанных данных). И скажем: валите-ка ребятки все в одну кучу, небось поспеете, а дальше не ваша забота (легкий ввод). Клиенту же - а ты браток, вишь-ка - вон кучка - ковыряйся сколь влезет, авось чего найдешь, если ящик на голову не упадет. (сложный и медленный пользовательский запрос). В любом случае одни царствуют, ругие горюют, а дела нет. А видим: разгрузка лихо идет, водилы перекуры устраивают. Э братцы, да от вас не убудет, если вы хотя бы ящики поставите не как попало, а кажный продукт один к одному. А то и в склад успеете доставить (частичная обработка ввода). Да и клиенту сердешному все меньше маяться. А и у самих тоже вроде бы руки не к известному месту пришиты. Вполне могем отбирать товар, удобно складировать и оформлять торговый зал не хуже людей (к примеру периодические обработки на сервере). Клиенту же предложим такое: уж не обессудь если чего в зале не найдешь, у нас и склад есть - там правда кофею не подают, а найти чего хошь тебе посильно будет. Так все при деле, и глядишь дело не загибается. А если серьезно, при выбранном Вами подходе "тяжелого ввода" выбор между процедурами и триггерами не столь важен. ИМХО если какой-то выигрыш и есть, то копейки. Для достижения результата гораздо важнее сбалансировать степень сложности обработки ввода и клиентских запросов, "золотая середина" существует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 21:55 |
|
||
|
Что быстрее, триггер или процедура?
|
|||
|---|---|---|---|
|
#18+
@Vlado Все бы хорошо, но от того, какая информация придет, зависит, сможет ли клиент в дальнейшем "отовариваться в магазине". Данная обработка завязана на функционировании realtime-сервисов. Это как разговоры по мобиле. Позвонил - баланс уменьшился. Только в моем случае перерасхода допустить нельзя. Поэтому в любом сучае обрабатывать логи приходится по мере их поступления. Естесственно, логи обрабатываются настолько, насколько минимально необходимо для функционирования вышеуказанных сервисов. Вся статистика и т.п. обсчитывается при запросе оператора, и в этом случае фактор времени не так существенен. Вобщем, я так понял, что нет никакой разницы, что триггер, что ХП :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 10:27 |
|
||
|
Что быстрее, триггер или процедура?
|
|||
|---|---|---|---|
|
#18+
[quot [DAN]]@Vlado ... Поэтому в любом сучае обрабатывать логи приходится по мере их поступления. ... Вобщем, я так понял, что нет никакой разницы, что триггер, что ХП :)[/quot] если есть понимание, что триггер это такая ХП (и именно ХП) которая только лишь вызывается по мере поступления - то "дразницы нет". Если считать, что ХП все-таки можно вызывать не на каждую вставку/редактирование, а с некой периодичностью, то дразница появляется в способах обработки (если в триггере "на каждую запись" вы монохерственно пересчитываете агрегаты по всем данным - то зачем? делать это на каждую запись - делайте 1-2 раза в секунду. Весь вопрос в самой возможности "проредить" тяжелые операции. Т.е. допускается это предметной областью, или нет). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 11:07 |
|
||
|
Что быстрее, триггер или процедура?
|
|||
|---|---|---|---|
|
#18+
4321Весь вопрос в самой возможности "проредить" тяжелые операции. Т.е. допускается это предметной областью, или нет О чем и речь. Предметная область подразумевает применение "тяжелых" операций к каждому логу, вне зависимости от наличия (или отсутствия) сопряженных обсчетов. Представьте, что вы совершили некий телефонный разговор. Для того, чтобы вы могли позвонить в следующий раз, ваш баланс после состоявшегося разговора должен быть актуален на момент запроса следующего звонка, должно быть определено направление и тариф звонка, должен быть выставлен лимит времени разговора и т.д. Соответственно, при факте состоявшегося разговора приходит лог, который и необходимо обработать по всем вышеуказанным параметрам, и как итог обновить состояние вашего баланса. В этом смысле я не вижу разницы между применением триггера и ХП. Если по скорости работы они приблизительно одинаковые, то мне представляется удобнее использовать триггер. Спасибо всем участникам обсуждения! Если по вопросу есть мнения, с превиликим удовольствием выслушаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 12:53 |
|
||
|
Что быстрее, триггер или процедура?
|
|||
|---|---|---|---|
|
#18+
[DAN] , если 50 логов - это имеется ввиду 50 файлов (читай - наборов строк, каждая строка - один разговор), то, имхо, лучше использовать триггер, и вставлять каждый лог через COPY - экономия при выстраивании плана запроса и уменьшение количества запросов к базе (в моем случае). У меня база по обсчету интернет-трафика. поступает файл с данными, я его COPY сую в Postgres, триггер обрабатывает - определяет тип трафика и клиента, которому принадлежит IP и т.д. 2500 строк обрабатывается примерно 6-7 сек. (XEON 2х2.8) (на неоптимизированной БД) Думаю, у тебя похожая ситуация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2005, 11:08 |
|
||
|
Что быстрее, триггер или процедура?
|
|||
|---|---|---|---|
|
#18+
Скрябин Дмитрий [DAN] , если 50 логов - это имеется ввиду 50 файлов (читай - наборов строк, каждая строка - один разговор), то, имхо, лучше использовать триггер, и вставлять каждый лог через COPY - экономия при выстраивании плана запроса и уменьшение количества запросов к базе (в моем случае). У меня база по обсчету интернет-трафика. поступает файл с данными, я его COPY сую в Postgres, триггер обрабатывает - определяет тип трафика и клиента, которому принадлежит IP и т.д. 2500 строк обрабатывается примерно 6-7 сек. (XEON 2х2.8) (на неоптимизированной БД) Думаю, у тебя похожая ситуация. Привет, та же задача, всё так же сделано, только вот про "каждый лог через COPY - экономия " можно подробнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2005, 01:50 |
|
||
|
Что быстрее, триггер или процедура?
|
|||
|---|---|---|---|
|
#18+
4_Alex Привет, та же задача, всё так же сделано, только вот про "каждый лог через COPY - экономия " можно подробнее? При запросах (вставке данных через insert) сначала выполняется разбор запроса - какие таблицы, какие данные, их типы и т.д. Если выполняются одинаковые запросы (select * from table), то план разбора создается только первый раз, затем берется из кеша. Но т.к. вставляемые данные всегда разные, то разбор выполняется для каждой строки. Также для каждой строки проверяются внешние ключи и т.д. А при копи все это делается только один раз. разбор - в начале, проверка на условия и ключи - после вставки. Если данных много, то выйгрыш в скорости заметен. Это я так себе понимаю. В доках написано не много про это, но по аналогии с другими БД, можно предположить так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2005, 08:45 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=345&tid=2007361]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
65ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
| others: | 271ms |
| total: | 454ms |

| 0 / 0 |
