Comments 12
Если столкнётесь с проблемами при увеличении нагрузки, поглядите на фичу под названием Change Data Capture (CDC).
У нас есть сервис который разгребает создаваемые ей таблицы с логами и всё сливает в кролика — не без проблем и ограничений, но вполне работает.
У нас есть сервис который разгребает создаваемые ей таблицы с логами и всё сливает в кролика — не без проблем и ограничений, но вполне работает.
Вот эта часть непонятна совершенно:
независимо от того, роль или имя входа было использовано в предложении AUTHORIZATION, класс appdomain должен быть создан с тем же именем, как и при загрузке сборки в домен. Рекомендуется разделять сборки разными именами appdomain классов, чтобы при падении одной сборки не свалились остальные. Однако если сборки имеют зависимости друг от друга, их нельзя разделить в разные классы.
Ни разу не слышал чтобы "имена appdomain классов" можно было указывать в SQLCLR вручную. В статье эти "appdomain классы" тоже ни разу не упомянуты...
В нашей системе мы используем сервис-посредника между SqlService Broker и RabbitMq, так как не хотели мучиться с поддержкой CLR процедур. Производительность отличная и при увеличении нагрузки. Вообще в идеальном мире хотелось бы отправлять в кролика данные только из сервисов, но легаси части системы не позволяют
Статья про то, как не стоит делать
Как бы вы сделали? Просто мы ищем альтернативные решения.
У нас есть «подобный» функционал через CLR по вызову SOAP сервисов из SQL. И при определенной нагрузке падает SQL сервер, именно из-за CLR вызовов.
Правильно писать в базу из среднего слоя и если транзакция закомичена успешно, то вызывать отправку сообщения в MQ.
Правильно писать в базу из среднего слоя и если транзакция закомичена успешно, то вызывать отправку сообщения в MQ.
Мы написали свой сервис, который выгребает из SQL и складывает в Rabbit (или на самом деле куда нужно). Все-таки SQL в первую очередь это про хранение данных, а всякая логика по отправке сообщений это не его зона ответственности, имхо. Из плюсов: сервис легко деплоить куда надо, писать можно на чем угодно, при смене БД ниче не разломается, он легко тестируется и так далее.
С точки зрения использования собственных сборок на SQL, мы их тоже юзаем, но например в задаче подсчета площади геометрий в реальных (!) метрах. SQL из коробки это делать не умеет (STArea возвращает на самом деле не реальные площади если хранить данные в планарных координатах). В этом смысле мы лишь расширяем функционал по чтению данных, но при этом не возлагаем никаких бизнес-операций на БД.
С точки зрения использования собственных сборок на SQL, мы их тоже юзаем, но например в задаче подсчета площади геометрий в реальных (!) метрах. SQL из коробки это делать не умеет (STArea возвращает на самом деле не реальные площади если хранить данные в планарных координатах). В этом смысле мы лишь расширяем функционал по чтению данных, но при этом не возлагаем никаких бизнес-операций на БД.
Без транзакционной консистентности не интересно.
Хочется гарантий, что сообщения добавлены в очередь только при успешном коммите транзакции, и отброшены в остальных вариантах.
Хочется гарантий, что сообщения добавлены в очередь только при успешном коммите транзакции, и отброшены в остальных вариантах.
Вы бы лучше написали как в SQL Server подписываться на сообщения.
Sign up to leave a comment.
RabbitMQ — SQL Server