Récemment, des chercheurs de l’UC Berkeley ont publié TAOBench, une référence de bout en bout pour les charges de travail des réseaux sociaux basée sur les traces collectées à partir de TAO, la base de données distribuée pour Meta. Parmi les opérations de données typiques dans les applications de réseaux sociaux, 99,7 % sont lues, tandis que seulement 0,2 % sont en écriture et 0,01 % sont des transactions en écriture. Certaines autres découvertes incluent:
- Les raccourcis clavier de transaction sont souvent colocalisés.
- Les hotspots de lecture et d’écriture apparaissent sur des touches différentes.
- Le conflit peut résulter intentionnellement.
Toutes ces caractéristiques des charges de travail des applications de réseaux sociaux posent des défis particuliers.
Dans cet article, nous partagerons les défis technologiques typiques auxquels sont confrontées les applications de réseaux sociaux. Sur la base des résultats de TAOBench, nous discuterons également de certaines fonctionnalités et optimisations des bases de données SQL distribuées qui aident à optimiser les performances de référence des réseaux sociaux.
Les défis techniques sous-jacents des applications de réseaux sociaux
Les applications de réseaux sociaux permettent aux utilisateurs de partager des informations, telles que du texte, des photos, des vidéos et des liens, et d’interagir les uns avec les autres via diverses fonctionnalités, telles que la messagerie, les forums et les groupes. Ces objets et fonctionnalités fonctionnent ensemble pour décrire les relations. En tant qu’utilisateur d’une application sociale, vous aurez de nombreux besoins qui posent des problèmes de données :
- Vous ne voulez pas que des personnes non autorisées voient vos messages, mais vous voulez que les personnes pertinentes pour vous les voient.
- Vous voulez que vos messages soient visibles immédiatement, pas retardés pendant des heures.
- Vous ne voulez pas manquer les réponses qui arrivent en retard. Les réponses tardives perturbent également les utilisateurs.
- Vous voulez accéder à l’information à tout moment, n’importe où.
Les défis technologiques sous-jacents des applications de réseaux sociaux incluent l’évolutivité, la confidentialité, la sécurité et la gestion des données.
- Évolutivité. Il s’agit de la capacité d’un système à gérer une quantité croissante de trafic et de données sans devenir lent ou sans réponse. Les applications de réseaux sociaux doivent gérer de grandes quantités de données et de trafic : elles comptent souvent des millions d’utilisateurs qui génèrent et accèdent constamment à des données.
- Confidentialité et sécurité. Ceux-ci sont vitaux pour les applications de réseaux sociaux. Ces applications contiennent souvent des informations personnelles sensibles, telles que des profils d’utilisateurs, des messages et des connexions, et elles doivent protéger ces informations contre tout accès et divulgation non autorisés.
- Gestion de données. Les applications doivent pouvoir stocker, traiter et récupérer efficacement de grandes quantités de données tout en garantissant l’intégrité et la disponibilité des données.
Tous ces besoins sont encore plus complexes à l’hyper-échelle, une échelle qui augmente avec le temps. Comme le mentionne le document TAO, « Une seule page Facebook peut regrouper et filtrer des centaines d’éléments du graphe social…. Elle doit être efficace, hautement disponible et s’adapter à des taux de requête élevés. »
Comment les bases de données SQL distribuées s’adaptent-elles ?
Pour gérer le volume élevé de données et de trafic généré par les réseaux sociaux, les systèmes de base de données doivent pouvoir évoluer horizontalement, en utilisant plusieurs serveurs et d’autres ressources pour répartir la charge de travail et améliorer les performances.
En plus de l’évolutivité, les bases de données de réseaux sociaux doivent pouvoir prendre en charge des requêtes rapides et efficaces pour offrir aux utilisateurs une expérience fluide et réactive. Cela implique l’utilisation d’indexation et de structures de données spécialisées, ainsi que des algorithmes complexes d’optimisation des requêtes.
Les bases de données SQL distribuées sont conçues pour gérer de grandes quantités de données et de trafic et peuvent être facilement mises à l’échelle horizontalement sur plusieurs serveurs et autres ressources. Ils peuvent également offrir des fonctionnalités telles que la haute disponibilité, la tolérance aux pannes et la modélisation flexible des données, qui peuvent être utiles pour les applications de réseaux sociaux.
Indications dans le test TAOBench
Dans le test TAOBench, un chercheur de l’UC Berkeley a testé plusieurs bases de données cloud distribuées avec des ressources d’infrastructure à prix équivalent. Le résultat est illustré ci-dessous.
Benchmark de TAOBench sur les bases de données distribuées
La figure montre que la latence de toutes les bases de données augmente lorsque le débit atteint un certain niveau. (Chaque base de données a des limites d’évolutivité et de performances différentes.) En effet, ces bases de données (à l’exception de Cloud Spanner) sont limitées à des ressources de coût égal. Par rapport à d’autres fournisseurs, TiDB, une base de données SQL distribuée, affiche des performances stables avec la meilleure évolutivité. Cela lui permet d’atteindre un débit plus élevé.
Architecture et optimisations de TiDB pour les réseaux sociaux
TiDB est une base de données SQL distribuée qui offre évolutivité, haute disponibilité, transactions ACID et compatibilité MySQL, ce qui la rend idéale pour les scénarios OLTP. Aujourd’hui, TiDB joue un rôle vital dans de nombreuses entreprises de réseaux sociaux, telles que Zhihu (Quora en Chine), Redbook, Pinterest et Bilibili. De nombreuses entreprises utilisent TiDB pour les aider à gérer les problèmes de données à grande échelle. TiDB fournit également de véritables capacités de traitement transactionnel/analytique hybride (HTAP) qui simplifient les piles technologiques en combinant l’OLTP et l’analyse en temps réel.
En tant que base de données SQL distribuée, TiDB excelle dans les tests TAOBench pour les performances et la mise à l’échelle. Il y a quelques bonnes raisons architecturales :
- Cohérence et isolation : prise en charge d’ACID et des transactions distribuées basées sur Percolator
- Haute disponibilité : répliques de données basées sur Raft
- Haut débit : nœuds horizontaux élastiques et évolutifs pour prendre en charge l’écriture multiple
- Accès aux données relationnelles : compatibilité MySQL
- Capacité à gérer les problèmes de points d’accès : fractionnement automatique et rééquilibrage avec la région de données
De plus, certains aspects de la conception de TiDB le rendent bien adapté aux applications de mise en réseau.
Partage dynamique automatique et rééquilibrage
Comme le dit le document TAOBench, « les raccourcis clavier de transaction sont souvent colocalisés ». Le problème des points chauds est difficile dans les applications de réseaux sociaux.
Dans TiDB, l’unité de stockage de données fondamentale pour la gestion et la distribution est appelée une « région ». Les régions peuvent être divisées et fusionnées en fonction de la quantité de données qu’elles gèrent et peuvent être programmées pour se déplacer entre les nœuds.
En règle générale, les données sont réparties uniformément sur tous les nœuds de stockage et TiDB équilibre automatiquement les ressources de chaque magasin en fonction de la charge. L’utilisation du processeur et du disque d’un nœud de stockage peut devenir un goulot d’étranglement. Le pilote de placement (PD) de TiDB estime la charge des régions de données en fonction de statistiques telles que le nombre de requêtes et la quantité de données écrites et synchronisées. PD peut programmer l’opération d’équilibrage en conséquence.
Dans un réseau social, les hotspots peuvent être concentrés dans une région de données. TiDB échantillonne une région de données pour analyser la répartition de la charge de travail. Il trouve ensuite un point de partage approprié pour permettre à la région de données chaudes de se diviser en régions plus petites. Après le fractionnement, le planificateur d’équilibrage des points d’accès peut déplacer les points d’accès dans différents nœuds. Grâce à ces deux fonctionnalités de planification, TiDB peut pleinement utiliser la nature distribuée du stockage, des E/S et de l’informatique. Cela permet de maintenir des performances stables, même en cas de points chauds importants.
Traitement des hotspots dans TiDB
Optimisation des transactions d’écriture pour les participants colocalisés
Les systèmes distribués qui prennent en charge les transactions inter-lignes et inter-nœuds utilisent généralement la validation en 2 phases (2PC) pour obtenir l’atomicité. L’implémentation 2PC de TiDB est basée sur Percolator. Dans le modèle Percolator de TiDB, une transaction est considérée comme validée une fois que la clé primaire est validée. Cela nécessite au moins deux allers-retours réseau. Cependant, toutes les transactions ne nécessitent pas 2PC pour atteindre l’atomicité. Si une transaction n’implique que des données hébergées sur un nœud, les validations atomiques peuvent être réalisées avec une seule série de RPC.
Processus optimisé de TiDB pour les transactions d’écriture
L’article de TAOBench indique que « les raccourcis clavier dans les transactions d’écriture ont tendance à être colocalisés sur les mêmes fragments ». Cette optimisation dans TiDB réduit efficacement le nombre de phases de validation des transactions. Dans les résultats des tests, nous avons observé que les opérations de validation par seconde (OPS) sont passées de 6 000 à moins de 1 000, ce qui indique que la plupart des 2PC ont été réduits à 1PC. Cependant, étant donné que les écritures dans TAOBench ne représentent qu’environ 0,2 % de tout le trafic, les requêtes par seconde (RPS) globales n’ont connu qu’une légère amélioration.
Commit performance observée dans TAOBench
Un sujet potentiel d’optimisation future consiste à utiliser l’affinité des données pour colocaliser autant de données pertinentes que possible dans une région de données. Cela peut réduire la surcharge de 2PC et améliorer les performances.
Planifier le cache pour les charges de travail lourdes en lecture
TiDB prend en charge le cache de plan pour les instructions SQL. Cela lui permet d’ignorer la phase d’optimisation, qui comprend l’optimisation basée sur les règles et l’optimisation basée sur les coûts. Pour les charges de travail à lecture intensive, le fait d’ignorer ces processus permet d’économiser des ressources informatiques et d’améliorer les performances. D’après nos tests, l’activation du cache du plan améliore le RPS d’environ 10,5 %.
Planifier le cache dans TiDB
Collecte de déchets à réglage semi-automatique
Pour tout système gourmand en données, la récupération de place (GC) est une tâche d’arrière-plan gourmande en ressources. Les paramètres de seuil GC peuvent affecter de manière significative les performances du système, en particulier lorsqu’il consomme beaucoup de ressources CPU. Le réglage automatique Go GC, une optimisation proposée par un ingénieur Uber, peut réduire les opérations GC inutiles et économiser des frais généraux sur les opérations légères fréquentes. TiDB a adopté cette optimisation, qui a considérablement amélioré le débit de TAOBench et de nombreuses autres charges de travail de traitement transactionnel en ligne (OLTP). Cependant, il y a un compromis. Bien que cette méthode réduise les GC inutilement fréquents, dans les cas extrêmes, elle peut augmenter le risque de pannes de mémoire insuffisante (OOM). Les résultats peuvent être trouvés dans le graphique suivant.
Itération et évaluation continues
En plus des fonctionnalités et des optimisations dont nous avons parlé, l’évolution du produit lui-même est essentielle pour relever les défis d’évolutivité. TiDB itère rapidement et souvent, avec une cadence de publication d’un à deux mois. Pour capturer les gains de performances sur différentes versions, l’équipe a également configuré TAOBench pour comparer les performances de TiDB 6.4 avec TiDB 5.0. Comme indiqué dans le graphique, nous avons réalisé une amélioration de 30 % du QPS au cours de la dernière année et demie.
Comparaison des performances globales de TiDB sur TAOBench
Conclusion
Globalement, la charge de travail d’un réseau social…