CockroachDB 22.2 [Français]
[English version available here]
Récemment, CockroachLabs a lancé CockroachDB 22.2 avec un grand nombre de nouvelles fonctionnalités.
Pour n'en citer que quelques-unes, vous trouverez des User Defined Functions, Time-To-Live au niveau des lignes, et le CDC (Change Data Capture) avec transformations et filtrage. Chacune de ces fonctionnalités est une grande amélioration, mais pouvons-nous obtenir plus en combinant toutes les fonctionnalités de la version 22.2 ?
Exemple de Use Case
Le cas d'utilisation dont nous allons parler sera facile à comprendre, mais il démontrera la puissance de toutes les améliorations récentes.
Nous commençons par un exemple que vous trouverez plusieurs fois dans le document, le transfert de fonds entre comptes. Nous n'allons pas simplement transférer des fonds. Nous voulons maintenant intégrer un mécanisme de détection des fraudes (n'espérez pas lancerr une fintech avec ce genre de détection des fraudes !)
Voici le schéma à utiliser pour exécuter cet exemple.
Nous créons une table pour les comptes et les transferts. La partie intéressante concerne les anomalies et les comptes bloqués. Pour ces tables, nous utilisons la fonction TTL. Pour les anomalies, nous suivons le niveau d'anomalie (nous y reviendrons plus tard) de chaque transfert pendant 1 minute.
Les comptes bloqués aideront à bloquer le transfert si le compte source semble suspect. Nous supprimons les lignes toutes les 10 minutes.
Mise en place des fonctionnalités
Pour chaque transfert effectué, nous voulons émettre un changement avec l'identifiant du transfert, le compte source et le compte destination.
Ceci sera fait en utilisant une transformation CDC comme celle-ci :
Le flux CDC enverra chaque transfert supérieur à 100 avec seulement l'identifiant, la source et la destination.
Avant de créer le CDC, n'oubliez pas d'activer KV rangefeed dans votre cluster :
Nous utilisons également une fonction définie par l'utilisateur pour "calculer" le niveau d'anomalie :
La fonction utilisera une logique simple pour déterminer le niveau d'anomalie en fonction du montant des transferts.
Logique
Maintenant que nous avons configuré toutes ces fonctionnalités et que tout est prêt à être configuré, nous pouvons maintenant exécuter la logique métier.
Notre programme va effectuer des transferts: Il sélectionne aléatoirement 2 comptes, un montant aléatoire, et enfin essaie de réaliser le transfert.
Le transfert vérifiera le solde disponible du compte et si le compte figure dans la liste des comptes bloqués.
IMPORTANT: n'oubliez pas que CDC est exécuté sur votre cluster. N'utilisez donc pas "localhost" lorsque vous exécutez CockroachDB en mode Serverless ou Dedicated. Utilisez un nom de serveur approprié sur lequel votre point de terminaison peut être atteint.
Le code démarre également un serveur web pour recevoir le flux CDC (rappelez-vous le localhost dans la partie création du CDC). Pour chaque transfert effectué, nous recevons l'identifiant, la source et la destination de la table des transferts si, et seulement si, le montant est supérieur à 100.
À partir de là, nous exécutons la logique que nous voulons.
Nous appelons notre UDF (User Defined Function), pour obtenir le niveau d'anomalie de ce transfert. Ensuite, nous ajoutons ce niveau dans lq table des anomalies afin de pouvoir suivre tous les transferts "suspects" de ce compte. Rappelez-vous, avec le TTL, une anomalie ne restera dans la table que pendant 1 minute.
Ensuite, nous calculons un taux de risque du compte pour déterminer si nous devons l'insérer dans la liste des comptes bloqués :
Le taux est simplement calculé en comptant les transferts marqués comme warning et 5 fois les transferts marqués comme alerte. C'est là que le TTL est vraiment important car vous ne voulez pas garder tous ces niveaux d'anomalie pour éviter de bloquer un compte indéfiniment !
Derniers points
Comme nous l'avons mentionné, il s'agit d'un exemple simple sans véritable logique de détection des fraudes. Mais l'idée est là. Le CDC, l'UDF et le TTL sont d'excellentes fonctionnalités et sont encore meilleures lorsqu'elles fonctionnent ensemble.
Vous pouvez imaginer bien d'autres choses en suivant ces étapes simples, comme une fonction de rate limit, l'activation du calcul des paramètres en temps quasi réel pour les algorithmes ML, etc.
L'architecture Event-Driven est désormais aussi plus facile à mettre en œuvre.
Vous pouvez consulter le code source utilisé ici.