An in-depth look at database and cache internals, and the tradeoffs in each. ScyllaDB tient à remercier publiquement dormando (Memcached maintenance) et Danny Kopping pour leurs contributions à ce projet, ainsi que pour leur soutien et leur patience. Dormir par Danny Kopping Les ingénieurs derrière ScyllaDB – la base de données pour des performances prévisibles à l’échelle – se sont unis avec Memcached maintenance dormando pour comparer les deux technologies face à face, d’une manière collaborative et neutre du fournisseur. Les résultats révèlent que : Tant Memcached que ScyllaDB ont maximisé les disques et la bande passante du réseau tout en étant stressés dans des conditions similaires, maintenant des performances similaires dans l'ensemble. Alors que ScyllaDB a nécessité des changements de modélisation de données pour saturer complètement le débit réseau, Memcached a nécessité des fils IO supplémentaires pour saturer l'I/O du disque. Bien que ScyllaDB a montré de meilleures latences par rapport aux demandes pipelines Memcached vers le disque, les latences Memcached ont été meilleures pour les demandes individuelles. Ce document explique notre motivation pour ces tests, fournit un résumé des scénarios et des résultats testés, puis présente des recommandations pour quiconque pourrait décider entre ScyllaDB et Memcached. Il y a aussi avec un regard plus approfondi sur les tests et les résultats et des liens vers les configurations spécifiques que vous pouvez utiliser pour effectuer les tests vous-même. un Gitbook détaillé pour ce projet, Bonus: dormando et moi avons récemment discuté de ce projet au P99 CONF, une conférence hautement technique sur la performance et l'ingénierie à faible latence. Regardez la demande Bonus: dormando et moi avons récemment discuté de ce projet au P99 CONF, une conférence hautement technique sur la performance et l'ingénierie à faible latence. Watch on demand Regardez la demande Pourquoi avons-nous fait cela ? Tout d'abord, ScyllaDB a investi beaucoup de temps et de ressources d'ingénierie dans l'optimisation de notre base de données pour fournir des latences faibles prévisibles pour les applications riches en données en temps réel. L’architecture de rien, et (en contournant complètement le cache de la page Linux) sont quelques exemples notables de telles optimisations. Télécharger Shard-per-core Planificateur de l'espace utilisateur I/O Implémentation du cache interne Deuxièmement, les performances convergent au fil du temps.Les caches mémoire sont considérées (pour une longue période) comme l’un des composants d’infrastructure les plus rapides.Toutefois, il y a quelques années depuis que les solutions de caches ont commencé à regarder dans le domaine des disques flash.Ces initiatives posent évidemment une question intéressante: If an in-memory cache can rely on flash storage, then why can’t a persistent database also work as a cache? 3 - Nous avons déjà discuté et a récemment exploré comment des équipes spécifiques ont réussi . 7 raisons de ne pas placer un cache devant votre base de données Remplacer ses caches par ScyllaDB Quatrièmement, lors du P99 CONF de l’année dernière, Danny Kopping nous a donné un discours éclairant, , où il a expliqué comment Memcached Extstore a aidé Grafana Labs à évoluer leur empreinte cache 42x tout en réduisant les coûts. Cache-moi si tu peux Et enfin, malgré les critiques (valides) que reçoivent les critères de performance, ils jouent toujours un rôle important dans la promotion de l’innovation. Passons maintenant à la comparaison. établissement Les instances Les tests ont été effectués à l’aide des types d’instances AWS suivants : Chargeur : c7i.16xlarge (64 vCPUs, 128 Go de RAM) Memcached: i4i.4xlarge (16 vCPUs, 128GB de RAM, 3.75TB NVMe) ScyllaDB : i4i.4xlarge (16 vCPU, 128GB de RAM, 3,75TB NVMe) Toutes les instances peuvent fournir 25Gbps de bande passante réseau. Gardez à l'esprit qu'en particulier lors des tests de maximisation de la capacité de réseau promise, nous avons remarqué . en haut réduire la bande passante jusqu’à la capacité de base des instances Optimisations et paramètres Pour surmonter les obstacles potentiels, les optimisations et paramètres suivants ont été appliqués : AWS : Toutes les instances ont utilisé une stratégie de placement de cluster, suivant les documents AWS : « Cette stratégie permet aux charges de travail d’atteindre les performances réseau à faible latence nécessaires à la communication node-to-node étroitement liée qui est typique des applications de calcul haute performance (HPC). » Memcached: Version 1.6.25, compilé avec Extstore activé. Sauf où désigné, exécuté avec 14 fils, attaché à des CPU spécifiques. Les 2 vCPU restants ont été attribués à la CPU 0 (core & HT frère) pour gérer les IRQ de réseau, comme spécifié par le mode sq_split dans seastar perftune.py. Les opérations CAS ont été désactivées pour économiser de l'espace sur l'ensemble des éléments. Les arguments de ligne de commande complets étaient:taskset -c 1-7,9-15 /usr/local/memcached/bin/memcached -v -A -r -m 114100 -c 4096 -lock-memory -threads 14 - scylla -C ScyllaDB : paramètres par défaut configurés par ScyllaDB Enterprise 2024.1.2 AMI (ami-id: ami-018335b47ba6bdf9a) dans un i4i.4xlarge. Les stressants Pour les cartouches, nous avons utilisé , partie de la suite de tests officielle de memcached. Les profils de stress applicables sont dans le Le répertoire GitHub. McShredder Fee-mendes et Shredders Pour ScyllaDB, nous avons utilisé , comme livré avec ScyllaDB, et spécifié des charges de travail comparables à celles utilisées pour Memcached. Cassandre stressé Tests et résultats Ce qui suit est un résumé des tests que nous avons menés et de leurs résultats.Si vous voulez une description et une analyse plus détaillées, allez à . L'écriture élargie de ce projet L’efficacité du cache RAM Plus vous pouvez entrer dans la RAM, plus votre chance d'obtenir des hits cache est meilleure. Plus de hits cache entraîne un accès significativement plus rapide que l'accès au disque. Ce projet a commencé par mesurer le nombre d'éléments que nous pouvions stocker dans chaque datastore. Tout au long de nos tests, la clé était comprise entre 4 et 12 octets (key0 .. keyN) pour Memcached, et 12 octets pour ScyllaDB. mémoire Memcached a stocké environ 101M d'articles jusqu'à ce que l'expulsion ait commencé. Il est efficace en mémoire. De la mémoire 114G attribuée de Memcached, cela représente environ 101G de valeurs, sans tenir compte de la taille de la clé et d'autres drapeaux: ScyllaDB Ce n'est pas surprenant, étant donné que son protocole nécessite plus de données à stocker dans le cadre d'une écriture (telles que le timestamp d'écriture depuis l'époque, la durée de vie de la ligne, etc.). Takeaways Memcached stocke environ 65% plus d’éléments de mémoire que ScyllaDB. Les lignes ScyllaDB ont un surtête plus élevé par élément pour prendre en charge une orientation large colonne. Dans ScyllaDB, Bloom Filters, Index Caching, et d'autres composants sont également stockés dans la mémoire pour soutenir des recherches de disque efficaces, contribuant à une autre couche de surchauffe. Travail en mémoire In-Memory Le La charge de travail (bien que irréaliste) d'un cache est celle où toutes les données s'intègrent dans la RAM - de sorte que les lectures ne nécessitent pas d'accès au disque et qu'il n'y a pas d'évictions ou de manquements. ScyllaDB et Memcached utilisent la logique LRU (le moins récemment utilisé) pour libérer la mémoire: Lorsque le système fonctionne sous pression, les éléments sont expulsés de la queue du LRU; ce sont généralement les éléments les moins actifs. Idéal Supprimer les évictions et les manquements de cache de l'image aide à mesurer et à définir une base de performance pour les deux entrepôts de données. Il met l'accent sur ce qui compte le plus pour ces types de charges de travail: le débit de lecture et la latence de demande. Dans ce test, nous avons d’abord réchauffé les deux magasins avec les mêmes tailles de charge utile utilisées lors du test précédent. Memcached Memcached a atteint un chiffre impressionnant de 3 millions de gains par seconde, maximisant pleinement la bande passante AWS NIC (25 Gbps)! Memcached a maintenu un rythme 3M stable, maximisant complètement le débit NIC Le pars montrer que p99.999 réponses complétées en dessous de 1ms: Résultats Stat : cmd_get : Total des opérations : 5503513496 Fréquence : 3060908/s === heures mg === heures 1 à 10 0 000 % 10-99us 343504394 6 238% 100-999us 5163057634 93.762% 1 à 2 ms 11500 0.00021% ScyllaDB Pour lire plus de lignes dans ScyllaDB, nous avions besoin de concevoir un meilleur modèle de données pour les requêtes client en raison des caractéristiques du protocole (en particulier, aucun pipelining).Avec une clé de cluster, nous pouvions complètement maximiser le cache de ScyllaDB, ce qui a entraîné une amélioration significative du nombre de lignes cachées. En conséquence, le nombre d'enregistrements dans le cache s'est considérablement amélioré par rapport aux nombres de valeurs clés affichés précédemment. Comme dormando a correctement souligné (merci!), cette configuration est significativement différente de la configuration Memcached précédente. Alors que la charge de travail Memcached frappe toujours une paire de valeurs de clé individuelle, une seule requête dans ScyllaDB entraîne le retour de plusieurs lignes. Nous avons expliqué les raisons de ces changements Là, nous avons couvert des caractéristiques du protocole CQL (telles que l'overhead par élément [par rapport à memcached] et aucun support pour le pipelining) qui rendent les partitions larges plus efficaces sur ScyllaDB que les collections à clé unique. Dans l’écriture détaillée Grâce à ces ajustements, nos chargeurs ont effectué un total de 187K opérations de lecture par seconde sur 30 minutes. Similaire à memcached, ScyllaDB a également maximisé le débit NIC. Il a servi environ 3M rangées / seconde uniquement à partir de données dans la mémoire: ScyllaDB expose des informations de latence du côté du serveur, ce qui est utile pour analyser la latence sans le réseau.Durant le test, la latence p99 du côté du serveur de ScyllaDB est restée dans les limites de 1ms: Les percentiles du côté client sont, sans surprise, plus élevés que la latence du côté serveur avec une lecture P99 de 0,9ms. Takeaways Tant Memcached que ScyllaDB saturaient complètement le réseau ; pour empêcher la saturation des paquets réseau maximaux par seconde, Memcached s’appuyait sur le pipelining des demandes tandis que ScyllaDB passait à une orientation large-colonne. Le cache de ScyllaDB a montré des gains considérables en suivant un schéma de colonne large, capable de stocker plus d'éléments par rapport à la précédente orientation simple de la valeur de clé. Au niveau du protocole, le protocole de Memcached est plus simple et léger, tandis que le CQL de ScyllaDB offre des fonctionnalités plus riches mais peut être plus lourd. Ajouter des disques à l'image La mesure des performances du stockage flash présente ses propres défis, ce qui rend presque impossible de caractériser pleinement une charge de travail donnée de manière réaliste. Pour les tests liés aux disques, nous avons décidé de mesurer la situation la plus pessimiste : comparer les deux solutions servant des données (principalement) à partir du stockage de blocs, sachant que : La probabilité de charges de travail réalistes en faisant cela est quelque part proche de zéro Les utilisateurs devraient s'attendre à des chiffres entre la charge de travail optimiste du cache précédent et la charge de travail pessimiste liée au disque dans la pratique Memcached Extstore Le À un niveau élevé, il permet à memcached de conserver sa table hash et ses clés dans la mémoire, mais de stocker les valeurs sur le stockage externe. Extension de page wiki Au cours de nos tests, nous avons peuplé le memcached avec des éléments 1.25B avec une taille de valeur de 1KB et une taille de clé jusqu'à 14 octets: Avec Extstore, nous avons stocké environ 11X le nombre d'articles par rapport à la charge de travail précédente dans la mémoire jusqu'à ce que les détournements commencent à démarrer (comme montré dans le panneau à droite dans l'image ci-dessus). Read-Only Performance Pour les tests de performance réels, nous avons mis l'accent sur Extstore par rapport aux tailles d'éléments de 1KB et 8KB. Test Type Items per GET Payload Size IO Threads GET Rate P99 perfrun_metaget_pipe 16 1KB 32 188K/s 4~5 ms perfrun_metaget 1 1KB 32 182K/s <1ms perfrun_metaget_pipe 16 1KB 64 261K/s 5~6 ms perfrun_metaget 1 1KB 64 256K/s 1~2ms perfrun_metaget_pipe 16 8KB 16 92K/s 5~6 ms perfrun_metaget 1 8KB 16 90K/s <1ms perfrun_metaget_pipe 16 8KB 32 110K/s 3~4 ms perfrun_metaget 1 8KB 32 105K/s <1ms Pépinière_pipe 16 1 kB 32 188 K / s 4 à 5 ms Résumé - Méthode 1 1 kB 32 182 K / s > 1 ms Pépinière_pipe 16 1 kB 64 261 K/s 5 à 6 ms Résumé - Méthode 1 1 kB 64 256K / s 1 à 2 ms Pépinière_pipe 16 8 kB 16 92 K / s 5 à 6 ms Résumé - Méthode 1 8 kB 16 90 K/s > 1 ms Pépinière_pipe 16 8 kB 32 110 K/s 3 à 4 ms Résumé - Méthode 1 8 kB 32 105 K/s > 1 ms ScyllaDB Nous avons peuplé ScyllaDB avec le même nombre d'éléments que ceux utilisés pour memcached. Bien que ScyllaDB ait montré des taux de GET plus élevés que pour memcached, il l'a fait avec des latences de queue légèrement plus élevées par rapport aux charges de travail non pipelining de memcached. Test Type Items per GET Payload Size GET Rate Server-side P99 Client-side P99 1KB Read 1 1KB 268.8K/s 2ms 2.4ms 8KB Read 1 8KB 156.8K/s 1.54ms 1.9ms 1kb de lecture 1 1 kB 288 K/s 2 ms 2,4 ms 8kb de lecture 1 8 kB 156.8K par seconde 1 54 ms 1 9 ms Takeaways Extstore a nécessité un réglage considérable de ses paramètres afin de saturer complètement le stockage flash I/O. En raison de l'architecture Memcached, les charges payantes plus petites ne sont pas en mesure d'utiliser pleinement l'espace disque disponible, offrant des gains plus petits par rapport à ScyllaDB. Les taux de ScyllaDB étaient globalement plus élevés que Memcached dans une orientation de valeur clé, en particulier sous des tailles de charge utile plus élevées. Surécrire le workload En suivant nos résultats précédents sur le disque, nous avons ensuite comparé les deux solutions dans une charge de travail de lecture principalement ciblant le même débit (250K op/sec). Il s’agit d’un scénario de « moitié pire scénario ». Test « basique » pour Extstore Memcached Memcached a atteint un taux légèrement inférieur à 249K pendant le test. Bien que les taux d'écriture restent stables pendant la durée du test, nous avons observé que les lectures fluctuaient légèrement : Tout au long de la course Nous avons également observé une légère Même si les ratios de lecture ont baissé, les latences sont restées faibles.Ces résultats sont résumés ci-dessous: extstore_io_queue à partir de Operation IO Threads Rate P99 Latency cmd_get 64 224K/s 1~2 ms cmd_set 64 24.8K/s <1ms CMD - GET 64 224 K/s 1 à 2 ms cmd_configuré 64 24 8 K/s > 1 ms ScyllaDB Le test ScyllaDB a été exécuté à l'aide de 2 chargeurs, chacun avec la moitié du taux cible. Même si ScyllaDB a atteint un débit légèrement plus élevé (259.5K), les latences d'écriture ont été maintenues faibles tout au long de la course et les latences de lecture ont été plus élevées (similaire à celle de memcached): Le tableau ci-dessous résume les résultats d'exécution du côté client sur les deux chargeurs: Loader Rate Write P99 Read P99 loader1 124.9K/s 1.4ms 2.6 ms loader2 124.6K/s 1.3ms 2.6 ms Loisirs1 124.9K par seconde 1.4 Les 6.2 Les ms Télécharger2 124.6K par seconde 1.3 Les 6.2 Les ms Takeaways Les taux d'écriture de Memcached et de ScyllaDB étaient stables, avec des lectures légèrement fluctuantes tout au long de la course. ScyllaDB écrit encore compte pour le commitlog overhead, qui se trouve dans le chemin d'écriture chaude Les latences du côté serveur de ScyllaDB étaient similaires à celles observées dans les résultats Memcached, bien que les latences du côté client soient légèrement plus élevées. Lire une analyse plus détaillée dans le Gitbook pour ce projet Envelopper le Les deux memcached et ScyllaDB ont réussi à maximiser l'utilisation du matériel sous-jacent dans tous les tests et à maintenir les latences prévisiblement faibles. Si votre charge de travail existante peut accueillir un modèle de valeur clé simple et que cela bénéficie du pipelining, alors memcached devrait être plus adapté à vos besoins. Une autre raison de s'accrocher à Memcached: il fournit facilement un trafic bien au-delà de ce qu'un NIC peut supporter. En raison de cela, vous pourriez utiliser des types d'instances plus petits et / ou moins chers pour maintenir une charge de travail similaire, à condition que la mémoire et l'empreinte de disque disponibles suffisent à vos besoins de charge de travail. Le thème de la nouvelle hacker Un autre angle à considérer est la taille des ensembles de données. Même si Extstore offre de grandes économies de coûts en vous permettant de stocker des éléments au-delà de la RAM, il y a une limite au nombre de clés pouvant s'adapter par GB de mémoire. Les charges de travail avec des éléments très petits devraient observer des gains plus petits par rapport à ceux avec des éléments plus grands. Ce n'est pas le cas avec ScyllaDB, qui vous permet de stocker des milliards d'articles indépendamment de leur taille. Il est également important de considérer si la persistance des données est requise.Si c'est le cas, alors exécuter ScyllaDB en tant que cache distribué répliqué vous fournit une plus grande résilience et des opérations non-stop, avec le commerce étant (et comme ) que la réplication réduit de moitié la taille de votre cache efficace. Malheureusement, Extstore ne prend pas en charge les redémarrages chauds et donc l'échec ou l'entretien d'un seul nœud est susceptible d'élever votre ratio de manque de cache. Que cela soit acceptable ou non dépend de la sémantique de votre application: Si un manque de cache correspond à un tour à la base de données, alors la latence de bout à bout sera momentanément plus élevée. Les États-Unis ont correctement En ce qui concerne le hashing cohérent, les clients memcached sont responsables de la distribution des clés sur vos serveurs distribués. Cela peut entraîner des hiccups, car les différentes configurations du client feront en sorte que les clés soient attribuées différemment et que certaines implémentations ne soient peut-être pas compatibles les unes avec les autres. ScyllaDB adopte une approche différente : le hashing cohérent est effectué au niveau du serveur et propagé aux clients lors de la première connexion. Configuration du client wiki de Memcached Alors qui a gagné (ou qui a perdu)? Eh bien... Ce n’est pas nécessairement une compétition, ni une liste exhaustive décrivant chaque considération pour chaque solution. ScyllaDB et memcached utilisent des approches différentes pour exploiter efficacement l’infrastructure sous-jacente. Nous avons été heureux de voir ScyllaDB correspondant aux chiffres de l'industrie reconnue Memcached. Bien sûr, nous n'avions aucune espérance que notre base de données soit "plus rapide."En fait, comme nous approchons de la latence de microsecondes à l'échelle, la définition de plus rapide devient assez subjective. 🙂
