Notes d'étude HCIP-Planification des services de base de données-5

1. Présentation des services de base de données

1.1 Tendance de développement de la base de données

• L'échelle des données croît de manière explosive et les modes d'application des données sont constamment enrichis. Avec l'application à grande échelle du cloud computing, le modèle commercial traditionnel a changé.

1.2 Avantages de la base de données cloud

• Par rapport aux bases de données traditionnelles, les bases de données cloud présentent généralement les avantages suivants
  • Facilité d'utilisation : les bases de données cloud sont généralement fournies en tant que service cloud. Comme d'autres services cloud, elles peuvent être rapidement déployées et exécutées, et éliminent généralement le besoin d'exploitation et de maintenance.
  • Évolutivité élevée : Conçu pour l'environnement cloud, basé sur une architecture ouverte et un environnement où le cloud computing et le stockage sont séparés, l'évolutivité est plus forte
  • Faible coût : par rapport aux bases de données traditionnelles à l'ancienne, il a des coûts logiciels et matériels inférieurs et un faible coût total de possession en raison d'autres fonctionnalités telles que les services cloud à l'utilisation et l'anti-diffusion à la demande.

1.3 Classification de la base de données : SQL & NoSQL

• Base de données relationnelle : une base de données qui utilise un modèle relationnel pour organiser les données. Le modèle relationnel fait référence au modèle de table à deux dimensions, et une base de données relationnelle est une organisation de données composée de tables à deux dimensions et des connexions entre elles.
• Base de données non relationnelle : désigne un système de stockage de données non relationnel, distribué et ne garantissant généralement pas le respect des principes ACID.
• Produits communs :
  • Base de données relationnelle : SQL Server, MySQL, PostgreSQL.
  • Bases de données non relationnelles : Redis, Memcached, MongoDB.

1.4 Panorama de la base de données HUAWEI CLOUD

• Les bases de données sont divisées en bases de données relationnelles et bases de données non relationnelles :
• Base de données relationnelle : RDS pour MySQL, RDS pour PostgreSQL, RDS pour SQL Server, GaussDB (pour openGauss), GaussDB (pour MySQL).
• Bases de données non relationnelles : GaussDB (pour Mongo), GaussDB (pour Cassandra), GaussDB (pour Redis), GaussDB (pour Influx), DDS, DCS.
• Les services écologiques de la base de données incluent principalement : DDM, DRS, UGO. Middleware de base de données distribuée DDM Le middleware de base de données distribuée (DDM en abrégé) se concentre sur la résolution du problème de l'expansion de la base de données distribuée, élimine les goulots d'étranglement de capacité et de performances des bases de données traditionnelles et permet un accès simultané élevé à des données volumineuses.
• DDM est un middleware de base de données distribuée natif du cloud développé indépendamment par HUAWEI CLOUD. Il adopte une architecture de séparation de stockage et de calcul et fournit des fonctionnalités telles que la sous-base de données et la sous-table, la séparation en lecture-écriture et l'expansion élastique. Il est stable, fiable , hautement évolutif, et peut être exploité et entretenu en continu. . La gestion des clusters de serveurs est totalement transparente pour les utilisateurs. Les utilisateurs peuvent effectuer des opérations et la maintenance de la base de données ainsi que la lecture et l'écriture de données via la console de gestion DDM, offrant une expérience similaire aux bases de données autonomes traditionnelles.
• Avantages du produit : division automatique des bases de données et des tables, séparation en lecture et en écriture, expansion élastique.

2. Comparaison et sélection de services de base de données sur le cloud

2.1 Service de base de données relationnelle

2.1.1 Principes de conception SQL sur le cloud

• Présentation de la scène :
  • Petit système, applications périphériques : QPS de niveau 100 000, petit OLTP, volume de données de dizaines à centaines de Go.
  • Applications au niveau de l'entreprise : millions de RPS, OLTP de taille moyenne, volume de données de TB à dizaines de TB.
  • Système d'entreprise central à haute simultanéité : OLTP ultra-large, charge mixte, distribution native, plus de dix To.

2.1.1.1 ApsaraDB pour RDS

• sécurité:
  • Les instances ApsaraDB pour RDS s'exécutent dans des clouds privés virtuels indépendants des locataires, ce qui peut améliorer la sécurité des instances ApsaraDB pour RDS. Les utilisateurs peuvent utiliser de manière complète la configuration des sous-réseaux et des groupes de sécurité pour terminer l'isolation d'ApsaraDB pour les instances RDS.
• Contrôle d'accès:
  • Lors de la création d'une instance ApsaraDB pour RDS, le service ApsaraDB pour RDS créera de manière synchrone un compte principal de base de données pour le locataire, créera une instance de base de données et un sous-compte de base de données selon les besoins, et affectera des objets de base de données au sous-compte de base de données, réalisant ainsi le but de la séparation des autorisations.
• Cryptage des transmissions :
  • Utilisez le certificat racine CA téléchargé à partir de la console de service et fournissez le certificat lors de la connexion à la base de données pour authentifier le serveur de base de données et atteindre l'objectif de transmission cryptée.
• Cryptage du stockage :
  • Le service ApsaraDB pour RDS prend en charge le stockage chiffré des données stockées dans la base de données, et la clé de chiffrement est gérée par le KMS du service de chiffrement zéro données.
• Suppression de données :
  • La suppression sécurisée inclut non seulement le disque attaché à l'instance de base de données, mais également l'espace de stockage pour les données de sauvegarde automatique. L'instance supprimée peut restaurer les données de l'instance via la sauvegarde manuelle conservée ou utiliser l'instance pendant la période de rétention de la corbeille pour restaurer les données en reconstruisant l'instance.

2.1.1.2 Moteurs pris en charge par le service RDS

• RDS pour MySQL :
  • L'architecture est mature et stable, prend en charge les applications populaires et convient à plusieurs domaines et industries ; prend en charge diverses applications WEB à faible coût et constitue le premier choix pour les petites et moyennes entreprises.
  • La console de gestion fournit des informations de surveillance complètes, faciles à utiliser, flexibles dans la gestion, visibles et contrôlables.
  • Expansion et contraction flexibles des ressources requises en fonction des conditions commerciales à tout moment, dépenses à la demande, sur mesure.
• RDS pour PostgreSQL
  • Prise en charge du plug-in postgis, excellente application spatiale.
  • Les scénarios d'application sont riches et le coût est faible.Les ressources requises peuvent être étendues de manière flexible en fonction de la situation de l'entreprise à tout moment, et hw35802903 peut être ouvert à la demande et personnalisé.
• RDS pour SQL Server :
  • ApsaraDB pour RDS pour SQL Server présente les caractéristiques suivantes : stabilité, fiabilité, fonctionnement sûr, mise à l'échelle élastique, gestion facile et fonctionnalités économiques et pratiques. Il dispose d'une architecture haute disponibilité, d'une garantie de sécurité des données et d'une fonction de récupération de deuxième niveau en cas de panne, offrant une solution de sauvegarde flexible

2.1.2 ApsaraDB pour RDS pour MySQL

• Type et version de la base de données : MySQL 5.6, 5.7, 8.0.
• Sécurité des données : plusieurs politiques de sécurité protègent la base de données et la confidentialité des utilisateurs.
• Haute fiabilité des données : le stockage de la base de données prend en charge plus de trois copies,
• La fiabilité des données de la base de données est aussi élevée que 99,9999999 % (9 9s) et la fiabilité des données de sauvegarde est aussi élevée que 99,999999999 % (11 9s)
• Haute disponibilité des services (reprise après sinistre dans la même ville) : les instances principales et de secours prennent en charge le déploiement dans ou entre les AZ, avec une haute disponibilité des services de plus de 99,95 %.
• Accès à l'instance : plusieurs méthodes d'accès, y compris : accès IP à l'intranet, accès IP au réseau public, accès VPN
• Gestion des instances : prend en charge la gestion du cycle de vie, comme l'ajout, la suppression, la modification, la vérification et le redémarrage des instances.
• Mise à l'échelle élastique : mise à l'échelle horizontale, ajout et suppression d'instances en lecture seule (jusqu'à 5), mise à l'échelle verticale, modification des spécifications d'instance et extension de l'espace de stockage (jusqu'à 10 To).
• Sauvegarde et restauration : sauvegarde, sauvegarde automatique, sauvegarde manuelle, sauvegarde complète, sauvegarde incrémentielle, ajout de fichier de sauvegarde, suppression, copie et autre gestion du cycle de vie. Récupération, restauration à n'importe quel moment dans le temps pendant la période de conservation de la sauvegarde (récupération ponctuelle, appelée PITR) / un moment de sauvegarde complet, restauration vers la nouvelle instance / l'instance d'origine. La période de conservation des sauvegardes peut aller jusqu'à 732 jours.

2.1.2.1 Haute disponibilité inter-AZ

• Lors de la création d'une base de données, les utilisateurs peuvent choisir le type d'instance en mode actif/veille. Lorsque la base de données principale tombe en panne, elle bascule automatiquement vers la base de données de secours pour continuer à fournir des services externes. Lorsque la base de données de secours échoue également, elle accède automatiquement aux bases de données principale et de secours dans une autre zone de disponibilité pour fournir des services externes.
• Combiné avec DDM, RDS peut prendre en charge la création de jusqu'à 5 réplicas en lecture seule. Le maître et la sauvegarde complètent les données d'écriture, et le réplica en lecture seule ne termine que la lecture des données pour réaliser une segmentation automatique du trafic.
• Le mode actif-veille fournit VIP (adresse IP virtuelle) au monde extérieur. Lorsque le VIP est lié à la base de données 1, la base de données est la base de données principale. Lorsque la base de données principale échoue, le VIP flottera vers la base de données de secours, et la base de données de secours base de données deviendra une nouvelle bibliothèque principale. La dérive interne du VIP peut être complétée en quelques secondes, et le service est toujours fourni en externe. Le côté utilisateur est complètement inconscient.
• Restrictions : les utilisateurs ne peuvent créer des répliques en lecture seule qu'après avoir acheté la base de données.

2.1.2.2 Séparation lecture et écriture

• Après avoir créé un réplica en lecture seule, lorsque la base de données fournit des services externes, elle distingue d'abord les demandes du côté utilisateur pour déterminer si le type de demande est l'écriture de données ou la lecture de données. S'il s'agit d'écrire des données, les bases de données maître et de secours qui acheminent la demande terminent l'opération d'écriture des données. S'il s'agit de données lues, acheminez la demande vers le réplica en lecture seule pour terminer la lecture des données.

2.1.2.3 Haute sécurité des données

• Le nombre de jours qui prend en charge la configuration personnalisée (c'est-à-dire la période de rétention de la sauvegarde, la valeur est de 0 à 732) pour conserver cette sauvegarde automatique

2.1.2.4 Optimisation du noyau

2.1.2.5 Cas

2.1.3 ApsaraDB pour RDS pour PostgreSQL

• Base de données : fournit un support pour les versions 9.5/9.6/10.0/11/12
• Sécurité : plusieurs politiques de sécurité protègent la base de données et la confidentialité des utilisateurs.
• Migration des données : prise en charge de la migration en ligne et hors ligne cloud-on/off-cloud et cross-cloud
• Haute disponibilité : copiez les données de l'instance de base de données principale vers une instance de base de données de secours. Une fois que l'instance de base de données principale échoue et devient indisponible, elle peut être basculée vers l'instance de base de données de secours en peu de temps
• Surveillance : prend en charge la surveillance des indicateurs de performance clés des instances de base de données et des moteurs de base de données, y compris l'utilisation de la capacité de calcul/mémoire/stockage, les activités d'E/S, le nombre de connexions à la base de données, le QPS/TPS, le pool de mémoire tampon, les activités de lecture/écriture, etc.
• Mise à l'échelle élastique : mise à l'échelle horizontale, ajout et suppression d'instances en lecture seule (jusqu'à 5 instances en lecture seule par cluster de base de données) ; mise à l'échelle verticale, modification des spécifications d'instance de base de données, extension en un clic, sans interrompre l'activité.
• Sauvegarde et restauration : sauvegarde, prise en charge de la sauvegarde automatique, sauvegarde manuelle des données, restauration, prise en charge de la restauration vers un point de fichier de sauvegarde.

2.1.3.1 Haute fiabilité et haute disponibilité

• PG prend en charge la haute disponibilité inter-AZ. Si la bibliothèque principale tombe en panne, elle lancera trois fois la détection des pannes et l'arrêtera. Si elle ne peut pas être extraite, elle basculera automatiquement. La bibliothèque principale basculera vers la bibliothèque de secours. Elle être automatiquement lié à la nouvelle bibliothèque principale, et cette commutation est au deuxième niveau.
• La base de données HUAWEI CLOUD offre des capacités de sauvegarde et de récupération des données. Les utilisateurs peuvent définir des politiques de sauvegarde automatique et prendre en charge les sauvegardes automatiques quotidiennes. Le cycle de sauvegarde peut aller jusqu'à 732 jours. Dans le même temps, des sauvegardes incrémentielles seront effectuées toutes les cinq minutes pour garantir la fiabilité des données.
• Si les données sont anormales ou supprimées accidentellement, etc., il peut prendre en charge la restauration de la base de données à tout moment antérieur.
• Les fichiers de sauvegarde sont stockés dans OBS, et OBS lui-même n'a pas la capacité d'aller en ligne, offrant une fiabilité des données de 11 sur 9.

2.1.4 Sélection de la base de données

2.1.5 Comparaison de bases de données

• Explication : La similarité des couleurs représente le degré de conformité. Le bleu est utilisé ici, indiquant que pg et mysql peuvent être utilisés dans la plupart des scénarios.
  • Le degré d'utilisation de la base de données et l'habitude de conception de l'architecture, comme certaines sociétés de jeux et d'Internet, ne considèrent la base de données que comme un outil de stockage de données5, qui est un mode "base de données légère et application lourde". et MySQL peuvent être utilisés. Mais si de nombreuses fonctions dépendent des caractéristiques de la base de données, il est donc recommandé d'utiliser PG. Le middleware de base de données est un logiciel de base, stable et fiable, et les bases de données open source sont autonomes et contrôlables. Il est raisonnable de choisir s'appuyer sur un tel logiciel de base
  • L'activité est-elle purement transactionnelle ou mixte avec l'analyse transactionnelle ? Pour le premier, suivez les habitudes d'origine de l'entreprise. Si c'est le second, il est recommandé d'utiliser PG. Les capacités d'analyse de PG sont très bonnes.
  • Si vous utilisez beaucoup de procédures stockées, il est recommandé d'utiliser PG, sinon suivez les habitudes de l'entreprise
  • S'il existe une demande d'accès à une base de données hétérogène, PG est recommandé. PG fournit Foreign DataWrapper, qui permet aux utilisateurs d'accéder à des données en dehors de PG via SQL.
  • Pour l'utilisation de types complexes, il est recommandé d'utiliser PG. Les tableaux PG, les types de données spatiales, les types de données réseau JSON, XML, etc. sont très matures et prennent en charge la personnalisation
• Si vous avez des exigences en matière d'informations géographiques, d'espace, d'accès à des bases de données hétérogènes, d'apprentissage automatique, de récupération de texte, d'images, de séries chronologiques, multidimensionnelles, de segmentation de mots, etc., et que vous ne souhaitez pas introduire de nouvelles bases de données spécialisées, alors PG est recommandé.

2.1.6 Cas

2.1.7 ApsaraDB pour GaussDB (pour MySQL)

• Stockage DFV partagé :
  • Un seul exemplaire est stocké. Lors de l'ajout d'un nœud en lecture seule, il vous suffit d'ajouter un nœud informatique, pas besoin d'acheter du stockage supplémentaire. S'il y a plus de nœuds en lecture seule, plus de coûts de stockage peuvent être économisés.
• Architecture Actif-Actif :
  • Il n'y a plus de base de données de secours, toutes les bases de données en lecture seule sont à l'état Actif et supportent le trafic de lecture, ce qui augmente l'utilisation des ressources.
• Journal en tant qu'architecture de données :
  • Il n'est plus nécessaire de rafraîchir la page, toutes les opérations de mise à jour sont uniquement enregistrées dans les journaux et la double écriture n'est plus nécessaire. La précieuse bande passante du réseau est réduite.

2.1.7.1 Exécution parallèle

• Instruction de requête TPCH de test à 32 cœurs de 256 Go avec un volume de données de 100 Go, et les performances sont améliorées de 8 fois dans le scénario simultané à 16 threads

2.1.7.2 Expansion horizontale

• Extension linéaire des performances de lecture et d'écriture de GaussDB (pour MySQL) :
  • Lorsque vous augmentez le nombre de nœuds, étant donné que la couche inférieure utilise le stockage distribué DFV, il n'est pas nécessaire de repartitionner le stockage pour les nœuds nouvellement ajoutés et de partager le même que les autres nœuds. stockage en bloc

2.1.7.3 Sauvegarde efficace

• Par rapport à la récupération de panne de base de données traditionnelle, GaussDB (pour MySQL) restaurera progressivement certaines données et fournira des services externes lors de la restauration des données jusqu'à ce que toutes les données soient restaurées. Cependant, les bases de données traditionnelles ne fournissent des services externes qu'après avoir toutes été restaurées.

2.1.7.4 Cas

2.1.8 ApsaraDB pour GaussDB (pour openGauss)

• Haute sécurité:
  • GaussDB (pour openGauss ) possède des fonctionnalités de sécurité de base de données commerciales de haut niveau : désensibilisation dynamique des données, cryptage transparent TDE, contrôle d'accès au niveau des lignes et informatique cryptée. Il peut répondre aux principales exigences de sécurité des gouvernements, des entreprises et des clients financiers.
• Outils sonores et capacités de service :
  • GaussDB (pour openGauss) dispose déjà de HUAWEI CLOUD, la capacité de déploiement de services commerciaux de HUAWEI CLOUD Stack, et dispose d'outils écologiques tels que DAS, wUGO et DRS. Garantir efficacement les besoins de travail quotidiens des utilisateurs tels que le développement, l'exploitation et la maintenance, l'optimisation, la surveillance, la migration, etc.
• Full-stack auto-développé :
  • GaussDB (pour openGauss) est basé sur l'écologie Peng et est actuellement la seule marque nationale capable d'atteindre une contrôlabilité indépendante de la pile complète.Dans le même temps, GaussDB (pour openGauss) peut optimiser en continu la couche inférieure en fonction des avantages matériels pour améliorer le performances globales du produit.
• Ecologie open source :
  • GaussDB (pour openGauss) prend déjà en charge la communauté open source et fournit des téléchargements des versions principales et de sauvegarde.

2.1.8.1 Rôles clés

• etcd : composants de cohérence
• CMS : pour la gestion du cluster, le contrôle de la commutation active et de secours, lié à la haute disponibilité

2.1.8.2 Haute performance - Cadre d'exécution parallèle distribué

2.1.9 Hautes performances - Performances de traitement des transactions distribuées, technologie GTM-Lite

2.1.9.1 Cas : GaussDB aide les opérations commerciales intelligentes

2.2 Services de bases de données non relationnelles

2.2.1 Principes de conception NoSQL sur le cloud

2.2.2 Service de base documentaire DDS

• Type et version de la base de données : Compatible avec la version MongoDB 4.0/4.2.
• Sécurité des données : plusieurs politiques de sécurité protègent la base de données et la confidentialité des utilisateurs. Haute fiabilité des données : le stockage de la base de données prend en charge plus de trois copies, la fiabilité des données de la base de données est élevée, atteignant 99,9999999 % (9 neufs) et la persistance des données de sauvegarde atteint 99,9999999999 % (12 neufs)
• Haute disponibilité des services (reprise après sinistre dans la même ville) : les instances de cluster/ensemble de réplicas prennent en charge le déploiement dans une AZ ou sur 3AZ, et la disponibilité du service est supérieure à 99,95 %.
• Surveillance d'instance : prend en charge la surveillance des indicateurs de performance clés du système d'exploitation de l'instance de base de données et du moteur de base de données, y compris l'utilisation de la capacité de calcul/mémoire/stockage, les activités d'E/S, les connexions à la base de données, etc.
• Mise à l'échelle élastique : mise à l'échelle horizontale, ajout et suppression de fragments de fragments (jusqu'à 32), prise en charge d'ensembles de répliques à 7 nœuds et prise en charge de nœuds en lecture seule ; mise à l'échelle verticale, modification des spécifications d'instance et extension de l'espace de stockage (maximum 32 x 2 To).
• Sauvegarde et restauration : sauvegarde, sauvegarde automatique, sauvegarde manuelle, sauvegarde complète, sauvegarde incrémentielle, ajout de fichier de sauvegarde, suppression, copie et autre gestion du cycle de vie ; restauration, prise en charge de la restauration à tout moment de la période de conservation de la sauvegarde (Point-ln -Time récupération, PITR)/un point temporel de sauvegarde complète, restauration vers la nouvelle instance/instance d'origine. La période de conservation des sauvegardes peut aller jusqu'à 732 jours.

2.2.3 Haute fiabilité - extension en ligne sans interruption, trois copies de stockage

2.2.4 Haute fiabilité - archivage, sauvegarde et restauration des données

2.2.5 Sauvegarde de zone de disponibilité croisée - La sauvegarde est répliquée dans toutes les régions et peut être restaurée à différents endroits

2.2.6 Reprise après sinistre entre zones de disponibilité - Reprise après sinistre en temps réel entre régions et synchronisation des données en temps réel

2.2.7 Cas : Aider l'industrie du jeu vidéo

• scène de jeu
• Dans les applications de jeu, certaines informations utilisateur, telles que l'équipement utilisateur et les points utilisateur, peuvent être stockées dans la base de données DDS pendant la période de pointe de l'activité du joueur, ce qui nécessite des capacités de simultanéité élevées. Les types de cluster DDS peuvent être utilisés pour gérer des scénarios de simultanéité élevée . Les fonctionnalités de haute disponibilité des jeux de répliques DDS et de l'architecture de cluster peuvent répondre au fonctionnement continu et stable des jeux dans des scénarios à forte simultanéité.
• De plus, DDS est compatible avec MongoDB et dispose d'une méthode No-Schema, qui peut éviter la douleur de changer la structure de la table pendant les changements de jeu, et est très adaptée aux besoins commerciaux flexibles et changeants du jeu. Les utilisateurs peuvent stocker des données structurées avec un schéma fixe dans la base de données cloud RDS, stocker des affaires avec un schéma flexible dans DDS et stocker des données à haute température dans GaussDB (pour Redis), afin de réaliser un accès efficace aux données commerciales et de réduire le coût d'entrée du stockage données.

2.2.8 ApsaraDB pour GaussDB (pour NoSQL)

• Interface Cassandre compatible :
  • Prise en charge du modèle de données à colonne large
  • Super performance d'écriture, adaptée à l'IoT, à la détection anti-fraude financière et à d'autres scénarios
• Compatible avec l'interface MongoDB :
  • Prend en charge le modèle de données de document.
  • Il présente d'excellents avantages en termes de performances de lecture et d'écriture, de sensibilité et de fiabilité.
• Compatible avec l'interface Redis :
  • Le premier produit de base de données Redis sur le cloud qui sépare l'informatique et le stockage.
  • Il présente des avantages exceptionnels en termes de fiabilité des données, d'évolutivité et de performances en termes de coûts.
• Compatible avec l'interface InfluxDB.
  • Architecture de cluster et disposition des données conçues pour les données de séries chronologiques
  • Performances d'écriture élevées et taux de compression élevé.

2.2.9 ApsaraDB pour GaussDB (pour Redis)

• GaussDB (pour Redis) a les caractéristiques d'une performance à coût élevé, d'une mise à l'échelle élastique et d'une séparation chaude et froide.
• Rentable:
  • Basé sur le stockage partagé, sur la prémisse de fournir des performances suffisantes, le coût d'utilisation de Redis pour les données massives est considérablement réduit
  • Toutes les données sont stockées sur le disque, et la séparation chaude et froide est réalisée, le problème d'accès interactif entre le cache (cache) et la base de données (DB) est résolu, et la lisibilité et l'efficacité de fonctionnement du programme sont améliorées.
• Mise à l'échelle élastique sans perte :
  • Personnalisation approfondie de RocksDB, expansion élastique divisée de deuxième niveau.
  • La mise à l'échelle et la réduction sont rapides et fluides sans déplacer les données.
  • Grâce à l'agent proxy, l'entreprise de la couche supérieure ne peut pas percevoir le noyau pour gérer la migration des données pendant le processus d'expansion et de contraction.
• Séparation chaud et froid :
  • Les données chaudes résident en mémoire et les données froides sont stockées de manière persistante dans leur intégralité, remplaçant l'architecture de séparation chaude et froide de Redis + MySQL. 0 réalise l'échange automatique de données chaudes et froides, les utilisateurs n'ont pas besoin d'échanger des données manuellement et le développement du code est plus concis

2.2.10 Cas : Aider l'industrie de l'énergie

• Bien que GaussDB (pour Redis) soit compatible avec l'interface Redis, il fournit également des capacités de stockage de données de grande capacité, à faible coût et hautement fiables, qui peuvent être utilisées comme solution idéale pour de tels scénarios de stockage persistants.

2.2.11 Base de données cloud GaussDB (pour Mongo)

2.2.12 Cas : Aider l'industrie du jeu vidéo

• scène de jeu.
  • Compatible avec le protocole MongoDB, l'application de jeu peut y stocker certaines données de jeu, telles que l'équipement utilisateur, les points utilisateur, etc. Pendant la période de pointe de l'activité des joueurs, les exigences de simultanéité sont élevées et les nœuds informatiques peuvent être ajoutés rapidement et de manière flexible pour faire face aux jeux à forte simultanéité.

3. Plan de migration de la base de données

• Solution globale de migration de base de données HUAWEI CLOUD

• Méthode de migration de la base de données
• La migration de la base de données est généralement mise en œuvre sous la forme d'une combinaison UGO+DRS. Lorsqu'un utilisateur migre une base de données vers HUAWEI CLOUD à partir d'un fournisseur hors cloud ou d'un autre cloud, utilisez d'abord l'outil UGO pour analyser la base de données source, puis commencez à migrer la base de données en fonction du scénario réel et en vous référant à la solution fournie par l'outil UGO. Le service de réplication de données DRS réalise la migration des données de la base de données source vers la base de données cible grâce à la technologie de données complètes + migration incrémentale.

3.1 Service de réplication de données DRS

、

• Facile à utiliser :
  • Dans les scénarios traditionnels, une formation technique professionnelle est requise, les étapes sont compliquées et le seuil technique est relativement élevé
• Cycle court
  • Dans les scénarios traditionnels, un déploiement manuel est requis, allant de quelques jours à la semaine dernière ou au mois dernier
• faible coût:
  • Dans le scénario traditionnel, l'investissement est élevé et l'entreprise ne peut pas être payée de manière flexible à la demande
• faible risque
  • Dans les scénarios traditionnels, une interruption d'activité et une migration manuelle sont nécessaires, et il existe un risque de perte de données si la migration échoue

3.1.1 Migration en direct

• La migration en temps réel prend en charge plusieurs méthodes de migration de réseau, telles que : réseau public, réseau VPC, réseau VPN et réseau privé via divers liens réseau, qui peuvent rapidement réaliser la migration de base de données de plate-forme inter-cloud, la migration de base de données hors cloud vers le cloud ou le cloud Migration interrégionale de divers scénarios commerciaux tels que la migration de bases de données

3.1.2 Migration de sauvegarde

3.1.3 Synchronisation en temps réel

3.1.4 Abonnement aux données

3.1.5 Reprise après sinistre en temps réel

3.1.6 Cas : Aider l'industrie automobile

3.2 Outil de migration de base de données UGO

• Le service est actuellement au stade commercial et n'est développé que dans les régions Chine du Sud-Guangzhou et Asie-Pacifique-Singapour

3.2.1 Image source

• Image de la bibliothèque source de la compétence de base UGO :
  • Le profil de la bibliothèque source prend des scénarios commerciaux massifs comme exemples et utilise des indicateurs de base de données clés comme caractéristiques pour effectuer la formation, résume l'image complète des informations de la base de données et fournit une analyse plus précise et rapide des informations importantes telles que les scénarios d'application de la bibliothèque source et les habitudes de fonctionnement des utilisateurs nw3580 Base de données suffisante.

3.2.2 Sélection et spécifications du type de cible

• Sélection des cibles et spécifications des capacités de base d'UGO :
  • Selon l'entrée d'image de la bibliothèque source, la compatibilité complète, les performances, la complexité des objets, les scénarios d'utilisation, etc., recommandez intelligemment la sélection de type de bibliothèque cible appropriée et la priorité yo, ainsi que les spécifications et les coûts sous différentes sélections.

3.2.3 Analyse de compatibilité

• Analyse de compatibilité de la compétence de base UGO
  • En prenant l'image de la bibliothèque source comme entrée, le taux de conversion du noyau UGO vers la bibliothèque cible est utilisé pour effectuer une analyse de compatibilité sur les principaux types d'objets 14. L'analyse de compatibilité inclut la prise en charge native, la prise en charge UGO et la non-prise en charge. Grâce à la construction continue du noyau au cours des dernières années, UGO peut atteindre un taux de conversion grammatical élevé sur la base d'une formation avec des centaines de millions d'échantillons

3.2.4 Évaluation de la charge de travail

• Évaluation de la charge de travail des compétences de base de l'UGO :
  • Sur la base des coûts réels de la migration humaine dans des scénarios d'entreprise massifs, en tant que référence d'évaluation, basée sur le processus de migration automatisé d'un grand nombre de scénarios d'entreprise, la charge de travail de migration cumulée est utilisée comme entrée, combinée avec le volume de code, le taux de conversion et la difficulté de la transformation de fonctionnalités incompatibles, etc., pour produire de manière complète l'évaluation de la charge de travail de migration .

3.2.5 Migration de la structure de la base de données

• Migration de la structure de la base de données de la compétence de base UGO :
  • La migration structurelle prend l'évaluation de pré-migration comme entrée et guide de programme, et aide les utilisateurs à personnaliser et à filtrer les objets de migration avant la conversion. Après la conversion, marquez les objets ayant échoué à la conversion et les raisons de l'échec. Les utilisateurs peuvent corriger les objets en fonction des raisons de l'échec et effectuer des tests de vérification après correction. Les objets qui échouent à la vérification retournent à l'étape de correction pour être remodifiés et continuent à être soumis pour vérification jusqu'à ce que tous les objets soient vérifiés avec succès et que l'ensemble du processus de mise en œuvre de la migration se termine.

3.2.6 Appliquer les migrations SQL

3.2.7 Cas : Aider l'industrie de la communication

questions de réflexion

fin de floraison