Admin ›
Технология In-Memory OLTP (для SQL Server 2014) ›
#12
04.10.16 10:48
Статья вызвала удивление.
Если мы переносим бизнес-логику на SQL-сервер, то мы вообще-то теряем те самые управляемые блокировки платформы, т.к. они реализованы на уровне сервера приложений.
Потому что бизнес-логика в ряде мест не укладывается в пресловутый Read Committed.
Описанное преимущество "мультиверсионности" и отсутствия необходимости в блокировках не выдерживает критики - СУБД-версионники существуют десятки лет, Read Committed Snapshot для MS SQL поддерживается начиная с 8.3, но когда ты контролируешь остатки, распределяешь партии или взаиморасчеты, концепция "версий" не обеспечивает целостности данных, т.к. недопустимо, чтобы каждый поток видел свою "версию" остатков - здесь бизнес-логика требует видеть реальный остаток именно сейчас. Именно для этого и используются управляемые блокировки, "дополняющие" используемый уровень изоляции СУБД (Да даже в автоматическом режиме с Serializable на регистрах нужно было хинтить for update!).
Показанные замеры с переносом логики в ХП SQL не имеют смысла, если потеряна поддержка управляемых блокировок - потому что очевидно, что при контроле остатков, задержка была именно в ожидании установки блокировки!
Не совсем ясно, как вообще выполняются ХП? откуда берется код? Вот платформа проверяет наличие записей в регистре, проверяет его настройки по метаданным, пишет со сплиттером или без, с учетом разделителя данных в multitanancy и в определенном порядке, добавляет условия RLS,обновляет таблицу итогов - это всё помимо управляемых блокировок. Неужто всё это перенесено на уровень SQL и учтено в замерах?
Ответ на вопрос "директора" есть на ИТС, ИС, Мисте, где угодно, странно видеть это основанием к подобному исследованию.
