Notre mission n'est pas seulement de construire une solution robuste, mais \u00e9galement d'investir dans la recherche et le d\u00e9veloppement et d'aller au-del\u00e0 des limites des architectures traditionnelles pour mieux \u00e9voluer et r\u00e9pondre \u00e0 de nouveaux cas d'utilisation difficiles comme le traitement et l'analyse d'une grande quantit\u00e9 de donn\u00e9es en temps r\u00e9el. .<\/p>\n
Chaque solution pr\u00e9sente ses propres avantages et inconv\u00e9nients, d'autant plus que nous ex\u00e9cutons souvent des syst\u00e8mes sur des r\u00e9seaux et des disques existants et que nous gardons sous contr\u00f4le les co\u00fbts du processeur et de la m\u00e9moire. Sans remonter jusqu'\u00e0 l'\u00e9poque d'Alan Turing, les caract\u00e9ristiques des probl\u00e8mes trait\u00e9s par la solution Moneythor ont depuis longtemps \u00e9t\u00e9 class\u00e9es en deux cat\u00e9gories distinctes, le traitement des transactions en ligne (OLTP)<\/strong> et traitement analytique en ligne (OLAP)<\/strong>.<\/p>\n La solution Moneythor propose un moteur d\u00e9ploy\u00e9 entre les syst\u00e8mes d'enregistrement des institutions financi\u00e8res et leurs canaux num\u00e9riques pour proposer des exp\u00e9riences engageantes et personnalis\u00e9es pour les utilisateurs finaux. Il est donc attendu que notre solution puisse dig\u00e9rer un grand volume de donn\u00e9es en temps r\u00e9el de mani\u00e8re fiable et \u00e9volutive.<\/p>\n Les syst\u00e8mes de gestion de bases de donn\u00e9es relationnelles (SGBDR) se sont historiquement r\u00e9v\u00e9l\u00e9s \u00eatre un moyen efficace et fiable de mettre en \u0153uvre un tel syst\u00e8me OLTP, car ils offrent \u00e9galement l'avantage extr\u00eamement pr\u00e9cieux d'\u00eatre conformes \u00e0 l'ACID.<\/p>\n Notre solution comprend \u00e9galement Gestion de finances personnelles (PFM)<\/a> des fonctionnalit\u00e9s pilot\u00e9es par des API qui peuvent cr\u00e9er, lire, mettre \u00e0 jour et supprimer des objets personnalis\u00e9s tels que des budgets, des objectifs, des abonnements et bien plus encore. Il est donc crucial que les canaux digitaux appelant notre API puissent s'appuyer inconditionnellement sur leurs r\u00e9ponses et pour cela, notre solution tire largement parti de la Atomicit\u00e9<\/strong>, Coh\u00e9rence<\/strong>, Isolement<\/strong> et Durabilit\u00e9 <\/strong>(ACID) de la base de donn\u00e9es, qu'il s'agisse d'un SGBDR ou non.<\/p>\n La solution Moneythor permet de fournir des informations, des recommandations et des coups de pouce bas\u00e9s sur les donn\u00e9es et adapt\u00e9s \u00e0 chaque client. C\u2019est l\u00e0 que la partie analytique de la solution brille et permet \u00e0 nos clients d\u2019imaginer une large gamme de nudges contextuels et personnalis\u00e9s pour leurs clients.<\/p>\n Une telle analyse de donn\u00e9es repose g\u00e9n\u00e9ralement sur un syst\u00e8me OLAP optimis\u00e9 pour cette t\u00e2che et c'est l\u00e0 que des frictions peuvent appara\u00eetre lorsque l'on tente de cr\u00e9er une solution au-dessus d'OLTP et d'OLAP.<\/p>\n Tout en \u00e9tant intelligents dans ce qu'ils peuvent faire avec les donn\u00e9es, les syst\u00e8mes OLAP fonctionnent bien lorsque les donn\u00e9es ne changent pas beaucoup, ce qui n'est pas un sc\u00e9nario typique avec une solution bancaire num\u00e9rique qui re\u00e7oit des millions de transactions par jour, en temps r\u00e9el et lorsque les donn\u00e9es l\u2019analyse devrait avoir lieu \u00e0 ce moment-l\u00e0. De plus, les donn\u00e9es peuvent \u00eatre modifi\u00e9es par les utilisateurs eux-m\u00eames, ce qui peut conduire \u00e0 un r\u00e9sultat compl\u00e8tement diff\u00e9rent en mati\u00e8re de nudges personnalis\u00e9s.<\/p>\n Les syst\u00e8mes OLAP ne sont pas n\u00e9cessairement con\u00e7us avec un temps de r\u00e9ponse rapide comme priorit\u00e9 absolue, alors que les nouvelles exp\u00e9riences utilisateur construites sur l'API Moneythor sont servies via HTTP et donc synchrones. Attendre plus de quelques secondes pour qu\u2019un \u00e9cran soit rendu semble aujourd\u2019hui une \u00e9ternit\u00e9.<\/p>\n Compte tenu de ces contraintes, la solution Moneythor exploite le meilleur des deux types de syst\u00e8mes et att\u00e9nue leurs lacunes gr\u00e2ce \u00e0 une architecture distribu\u00e9e pr\u00e9sentant les caract\u00e9ristiques ci-dessous.<\/p>\n je)<\/strong> Lorsque les avantages d\u00e9passent largement le co\u00fbt de la redondance et du traitement suppl\u00e9mentaire, les donn\u00e9es du magasin persistant sont d\u00e9normalis\u00e9es au cas par cas. Cela nous permet de continuer \u00e0 traiter les donn\u00e9es transactionnelles tout en ma\u00eetrisant le temps de traitement analytique.<\/p>\n ii)<\/strong> La solution Moneythor se situe entre d'autres syst\u00e8mes et s'int\u00e8gre nativement aux plateformes de streaming d'\u00e9v\u00e9nements distribu\u00e9s. Par exemple, Apache\u00a0Kafka<\/a> est un outil tr\u00e8s populaire et, associ\u00e9 \u00e0 la solution Moneythor, il am\u00e9liore consid\u00e9rablement les performances globales et simplifie la mise en \u0153uvre et l'\u00e9volutivit\u00e9, car les deux syst\u00e8mes sont distribu\u00e9s par conception. Alors que les API s'appuient fortement sur les propri\u00e9t\u00e9s ACID pr\u00e9sent\u00e9es ci-dessus et garantissent une r\u00e9ponse, lorsqu'il s'agit d'un flux de messages, Kafka et d'autres proposent g\u00e9n\u00e9ralement 3 modes de livraison de message diff\u00e9rents\u00a0: un message peut \u00eatre livr\u00e9 ou non, un message peut \u00eatre livr\u00e9 plusieurs fois. fois, ou un message est d\u00e9livr\u00e9 exactement une fois. Le premier mode est \u00e9videmment interdit lorsqu\u2019il s\u2019agit de transactions financi\u00e8res, et m\u00eame s\u2019il peut \u00eatre int\u00e9ressant de rechercher une livraison \u00ab exactement une fois \u00bb, cela entra\u00eene un co\u00fbt suppl\u00e9mentaire en termes de performances et de complexit\u00e9. Pour cette raison et parce que les messages dans Moneythor sont idempotents, notre solution est construite autour d'un concept de livraison \u00ab au moins un \u00bb qui garantit qu'aucun message ne sera perdu, et les consommateurs peuvent simplement contr\u00f4ler les doublons gr\u00e2ce aux drapeaux idempotents.<\/p>\n ii)<\/strong> Enfin, nous ne pouvons pas discuter des syst\u00e8mes distribu\u00e9s sans pr\u00eater attention aux CASQUETTE<\/strong> et PACELC<\/strong> th\u00e9or\u00e8mes. La premi\u00e8re stipule que tout magasin de donn\u00e9es distribu\u00e9 ne peut fournir que deux des trois garanties suivantes\u00a0:<\/p>\n Coh\u00e9rence<\/strong> (C) : chaque lecture, chaque appel API dans le contexte pr\u00e9sent, re\u00e7oit la version la plus r\u00e9cente des donn\u00e9es ou une erreur.<\/p>\n Disponibilit\u00e9<\/strong> (A) : chaque requ\u00eate API re\u00e7oit une r\u00e9ponse (sans erreur), sans garantie qu'elle contienne les donn\u00e9es les plus r\u00e9centes.<\/p>\n Tol\u00e9rance de partition<\/strong> (P) : le syst\u00e8me continue de fonctionner malgr\u00e9 un nombre arbitraire de messages abandonn\u00e9s (ou retard\u00e9s) par le r\u00e9seau entre les n\u0153uds.<\/p>\n Dans la plupart des cas, la solution Moneythor est d\u00e9ploy\u00e9e dans un environnement o\u00f9 il n'y a qu'une seule instance logique de la base de donn\u00e9es (ce syst\u00e8me de base de donn\u00e9es fonctionnant g\u00e9n\u00e9ralement dans un cluster pour une haute disponibilit\u00e9). Le nombre de partitions dans ce contexte est de 1 mais ce serait une erreur d'imaginer que le syst\u00e8me puisse donc assurer \u00e0 la fois coh\u00e9rence et disponibilit\u00e9. En effet, en l'absence de partitionnement, le th\u00e9or\u00e8me PACELC affine ces r\u00e8gles en affirmant qu'il faut choisir entre Latence<\/strong> (Atterrir Coh\u00e9rence<\/strong> (C).<\/p>\n La solution Moneythor est con\u00e7ue pour \u00e9voluer verticalement en ajoutant de la puissance de traitement et horizontalement en ajoutant des instances suppl\u00e9mentaires dans son cluster. Il expose \u00e9galement un ensemble d'API frontales utilis\u00e9es pour offrir des fonctionnalit\u00e9s interactives riches aux utilisateurs finaux avec le temps de r\u00e9ponse minimum possible pour une exp\u00e9rience utilisateur optimale.<\/p>\n Pour ces raisons, la solution est optimis\u00e9e pour la latence. Bien que ce choix puisse para\u00eetre contre-intuitif surtout apr\u00e8s avoir affirm\u00e9 que les API s'appuient sur le mod\u00e8le ACID, la d\u00e9finition de la coh\u00e9rence est ici diff\u00e9rente et ne s'applique pas aux donn\u00e9es manipul\u00e9es et calcul\u00e9es par une API qui doit \u00eatre coh\u00e9rente quoi qu'il arrive mais d\u00e9terminer quand le plus de temps est disponible. les donn\u00e9es seront disponibles, imm\u00e9diatement ou \u00e9ventuellement.<\/p>\n Au contraire, cibler d'abord la coh\u00e9rence signifierait \u00e9galement que le syst\u00e8me devrait attendre que de nombreuses instances du cluster soient synchronis\u00e9es avant de renvoyer une r\u00e9ponse, car la solution utilise des caches en m\u00e9moire pour acc\u00e9l\u00e9rer le traitement et les temps de r\u00e9ponse des API. Malgr\u00e9 le meilleur r\u00e9seau et le meilleur processeur de sa cat\u00e9gorie, il serait extr\u00eamement difficile de garantir des temps de r\u00e9ponse de premier ordre dans ce cas.<\/p>\n Essentiellement, il existe des principes simples qui peuvent \u00eatre mis en \u0153uvre pour r\u00e9duire consid\u00e9rablement le risque de lecture de donn\u00e9es d\u00e9synchronis\u00e9es. Un \u00e9quilibreur de charge correctement configur\u00e9 acheminant les requ\u00eates dans le cluster vers la m\u00eame instance o\u00f9 les donn\u00e9es du contexte actuel ont d\u00e9j\u00e0 \u00e9t\u00e9 trait\u00e9es et mises en cache auparavant en est un exemple.<\/p>\n Construire une solution hautement \u00e9volutive et en temps r\u00e9el combinant des donn\u00e9es transactionnelles et analytiques est un compromis entre les fonctionnalit\u00e9s qui peuvent \u00eatre fournies, les temps de r\u00e9ponse attendus et bien s\u00fbr le co\u00fbt de d\u00e9ploiement et d'exploitation d'un tel syst\u00e8me.<\/p>\n Les architectures distribu\u00e9es et d\u00e9centralis\u00e9es peuvent \u00eatre complexes \u00e0 construire, et il est n\u00e9cessaire de comprendre leurs caract\u00e9ristiques pour tenir leurs promesses. Parall\u00e8lement, la technologie \u00e9volue et le calcul haute performance est de plus en plus accessible, notamment avec les plateformes Cloud. Ce sont les raisons pour lesquelles nous avons choisi de prendre cette direction, qui nous permet d\u00e9sormais de r\u00e9pondre avec succ\u00e8s aux besoins de personnalisation bas\u00e9e sur les donn\u00e9es des banques num\u00e9riques et des institutions financi\u00e8res de toutes tailles.<\/p>\n Pour en savoir plus sur la solution Moneythor et notre technologie, veuillez Contactez-nous<\/a>.<\/p>\n\tOLTP<\/h2>\n
\n
OLAP<\/h2>\n
Syst\u00e8mes distribu\u00e9s<\/h2>\n
Conclusion<\/h2>\n
![\"Abonnez-vous](\"https:\/\/www.moneythor.com\/wp-content\/uploads\/2024\/02\/Article-CTA-NEW-BRANDING.png\")
\t\t\t\t\t\t\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/a>\t\t\n