В этом объяснении рассматриваются различия между Дебезий SQL Серверный CD C Разъем и JDB C Разъем , с более общей интерпретацией о Дебезий и CD C.
tl; др. Прокрутите вниз:)
Дебезий
Дебезий является используется только как исходный соединитель, записывает все изменения на уровне строк.
Документация Debezium говорит:
Debezium - это набор распределенных сервисов для сбора изменений в ваши базы данных, чтобы ваши приложения могли видеть эти изменения и реагировать на них. Debezium записывает все изменения на уровне строк в каждой таблице базы данных в потоке событий изменений, и приложения просто читают эти потоки, чтобы увидеть события изменений в том же порядке, в котором они произошли.
Коннектор Debezium для SQL Сервер сначала записывает снимок базы данных, а затем отправляет записи изменений на уровне строк в Kafka, каждая таблица в свою топику Kafka c.
Соединитель Debezium для SQL Документация сервера говорит:
Соединитель сервера SQL Дебезиума может отслеживать и записывать изменения на уровне строк в схемах SQL База данных сервера.
При первом подключении к базе данных / кластеру SQL Сервер считывает непротиворечивый снимок всех схем. Когда этот моментальный снимок завершается, соединитель непрерывно передает изменения, зафиксированные на SQL сервере, и генерирует соответствующие события вставки, обновления и удаления. Все события для каждой таблицы записываются в отдельную топику Kafka c, где они могут быть легко использованы приложениями и службами.
Kafka Connect JDB C
Kafka Connect JDB C можно используется в качестве источника или приемника для Kafka, поддерживает любую базу данных с драйвером JDB C.
JDB C Документация по соединителям говорит:
Вы можете использовать исходный соединитель Kafka Connect JDB C для импорта данных из любой реляционной базы данных с драйвером JDB C в темы Apache Kafka®. Вы можете использовать соединитель приемника JDB C для экспорта данных из тем Kafka в любую реляционную базу данных с драйвером JDB C. Соединитель JDBC поддерживает широкий спектр баз данных, не требуя специального кода для каждой из них.
У них есть некоторые спецификации по установке на Microsoft SQL Server , которые я нахожу неуместными для этого обсуждения.
Так что, если JDB C Connector поддерживает и источник, и приемник, а Debezium поддерживает только источник (не приемник), мы понимаем, что для записи данных из Kafka в базы данных с драйвером JDB C (приемник) соединитель JDB C - это путь к go (включая SQL Server).
Теперь сравнение следует сузить только до поля источников.
JDB C Документация по соединителю источника не говорит намного больше с первого взгляда:
Данные загружаются путем периодического выполнения запроса SQL и создания выходной записи для каждой строки в наборе результатов. По умолчанию все таблицы в базе данных копируются, каждая в свой собственный вывод topi c. База данных отслеживается на наличие новых или удаленных таблиц и автоматически адаптируется. При копировании данных из таблицы соединитель может загружать только новые или измененные строки, указав, какие столбцы следует использовать для обнаружения новых или измененных данных.
Поиск немного дальше, чтобы понять их различия, в этом блоге Debezium , который использует Debezium MySQL Connector в качестве источника и JDB C Connector в качестве приемника, есть объяснение о различия между ними, которые обычно говорят нам о том, что Debezium предоставляет записи с дополнительной информацией об изменениях базы данных, в то время как JDB C Connector предоставляет записи, которые больше ориентированы на преобразование изменений базы данных в простые команды вставки / вставки :
Соединитель Debezium MySQL был разработан, чтобы специально фиксировать изменения в базе данных и предоставлять как можно больше информации об этих событиях, выходящих за рамки только нового состояния каждой строки. Между тем, Confluent JDB C Sink Connector был разработан для простого преобразования каждого сообщения в вставку / вставку базы данных на основе структуры сообщения. Итак, два соединителя имеют разные структуры для сообщений, но они также используют разные соглашения об именах topi c и поведение представления удаленных записей.
Кроме того, они имеют разные имена топи c и разные методы удаления:
Debezium использует полностью квалифицированные имена для целевых тем, представляющих каждую таблицу, которой он управляет. Именование следует шаблону [логическое имя]. [Имя базы данных]. [Имя таблицы]. Kafka Connect JDBC Connector работает с простыми именами [table-name].
...
Когда коннектор Debezium обнаруживает удаление строки, он создает два сообщения о событии: событие удаления и сообщение о надгробии. Сообщение об удалении имеет конверт с состоянием удаленной строки в поле «до», а поле «после» - ноль. Надгробное сообщение содержит тот же ключ, что и сообщение об удалении, но все значение сообщения равно нулю, и сжатие журнала Kafka использует это, чтобы знать, что оно может удалить любые более ранние сообщения с тем же ключом. Ряд соединителей приемника, включая соединитель раковины JDB C Confluent, не ожидают этих сообщений и вместо этого потерпят неудачу, если увидят сообщение любого типа.
Этот Confluent blog объясняет больше, как работает CD C и JDB C Connector, it (JDB C Connector) выполняет запросы к исходной базе данных каждый фиксированный интервал, что не очень масштабируемое решение, в то время как CD C имеет более высокую частоту при потоковой передаче из журнала транзакций базы данных :
Соединитель работает, выполняя запрос через JDB C, против исходной базы данных. Это делается для извлечения всех строк (объемных) или тех, которые изменились с тех пор ранее (добавочные). Этот запрос выполняется с интервалом, определенным в poll.interval.ms. В зависимости от используемых объемов данных, физической структуры базы данных (индексация и т. Д. c.) И другой рабочей нагрузки в базе данных, это может оказаться не самым масштабируемым вариантом.
...
Выполнено правильно, CD C в основном позволяет вам передавать каждое отдельное событие из базы данных в Kafka. В широком смысле, реляционные базы данных используют журнал транзакций (также называемый журналом binlog или redo log в зависимости от разновидности БД), в который записывается каждое событие в базе данных. Обновите строку, вставьте строку, удалите строку - все это идет в журнал транзакций базы данных. Инструменты CD C обычно работают с использованием этого журнала транзакций для извлечения с очень низкой задержкой и низким воздействием на события, происходящие в базе данных (или в схеме / таблице в ней).
Этот блог также говорится о различиях между CD C и JDB C Connector, в основном говорит, что JDB C Connector не поддерживает синхронизацию удаленных записей, что подходит для прототипирования, а CD C подходит для более зрелых систем :
Соединитель JDB C не может извлечь удаленные строки. Потому что, как вы запрашиваете данные, которые не существуют?
...
Мой общий подход к CD C против JDB C заключается в том, что JDB C отлично подходит для создания прототипов и хороших рабочих нагрузок с небольшим объемом. Что следует учитывать при использовании JDBC-коннектора:
Не дает истинного CD C (захватить удаление записей, требуется до / после версий записей) Задержка при обнаружении новых событий Влияние непрерывного опроса исходной базы данных (и сбалансировать это с желаемой задержкой) Если вы не выполняете массовое извлечение из таблицы, вам необходимо иметь идентификатор и / или временную метку, которую вы можете использовать для обнаружения новых записей. Если у вас нет схемы, это становится проблемой.
tl; dr Заключение
Основные различия между Debezium и JDB C Разъем:
- Дебезиум используется только в качестве источника Kafka, а разъем JDB C может использоваться в качестве источника и приемника Kafka.
Для источников:
JDB C Connector не поддерживает синхронизацию удаленных записей, в то время как Debezium поддерживает. JDB C Соединитель запрашивает базу данных каждый фиксированный интервал, что является не очень масштабируемым решением, в то время как CD C имеет более высокую частоту потоковой передачи из журнала транзакций базы данных. Debezium предоставляет записи с дополнительной информацией об изменениях базы данных, а JDB C Connector предоставляет записи, которые больше ориентированы на преобразование изменений базы данных в простые команды вставки / вставки. Различные топи c наименование.