Hoe werkt Change Data Capture het lokale kennisindex bij?
Change data capture werkt een lokale kennisindex bij door vastgelegde wijzigingen in de bron om te zetten in gebeurtenissen die downstream-indexeringsworkers incrementeel kunnen verwerken.
Dit is belangrijk wanneer een kennisbank voor thuisgebruik wordt ondersteund door een gestructureerde applicatiedatabase in plaats van alleen door een mapwatcher. Notities, inventarisrecords, mediametadata, bladwijzers, geschiedenis van domotica of rijen in een documentcatalogus kunnen voortdurend veranderen. De volledige database opnieuw lezen om één bewerkt record te ontdekken, verspilt I/O en zorgt voor lange vertragingen voordat wijzigingen zichtbaar zijn. CDC volgt in plaats daarvan de eigen wijzigingsstroom van de database en geeft de indexer een reeks specifieke mutaties.
CDC leest een wijzigingsstroom van de bron in plaats van elke rij opnieuw te scannen
Veel databases leggen vastgelegde mutaties al vast in transactielogs, replicatiestromen of vergelijkbare geordende wijzigingsrecords. CDC-systemen abonneren zich op die stroom en vertalen informatie uit laag-niveau-logs naar verwerkbare insert-, update- en delete-gebeurtenissen.
Loggebaseerde CDC legt databasewijzigingen op rijniveau rechtstreeks vast vanuit de wijzigingsstroom van de bron. Zo zijn herhaalde volledige tabelcontroles overbodig om slechts een klein aantal mutaties te ontdekken.
Dit verschilt van een filesystemwatcher. Een watcher observeert gebeurtenissen op padniveau van het besturingssysteem, terwijl CDC logische bronmutaties binnen een database observeert en de volgorde van transacties en de identiteit van records kan behouden.
De kennisindex ontvangt een veel kleinere werklijst: “record 184 is gewijzigd” is goedkoper om te verwerken dan “scan 900.000 rijen en vergelijk ze allemaal opnieuw”.
Elke gebeurtenis bevat de identiteit die nodig is om afgeleide indexrecords te vinden
Een updategebeurtenis is alleen nuttig wanneer de indexer de gewijzigde bronrij kan koppelen aan de chunks, tekstvelden, metadatarecords of vectoren die daar eerder van zijn afgeleid.
Een replica-identiteit bepaalt welke informatie voor het identificeren van rijen beschikbaar is voor gerepliceerde updates en deletes. Zo krijgen downstream-consumenten een stabiele manier om afgeleide indexrecords te targeten.
Een lokale indexeringspipeline moet in elk afgeleid record een vergelijkbare stabiele bronsleutel bewaren. Een `UPDATE` kan dan alleen de betreffende documentfamilie ophalen en opnieuw opbouwen, terwijl een `DELETE` elke vector kan vinden die ongeldig moet worden. Zonder stabiele identiteit kan de gebeurtenisstroom het systeem wel vertellen dat er iets is gewijzigd, maar moet het nog steeds uitgebreid zoeken om te ontdekken welke geïndexeerde artefacten bij die bron horen.
De indexer vertaalt databasemutaties naar acties in de zoeklaag
Een CDC-gebeurtenis bevat geen embedding en kent het chunkingbeleid niet. Het is een melding vanuit de gezaghebbende bronlaag, geen kant-en-klare vectorbewerking.
Gestructureerde wijzigingsgebeurtenisrecords scheiden de bronmutatie van de downstream-indexeringslogica. Zo kan de consumer bepalen of een insert, update of delete parseren, embedden of buiten gebruik stellen vereist.
De indexeringsworker kan een insert koppelen aan parseren en toevoegen, een update aan vergelijken en opnieuw opbouwen, en een delete aan het markeren als verwijderd of verwijderen van alle zoekrecords die van de bronsleutel zijn afgeleid.
Content hashing kan deel uitmaken van dat updatepad. CDC geeft aan welk bronrecord is gewijzigd; de hashcontrole kan vervolgens bepalen of de tekst die aan het embeddingmodel wordt gevoerd daadwerkelijk is veranderd.
Offsets en checkpoints laten de consumer na een herstart doorgaan
Een thuisserver wordt opnieuw opgestart, containers worden bijgewerkt en indexeringsworkers vallen soms uit. Als de consumer zijn positie kwijtraakt, kan hij wijzigingen missen of een grote hoeveelheid werk opnieuw uitvoeren.
Opgeslagen bronoffsets laten een captureproces na een herstart vanaf een bekende locatie doorgaan, in plaats van wijzigingen stilletjes over te slaan of vanaf het begin opnieuw te starten.
De consumer van de kennisindex moet zijn eigen checkpoint pas vastleggen nadat de bijbehorende indexmutatie duurzaam is opgeslagen. Anders kan een gebeurtenis worden bevestigd voordat de bijbehorende vectoren of metadata daadwerkelijk zijn geschreven. Het opnieuw afspelen van een gebeurtenis moet bovendien veilig zijn. Upserts op basis van stabiele ID's, versiecontroles en idempotente delete-afhandeling voorkomen dat dubbele levering dubbele chunks oplevert.
CDC verkort de vertraging voordat wijzigingen zichtbaar zijn, maar vervangt reconciliatie niet
Loggebaseerde streaming is sterk voor geordende databasewijzigingen, maar configuratiefouten, retentielimieten, connectorstoringen, schemawijzigingen of bugs in de consumer kunnen nog steeds hiaten tussen de bron en de index veroorzaken.
Het risico op gemiste wijzigingsgebeurtenissen laat zien waarom een snelle incrementele stroom nog steeds moet worden ondersteund door tragere reconciliatie met de gezaghebbende bronstatus.
Periodieke reconciliatie kan aantallen bronrijen, versies, content-hashes, verwijderingsmarkeringen en geïndexeerde ID's vergelijken om alles te herstellen wat de live stroom heeft gemist.
Zo krijgt het systeem twee tijdschalen: CDC houdt gewone wijzigingen binnen seconden of minuten actueel, terwijl reconciliatie op tragere schaal de volledigheid waarborgt.
Hoge updatesnelheden veroorzaken backpressure tussen bron en index
Een database kan wijzigingen sneller vastleggen dan OCR, chunking, embedding of onderhoud van de vectorindex ze kan verwerken. De CDC-wachtrij wordt dan een buffer tussen bronactiviteit en de actualiteit van de zoekindex.
Een duurzame binaire log van gebeurtenissen die gegevens wijzigen biedt een geordende geschiedenis die een tragere downstream-indexer na tijdelijke uitval kan verwerken, binnen de retentieperiode van het bronsysteem.
Bundel updates aan dezelfde bron-ID die dicht bij elkaar liggen, geef prioriteit aan deletes en wijzigingen in rechten, en monitor vertraging in plaats van alleen de lengte van de wachtrij. Duizend gebeurtenissen kunnen staan voor duizend onafhankelijke documenten of voor herhaalde bewerkingen van één record. De index is pas actueel wanneer de consumer gebeurtenissen tot en met een bekende bronpositie heeft toegepast en al het vereiste downstream-embedding- of compactionwerk voor die records is voltooid.
Veelgestelde vragen
Is change data capture alleen bedoeld voor SQL-databases?
Nee. CDC is een algemeen patroon voor het verwerken van bronmutaties. SQL-transactielogs komen vaak voor, maar andere systemen bieden wijzigingsstromen, commitlogs, gebeurtenisfeeds of append-only-records met vergelijkbare eigenschappen.
Gaan wijzigingen verloren wanneer de indexeringsconsumer offline is?
Niet per se. Als de bron het wijzigingslog bewaart en de connector zijn offset behoudt, kan de consumer doorgaan en de achterstand opnieuw afspelen. Retentielimieten blijven belangrijk tijdens langdurige uitval.
Kan CDC periodieke volledige reconciliatie vervangen?
Meestal niet. Reconciliatie blijft nuttig om gemiste gebeurtenissen, fouten in de koppeling, verouderde afgeleide records en bronwijzigingen die buiten het capturepad hebben plaatsgevonden, op te sporen.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Kunnen thuiscamera's gebeurtenissen synchroniseren zonder cloudtijdservices?
Een mechanismegerichte uitleg van cameratiijd zonder cloud, de afwegingen bij gedeelde bronnen, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
Kan een lokale AI-service beschadigde modellagen detecteren vóór de inferentie?
Een mechanismegerichte uitleg van detectie van beschadigingen in modellagen, de afwegingen rond gedeelde bronnen, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
Kan een RAG-systeem worden hersteld zonder elke embedding opnieuw te genereren?
Een mechanismegerichte uitleg van RAG-herstel zonder opnieuw te embedden, de afwegingen rond gedeelde bronnen, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
