Когда использовать CDC для отслеживания истории?

26

Сбор данных изменений SQL Server - это функция, которая считывает исторические данные из журналов транзакций SQL Server и сохраняет их в специальной таблице.

Благодаря использованию специальных функций табличных значений (TVF) он позволяет пользователю запрашивать эти данные, делая возможным либо получить все изменения в конкретной таблице, либо только чистые изменения, которые произошли в результате изменений в течение определенного времени.

CDC имеет определенные преимущества

Его можно настроить для отслеживания только определенных таблиц или столбцов.
Он способен обрабатывать изменения модели в определенной степени.
Это не влияет на производительность так сильно, как триггеры, потому что он работает с журналами транзакций.
Он легко включается / отключается и не требует дополнительных столбцов в таблице, которые должны отслеживаться.

У этого также есть некоторые недостатки:

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

Я много читал о CDC, и хотя теперь я знаю, как его использовать, я все еще не уверен, является ли это правильным инструментом для меня.

Для каких задач / сценариев CDC является правильным инструментом? (Например, разрешить пользователям восстанавливать объект данных до определенного момента времени? Аудит? Отображение полной истории данных?)
Когда вам лучше не использовать CDC, а прибегнуть к индивидуальному триггерному решению?
Можно ли использовать CDC в оперативной базе данных и использовать данные CDC в оперативном приложении? (например, показывать его конечному пользователю) Или это явно неправильное использование этой функции?

Я часто слышу, что CDC является инструментом аудита, но разве для этого не предназначен SQL Server Audit ? Они оба разные инструменты для одной и той же задачи? Или CDC может использоваться для других вещей?

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

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

sql-server change-data-capture data-versioning

— magnattic
источник

1

В идеале, «структура» не будет принимать такого рода решения; это будет оставлено для отдельных проектов. Но поскольку вас просят сделать это, я бы, по крайней мере, обратил внимание на то, кто предъявляет вам эти требования: существуют разные способы выполнить это, и лучший выбор в значительной степени зависит от точного использования и потребностей. Спросите, могут ли они дать вам какие-либо разъяснения, которые могут помочь вам решить (например, важнее ли производительность или гибкость). Другой вариант, который следует рассмотреть, - это разработать оба варианта как часть «фреймворка» и позволить реальным проектам выбирать, какой из них включить.

— jpmc26

@ jpmc26, рамки могут быть необходимы, чтобы остановить каждый проект тратить время на решение такого рода вопроса.

— Ян Рингроз

@IanRingrose Моя точка зрения заключается в том, что попытка принять это решение без учета конкретных потребностей проекта в долгосрочной перспективе вызовет больше проблем, чем решит (и, следовательно, на самом деле будет стоить дороже, чем тратить это время). Это решение, которое не может быть эффективно принято в общем случае. Специфика проекта должна быть учтена. Используя общее решение, будет потрачено время, используя выбранное решение и делая предположения вокруг него только для тех предположений, которые будут нарушены, когда обнаружится, что это не подходящее решение. Тогда систему нужно будет перепроектировать.

— jpmc26

1

@ jpmc26 Я мог бы пойти на решение, которое вы предложили, на случай, если я найду способ реализовать его: разработку отслеживания истории как на основе триггера, так и на основе CDC, с возможностью переключения и за общим интерфейсом. Затем приложения могут выбирать одно или другое, в зависимости от своих требований, но не нужно беспокоиться о его реализации самостоятельно. Конечно, я все еще хотел бы получить хороший ответ на мой вышеупомянутый вопрос, потому что, если CDC в любом случае не предназначен для такого рода задач (например, потому что он полезен только для аудита), я мог бы избавить себя от проблем и всегда использовать триггеры ,

— Magnattic

«Если агент не работает или аварийно завершает работу, история не отслеживается» - но если он будет перезапущен, изменения не будут потеряны, верно?

— Энди Джоунер

12

Во-первых,

Сбор данных об изменениях доступен только в выпусках SQL Server Enterprise, Developer и Evaluation.

Таким образом, это может решить для вас, не будут ли у ваших клиентов корпоративные выпуски, или вы еще не знаете, будете ли вы использовать корпоративные выпуски. (Поскольку спецификация включает «несколько будущих приложений», это может стать для вас реальной проблемой)

В отличие от триггеров, это не в режиме реального времени, это одновременно и преимущество, и недостаток. Использование триггеров всегда замедляет обновление.

Я работал над одной системой, когда мы использовали триггеры (сгенерированные CodeSmith), а также отслеживали все изменения в записях, мы также связывали изменения вместе с «исторической» таблицей, которая включала модуль приложения, которое внесло изменения, и элемент пользовательского интерфейса, который пользователь использовал для внесения изменений.

Однако вам лучше всего решить эту проблему на уровне приложения, например, записав все обновления в очередь сообщений, которая затем воспроизводится для создания базы данных в любой данный момент времени, см. Временные шаблоны в блоге Martin Flowler для хорошего обзора вариантов.

— Ян Рингроз
источник

Ссылка очень интересная, спасибо за это. Тем не менее, решение этого на уровне приложения не вариант в моем случае. Предполагается, что фреймворк, который я создаю, выполняет большую часть работы, включая отслеживание истории, для приложений на его основе. Затем приложения работают с общим интерфейсом для хранения / извлечения данных, поэтому им не нужно заботиться о том, как хранятся данные. Я знаю, что эта задача далеко не тривиальна.

— Magnattic

Кроме того, в настоящее время я не рассматриваю Enterprise Edition или не являюсь решающим фактором в нашем случае. Будущие приложения, о которых я говорю, скорее всего, все будут создаваться и размещаться нами.

— Magnattic

@atticae, Ваш фреймворк не должен ограничиваться базой данных, он может включать в себя код, который запускается за пределами базы данных.

— Ян Рингроз

Конечно, это не ограничивается базой данных. (Я бы не назвал это фреймворком в этом случае.) Я понимаю, что вы сейчас имеете в виду под «уровнем приложения», и в настоящее время я фактически использую вариант шаблона Temporal Property, о котором говорит ваша ссылка. Каркас, который я создаю, предоставляет этот интерфейс приложениям, которые его используют. Тем не менее, это часть интерфейсной стороны, и ничто из этого действительно не отвечает на мои вопросы, изложенные выше.

— Magnattic

Еще раз спасибо за ваш ответ. Вероятно, это решающий фактор для большинства людей, поэтому я думаю, что это хороший ответ и, вероятно, поможет будущим посетителям решить не использовать CDC. Тем не менее, я чувствую, что на самом деле это не отвечает на большинство моих вопросов, поэтому мне придется отдать вознаграждение stacylaray, который был единственным, кто пытался ответить на все мои вопросы. (Хотя я надеялся на ответ немного более сложный.)

— magnattic

12

Вот очень хорошо написанная серия из 9 частей, в которой рассматриваются различные способы аудита изменений данных SQL Server. Части 3, 4 и 5 посвящены CDC. Стоит прочитать все статьи, потому что это ответит на ваши вопросы, например, различные сценарии, в которых функции будут подходящими и накладными. http://solutioncenter.apexsql.com/tag/methods-for-auditing-sql-server

— Brynn
источник

1

Пролистав статью, я все еще не намного умнее. В большинстве статей подробно рассказывается, как использовать CDC и как он сравнивается с отслеживанием изменений. Это действительно не отвечает на мои вышеупомянутые вопросы, хотя.

— Magnattic

9

Для каких задач / сценариев CDC является правильным инструментом? (например, разрешить ли пользователям восстанавливать объект данных до определенного момента времени?

Может быть, это зависит.

Аудиторская проверка?

Да.

Отображение полной истории данных?)

Да.

Когда вам лучше не использовать CDC, а прибегнуть к индивидуальному триггерному решению?

Когда данные в таблице изменений не соответствуют вашим потребностям.

Можно ли использовать CDC в оперативной базе данных и использовать данные CDC в оперативном приложении? (например, показывать его конечному пользователю)

Да.

Или это явно неправильное использование этой функции?

Нет, это не злоупотребление этой функцией.

Я часто слышу, что CDC - это инструмент аудита, но разве не для этого предназначен SQL Server Audit?

Да.

Они оба разные инструменты для одной и той же задачи?

Нет.

Или CDC может использоваться для других вещей?

CDC можно использовать для других целей.

Существует отслеживание изменений и сбор данных изменений. Оба имеют свои корни в репликации.

Отслеживание изменений предоставляет способ обеспечить чистые изменения в таблице. Примером использования может быть синхронизация устройства.

CDC, с другой стороны, отслеживает каждое небольшое изменение, историю. Можно использовать эту историю для обновления хранилища данных вместо массового копирования в данные, или можно использовать эту историю в качестве самих данных и создавать на их основе отчеты. Таблица изменений не скрыта и не имеет какой-то странной схемы или чего-то еще. Вы можете запросить его и использовать данные по своему усмотрению. Просто имейте в виду ... это не в реальном времени, как сказал Ян. Данные поступают из журнала транзакций, поэтому позаботьтесь о них, как если бы вы использовали репликацию, зеркалирование или доставку журналов. По большому счету, это будет быстрее, чем триггеры. Вам нужно будет использовать Snapshot Isolation, что связано с накладными расходами, и вам придется подумать о Disaster Recovery.

— stacylaray
источник

2

Точка коррекции. Одно время сбор данных об изменениях был доступен только в перечисленных выше версиях. Однако сбор данных об изменениях стал доступен в стандартной редакции начиная с пакета обновления 1 (SP1) 2016 года. Таким образом, многие статьи, написанные до 2016 SP1, звучат так, как будто CDC недоступен для тех из нас, кто использует стандартную версию. Это больше не так. Документ Microsoft с изложением доступных CDC находится по ссылке ниже.

https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2016?view=sql-server-2017#DW

— Роберт Сиверс
источник