بیشتر پایپ‌لاین‌ها به بارگذاری مجدد کل جدول‌ها یا کوئری‌های بازه زمانی متکی‌اند. این تاکتیک‌ها حجم عظیمی از داده‌های بدون تغییر را جابه‌جا می‌کنند و صورت‌حساب‌های ابری را باد می‌کنند. یک تازه‌سازی کامل واحد گیگابایت‌ها ترافیک شبکه مصرف می‌کند و جدول‌های تراکنشی را قفل می‌کند، و پنجره‌های نگه‌داری را به تمرین آتش‌سوزی عملیاتی تبدیل می‌کند.
گرفتن داده‌های تغییر (CDC) این مشکل را حل می‌کند. با استریم کردن فقط درج‌ها، به‌روزرسانی‌ها و حذف‌هایی که در لاگ‌های پایگاه‌داده ثبت شده‌اند، CDC فقط داده‌های تغییر یافته را جابه‌جا می‌کند بدون قفل کردن جدول‌های منبع در حالی که تاریخچه‌ی دقیق هر تغییر را حفظ می‌کند. نتیجه پایپ‌لاین‌های لاغرتر، همگام‌سازی سریع‌تر و رد حسابرسی است که الزامات انطباق را برآورده می‌کند.
رویکردهای اصلی برای CDC چه هستند؟
| رویکرد | مزایا | معایب | بهترین کاربرد |
|---|---|---|---|
| مبتنی بر لاگ | تأثیر کم، توان عملیاتی بالا، تاریخچه کامل | راه‌اندازی پیچیده، قفل شدن به فروشنده، پشتیبانی محدود SaaS | تکرار با حجم بالا و تأخیر پایین |
| مبتنی بر تریگر | کار می‌کند همه‌جا، منطق سفارشی، رد حسابرسی | کند کردن تراکنش‌ها، نگه‌داری زیاد، ریسک برگشت | وقتی دسترسی به لاگ مسدود است اما دقت لازم است |
| مبتنی بر زمان‌مُهر | SQL ساده، راه‌اندازی سریع، بدون دسترسی ویژه | بار خواندن سنگین، از دست دادن حذف‌ها، تغییرات شِما | مجموعه‌داده‌های کوچک، تأخیر غیر بحرانی |
| دیفینگ (Diffing) | مستقل از پایگاه‌داده، کار روی فایل‌های تخت، ساده برای جدول‌های کوچک | اسکن پرهزینه، تأخیر بالا، بدون زمینه رخداد | جدول‌های مرجع، آشتی موردی |
۱. CDC مبتنی بر لاگ (Log)
یک پایپ‌لاین مبتنی بر لاگ، لاگ تراکنش پایگاه‌داده را دنبال می‌کند (همان فایلی که موتور برای دوام می‌نویسد) تا هر INSERT، UPDATE و DELETE را به ترتیب استریم کند. چون هرگز از جدول‌های تولیدی کوئری نمی‌گیرد، از قفل شدن یا بار خواندن اضافه اجتناب می‌کنید و تاریخچه‌ی کامل و زمانی تغییرات را به دست می‌آورید.
این رویکرد حداقل تأثیر منبع را ارائه می‌دهد چون خواندن لاگ برای اپلیکیشن‌ها عملاً نامرئی است. همچنین توان عملیاتی بالا را مدیریت می‌کند و میلیون‌ها رخداد در دقیقه پردازش می‌کند.
معایب:
-
پیچیدگی راه‌اندازی نیازمند دسترسی سطح بالا و تنظیم دقیق نگه‌داری است
-
منطق پارسینگ به ساختار لاگ هر پایگاه‌داده وابسته می‌شود و قفل شدن به فروشنده ایجاد می‌کند
-
برخی پایگاه‌داده‌های SaaS لاگ‌های خود را افشا نمی‌کنند و دسترسی را کاملاً محدود می‌سازند
نکته حرفه‌ای: از CDC مبتنی بر لاگ استفاده کنید وقتی که به تأخیر زیر ثانیه اهمیت می‌دهید یا نیاز به تکرار سیستم‌های OLTP با حجم بالا بدون کندی تولید دارید.
۲. CDC مبتنی بر تریگر (Trigger)
در این‌جا شما تریگرهای پایگاه‌داده ایجاد می‌کنید که روی هر تغییر داده فعال می‌شوند و یک رکورد در جدول حسابرسی می‌نویسند. پایپ‌لاین سپس آن استریم حسابرسی را می‌خواند.
این روش همه‌جا کار می‌کند چون تقریباً هر موتور رابطه‌ای از تریگر پشتیبانی می‌کند. شما می‌توانید منطق سفارشی را مستقیماً در بدنه تریگر تعبیه کنید، رخدادها را با شناسه کاربر غنی کنید یا فیلدهای حساس را ماسک کنید. جدول‌های سایه همچنین به‌عنوان رد حسابرسی داخلی برای انطباق عمل می‌کنند.
معایب:
-
هر تراکنش نوشتن‌های اضافی اجرا می‌کند، بار کاری شلوغ را کند کرده و ضربه قابل اندازه‌گیری به کارایی وارد می‌کند
-
هر تغییر شِما نیازمند به‌روزرسانی تریگرها و شِمای حسابرسی است و سربار نگه‌داری را افزایش می‌دهد
-
خرابی احتمالی تریگر می‌تواند تراکنش‌های تولید را برگرداند
نکته حرفه‌ای: تریگرها را انتخاب کنید وقتی دسترسی به لاگ غیرممکن است اما هنوز تاریخچه ردیف-سطحی دقیق نیاز دارید.
۳. ستون‌های تایم استمپ (CDC مبتنی بر Query)
در این الگو شما یک ستون last_modified اضافه می‌کنید و به‌طور دوره‌ای برای ردیف‌هایی که جدیدتر از آخرین همگام‌سازی هستند کوئری می‌گیرید. این SQL ساده است و هیچ امتیاز ویژه‌ای نیاز ندارد.
مزایا:
-
با افزودن یک ستون و یک کوئری زمان‌بندی شده سریعاً شروع می‌کنید
-
هیچ زیرساخت اضافی نیاز نیست چون همه‌چیز روی اتصال پایگاه‌داده ساده اجرا می‌شود
معایب:
-
اسکن‌های مکرر جدول‌های بزرگ را می‌کوبند و بار خواندن سنگین ایجاد می‌کنند
-
حذف‌ها مشکل‌سازند چون ردیف‌های ناپدید شده زمان‌مُهر ندارند، مگر این‌که پرچم soft-delete اضافه کنید
-
افزودن ستون زمان‌مُهر ممکن است نیازمند تغییر شِما و زمان توقف در اپلیکیشن‌های قدیمی باشد
نکته حرفه‌ای: رویکردهای مبتنی بر polling برای مجموعه‌داده‌های کوچک یا پروژه‌های موقت که سرعت بلادرنگ حیاتی نیست مناسب‌اند.
۴. رویکرد دیفینگ (Diffing)
دیفینگ دو اسنپ‌شات می‌گیرد: جدول دیروز و جدول امروز، و تفاوت را بیرون از پایگاه‌داده محاسبه می‌کند. هیچ قابلیت بومی نیاز ندارد که این هم قوت و هم ضعف آن است.
این روش مستقل از پایگاه‌داده حتی روی فایل‌های تخت یا سیستم‌هایی بدون تریگر یا لاگ کار می‌کند. برای جدول‌های کوچک با چند هزار ردیف، دیف شبانه ساده و بدون دردسر است.
معایب:
-
اسکن و مقایسه‌ی تمام‌قد در مجموعه‌داده‌های بزرگ پرهزینه می‌شود
-
تأخیر بالا است و به فاصله‌ی اسنپ‌شات محدود می‌شود
-
تغییرها زمینه رخداد را از دست می‌دهند — فقط می‌دانید ردیفی تغییر کرده نه چگونه یا چه زمانی
نکته حرفه‌ای: دیفینگ را برای موارد خاص مانند جدول‌های مرجع یا آشتی موردی نگه دارید، جایی که سه گزینه دیگر عملی نیستند.
