change data capture क्या है, और log based CDC किसी timestamp column को poll करने से कैसे अलग है?

change data capture किसी source database से row स्तर के बदलाव stream करता है। log based CDC सीधे transaction log पढ़ता है, इसलिए वह inserts, updates और hard deletes को commit के क्रम में पकड़ता है और source पर लगभग कोई बोझ नहीं डालता। updated_at column को poll करना आसान है लेकिन वह hard deletes चूक जाता है, दो polls के बीच की बीच वाली स्थितियां चूक जाता है, इस बात पर टिका रहता है कि application उस column को भरता रहे, और clock या transaction boundary की गड़बड़ी पर rows छोड़ सकता है।

CDC का मकसद पूरी tables दोबारा पढ़ने के बजाय row स्तर के बदलाव लेना है। log based CDC, जैसे Debezium से Postgres का write ahead log या MySQL का binlog पढ़ना, आपको हर insert, update और delete commit के क्रम में देता है और primary पर लगभग कोई query बोझ नहीं डालता। updated_at column poll करना सेट करना कहीं आसान है, और धीरे बदलने वाले reference data के लिए ठीक भी है, लेकिन उसमें असली छेद हैं। वह hard deletes देख ही नहीं सकता, इसलिए rows चुपचाप आगे हमेशा के लिए टिकी रहती हैं। अगर दो polls के बीच row दो बार बदली तो बीच की स्थितियां छूट जाती हैं, और यह इस पर टिका है कि हर writer वह column सेट करना याद रखे, जो हमारे यहां एक पुरानी job ने कभी नहीं किया। log based CDC की अपनी ऑपरेशनल कीमत है। आपको replication slot चाहिए, और अगर आपका consumer अटक गया तो log खाली नहीं होगा और source की disk भर जाएगी, जो सचमुच खतरनाक failure है। इसलिए मैं pipeline lag के साथ साथ slot lag को भी पहले दर्जे का alert बनाकर रखता हूं।