Le test de référence Transaction Processing Performance Council Benchmark C (TPC-C) est de loin l’étalon le plus crédible et le plus fiable de la fonctionnalité et des performances des bases de données de traitement des transactions en ligne dans l’industrie des bases de données dans le monde entier. Le 20 mai 2020, le TPC a publié les résultats des tests de référence TPC-C d’OceanBase – 707 millions de transactions par minute (tpmC), avec des coûts système par tpmC encore réduits à 3,98 RMB. Il s’agissait du deuxième défi TPC-C relevé par OceanBase après avoir atteint 60,88 millions de tpmC lors de ses débuts lors du test de référence en octobre 2019.
Lors de la 48e Conférence internationale sur les très grandes bases de données (VLDB 2022), un sommet sur les bases de données qui vient de se terminer en septembre, Xu Quanqing, chercheur principal en bases de données d’OceanBase, a présenté un article intitulé « OceanBase : A 707 Million tpmC Distributed Relational Database System », qui présente l’architecture d’OceanBase, un système de base de données distribué, et comment le test de référence TPC-C en 2020 a été effectué.
Qu’y a-t-il de si spécial dans le test de référence TPC-C qui a incité OceanBase à établir de nouveaux sommets mondiaux deux fois de suite en deux ans ?
Scénario de test de référence TPC-C : la meilleure plage de test pour les bases de données transactionnelles
Le scénario de test de référence TPC-C est une représentation très abstraite d’un système de production réel, qui est plus complexe.
Cinq types de transactions sont conçus dans le modèle de test :
- Pas plus de 45 % des nouvelles transactions de commande
- Pas moins de 43% des transactions de paiement
- Pas moins de 4% des transactions en statut de commande
- Pas moins de 4% des transactions de livraison
- Pas moins de 4% des transactions au niveau des stocks
Les deux principaux types de transactions simulent la création de commandes et les transactions de paiement dans le système de production. Aussi simple qu’il puisse paraître, ce modèle TPC-C est une excellente abstraction du traitement réel des transactions en ligne et s’applique à diverses industries modernes, telles que le commerce électronique, la banque, les transports, les communications et les services gouvernementaux et d’entreprise.
En outre, le TPC a spécifié des règles strictes pour le test. Par conséquent, à l’instar du Double 11 Shopping Festival, le test de référence TPC-C est également une excellente gamme de tests qui offre à OceanBase l’occasion d’essayer et d’affiner ses produits dans des circonstances difficiles.
Exigences du test de référence TPC-C sur le traitement des transactions et la gigue des performances
De nombreux fournisseurs de bases de données exécutent des ensembles de données TPC-C avec des outils d’analyse comparative généraux tels que BenchmarkSQL et OLTPBench et affirment que leurs produits sont testés en stricte conformité avec les spécifications TPC-C.
Cependant, TPC ne reconnaît pas les résultats de leurs tests, car les résultats ne sont pas audités par des auditeurs agréés par TPC.
Le test de référence TPC-C est soumis à un processus d’audit strict. Avant de pouvoir démarrer le test de performances, les fournisseurs doivent réussir la vérification des fonctionnalités qui vérifie si leurs bases de données répondent aux exigences relatives aux propriétés d’atomicité, de cohérence, d’isolation et de durabilité (ACID) des transactions. En d’autres termes, les bases de données qui échouent à la vérification ACID ne sont pas éligibles pour le test de référence TPC-C. Par exemple, certains fournisseurs créent des bases de données « distribuées » en empilant simplement plusieurs bases de données autonomes. De telles bases de données sans architecture distribuée native, bien que chaque base de données de composants réponde aux exigences ACID, sont incapables de gérer ces propriétés clés dans leur ensemble et ne peuvent donc pas participer au test de référence officiel TPC-C pour produire des résultats de performance convaincants.
Plus précisément, le test de référence TPC-C impose des exigences élevées sur les deux aspects suivants d’un système de base de données :
1. Capacité de traitement des transactions
En tant que test de référence pour les systèmes de traitement des transactions en ligne (OLTP), TPC-C exige que la base de données testée soit conforme à ACID en termes de transactions. Pour réussir le test, une base de données doit être capable d’une isolation sérialisable, le niveau d’isolation de transaction le plus strict, et résister à tout point de défaillance unique.
Évidemment, ce sont les exigences de base pour une base de données OLTP.
Le test de référence TPC-C nécessite également que la base de données traite au moins une certaine quantité de transactions distribuées ; pour être plus précis, 10 % des nouvelles transactions de commande et 15 % des transactions de paiement dans un environnement distribué, qui peut être réparti sur un maximum de 15 nœuds.
Les propriétés ACID des transactions sont testées séparément :
- Dans le test d’atomicité, les transactions de paiement sont validées et annulées pour confirmer si la base de données prend en charge l’atomicité des transactions.
- Dans le test de cohérence, la base de données doit assurer la cohérence des données dans les quatre premiers des 12 scénarios conçus. Chaque scénario est essentiellement une grande transaction SQL complexe. Pour une base de données distribuée, la clé est d’assurer la cohérence globale des données à tout moment.
- Dans le test d’isolement, la base de données doit s’assurer que toutes les transactions autres que celles de type niveau de stock sont isolées jusqu’au niveau sérialisable le plus élevé, qui doit être vérifié dans neuf scénarios conçus.
- Dans le test de durabilité, la base de données doit enregistrer les résultats des transactions d’écriture sur le disque dans un certain laps de temps, même dans les pires circonstances possibles, telles que la défaillance permanente d’une partie du support de stockage.
Il est extrêmement difficile pour une base de données distribuée de réussir la vérification ACID. Le niveau d’isolation sérialisable en particulier est difficile à atteindre. C’est l’une des raisons pour lesquelles peu de bases de données distribuées peuvent réussir le test de référence officiel TPC-C.
2. Exécuter pendant au moins 2 heures avec une gigue inférieure à 2 %
Un fonctionnement continu et stable de la base de données est requis dans le test de référence TPC-C. Pour réussir le test, une base de données doit fonctionner avec des performances stables pendant au moins 8 heures, à l’exclusion des durées de montée et de descente, et la variation de performances cumulée ne doit pas dépasser 2 % sur l’intervalle de mesure, qui n’est pas inférieur à 2 heures. Cela nécessite qu’un système distribué soit hautement disponible et stable.
En fait, les systèmes informatiques ont tendance à connaître des sautes de performances importantes et peuvent s’effondrer sous une charge de travail extrême qui, cependant, n’est pas autorisée dans un environnement de production réel.
Par conséquent, les spécifications TPC-C ci-dessus sont assez pratiques. Certains peuvent se demander s’il est possible qu’une base de données génère un pic de performances transitoire d’une manière ou d’une autre et obtienne un excellent score pour des performances élevées. Il s’agit d’une violation complète des spécifications TPC-C car cela ne garantit pas l’état stable de la base de données sur une période prolongée, et encore moins la limite de 2 % sur la gigue de performance cumulée.
Des technologies qui prennent en charge les performances de 707 millions de tpmC avec 1 500 serveurs en cours d’exécution
Test mondialement reconnu sur les systèmes OLTP, le test de référence TPC-C a des exigences strictes pour les systèmes de base de données testés. OceanBase, un système de base de données distribué, ne fait pas exception. La plupart des défis auxquels OceanBase est confronté dans le test concernent ses fonctionnalités « natives », telles que le traitement distribué des transactions, la cohérence des données, la haute disponibilité et la mise à l’échelle linéaire. De ce point de vue, le record de 707 millions de tpmC a prouvé à son tour qu’OceanBase relève assez bien ces défis.
Les performances extraordinaires reposent essentiellement sur les choix architecturaux et techniques et les percées réalisées par l’équipe technique d’OceanBase. Comme mentionné ci-dessus, le test de référence TPC-C est une excellente gamme de tests pour l’amélioration des performances de la base de données. En préparation du test, l’équipe a investi énormément d’efforts pour optimiser le moteur de traitement des transactions, le moteur de stockage et le moteur SQL. Ces optimisations sont très adaptables aux scénarios de test de référence TPC-C très abstraits.
1. Forte cohérence des données garantie par l’architecture distribuée native
OceanBase utilise le protocole de consensus distribué Paxos, l’un des principes fondamentaux qui renforcent l’architecture distribuée d’OceanBase. Essentiellement, ce protocole garantit que les membres non fiables d’un système peuvent également fournir des services fiables. La panne d’un seul nœud n’a aucun impact sur le fonctionnement du système tant que la majorité des nœuds sont sains.
Le protocole Paxos garantit une forte cohérence entre les répliques et aucune perte de données (RPO = 0)
OceanBase utilise pleinement le protocole Paxos et le combine avec la journalisation en écriture anticipée (WAL). Chaque fois que de nouveaux journaux redo sont écrits sur le disque, les journaux sont synchronisés, avec une forte cohérence des données, avec la majorité des répliques, y compris le leader et plusieurs suiveurs dans le même groupe Paxos. Ce mécanisme apporte deux avantages :
- Si des réplicas minoritaires du groupe Paxos échouent, les réplicas majoritaires sains restants garantissent que les derniers journaux redo sont disponibles, garantissant ainsi un objectif de point de récupération zéro (RPO) qui signifie aucune perte de données.
- L’échec des adeptes minoritaires du groupe Paxos n’affecte en rien la forte cohérence des données entre les répliques majoritaires restantes.
En outre, divers mécanismes de vérification des données intégrés d’OceanBase peuvent détecter automatiquement des erreurs telles que des incohérences de données entre répliques, des erreurs de réseau, une corruption silencieuse des données et des incohérences d’index de table, afin d’assurer la cohérence des données entre plusieurs répliques.
En un mot, le protocole Paxos garantit une forte cohérence des données sur plusieurs répliques dans OceanBase et aucune perte de données (RPO = 0) en cas de panne. Il n’y a pas besoin de s’inquiéter des performances des applications.
L’équilibrage de charge automatique garantit des performances élevées basées sur la mise à l’échelle du système linéaire
Avec la disponibilité du système et la cohérence des données garanties, le cluster d’un système distribué peut être mis à l’échelle selon les besoins à l’aide de l’équilibrage de charge automatique pour mettre en œuvre les performances qui correspondent à l’échelle du cluster.
Dans OceanBase, une partition ou sous-partition (si les tables sont sous-partitionnées) est l’unité de base pour la distribution des données. Une table non partitionnée elle-même est considérée comme une partition. L’équilibrage de charge d’OceanBase est lié aux partitions.
Chaque partition a au moins trois copies (ou répliques) dans le cluster. L’une des répliques est…