Bases de données non relationnelles et charges de travail mixtes prenant en charge –

Cet article a été créé en partenariat avec MongoDB . Merci de soutenir les partenaires qui rendent SitePoint possible.

Supposons que vous développiez une plate-forme de commerce électronique et que, dans le cadre de cet exercice, vous deviez mettre au point une nouvelle architecture de données pour la gestion des stocks. Vous devez prendre en charge des charges de travail transactionnelles rapides pour assurer le suivi des stocks presque en temps réel.

L'entreprise souhaite également pouvoir répondre à des questions telles que "sur la base de données historiques, quand devons-nous nous réapprovisionner en widgets et en gizmos ? ”Et“ Quelles sont les personnes qui achètent les widgets et généralement, où sont-ils situés? ”Votre architecture de données doit prendre en charge des charges de travail mixtes .

Où commencerais-tu?

Pour le composant transactionnel, vous vous rendrez probablement compte qu'il vous faut une base de données opérationnelle, c'est-à-dire une base de données vous permettant d'effectuer des opérations de lecture, d'écriture et de mise à jour sur vos données. Cela devrait être logique car vous devez non seulement connaître le nombre de widgets que vous avez dans votre inventaire, mais également être en mesure de le mettre à jour lorsqu'un client achète un widget. Et vous devez également vous assurer que votre couche de données est en mesure de fournir une vue cohérente des données à toutes les applications connectées. Sinon, vos clients bientôt mécontents se retrouveraient dans des paniers non disponibles dans leurs paniers.

Pour supporter votre charge de travail transactionnelle, il ne manque pas de bases de données opérationnelles parmi lesquelles choisir car les technologies sous-jacentes sont de retour 40 années. Pour les applications devant gérer divers types de données et structures de données, telles que notre application d'inventaire, de nombreuses entreprises ont opté pour de nouvelles options non relationnelles au lieu de bases de données relationnelles telles qu'Oracle, MySQL ou SQL Server.

En effet, les bases de données non relationnelles, qui ne stockent pas les données en rangées et en colonnes comme le font les bases de données relationnelles, offrent plus de souplesse dans leur capacité à ingérer et à traiter des données de formats et de formes variés, permettant ainsi d’économiser beaucoup de temps et cycles de développement et d'itération d'applications. Conçues pour évoluer verticalement («acquérir une machine plus grande»), les bases de données relationnelles traditionnelles ont également du mal à prendre en charge les requêtes distribuées avec une faible latence et peuvent rencontrer des limitations de performances. Cela pourrait poser problème si nous avons des clients répartis géographiquement ou des pics inattendus dans l'utilisation des applications.

Pour examiner les architectures de données permettant de prendre en charge des charges de travail mixtes comparons l’implémentation à deux bases de données opérationnelles non relationnelles populaires: DynamoDB, qui est un service de base de données non relationnelle développé par AWS; et MongoDB l'une des bases de données non relationnelles les plus populaires.

Workloads mixtes avec DynamoDB

DynamoDB est un service de base de données Cloud entièrement géré qui stocke les données sous forme d'un ensemble de paires clé-valeur dans lesquelles une clé sert d'identificateur unique. Les clés et les valeurs peuvent être n'importe quoi, allant des objets simples aux objets composés complexes. Cela simplifie considérablement l'ingestion et la persistance d'une grande variété de données par rapport à l'utilisation d'une base de données relationnelle.

Toutefois, pour les requêtes autres que les analyses que nous voulons que notre architecture de données prenne en charge, AWS vous recommande d'utiliser des produits supplémentaires tels qu'Amazon EMR, Amazon Redshift, etc.

Source: https://aws.amazon.com/dynamodb/

En effet, le pouvoir d'expression du langage de requête DynamoDB, ou plus simplement, le Le nombre d'idées pouvant être représentées et communiquées à l'aide du langage de requête de DynamoDB est quelque peu limité. Cette qualité est assez courante parmi les bases de données non relationnelles – parfois appelées bases de données «NoSQL» – optimisées pour la flexibilité et l'évolutivité des modèles de données, souvent au détriment des fonctionnalités de base de données.

Comme vous pouvez le constater à partir du modèle recommandé ci-dessus, les données sont stockées dans DynamoDB, puis transférées vers Amazon EMR, qui fournit un environnement Big Data géré pour le traitement. Les données sont ensuite acheminées vers Amazon Redshift, un entrepôt de données géré pour agrégation. Enfin, Amazon Quicksight, outil de veille stratégique, peut utiliser les données agrégées pour créer des graphiques et des tableaux de bord que les utilisateurs professionnels peuvent exploiter.

Cette architecture de données comporte de nombreux éléments mobiles, sans parler de la complexité accrue de l'apprentissage de l'utilisation, du développement et de l'exploitation de plusieurs composants (compensés par l'utilisation de services gérés plutôt que par l'ensemble votre propre) et les coûts. Et puisque les données sont déplacées d'un système à l'autre, il est très probable que les données représentées dans les graphiques et les tableaux de bord à une extrémité ne correspondent pas à l'état actuel de la base de données source.

Cette approche n’est pas fondamentalement fausse tant que les mises en garde ci-dessus vous conviennent, mais examinons-en une autre.

Charges de travail mixtes avec MongoDB

MongoDB est similaire à DynamoDB à quelques égards:

• Il s'agit d'une base de données non relationnelle
• Elle est disponible en tant que base de données en nuage entièrement gérée via . MongoDB Atlas

C’est là que finissent les similitudes. Contrairement à DynamoDB, les données sont stockées dans des documents de type JSON. Les documents peuvent contenir autant de paires clé-valeur ou de structures imbriquées complexes qu'une application. MongoDB possède également un langage de requête expressif qui le différencie des autres bases de données non relationnelles. Il est non seulement facile d’obtenir des données dans la base de données, mais il est également facile de les récupérer de manière à servir une variété de cas d’utilisation. Par exemple, la base de données dispose d'une structure d'agrégation qui vous permet d'effectuer des analyses sur place sans déplacer les données vers un autre système.

Cela signifie que notre architecture de données permettant de prendre en charge des charges de travail mixtes peut être beaucoup plus simple. Si nous supprimons Amazon EMR et Amazon Redshift (ou les services équivalents de votre fournisseur de cloud), nous conservons la base de données et notre outil de veille stratégique ou de tableau de bord de choix.

Nous devons cependant prendre en compte un autre point: comment garantir que les requêtes analytiques, qui durent généralement plus longtemps que celles prenant en charge une charge de travail transactionnelle, n'affectent pas les performances du système global? Heureusement, MongoDB a aussi une réponse à cela. La base de données prend en charge de manière native la réplication et le basculement automatisé pour assurer une haute disponibilité, mais des nœuds de réplica peuvent également être ajoutés et utilisés pour isoler des charges de travail et des requêtes spécifiques.

Atlas, le service entièrement géré pour MongoDB vous permet de créer un cluster de base de données et d'ajouter des nœuds de réplicas supplémentaires pour l'isolation de la charge de travail (appelés "nœuds d'analyse" spécialisés) en un seul clic. appel. Toutes les requêtes analytiques de longue durée atteindraient ces nœuds d’analyse, garantissant ainsi que les performances des charges de travail transactionnelles ne sont pas affectées.

Atlas fournit également un outil d'analyse en libre-service dans le nuage appelé MongoDB Charts, qui s'exécute de manière native sur des données MongoDB sans mouvement ni transformation de données. Cela vous donne des informations plus précises sur l'état réel des choses, car l'outil de BI exploite des données en temps réel.

Notez que, dans la mesure où vous exécuterez des requêtes analytiques sur un réplica, il est également possible d'assurer une cohérence éventuelle. Le "décalage" dans ce scénario est susceptible d'être plus court car il est lié au délai entre l'opération sur le réplica "principal" et l'application de cette opération au réplica d'analyse, et non le déplacement physique des données sur plusieurs systèmes disparates, comme indiqué dans architecture précédente.

Voilà ce qu'il vous faut – deux architectures de données différentes pour la prise en charge de charges de travail mixtes utilisant des bases de données non relationnelles. Chacun a ses compromis. Si vous avez besoin d'analyses complexes sur vos données transactionnelles, il peut être intéressant de prendre en compte la complexité, les temps de latence et les coûts supplémentaires associés à la transformation de vos données et à leur transfert entre Amazon EMR et Amazon Redshift.

Cependant, les questions d’analyse soulevées au début de cet article n’appellent pas ce niveau de complexité. En sélectionnant une base de données qui vous permet d'exécuter des analyses sur place ET un moyen d'isoler ces charges de travail afin de minimiser l'impact des performances sur les opérations en temps réel, votre architecture peut être beaucoup plus simple et plus facile à utiliser.