Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
dklim.kzn Member Откуда: Казань Сообщений: 123 |
Здравствуйте Задача - рилтайм заливка данных по odbc в базу, и там по поступлению - оперативная обработка. Не очень сложная, но оперативность нужна максимально возможная. Особенность в том, что могут быть разрывы связи. После этого в худшем случае будет перезаливка данных в размере 1млн. записей))) Это до 50 мб примерно. Причем льется и последнее самое, и история вперемешку)) Контроль будет по еще одной таблички, там примерно последние данные Так что можно оценить примерно что подтянулось уже... как-то)) Самый оперативный расчет-1 делается по данным за последние секунды Фоном идет расчет-2 чуть большего диапазона, его можно раз в минуту, например Идеи: 1. Заливка в таблицу оптимизированную для памяти. 2. Обработка либо триггером на вставку либо всё-таки в хранимой процедуре, вызываемой по джобу, в бесконечном цикле в ней. (можно перезапускать раз в час, например). Текущее содержимое завязать с другой таблицей, вставить итог в третью на обработку, далее можно переносить обработанное. Может даже и индексы по буферной таблице делать не придется, чтобы вставку не замедляли. Либо вью сделать... Это промежуточная таблица, видимо. С неё потом скидывать в обычную периодически. В общем, пока вопрос, на что лучше ориентироваться - триггер или хранимая процедура с бесконечным циклом. Но там WAITFOR нежелателен никакой вообще, просто молотить что есть постоянно. И если там минимальная пауза 1 сек, то не устроит. А если без этого, то как к такому сервер отнесется?))) Скорее всего заливка там идет по одной записи То есть триггер будет на каждую включаться Последовательные вызовы не перекроют друг друга в таком бешеном темпе? Не работал с триггерами, не знаю. Ждут друг друга? Заранее спасибо за рекомендации. Microsoft SQL Server 2017 (RTM) - 14.0.1000.169 (X64) |
8 мар 19, 12:03 [21827875] Ответить | Цитировать Сообщить модератору |
aleks222 Member Откуда: Сообщений: 1245 |
Слишком мутный поток сознания. |
8 мар 19, 17:31 [21828045] Ответить | Цитировать Сообщить модератору |
.Евгений Member Откуда: Сообщений: 654 |
dklim.kzn, Вы хотите натянуть СУБД на поток данных. Это плохая идея, потому что СУБД всегда работает с пачками данных в рамках транзакций. Существуют технологии, гораздо лучше подходящие для этого класса задач. Например, для гарантированной доставки есть интеграционная шина. Для потоков данных - решения класса StreamInsight или доработанного напильником ETL. |
8 мар 19, 19:35 [21828092] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
Скажем, ввёл операционист данные платежа, в результате обработки всё посчиталось, и засунулось в нужные таблицы. Так что по первому пункту вопрос непонятен - сама процедура заливки и является "обработкой". Дальше вопрос, как это технически организовать, но тут слишком мало информации. Какие то "рилтайм заливка данных по odbc в базу", что это такое? Вот, например, вызов хранимой процедуры для вставки данных - это тоже "рилтайм заливка данных по odbc в базу", и в процедуре можно как раз сделать ту самую обработку. Идея с триггером вообще не очень хороша, триггеры не предназначены для обработки, но можно и ими сделать. А то, что считается фоном, можно считать в джобе. |
||
8 мар 19, 21:43 [21828158] Ответить | Цитировать Сообщить модератору |
dklim.kzn Member Откуда: Казань Сообщений: 123 |
.Евгений, спасибо за инфу про StreamInsight, это интересно и скорее всего то, что надо. Займусь на досуге. Пока что хотелось бы сделать тем, что есть, и с чем имел дело. |
8 мар 19, 21:53 [21828162] Ответить | Цитировать Сообщить модератору |
dklim.kzn Member Откуда: Казань Сообщений: 123 |
alexeyvg, Заливка в базу - это настройка источника данных и скармливание его прикладной программе. После чего в указанную таблицу начинают добавляться строки. Думаю, триггером можно неплохо сделать. В нем же апдейт таблицы результатов, и потом апдейт таблицы с данными для расчетов (замена имеющегося значения поступившим по данному параметру). Вопрос только чтобы триггеры последовательно выполнялись, то есть ждали друг друга. Как это происходит? Про реализацию джобом - что будет без waitfor? Сервер не скипит? |
8 мар 19, 22:08 [21828172] Ответить | Цитировать Сообщить модератору |
dklim.kzn Member Откуда: Казань Сообщений: 123 |
Надо проверить, по одной ли записи льется приложения Если нет, то делать курсором перебор в нужном порядке. Но даже так вопрос про следующую сработку триггера. Можно задать, чтобы подождала завершение предыдущей? Или надо вручную регулировать? И разные ли таблицы inserted в них видны? Или если данные в моменте залетают быстрее обработки - в работающей процедуре триггера увидим новые данные по ходу пьесы? |
8 мар 19, 22:19 [21828175] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
Вот, исходя из этого, думайте, как и что у вас будет выполняться, и в какой последовательности. |
||
8 мар 19, 22:28 [21828178] Ответить | Цитировать Сообщить модератору |
.Евгений Member Откуда: Сообщений: 654 |
Минимальный шаг шедулера MS - 10 секунд. Максимально возможную оперативность вы не получите в силу отличительных свойств СУБД, со всеми их достоинствами и недостатками. Вы будете класть данные в таблицу и ее индексы, ждать окончания транзакции, бегать по индексу, выполнять код SQL (далеко не самый оперативный язык), еще вами упомянут некий контроль... вы забиваете гвоздь плоскогубцами. Так тоже можно, но заведомо не эффективно. |
||
9 мар 19, 00:05 [21828206] Ответить | Цитировать Сообщить модератору |
aleks222 Member Откуда: Сообщений: 1245 |
Вы бредите. MS SQL = On Line Transaction Processing. Т.е. обработка запросов в текущем времени. Можно, канешно, вещать о "других системах без индексов и транзакций и самых оперативных языках", но если подумать - голое балабольство выходит. Просто ты не умеешь готовить кошек. |
||
9 мар 19, 08:58 [21828273] Ответить | Цитировать Сообщить модератору |
dklim.kzn Member Откуда: Казань Сообщений: 123 |
.Евгений, Про 10 секунд шедулера То есть нельзя повесить задачу на 10:10:23 ? Просто из интереса вопрос) Так и непонятночто будет плохого, нсли сделать хранимую процелуру и написать там что нибудь из серии While 1=1 begin select a=count(*) from b (nolock) End Вопрос тупой, надо просто глянуть, но что то никто не намекнул) |
9 мар 19, 10:51 [21828310] Ответить | Цитировать Сообщить модератору |
.Евгений Member Откуда: Сообщений: 654 |
Я не хочу сейчас что-то доказывать или хвастаться. Я просто спрошу: вы понимаете, что такое StreamInsight и зачем это было создано, причем независимо от MS SQL? "Когда у тебя в руках молоток, все задачи кажутся гвоздями" (Маслоу). |
||||
9 мар 19, 10:57 [21828315] Ответить | Цитировать Сообщить модератору |
dklim.kzn Member Откуда: Казань Сообщений: 123 |
alexeyvg, "Было бы ошибкой думать" (с) Ленин То есть если случится два инсерта рядом, и триггер первого почему-то не закончится до начала второго - то они будут параллельно работать? Или всё же второй будет ждать, пока первый не снимет блокировку? Это в конце произойдет или можно командой сделать внутри триггера - отпустить, а дальше развлекаться с другими таблицами? В итоге я так и не понял, увижу ли я вторую запись в inserted до щавершения первого триггера. И еще не понял, разные ли таблицы inserted в двух смежных триггерах? Может она генерится отдельная для каждого? Руки не дошли почитать) но вроде ответы должны быть неемкие, если так - может подскажете всё же) |
9 мар 19, 11:00 [21828316] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
При этом они накладывают блокировки на те ресурсы, которые нельзя использовать параллельно. Например, при вставке нужно залочить страницу, что бы внести в неё изменения. Соответственно, ответ на ваш вопрос зависит от того, используют ли эти 2 действия один и тот же ресурс так, что бы это нужно было делать монопольно, или нет. Ситуация с триггером тут совершенно не отличается от случая, когда триггера нет.
|
||||||
9 мар 19, 20:36 [21828498] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8353 |
При чём здесь разрывы связи? Вы или гарантируете доставку или не гарантируете. Хоть фоном хоть патефоном. При планировании архитектуры решения таблички - это уже на самом последнем этапе, а Вы начали с табличек. |
9 мар 19, 22:53 [21828568] Ответить | Цитировать Сообщить модератору |
SIMPLicity_ Member Откуда: (((@))) Сообщений: 8823 |
Делаю JOB-ами. Запускаю по-необходимости. |
9 мар 19, 22:56 [21828570] Ответить | Цитировать Сообщить модератору |
dklim.kzn Member Откуда: Казань Сообщений: 123 |
alexeyvg, у нас не люди - у нас людь))) и не у нас, а у меня, я))) да, опытным путем установлено, что блокировка отрабатывает как надо сделал табличку, оптимизированную для памяти, и триггер к ней в неё льются данные из приложения, в триггере складываю в другую табличку пришедшие данные попробовал при нуле и 100 записях в ней уходить на ветку тяжелого селекта потом запоминать количество записей во второй табличке - нормально, 0 и 100, как надо да, в inserted постоянно одна строка кстати данные заливаются шустренько, 1 млн строк за 200 секунд, это 5000 в секунду, а у меня в прыжке 1500 допустим триггер instead of на память-оптимизированные таблички не ставится в варианте обычной таблички с таким триггером вставка во вторую табличку шуршит медленнее в общем, буду раз вставлять и раз в сутки чистить |
10 мар 19, 03:05 [21828621] Ответить | Цитировать Сообщить модератору |
dklim.kzn Member Откуда: Казань Сообщений: 123 |
Владислав Колосов, про доставку всё просто есть приложенька со своей связью, она мне будет пихать данные когда возникает разрыв - тогда она может танцевать как угодно реконнект, с последующей перезаливкой данных, возможно всего миллиона записей за день - легко так что никаких гарантий, и нужна лишь адекватная реакция на это всё |
10 мар 19, 03:09 [21828622] Ответить | Цитировать Сообщить модератору |
dklim.kzn Member Откуда: Казань Сообщений: 123 |
SIMPLicity_, между тем в oltp (процедурах, скомпилированных в собственном коде для память-оптимизированных таблиц) - waitfor нельзя)) так что джобом только обычную процедуру вещать с таким циклом, а уже из нее вызывать олтпшку но вроде у меня триггером должно неплохо получиться |
10 мар 19, 03:14 [21828623] Ответить | Цитировать Сообщить модератору |
Massa52 Member Откуда: Сообщений: 382 |
Я тоже так думал, что там всегда по одной бывает, пока не обжегся, когда туда неожиданно вкатилось больше. |
||
10 мар 19, 12:18 [21828671] Ответить | Цитировать Сообщить модератору |
Mind Member Откуда: Лучший город на Земле Сообщений: 2322 |
|
||||
11 мар 19, 22:25 [21829813] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8353 |
Там вообще путаница в головах - пишет о реалтйме и о том, что данные могут приходить мало того, что с перерывами, так еще и невадилированными. |
12 мар 19, 12:03 [21830082] Ответить | Цитировать Сообщить модератору |
dklim.kzn Member Откуда: Казань Сообщений: 123 |
Владислав Колосов, И что смущает то? Да, когда связь есть - всё должно щелкать рилтайм. Когда плсле обрыва она восстанавлиаается - в потоке летят свежие данные, а между ними по возможности и старые подливаются. Не я такое придумал, но ничего против не имею) |
12 мар 19, 20:43 [21830709] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |