Qu'est-ce que le change data capture, et en quoi le CDC basé sur les logs diffère-t-il d'un polling sur une colonne d'horodatage ?

Le change data capture diffuse les changements au niveau ligne depuis une base source. Le CDC basé sur les logs lit directement le journal de transactions : il capture donc les insertions, mises à jour et suppressions physiques dans l'ordre des commits, avec presque aucune charge sur la source. Le polling d'une colonne updated_at est plus simple mais rate les suppressions physiques, rate les états intermédiaires entre deux sondages, dépend de l'application qui maintient la colonne, et peut rater des lignes à cause de problèmes d'horloge ou de frontière transactionnelle.

Le CDC consiste à récupérer les changements au niveau ligne plutôt que de relire des tables entières. Le CDC basé sur les logs, avec quelque chose comme Debezium qui lit le write ahead log de Postgres ou le binlog MySQL, vous donne chaque insertion, mise à jour et suppression dans l'ordre des commits, et n'ajoute presque aucune charge de requêtes sur la primaire. Le polling d'une colonne updated_at est bien plus simple à mettre en place, et c'est très bien pour des données de référence qui bougent lentement, mais il a de vrais trous. Il ne voit pas du tout les suppressions physiques, donc des lignes persistent silencieusement en aval pour toujours. Il rate les états intermédiaires si une ligne change deux fois entre deux sondages, et il dépend du fait que chaque écrivain pense à renseigner la colonne, ce qu'un job legacy de notre parc n'a jamais fait. Le CDC basé sur les logs a son propre coût opérationnel. Il vous faut un slot de réplication, et si votre consommateur cale, le log n'est pas recyclé et le disque de la source se remplit, ce qui est une défaillance vraiment dangereuse. Je surveille donc le retard du slot comme une alerte de premier plan, à côté du retard du pipeline.