Change Data Capture (CDC)
- ●CDC হলো ডাটাবেসে ঘটে যাওয়া প্রতিটি change (insert/update/delete) রিয়েল-টাইমে ধরা।
- ●Log-based CDC ডাটাবেসের WAL/binlog পড়ে, ফলে source-এ প্রায় কোনো চাপ পড়ে না।
- ●এটি cache invalidation, data sync ও real-time streaming-এর জন্য বহুল ব্যবহৃত; Debezium জনপ্রিয় tool।
সমস্যাটা কী?
ভাবো তোমার একটা e-commerce অ্যাপ আছে। main database-এ product-এর দাম বদলালো। কিন্তু এই দাম আরও অনেক জায়গায় দরকার—search engine (Elasticsearch)-এ index আছে, একটা Redis cache আছে, একটা analytics warehouse আছে। এখন main DB-তে দাম বদলালে এই সব জায়গায় কীভাবে জানাবে?
সহজ উপায় হলো—প্রতি ৫ মিনিটে পুরো table আবার পড়ে কোথায় কী বদলেছে মেলানো (polling)। কিন্তু এটা ভয়াবহ অপচয়—লক্ষ row বারবার পড়া, real-time না, আর delete হওয়া row তো ধরাই যায় না (কারণ সেটা আর table-এ নেই)।
দরকার এমন কিছু যা ঠিক যে মুহূর্তে DB-তে কোনো change হয়, সেটা ধরে ফেলবে। এটাই Change Data Capture (CDC)।
মূল ধারণা
Change Data Capture (CDC) হলো একটা কৌশল যা ডাটাবেসে ঘটে যাওয়া প্রতিটি data change—insert, update, delete—কে শনাক্ত করে এবং অন্য system-এ পাঠানোর উপযোগী event হিসেবে capture করে, সাধারণত প্রায় রিয়েল-টাইমে।
মূল ধারণাটা হলো—ডাটাবেসকে শুধু "state-এর জায়গা" না ভেবে "ঘটনার (events) উৎস" হিসেবে দেখা। প্রতিটা change একটা event; CDC সেই event stream তৈরি করে যা অন্যরা subscribe করতে পারে।
কীভাবে কাজ করে
CDC মূলত দুইভাবে করা যায়—একটা দুর্বল, একটা শক্তিশালী।
Query/Polling-based (দুর্বল)
প্রতিটা table-এ একটা updated_at column রাখা হয়। CDC tool নিয়মিত query করে: "শেষ check-এর পর কোন row-এর updated_at বদলেছে?" সহজ, কিন্তু সমস্যা—delete ধরা যায় না, দুই poll-এর মাঝের দ্রুত পরিবর্তন মিস হতে পারে, আর বারবার query DB-তে চাপ দেয়।
Log-based (শক্তিশালী)
প্রতিটা ডাটাবেসই durability ও replication-এর জন্য একটা transaction log রাখে—PostgreSQL-এ WAL (Write-Ahead Log), MySQL-এ binlog, MongoDB-তে oplog। এই log-এ প্রতিটা committed change ক্রমানুসারে লেখা থাকে।
Log-based CDC এই log-টাই পড়ে (যেমন একটা replica-র মতো) এবং প্রতিটা change-কে event-এ রূপান্তর করে। সুবিধা:
- সম্পূর্ণ: insert/update/delete সব ধরে, delete-ও মিস হয় না।
- কম চাপ: এটা DB-তে query করে না, শুধু log পড়ে—তাই source DB প্রায় টের পায় না।
- ক্রম রক্ষা: change-গুলো ঠিক যে ক্রমে ঘটেছে সেই ক্রমেই আসে।
তুলনামূলক টেবিল
| বৈশিষ্ট্য | Polling-based | Log-based |
|---|---|---|
| Delete ধরা | যায় না | যায় |
| Source-এ চাপ | বেশি | খুব কম |
| Latency | poll interval | প্রায় রিয়েল-টাইম |
| Change order | নিশ্চিত নয় | সংরক্ষিত |
| Setup জটিলতা | সহজ | মাঝারি |
একটা চিত্র
ভাবো একটা ব্যাংকের শাখা ম্যানেজার জানতে চান সারাদিন কী কী লেনদেন হলো। Polling হলো—প্রতি ঘণ্টায় তিনি ভল্ট খুলে টাকা গুনে আগের সাথে মেলান। ক্লান্তিকর, আর কেউ টাকা তুলে আবার জমা দিলে তিনি টেরই পান না।
Log-based CDC হলো—ব্যাংকের cash register প্রতিটা লেনদেন ক্রমানুসারে একটা খাতায় (transaction log) লিখে রাখে: "১০টা ৩০—করিম ৫০০ জমা", "১০টা ৩২—রহিম ৩০০ উত্তোলন"। ম্যানেজার শুধু এই খাতা পড়লেই পুরো ছবি পেয়ে যান—কোনো কিছু না গুনে, ভল্টকে বিরক্ত না করে, কিছু মিস না করে।
প্রকারভেদ ও use case
CDC-র জনপ্রিয় ব্যবহার:
- Cache invalidation: DB-তে product দাম বদলালে CDC event পাঠায় → Redis cache-এর সেই key মুছে দেওয়া হয়।
- Search index sync: DB-তে নতুন product → CDC → Elasticsearch index আপডেট।
- Data warehouse sync: OLTP DB-র change রিয়েল-টাইমে warehouse-এ পৌঁছে (ELT-এর extract অংশ)।
- Microservice communication: এক service-এর DB change অন্য service event হিসেবে পায় (Outbox pattern)।
- Audit log: সব change-এর ইতিহাস রাখা।
সবচেয়ে জনপ্রিয় open-source tool হলো Debezium, যা PostgreSQL/MySQL/MongoDB-র log পড়ে change-গুলো Kafka topic-এ পাঠায়। সেখান থেকে যেকোনো consumer subscribe করতে পারে।
কখন ব্যবহার করবে / করবে না
- ব্যবহার করো: রিয়েল-টাইম sync দরকার, একাধিক system এক DB-র change জানতে চায়, ভারী batch job এড়াতে চাও, event-driven architecture বানাচ্ছ।
- করবে না: যদি দিনে একবার simple batch sync-ই যথেষ্ট হয়, তাহলে CDC infrastructure (Kafka, Debezium) maintain করার জটিলতা অপ্রয়োজনীয়।
CDC সাধারণত at-least-once delivery দেয়—মানে একই change event দুবার আসতে পারে (যেমন Debezium restart হলে)। তাই consumer-কে idempotent বানাও, যাতে একই event দুবার এলেও ভুল ফল না হয় (যেমন "set price = 500", "increment by 1" নয়)। এটা মাথায় না রাখলে duplicate event থেকে hard-to-debug bug তৈরি হয়।
বাস্তব উদাহরণ
একটা marketplace অ্যাপে seller দাম বদলালে আগে cache stale থেকে যেত—ইউজার পুরোনো দাম দেখত। তারা Debezium + Kafka দিয়ে CDC বসাল: PostgreSQL-এর WAL থেকে প্রতিটা products table change Kafka topic-এ যায়। তিনটি consumer subscribe করে—একটা Redis cache update করে, একটা Elasticsearch index ঠিক করে, একটা BigQuery-তে stream করে। এখন দাম বদলানোর কয়েক সেকেন্ডের মধ্যে সব জায়গায় sync হয়ে যায়, কোনো ভারী polling ছাড়াই।
ইন্টারভিউতে "DB থেকে cache কীভাবে real-time sync রাখবে?" জিজ্ঞেস করলে CDC-র কথা বলো: "Log-based CDC দিয়ে DB-র WAL/binlog পড়ে change event বানাব, Debezium দিয়ে Kafka-তে পাঠাব, consumer সেই event-এ cache invalidate করবে।" সাথে "consumer idempotent রাখব কারণ delivery at-least-once" যোগ করলে seniority বোঝা যায়।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Log-based CDC কীভাবে change ধরে?
2. নিচের কোনটি CDC-র সাধারণ use case?
3. Polling-ভিত্তিক CDC-র তুলনায় log-based CDC-র সুবিধা কী?