01
Achetez pour la charge de travail, pas pour le nom de la base de données
Apportez un profil de charge de travail : moteur de base de données et version, taille des données actives, utilisation mémoire de pointe, requêtes simultanées, volume d'écriture et croissance. Incluez les index, les journaux de transactions, l'espace temporaire et les tâches de maintenance. Une base de données de petite entreprise et un entrepôt de reporting peuvent nécessiter des machines très différentes même s'ils utilisent le même logiciel.
Identifiez la contrainte que vous essayez de modifier. Si un système existant attend sur le stockage ou une application distante, acheter plus de cœurs ne prouve pas que le problème disparaîtra. Utilisez votre propre mélange de requêtes et un jeu de données représentatif pour établir des critères d'acceptation pour le nouvel hôte.
02
Comparer trois allocations différentes
Ces candidats offrent des allocations de mémoire et de disque différentes ; ils ne sont pas classés par transactions par seconde. La capacité brute listée n'est pas l'espace de base de données utilisable après la redondance choisie.
- Xeon E-2388G : 64 GB de la mémoire ECC répertoriée et 2 TB de capacité brute NVMe. Un candidat plus petit lorsque la charge de travail mesurée tient confortablement.
- EPYC 7443P : 256 GB de mémoire ECC listée et 7.68 TB de capacité brute NVMe. À comparer lorsque la croissance de la mémoire ou des données exclut la configuration plus petite.
- EPYC 7513 : quatre périphériques NVMe et 15.36 TB de capacité brute. À envisager lorsque la disposition de disque prévue nécessite plus de périphériques, puis confirmez la configuration réelle.
03
Convenez de ce qui protège les données
Demandez le modèle de disque et l'endurance lorsque des écritures soutenues comptent. Le catalogue ne publie pas d'IOPS mesurés, de latence de validation ou de benchmark de base de données. Spécifiez la disposition du disque et l'exigence de récupération au lieu de supposer que NVMe ou ECC constitue un plan de résilience complet.
Une location unique est un hôte physique, pas un cluster de base de données géré. La réplication, le basculement, les sauvegardes adaptées aux bases de données et les tests de restauration restent de votre responsabilité, sauf accord séparé. Confirmez toute séparation réseau requise entre les nœuds de base de données ; un port public ou une seconde machine n'inclut pas de réseau de réplication privé.
04
Évaluez le déploiement complet et la migration
Comparez la location avec les licences de base de données, le stockage de sauvegarde et les options éventuellement citées. Vérifiez les licences logicielles par rapport à l'allocation exacte du processeur. Sélectionnez le système d'exploitation et confirmez sa version, la disposition des disques et la méthode d'accès avant l'installation ; la location de matériel n'inclut pas l'administration de base de données.
Choisissez une région en fonction des besoins réseau de l'application et confirmez le délai de livraison du modèle. Conservez la base de données existante jusqu'à ce que le nouvel hôte passe vos vérifications et qu'une restauration ait été démontrée. Une demande d'installation en file d'attente n'est pas une migration terminée ni une raison de supprimer l'ancienne copie.
Réponses directes
Questions avant de commander
Promettez-vous un taux de requête ou une latence de base de données ?
Aucune performance de base de données mesurée n'est publiée. Définissez des critères d'acceptation en utilisant votre moteur, schéma, mélange de requêtes et ensemble de données ; une spécification matérielle seule ne peut pas établir le résultat.
La gestion de base de données ou le basculement automatique sont-ils inclus ?
Non. C'est une location de matériel dédié. Confirmez toute assistance convenue séparément et planifiez l'administration, la réplication, les sauvegardes et la récupération avant de déplacer des données de production.