Migration de SQL vers NoSQL Databases
Étapes pour migrer des données d'une base de données relationnelle vers NoSQL
L'utilisation d'une base de données relationnelle dans vos applications .NET n'est pas sans limites, telles que son incapacité à gérer plus de charge sans remplacer le matériel existant (mise à l'échelle) et son incapacité à mettre à jour son modèle de données rigide, c'est-à-dire les lignes et les colonnes. Si vous êtes confronté à ces défis, vous avez peut-être déjà décidé de déplacer votre base de données vers NoSQL. Si vous n'êtes toujours pas convaincu, vous voudrez peut-être lire Constat NoSQL?
Considérant le cas où vous n'avez plus d'options pour mettre à l'échelle votre couche de base de données et que vous avez choisi de déplacer vos données vers NoSQL, la tâche ardue de la migration peut vous empêcher de franchir ce pas.
Bien que la migration soit une tâche importante, si elle est divisée en étapes, elle peut être abordée de manière très organisée, ce qui vous facilite la vie. Ce livre blanc est là pour vous aider à organiser votre processus de migration en 6 étapes logiques.
Si vous suivez ces étapes simples, elles vous aideront dans votre processus de migration. Cet article considère que vous connaissez déjà les bases des fonctionnalités de NosDB, un filet NoSQL Base de données documentaire. Si ce n'est pas le cas, rendez-vous sur site . Ci-dessous, je vous présente les détails du processus susmentionné.
Étape 1 : Identifier la portée
La première et la plus importante étape consiste à comprendre votre modèle économique et le schéma de la base de données. Vous devrez également comprendre parfaitement comment votre application accède à ces données et le flux de données vers et depuis votre base de données. Cela permet d’identifier deux informations clés :
- La partie de votre schéma de base de données la plus consultée (lecture, écriture ou les deux)
- Données regroupées, c'est-à-dire toujours consultées ensemble pour les lectures et les écritures.
Ces informations vous aident à identifier les décisions clés dans les étapes restantes. Par conséquent, c'est aussi l'étape la plus cruciale.
Étape 2: Identifiez NoSQL Configuration requise
Une fois que vous aurez fini de comprendre votre modèle d'entreprise et le flux de données, vous serez en mesure de prendre quelques décisions approximatives sur la façon de déployer votre NoSQL cluster, en fonction des besoins de votre entreprise. Par exemple, noter le nombre actuel d'applications en cours d'exécution, le nombre d'utilisateurs et le taux d'accès sont des mesures importantes. Noter quelle partie de vos données est hautement sensible, c'est-à-dire que vous devez avoir une sauvegarde à tout prix, vous aide également à décider de la stratégie de déploiement des nœuds de réplique.
Depuis un NoSQL database est une base de données distribuée, vous pouvez tirer parti de la nature distribuée à votre avantage et la déployer selon les besoins de votre entreprise. Le plus grand avantage dont vous bénéficiez, en plus de l'évolutivité, est la distribution/le déploiement de votre NosDB fragments de cluster sur différents emplacements GEO. Cela vous permet de déployer des partitions à proximité de l'emplacement géographique de votre application et d'éviter des déplacements réseau coûteux. Et cela améliore les performances de l'application.
N'oubliez pas que tout ce que nous faisons ici est d'esquisser les exigences. Nous reviendrons certainement sur ces paramètres après avoir identifié, créé et optimisé nos collections.
Étape 3 : Convertir et optimiser les collections JSON
Maintenant que vous avez les exigences de base de votre cluster de déploiement, votre « esquisse » dictera vos stratégies d'optimisation.
Convertir des tables en collections
Tout d'abord, convertissez simplement les tables de la base de données relationnelle en collections et convertissez vos colonnes en attributs. C'est le normalisée données provenant d'une base de données relationnelle.
Dénormaliser les données en incorporant des documents
Ensuite, vous devez dénormaliser des tables isolées, c'est-à-dire des tables qui n'ont de sens que si elles sont corrélées avec une autre table. En termes relationnels, les tables isolées sont tables de jonction. Par exemple, Détails de la commande dans une base de données Northwind ont plus de sens lorsqu'ils sont mentionnés en référence à une commande. Par conséquent, le bon choix serait d'intégrer OrderDetails dans le Commander documents.
Convertir les relations
Maintenant, ce qu'il vous reste, ce sont ces collections contenant des documents qui ont leurs tables de jonction enchâssés en eux. Mais qu'en est-il des relations plusieurs-à-plusieurs, un-à-plusieurs et autres ? C'est là que vos connaissances sur les données naturellement groupées et les données accessibles ensemble sont utiles.
Dans le Exemple de migration de la base de données NorthWind, Témoignages ainsi que Commander les tables sont liées mais pas toujours consultées ensemble. Il n'est donc pas logique d'intégrer le Objet client à l'intérieur de l' Document de commande. De plus, l'intégration de la Document client va dupliquer inutilement des données, ce que nous voulons éviter autant que possible. Sinon, un seul changement dans le profil du client obligera l'application à effectuer le changement dans tous les Commande.Client documents. Un coût de calcul inutile.
D'autre part, les catégories sont toujours requises par l'application chaque fois que le produit est récupéré ; c'est donc un bon candidat pour l'intégration. Et, n'oubliez pas que la beauté des documents JSON est qu'ils peuvent également prendre en charge des tableaux, et des tableaux de documents JSON, pour enrichir vos objets.
Modèle hybride - Le meilleur de la normalisation et de la dénormalisation
Depuis un NoSQL schéma est basé sur le flux de données de l'application, si une collection a l'avantage de la garder à la fois intégrée et non intégrée, adoptez le modèle hybride.
Dans l'exemple de base de données Northwind, référencé à la page précédente, ce phénomène peut être observé dans le Catégories ainsi que Produit les tables. Le scénario est que chaque fois qu'un Produit est accessible, l'application doit connaître son Catégories. Mais l'application doit également savoir Produits by Catégories.
Si la Catégories était conservé dans une table séparée, une seule récupération de produit signifierait deux appels de base de données, un pour récupérer le Produit et l'autre pour aller chercher les Catégories, d'où le surcoût du réseau. Si seulement le Catégories était intégré, alors pour trouver toutes les catégories, vous auriez à exécuter l'instruction SQL suivante :
SELECT DISTINCT product.Category.CategoryName FROM Products;Une requête SQL simple mais pas très efficace, n'est-ce pas ? Donc la réponse est de garder le Catégories document dans une collection séparée, mais n'intégrez que la partie qui est nécessairement requise par le produit. Cela s'appelle un Modèle hybride.
Par exemple, dans notre scénario, lorsque l'application récupère le document Produit, il suffit de connaître le Catégories Nom et Catégories La description. Par conséquent, il est totalement inutile d'intégrer le Catégories Image dans chaque document produit. En effet, s'il est dupliqué, il prendra beaucoup de stockage inutile et augmentera la taille du document imposant ainsi un coûteux voyage sur le réseau.
Il s'agit d'un cas d'utilisation parfait d'un modèle hybride, ainsi les collections auraient la forme suivante :
"Product" {
"name": "string",
"category": {
"name": "string",
"description": "string",
}
}et stockage Catégories également séparément :
"Category" {
"name": "string",
"description": "string",
"picture": byte[]
}
}Décidez de votre stratégie de distribution
La prochaine chose à décider est la stratégie de distribution probable de vos collections. L'esquisse initiale de vos exigences de configuration affecte directement cela.
Trois options s'offrent à vous pour votre stratégie de distribution :
- Distribution basée sur la plage : Cette stratégie vous permet de définir comment les données sont réparties entre les nœuds en fonction des plages spécifiées pour chaque partition. Par exemple, si votre NosDB cluster est GEO distribué avec un fragment à New York et un autre à Londres, les données générées et requises par les applications existantes à New York doivent se trouver au même emplacement GEO, optimisant ainsi les coûts du réseau. Cette stratégie est principalement utilisée dans les clusters distribués GEO, mais a également d'autres cas d'utilisation.
- Distribution basée sur le hachage : Le hachage vous permet de répartir uniformément les données sur les fragments, répartissant ainsi uniformément la charge. Cette stratégie n'est pas le meilleur choix pour un cluster distribué GEO, mais est idéale pour NosDB clusters au sein d'un même centre de données.
- Collection fragmentée unique (désactiver la distribution) : Cela désactive complètement la distribution sur une collection. Utilisez cette option si votre ensemble de données est petit ou si vous souhaitez spécifiquement qu'il se trouve sur une seule machine.
Après avoir décidé de votre stratégie de distribution, vous souhaiterez peut-être revoir l'optimisation de votre collection et votre stratégie de déploiement pour voir si elles peuvent être optimisées davantage. Quelques itérations suffisent généralement pour prendre une décision.
Étape 4 : migrer les données
Enfin, après un long remue-méninges, voici la partie relativement facile, à savoir la migration des données de la base de données relationnelle vers la NoSQL database.
Créez d'abord vos objets .NET représentant vos collections et documents JSON. Oui! aucun ORM n'est nécessaire pour insérer des données puisque l'API .NET convertit automatiquement vos objets .NET en documents JSON. (Juste une note, cependant, vous pouvez également choisir d'utiliser l'intégration ADO.NET fournie avec NosDB).
Ensuite, accédez à votre base de données relationnelle et remplissez ces objets .NET, puis insérez-les dans le NoSQL database. Vous pouvez également utiliser les déclencheurs CLR et les UDF CLR fournis par NosDB pour accompagner votre migration.
Une fois vos données migrées, il est maintenant temps de migrer votre application pour adopter les données en termes de collections et de documents. Sans NosDB vous n'avez pas la possibilité d'utiliser les déclencheurs et UDF ADO.NET ou CLR, mais vous pouvez toujours utiliser l'API.
Étape 5 : migrer l'application
Il existe plusieurs façons de migrer votre application .NET vers NosDB. NosDB prend en charge les opérations SQL telles que SELECT, INSERT, UPDATE et DELETE. L'utilisation d'opérations SQL réduit considérablement la courbe d'apprentissage pour migrer votre application, c'est-à-dire que vous pouvez utiliser la syntaxe à laquelle vous êtes habitué. Vous pouvez même gérer le cluster de bases de données dans NosDB en utilisant SQL.
NosDB prend en charge SQL avec toutes les multiples façons d'accéder à la base de données, à savoir :
- API .NET
- ADO.NET
- LINQ
- API Java
- API REST
Vous pouvez également utiliser l'API côté serveur pour améliorer les performances de votre application, en tirant parti de la puissance de la distribution à l'aide de frameworks tels que MapReduce. Si vous n'utilisez pas NosDB vous n'avez que la possibilité d'appeler directement l'API. SQL et ADO.NET ne sont fournis que par NosDB.
Étape 6 : Valider la migration
Après la migration, la validation est la dernière étape de tout le processus : vérifiez tous vos tests, validez les données migrées et votre application. Cette étape dépend entièrement de vous et de vos processus métier. Banc le nouvellement incorporé NoSQL database. Vérifiez les limites de la configuration actuelle du cluster (bien que vous puissiez évoluer quand vous le souhaitez) et équipez-vous des bons outils comme NosDB Management Studio pour gérer et surveiller l'ensemble du cluster à partir d'un seul emplacement.
C'est ça! Si vous suivez ces étapes, vous pouvez organiser votre migration d'une base de données relationnelle vers une NoSQL database dans un processus logique en 6 étapes.