Les bases de données et modèles graphes existent depuis largement plus d’une décennie et figurent parmi les technologies les plus influentes issues du mouvement NoSQL.
Les modèles de données graphes sont conçus nativement pour se concentrer sur les relations au sein des données, en les représentant sous forme de nœuds reliés par des arêtes. À ce titre, le modèle graphe est étonnamment similaire à la manière dont les humains pensent et s’expriment souvent.
Dans un graphe, le schéma nœud-arête-nœud correspond directement au schéma sujet-prédicat-objet courant dans des langues comme l’anglais. Ainsi, si vous avez déjà utilisé un outil de carte heuristique ou représenté des idées sur un tableau blanc, vous avez créé un graphe.
Les modèles de données graphes sont devenus un outil standard des data scientists qui appliquent l’intelligence artificielle (IA) à des domaines allant de la détection des fraudes et des systèmes de contrôle industriels aux moteurs de recommandation et aux vues client à 360.
Compte tenu de cette large applicabilité, il n’est pas surprenant que Gartner estime que les technologies de bases de données graphes seront utilisées dans plus de 80 % des innovations en matière de données et d’analytique, y compris la diffusion d’événements en temps réel, d’ici 2025. Mais à mesure que l’adoption s’accélère, des limites et des difficultés apparaissent. Et l’une des limites les plus importantes auxquelles sont confrontées les bases de données graphes est leur incapacité à passer à l’échelle.
À lire également : Tendances de la gestion des données en temps réel
Volume et vélocité de la génération de données moderne
Beaucoup de choses ont changé depuis l’apparition, il y a une dizaine d’années, de la génération la plus récente de bases de données graphes. Les entreprises doivent gérer des volumes de données potentiellement interrogeables qui étaient inimaginables auparavant. Ces données entrent dans l’entreprise et y circulent par différents canaux, et les entreprises veulent agir sur ces informations en temps réel.
Les conceptions originales des graphes ne pouvaient pas anticiper le volume colossal de données actuel ni la puissance de calcul nécessaire pour les exploiter. Et ce n’est pas seulement le volume des données qui ralentit les bases de données graphes. C’est aussi la vélocité de ces données.
Si les bases de données graphes peuvent exceller dans les calculs sur des ensembles de données de taille modérée au repos, elles deviennent particulièrement cloisonnées et subissent des compromis importants lorsque l’on souhaite déclencher des actions en temps réel sur des données en flux. Les flux correspondent à des données en mouvement permanent ; elles arrivent constamment de sources diverses.
Les entreprises veulent agir immédiatement sur ces données dans des pipelines de traitement d’événements, car lorsque certains événements ne sont pas détectés assez rapidement, au moment où ils se produisent, la possibilité d’agir disparaît. C’est le cas, par exemple, des incidents de sécurité, du traitement des transactions (comme la détection des fraudes ou la validation des crédits) et des actions automatisées de machine à machine.
Les anomalies et les schémas doivent être identifiés par des algorithmes d’IA et de ML capables d’automatiser une action, ou au moins de la faire remonter. Cette identification doit avoir lieu avant qu’une action automatisée puisse être exécutée.
Les bases de données graphes n’ont tout simplement jamais été conçues pour ce scénario. Elles sont généralement limitées à quelques centaines ou milliers d’événements par seconde. Or les entreprises actuelles doivent pouvoir traiter une vélocité de millions d’événements par seconde et, dans certains cas d’usage avancés, de dizaines de millions.
Il existe une limite stricte à la fois à la vitesse à laquelle les systèmes graphes peuvent traiter les données et à la complexité qu’ils peuvent gérer (par exemple, le nombre de sauts dans la requête). En raison de ces limites, les systèmes graphes ne sont souvent pas utilisés. Et puisqu’ils ne le sont pas, les équipes d’ingénierie des données n’ont d’autre choix que de recréer des fonctionnalités similaires à celles d’une base de données graphe, réparties dans leur architecture de microservices.
À lire également : Les meilleurs outils d’analytique des données
L’essor du développement de pipelines de données sur mesure
Ces solutions de contournement pour interroger les flux d’événements en temps réel exigent des efforts considérables. Les développeurs se tournent généralement vers des systèmes de traitement de flux d’événements comme Flink et ksqlDB, qui permettent — sans toutefois simplifier la tâche — d’utiliser une syntaxe de requête SQL familière pour interroger les flux d’événements.
Il n’est pas rare que les entreprises mobilisent pendant des mois ou des années des équipes d’ingénieurs des données pour développer des architectures de microservices étendues et complexes, afin d’atteindre les niveaux de capacité et de vitesse requis par les données en flux. Cependant, ces systèmes tendent à manquer des structures de requête suffisamment expressives pour détecter efficacement des schémas complexes dans les flux.
Comme indiqué précédemment, pour fonctionner avec les volumes et la vélocité exigés par les entreprises, ces systèmes ont dû faire des compromis difficiles, qui entraînent des limites importantes.
Par exemple, les fenêtres temporelles peuvent limiter la capacité d’un système à relier des événements qui n’arrivent pas dans un intervalle de temps étroit (souvent mesuré en secondes ou en minutes). Ainsi, au lieu d’apporter un éclairage essentiel ou une valeur métier, un événement est tout simplement ignoré s’il arrive ne serait-ce que quelques secondes trop tard.
Même avec des limites coûteuses comme les fenêtres temporelles, les systèmes de traitement de flux d’événements ont rencontré le succès. Beaucoup peuvent même passer à l’échelle pour traiter des millions d’événements par seconde — mais au prix d’efforts et de limitations importants qui les empêchent de fournir toute la puissance des modèles de données graphes.
À lire également : Pourquoi le cloud signifie cloud native
L’innovation répondra à la demande
La demande d’informations issues des flux instantanés de données événementielles et la valeur qu’ils apportent n’ont jamais été aussi élevées. À mesure que l’adoption s’accélère, les entreprises doivent s’attendre à voir émerger de nouvelles infrastructures de données capables d’éliminer bon nombre des difficultés de passage à l’échelle qui peuvent freiner la puissance des modèles de bases de données graphes.
À propos de l’auteur :
Rob Malnati est le directeur des opérations de thatDot