حقوق الطبع والنشر لمؤلفي ديبيزيوم. مرخص بموجب ترخيص أباتشي، الإصدار 2.0.
Debezium هو مشروع مفتوح المصدر يوفر نظامًا أساسيًا لتدفق البيانات بزمن وصول منخفض لالتقاط بيانات التغيير (CDC). يوفر هذا الرابط تطبيقًا مخزنًا لتدفق التغييرات الصادرة عن Debezium إلى قاعدة بيانات علائقية.
إن تطبيق هذا الموصل على علم بمصدر Debezium. وهذا يعني أن الموصل يمكنه استهلاك أحداث تغيير Debezium الأصلية دون الحاجة إلى استخدام ExtractNewRecordState لتسوية بنية الحدث. يؤدي هذا إلى تقليل التكوين الضروري لاستخدام موصل حوض JDBC. بالإضافة إلى ذلك، يعني هذا أيضًا أن جانب الحوض من خط الأنابيب يمكنه الاستفادة من بيانات تعريف Debezium، مثل نشر نوع العمود لدعم الدقة المناسبة لنوع العمود بسلاسة على جانب موصل الحوض من خط الأنابيب.
موصل حوض JDBC هو موصل حوض Kafka Connect التقليدي (المعروف أيضًا باسم المستهلك). وتتمثل مهمتها في قراءة السجلات من موضوع كافكا واحد أو أكثر وإنتاج عبارات SQL التي يتم تنفيذها على قاعدة البيانات الوجهة التي تم تكوينها.
SinkRecordDescriptor هو كائن يتم إنشاؤه من كل SinkRecord . معظم الطرق التي قد تستخدم SinkRecord تأخذ كائن الواصف هذا بدلاً من ذلك. الواصف هو في الواقع نسخة تمت معالجتها مسبقًا من SinkRecord ، مما يسمح لنا بإجراء هذه المعالجة المسبقة مرة واحدة ثم الاستفادة من هذه المعلومات عبر الموصل. عند إضافة طرق جديدة، ستحتاج بشكل عام إلى استخدام SinkRecordDescriptor .
سيكون لكل قاعدة بيانات مصدر عادةً تطبيق DatabaseDialect الخاص بها والذي يجب أن يمتد GeneralDatabaseDialect . اللهجة هي إحدى الآليات الأساسية التي يستخدمها موصل حوض JDBC لحل عبارات SQL وخصائص قاعدة البيانات الأخرى لقاعدة البيانات التي سيكتب الموصل الأحداث المستهلكة فيها. يعتمد موصل حوض JDBC على دقة لهجة Hibernate لتشغيل غلاف اللهجة الذي يستخدمه الموصل.
إذا لم يتم الكشف عن تعيين لهجة لقاعدة البيانات المصدر المستخدمة، فسيقوم موصل مصدر JDBC افتراضيًا باستخدام تطبيق GeneralDatabaseDialect . لا يدعم هذا التنفيذ المعمم كل جانب من جوانب الموصل، على سبيل المثال، لا يتم دعم وضع إدراج UPSERT عند اختيار هذه اللهجة لأن عبارة UPSERT تكون فريدة بشكل عام لقاعدة البيانات المستخدمة. إنها فكرة جيدة عمومًا إضافة تطبيق لهجة جديدة إذا كانت قاعدة بيانات الحوض الجديدة تتمتع بالتوافق الكامل مع السلوك الواسع لموصل حوض JDBC.
يرتبط كل حقل في رسالة كافكا بنوع مخطط، ولكن يمكن أن تحمل معلومات هذا النوع أيضًا بيانات تعريف أخرى مثل الاسم أو حتى المعلمات التي تم توفيرها بواسطة موصل المصدر. يستخدم موصل حوض JDBC نظام الكتابة، الذي يعتمد على عقد io.debezium.connector.jdbc.type.Type ، من أجل التعامل مع ربط القيمة، ودقة القيمة الافتراضية، والخصائص الأخرى التي يمكن أن تكون خاصة بالنوع.
هناك ثلاثة أنواع مختلفة من تطبيقات Type :
io.debezium.connector.jdbc.type.connect .io.debezium.connector.jdbc.type.debezium .io.debezium.connector.jdbc.dialect .يتم تسجيل الأنواع بنمط هرمي، بدءًا من أنواع Kafka Connect، ثم أنواع Debezium، وأخيرًا الأنواع الخاصة باللهجات. يتيح ذلك لأنواع Debezium تجاوز أنواع Kafka Connect إذا لزم الأمر، وأخيرًا اللهجة لتجاوز أي نوع آخر مساهم.
يتم حل الأنواع من خلال النظر أولاً إلى اسم مخطط كافكا وتعيينه لتسجيل النوع. إذا لم يكن للمخطط اسم، فسيتم استخدام نوع المخطط بعد ذلك للتحليل إلى نوع ما. يتيح ذلك لأنواع Kafka Connect الأساسية أن يكون لها رأي نهائي في كيفية تفسير البيانات إذا لم يتم اكتشاف أي نوع آخر من التطبيقات للحقل.
هناك استراتيجيتان للتسمية يستخدمهما موصل حوض JDBC:
TableNamingStrategyColumnNamingStrategy يتم شحن موصل حوض JDBC مع التطبيقات الافتراضية لكليهما، والموجودة في الحزمة io.debezium.connector.jdbc.naming . السلوك الافتراضي لهاتين الاستراتيجيتين هو كما يلي:
. باستخدام _ ويستخدم قيمة table.name.format التي تم تكوينها لحل الاسم النهائي للجدول. لذا بافتراض أن اسم موضوع الحدث هو server.schema.table مع الجدول الافتراضي table.name.format=dbo.${topic} ، سيتم إنشاء الجدول الوجهة كـ dbo.server_schema_table .يمكن تجاوز هاتين الاستراتيجيتين عن طريق تحديد مراجع اسم الفئة المؤهلة بالكامل في تكوين الموصل. مثال التكوين:
table.naming.strategy=io.debezium.connector.jdbc.naming.DefaultTableNamingStrategy
column.naming.strategy=io.debezium.connector.jdbc.naming.DefaultColumnNamingStrategy
يحتفظ موصل حوض JDBC بنموذج علائقي في الذاكرة، مشابه لموصلات مصدر Debezium. يمكن العثور على فئات النماذج العلائقية هذه في الحزمة io.debezium.connector.jdbc.relational .
مطلوب ما يلي للعمل مع قاعدة كود موصل حوض Debezium JDBC ولإنشاءه محليًا:
.mvnw لأوامر Maven) تعتمد مجموعة الاختبار بشكل كبير على استخدام TestContainer، وتبدأ تلقائيًا مجموعة متنوعة من قواعد بيانات المصدر والمصدر تلقائيًا. بدون بيئة متوافقة مع Docker، لن يتم تشغيل اختبارات التكامل. إذا لم تكن لديك بيئة Docker، فيمكنك تخطي اختبارات التكامل باستخدام وسيطة سطر الأوامر -DskipITs ، الموضحة أدناه:
$ ./mvnw clean verify -DskipITs
هناك ثلاثة أنواع من الأنواع في مجموعة الاختبار:
افتراضيًا، يتم تنفيذ جميع اختبارات الوحدة كجزء من عملية الإنشاء. يتم تنفيذ اختبارات التكامل المستندة إلى المصدر فقط لـ MySQL وPostgreSQL وSQL Server بشكل افتراضي، بينما لا يتم تنفيذ أي من الاختبارات المستندة إلى المصفوفة الشاملة.
لتنفيذ اختبارات التكامل المستندة إلى المصدر لـ Oracle وDB2، يجب توفير الوسيطة -Dtest.tags لتضمينها في البنية. وللقيام بذلك، قم بإضافة جميع اختبارات التكامل المطلوب تنفيذها، كما هو موضح أدناه لجميع قواعد البيانات:
$ ./mvnw clean install -Dtest.tags=it-mysql,it-postgresql,it-sqlserver,it-oracle,it-db2
من أجل تشغيل جميع اختبارات التكامل المستندة إلى المصدر لجميع قواعد البيانات، يتم توفير علامة مختصرة:
$ ./mvnw clean install -Dtest.tags=it
وبالمثل، من أجل تمكين اختبارات نهاية إلى نهاية محددة، يمكن أيضًا توفير الوسيطة -Dtest.tags مع العلامات الضرورية لكل نوع قاعدة بيانات مصدر:
$ ./mvnw clean install -Dtest.tags=e2e-mysql,e2e-postgresql,e2e-sqlserver,e2e-oracle,e2e-db2
من أجل تشغيل جميع اختبارات التكامل الشاملة، يتم توفير علامة مختصرة أيضًا:
$ ./mvnw clean install -Dtest.tags=e2e
من أجل تشغيل جميع الاختبارات لجميع مجموعات المصدر/المصرف:
$ ./mvnw clean install -Dtest.tags=all
يرحب مجتمع Debezium بأي شخص يريد المساعدة بأي شكل من الأشكال، سواء كان ذلك يتضمن الإبلاغ عن المشكلات، أو المساعدة في التوثيق، أو المساهمة في تغييرات التعليمات البرمجية لإصلاح الأخطاء، أو إضافة اختبارات، أو تنفيذ ميزات جديدة. راجع هذه الوثيقة للحصول على التفاصيل.
شكرًا جزيلاً لجميع المساهمين في حوض Debezium JDBC!
هذا المشروع مرخص بموجب ترخيص Apache، الإصدار 2.
