Catégories
Start-up et applications

Le passage du SGBDR à NoSQL nécessite une optimisation au fil du temps

Les entreprises se tournent rapidement vers les bases de données NoSQL pour répondre aux exigences de performances et d’évolutivité qui sont actuellement exigées par les tonnes de données. Le passage des systèmes de gestion de bases de données relationnelles (SGBDR) à NoSQL est de plus en plus répandu.

«La plupart des applications que nous voyons passer à NoSQL sont Greenfield, mais nous avons également commencé à voir plus de migrations récemment à partir de backends relationnels et il y a vraiment beaucoup de raisons à cela», Mark Gamble, directeur marketing produits et solutions chez Couchbase, une base de données cloud NoSQL, a déclaré lors d'une récente Webinaire SD Times.

Alors que les applications existantes architecturées sur un SGBDR ont peut-être bien fonctionné auparavant, il y a maintenant beaucoup de changements à venir et de nouvelles demandes attendues en termes d'évolutivité que l'architecture n'a pas été conçue pour gérer.

«Que ce soit parce qu'un fournisseur de téléphonie mobile souhaite donner plus de visibilité aux utilisateurs sur leur utilisation des données en rendant un service externe disponible à distance, ou peut-être que ce soit un détaillant qui a soudainement beaucoup de commandes en ligne, ou une entreprise de services financiers qui a des volumes de données croissants. et poursuit une architecture plus orientée services et consolidée. Chacun de ces exemples suit ce modèle général », a déclaré Gamble. «Beaucoup de changements, très rapides, et le besoin de plus de fiabilité et d'une meilleure évolutivité.»

Bien que les organisations qui planifient le changement en réalisent les avantages, elles craignent également qu'une migration technologique comporte des risques, en particulier si elle nécessite de modifier un modèle de données.

Il existe de nombreuses façons de procéder avec différents niveaux de risque et d'effort requis. «Nous équilibrons vraiment les performances et l’évolutivité avec nos efforts et nos risques», a déclaré Gamble.

La réécriture complète de l'application ou la refonte du schéma ont tendance à être extrêmement difficiles à réaliser correctement.

C’est pourquoi les entreprises ont tendance à opter pour deux options moins invasives. La première est la refactorisation, dans laquelle les organisations conservent tout, mais refactorisent la logique des données et le schéma SGBDR dans un schéma NoSQL des meilleures pratiques.

Une autre est l'approche «optimiser plus tard» dans laquelle les organisations hébergent leur schéma avec le moins de changements possible, font fonctionner l'application sur la nouvelle technologie et refactorisent / optimisent le schéma si nécessaire pour que les performances progressent. C'est l'option qui offre le meilleur équilibre entre une migration rapide et un faible risque et effort, selon Gamble.

Pour cette option, les organisations doivent disposer d'une base de données NoSQL prenant en charge les transactions SQL, ACID et les jointures. Ils doivent également comprendre comment les tableaux et les lignes sont liés aux documents, selon Gamble. Il y aura également des transitions SQL Dialect similaires à celles effectuées entre deux SGBDR.

«Une fois que tout est en marche, il se peut que nous ne voyions pas d’amélioration des performances tant que nous n’aurons pas optimisé. Nous devons vraiment nous attendre à cela dès le départ », a déclaré Gamble. «Lorsque nous passons à une architecture distribuée, il existe un autre sweet spot pour la performance.»

Lors de l’optimisation, il est important de minimiser les jointures en éliminant les tables disparates et en incorporant les détails directement dans l’enregistrement. D'autres considérations incluent l'utilisation d'un code d'application bien conçu comme guide et de penser en termes d'entités.

En outre, en essayant d'optimiser, les organisations devraient s'efforcer de réduire le nombre de transactions explicites et de jointures requises là où cela aura un impact certain sur les performances, selon Gamble.

«Si vous commencez à optimiser et que vous constatez des performances acceptables, votre optimisation peut être terminée. Vous pouvez répondre aux exigences avec moins de travail que vous ne le pensiez », a déclaré Gamble.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *