Здравствуйте

Задача - рилтайм заливка данных по odbc в базу, и там по поступлению - оперативная обработка.
Не очень сложная, но оперативность нужна максимально возможная.
Особенность в том, что могут быть разрывы связи.
После этого в худшем случае будет перезаливка данных в размере 1млн. записей)))
Это до 50 мб примерно.
Причем льется и последнее самое, и история вперемешку))
Контроль будет по еще одной таблички, там примерно последние данные
Так что можно оценить примерно что подтянулось уже... как-то))
Самый оперативный расчет-1 делается по данным за последние секунды
Фоном идет расчет-2 чуть большего диапазона, его можно раз в минуту, например

Идеи:
1. Заливка в таблицу оптимизированную для памяти.
2. Обработка либо триггером на вставку либо всё-таки в хранимой процедуре, вызываемой по джобу, в бесконечном цикле в ней.
(можно перезапускать раз в час, например).

Текущее содержимое завязать с другой таблицей, вставить итог в третью на обработку, далее можно переносить обработанное.
Может даже и индексы по буферной таблице делать не придется, чтобы вставку не замедляли.
Либо вью сделать...
Это промежуточная таблица, видимо.
С неё потом скидывать в обычную периодически.

В общем, пока вопрос, на что лучше ориентироваться - триггер или хранимая процедура с бесконечным циклом.
Но там WAITFOR нежелателен никакой вообще, просто молотить что есть постоянно.
И если там минимальная пауза 1 сек, то не устроит.
А если без этого, то как к такому сервер отнесется?)))

Скорее всего заливка там идет по одной записи
То есть триггер будет на каждую включаться
Последовательные вызовы не перекроют друг друга в таком бешеном темпе?
Не работал с триггерами, не знаю. Ждут друг друга?

Заранее спасибо за рекомендации.

Microsoft SQL Server 2017 (RTM) - 14.0.1000.169 (X64)

.Евгений,

спасибо за инфу про StreamInsight, это интересно и скорее всего то, что надо. Займусь на досуге. Пока что хотелось бы сделать тем, что есть, и с чем имел дело.

alexeyvg,

Заливка в базу - это настройка источника данных и скармливание его прикладной программе. После чего в указанную таблицу начинают добавляться строки.

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

Вопрос только чтобы триггеры последовательно выполнялись, то есть ждали друг друга. Как это происходит?

Про реализацию джобом - что будет без waitfor?
Сервер не скипит?

Надо проверить, по одной ли записи льется приложения
Если нет, то делать курсором перебор в нужном порядке.

Но даже так вопрос про следующую сработку триггера.
Можно задать, чтобы подождала завершение предыдущей?
Или надо вручную регулировать?
И разные ли таблицы inserted в них видны?
Или если данные в моменте залетают быстрее обработки - в работающей процедуре триггера увидим новые данные по ходу пьесы?

.Евгений,

Про 10 секунд шедулера

То есть нельзя повесить задачу на 10:10:23 ?
Просто из интереса вопрос)

Так и непонятночто будет плохого, нсли сделать хранимую процелуру и написать там что нибудь из серии
While 1=1 begin
select a=count(*) from b (nolock)
End

Вопрос тупой, надо просто глянуть, но что то никто не намекнул)

alexeyvg,

"Было бы ошибкой думать" (с) Ленин

То есть если случится два инсерта рядом, и триггер первого почему-то не закончится до начала второго - то они будут параллельно работать? Или всё же второй будет ждать, пока первый не снимет блокировку? Это в конце произойдет или можно командой сделать внутри триггера - отпустить, а дальше развлекаться с другими таблицами?

В итоге я так и не понял, увижу ли я вторую запись в inserted до щавершения первого триггера.

И еще не понял, разные ли таблицы inserted в двух смежных триггерах? Может она генерится отдельная для каждого?

Руки не дошли почитать) но вроде ответы должны быть неемкие, если так - может подскажете всё же)

alexeyvg,

у нас не люди - у нас людь)))
и не у нас, а у меня, я)))

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

да, в inserted постоянно одна строка

кстати данные заливаются шустренько, 1 млн строк за 200 секунд, это 5000 в секунду, а у меня в прыжке 1500 допустим

триггер instead of на память-оптимизированные таблички не ставится
в варианте обычной таблички с таким триггером вставка во вторую табличку шуршит медленнее

в общем, буду раз вставлять и раз в сутки чистить

Владислав Колосов,

про доставку всё просто
есть приложенька со своей связью, она мне будет пихать данные
когда возникает разрыв - тогда она может танцевать как угодно
реконнект, с последующей перезаливкой данных, возможно
всего миллиона записей за день - легко

так что никаких гарантий, и нужна лишь адекватная реакция на это всё

SIMPLicity_,

между тем в oltp (процедурах, скомпилированных в собственном коде для память-оптимизированных таблиц) - waitfor нельзя))

так что джобом только обычную процедуру вещать с таким циклом, а уже из нее вызывать олтпшку

но вроде у меня триггером должно неплохо получиться

Владислав Колосов,

И что смущает то?
Да, когда связь есть - всё должно щелкать рилтайм. Когда плсле обрыва она восстанавлиаается - в потоке летят свежие данные, а между ними по возможности и старые подливаются. Не я такое придумал, но ничего против не имею)