– Il faut le faire, dit-elle à haute voix, sans s'adresser à personne. – Il faut le faire ! C'est écrit noir sur blanc : la principale mission de la société est de générer des profits au profit des actionnaires. Réfléchissez à cela ! Ils n'ont peur de rien !
Yuli Dubov, « Le Moindre Mal »
En voyant un tel titre, vous avez sans doute déjà décidé que l'article est soit une bêtise, soit une provocation. Mais ne vous précipitez pas à tirer des conclusions : les employés de grandes entreprises, en particulier celles avec une participation étatique, sont souvent amenés à comparer différentes plateformes, y compris des plateformes très différentes - comme celles mentionnées dans le titre.
Bien sûr, personne ne compare les SGBD, car leurs points forts et faibles sont bien connus. En général, ce qui est comparé, ce sont des plateformes qui résolvent une tâche appliquée. Dans cet article, je vais présenter une méthode qui est utilisée à cet effet, en prenant l'exemple des bases de données, un sujet bien connu des lecteurs de Habr. Donc,
Motivation
Lorsque vous commencez un projet d'étude ou un projet de loisir, la motivation pour le choix de la plateforme peut varier : « je connais mieux cette plateforme », « celle-ci m'intéresse à explorer », « ici la documentation est la meilleure »… Dans le cas d'une entreprise commerciale, le critère de choix est simple : combien je vais devoir payer et qu'est-ce que je vais obtenir pour cet argent.
Naturellement, on veut payer moins, mais obtenir plus. Cependant, il faut déterminer ce qui est plus important - payer moins ou obtenir plus, et attribuer un poids à chaque critère. Supposons que notre priorité soit la qualité de la solution plutôt que son coût, nous attribuerons donc un poids de 40 % à la « Coût », et 60 % à la « Capacité ».
Dans les grandes entreprises, c'est généralement l'inverse - le poids du coût ne descend pas en dessous de 50 %, et peut même dépasser 60 %. Dans l'exemple modèle, seule la somme des poids des nœuds enfants d'un nœud parent doit être 100 %.
Critères d'élimination
Le site répertorie environ 500 systèmes de gestion de bases de données. Évidemment, si l'on choisit une plateforme cible parmi un tel nombre d'options, on pourrait obtenir un article de synthèse, mais pas un projet commercial. Pour réduire l'espace de choix, des critères d'élimination sont formulés, et si la plateforme ne répond pas à ces critères, elle n'est pas considérée.
Les critères d'exclusion peuvent concerner des caractéristiques technologiques, par exemple :
- les garanties ACID ;
- un modèle de données relationnel ;
- le support du langage SQL (notez que ce n'est pas la même chose que « modèle relationnel ») ;
- la possibilité de mise à l'échelle horizontale.
Il peut également y avoir des critères généraux :
- la disponibilité d'un support commercial en Russie ;
- le code source ouvert ;
- la présence de la plateforme dans le registre du ministère des Communications ;
- la présence de la plateforme dans un classement quelconque (par exemple, dans le top 100 du classement db-engines.com) ;
- la disponibilité d'experts sur le marché (par exemple, selon les résultats de la recherche du nom de la plateforme dans les CV sur le site hh.ru).
Enfin, il peut y avoir des critères spécifiques à l'entreprise :
- la présence de spécialistes dans le personnel ;
- la compatibilité avec le système de monitoring X ou avec le système de sauvegarde Y, sur lequel repose tout le support…
L'essentiel est que la liste des critères d'exclusion existe. Sinon, un expert (ou un « expert ») de confiance pour la direction dira inévitablement « pourquoi n'avez-vous pas choisi la plateforme Z, je sais qu'elle est la meilleure ».
Évaluation des coûts
Le coût de la solution est composé, de manière évidente, du coût des licences, du coût du support et du coût du matériel.
Si les systèmes sont à peu près de même classe (par exemple, Microsoft SQL Server et PostgreSQL), on peut simplifier en considérant que le nombre de matériel pour les deux solutions sera à peu près identique. Cela permettra de ne pas évaluer le matériel, économisant ainsi un temps et des efforts considérables. En revanche, si l'on compare des systèmes complètement différents (par exemple, Oracle vs. Redis), il est évidemment nécessaire de faire un sizing (calcul du matériel requis) pour une évaluation correcte. Le sizing d'un système inexistant est une tâche peu gratifiante, donc ce type de comparaison est généralement évité. Il est simple de le faire : dans les conditions d'exclusion, on précise zéro perte de données et un modèle relationnel ou, au contraire, une charge à partir de 50 000 transactions par seconde.
Pour évaluer les licences, il suffit de demander au fournisseur ou à ses partenaires le coût de la licence pour un nombre fixe de cœurs et de support pour une durée déterminée. En général, les entreprises ont déjà établi des relations solides avec les fournisseurs de logiciels, et si le service d'exploitation de bases de données ne peut pas répondre à la question sur le coût de manière autonome, un seul e-mail suffit pour obtenir cette information.
Les différents fournisseurs peuvent avoir des règles de licenciement différentes : en fonction du nombre de cœurs, du volume de données ou du nombre de nœuds. Une base Standby peut être gratuite ou licenciée de la même manière que la principale. Si des différences dans les métriques sont découvertes, il faudra décrire en détail le stand modèle et calculer le coût des licences pour celui-ci.
Un point important pour une comparaison correcte est d'avoir des conditions de support identiques. Par exemple, le support Oracle coûte 22 % du coût de la licence par an, tandis que pour le support PostgreSQL, il est possible de ne rien payer. Est-il correct de comparer ainsi ? Non, car les conséquences d'une erreur qui ne peut pas être corrigée par ses propres moyens sont complètement différentes : dans le premier cas, les spécialistes du support pourront rapidement aider à la résoudre, tandis que dans le second cas, il y a un risque de retard dans le projet ou d'arrêt du système final pour une durée indéterminée.
Il y a trois façons d'égaliser les conditions de calcul :
- Utiliser Oracle sans support (ce qui en réalité n'existe pas).
- Acheter un support pour PostgreSQL – par exemple, auprès de la société Postgres Professional.
- Intégrer dans le calcul les risques liés à l'absence de support.
Par exemple, le calcul des risques pourrait ressembler à ceci : en cas de défaillance irrémédiable de la base de données, l'arrêt du système sera d'un jour ouvrable. Le bénéfice prévu de l'utilisation du système est de 40 milliards de tugrik mongols par an, et la fréquence des pannes est estimée à 1/400, donc, le risque d'absence d'accompagnement est évalué à environ 100 millions de tugrik mongols par an. Il est évident que le « bénéfice prévu » et la « fréquence estimée des pannes » sont des valeurs virtuelles, mais il est nettement préférable d'avoir un tel modèle que de ne pas en avoir du tout.
En réalité, le système peut être trop important et les pertes de réputation dues à un long temps d'arrêt seraient inacceptables, donc un support sera nécessaire. Si un arrêt est toléré, renoncer au support peut parfois être un bon moyen d'économiser.
Supposons qu'après tous les calculs, le coût d'exploitation de la plateforme A pendant 5 ans s'est élevé à 800 millions de tugriks mongols, le coût d'exploitation de la plateforme B à 650 millions de tugriks, et le coût d'exploitation de la plateforme C à 600 millions de tugriks. La plateforme C, étant la moins chère, obtient un score complet pour son coût, tandis que les plateformes A et B reçoivent respectivement des scores légèrement inférieurs de 0,75 et 0,92, proportionnellement à leur coût plus élevé.
Évaluation des capacités
L'évaluation des capacités se divise en plusieurs groupes, dont le nombre n'est limité que par l'imagination de celui qui évalue. La division des capacités par équipes d'utilisateurs semble être la meilleure option; dans notre exemple, il s'agit des développeurs, des administrateurs et des responsables de la sécurité informatique. Supposons que les poids de ces fonctions se répartissent comme suit : 40:40:20.
Les fonctions de développement peuvent inclure :
- la facilité de manipulation des données ;
- la scalabilité ;
- la présence d'index secondaires.
La liste des critères, tout comme leurs poids, est très subjective. Même pour résoudre le même problème, ces listes, les poids des éléments et les réponses varieront considérablement en fonction de la composition de votre équipe. Par exemple, Facebook utilise MySQL pour stocker des données, tandis qu'Instagram est construit sur Cassandra. Il est peu probable que les développeurs de ces applications aient rempli de telles tables. On peut seulement supposer que Mark Zuckerberg a choisi un modèle relationnel complet, en payant cela avec la nécessité de partitionner les applications, tandis que Kevin Systrom a intégré la scalabilité dans la plateforme, au détriment de la facilité d'accès aux données.
Les fonctions d'administration incluent :
- les capacités du système de sauvegarde ;
- la facilité de surveillance ;
- la facilité de gestion des ressources – disques et nœuds ;
- les capacités de réplication des données.
Veuillez noter que les formulations des questions doivent permettre une évaluation quantitative. On peut même convenir de la façon d'évaluer telle ou telle fonctionnalité. Essayons, par exemple, d'évaluer les outils de sauvegarde en prenant comme exemple les outils fournis avec les bases de données Oracle :
Outil
Commentaire
Évaluation
imp\/exp
Exportation et importation de données
0.1
début\/fin de sauvegarde
Copie de fichiers
0.3
RMAN
Possibilité de sauvegarde incrémentielle
0.7
ZDLRA
Sauvagarde exclusivement incrémentielle, restauration la plus rapide jusqu'à un point donné
1.0
Si des critères d'évaluation clairs sont absents, il est judicieux de demander à plusieurs experts de donner des notes, puis de les moyenner.
Enfin, énumérons simplement les fonctions de sécurité de l'information :
- existence de politiques de gestion des mots de passe ;
- possibilité de connexion à des systèmes d'authentification externes (LDAP, Kerberos) ;
- modèle d'accès basé sur les rôles ;
- capacités d'audit ;
- chiffrement des données sur disque ;
- chiffrement lors de la transmission sur le réseau (TLS) ;
- protection des données contre les administrateurs.
Tests de performance
Je voudrais en outre mettre en garde contre l'utilisation comme arguments des résultats de tests de charge effectués par d'autres.
Tout d'abord, la structure des données et le profil de charge des applications testées peuvent différer considérablement de la tâche que vous vous apprêtez à réaliser. Il y a environ 10-15 ans, les fabricants de bases de données aimaient exhiber des résultats obtenus lors de tests TPC, mais il semble qu'aujourd'hui, personne ne prend ces résultats au sérieux.
Deuxièmement, la performance d'un système dépend énormément de la plateforme pour laquelle le code a été initialement écrit et du matériel sur lequel le test a été effectué. J'ai vu de nombreux tests où Oracle était comparé à PostgreSQL. Les résultats allaient d'une supériorité incontestée d'un système à une supériorité tout aussi incontestée de l'autre.
Et enfin, troisièmement, vous ne savez rien sur la personne qui a effectué le test. La qualification est importante, car elle influence la qualité de la configuration du système d'exploitation et de la plateforme, tout comme la motivation, qui affecte les résultats du test plus que tous les autres facteurs réunis.
Si la performance est un facteur critique, effectuez le test vous-même, de préférence avec l'aide de spécialistes qui configureront et maintiendront le système industriel.
Résultat
Enfin, le résultat de tout ce travail devrait être un tableau électronique où toutes les notes sont rassemblées, multipliées et additionnées :
Comme vous le savez, en modifiant les pondérations et en ajustant les notes, on peut obtenir n'importe quel résultat souhaité, mais c'est une toute autre histoire...
Source : habr.com
