Let’s look at the performance-related complexities that teams commonly face with write-heavy workloads and discuss your options for tackling them Les charges de travail de base de données lourdes en écriture présentent un ensemble de défis distinctement différent de ceux lourds en lecture. L'écriture à l'échelle peut être coûteuse, surtout si vous payez par opération et que l'écriture est 5 fois plus coûteuse que la lecture. Le verrouillage peut ajouter des retards et réduire le débit Les embouteillages I/O peuvent entraîner l'amplification d'écriture et compliquer la récupération d'accident Backpressure de la base de données peut gâcher la charge entrante Alors que le coût compte – beaucoup, dans de nombreux cas – ce n’est pas un sujet que nous voulons couvrir ici. Qu’entend-on par « réécriture en temps réel » ? Tout d’abord, nous allons clarifier ce que nous entendons par une charge de travail «d’écriture lourde en temps réel». Ingérer une grande quantité de données (par exemple, plus de 50K OPS) Plus d’écriture que de lecture Ils sont liés par des SLA de latence strictes (par exemple, une latence de milliseconde à un chiffre P99) Dans la nature, ils se produisent sur tout, des jeux en ligne aux bourses en temps réel. Internet des objets (IoT) charges de travail ont tendance à impliquer de petites mais fréquentes append-only écrits de données de séries temporelles. Ici, le taux d'ingestion est principalement déterminé par le nombre de points finaux collectant des données. pensez à des capteurs intelligents maison ou des équipements de surveillance industrielle envoyant constamment des flux de données à traiter et stocker. Les systèmes de journalisation et de surveillance traitent également de l'ingestion fréquente de données, mais ils n'ont pas de taux d'ingestion fixe. Ils ne s'appliquent pas nécessairement uniquement, et peuvent également être sujets à des points chauds, tels que lorsqu'un endpoint se comporte mal. Les plateformes de jeux en ligne doivent traiter les interactions utilisateur en temps réel, y compris les changements d'état du jeu, les actions des joueurs et les messages.La charge de travail a tendance à être forte, avec des hausses soudaines d'activité.Ils sont extrêmement sensibles à la latence car même de petits retards peuvent affecter l'expérience de jeu. Ces systèmes doivent maintenir des niveaux d'inventaire précis, traiter les commentaires des clients, suivre l'état des commandes et gérer les opérations de panier, ce qui nécessite généralement la lecture des données existantes avant de procéder à des mises à jour. Ces systèmes gèrent le traitement complexe des offres, y compris le suivi des impressions et les résultats des enchères, tout en surveillant simultanément les interactions des utilisateurs telles que les clics et les conversions. Les systèmes de Bourse en temps réel doivent prendre en charge les opérations de trading à haute fréquence, les mises à jour constantes des prix des actions et les processus complexes de correspondance des commandes, tout en maintenant une cohérence absolue des données et une latence minimale. Ensuite, examinons les principales considérations d’architecture et de configuration qui affectent les performances d’écriture. Architecture de moteur de stockage Le choix de l'architecture du moteur de stockage affecte fondamentalement les performances d'écriture dans les bases de données. Deux approches principales existent: les arbres LSM et les arbres B. Les bases de données connues pour gérer efficacement les enregistrements – tels que ScyllaDB, Apache Cassandra, HBase et Google BigTable – utilisent Log-Structured Merge Trees (LSM). Cette architecture est idéale pour gérer de grands volumes d’enregistrements. Les enregistrements étant immédiatement attachés à la mémoire, cela permet un stockage initial très rapide. Une fois que le «memtable» de la mémoire est rempli, les enregistrements récents sont rinçés sur le disque dans un ordre trié. Par exemple, voici à quoi ressemble le chemin d'écriture ScyllaDB: Avec les structures d'arbre B, chaque opération d'écriture nécessite la localisation et la modification d'un nœud dans l'arbre - et cela implique à la fois des I/O séquentiels et aléatoires.Avec la croissance du groupe de données, l'arbre peut nécessiter des nœuds supplémentaires et un rééquilibrage, ce qui conduit à plus d'I/O de disque, ce qui peut affecter les performances. Taille payante La taille de la charge utile affecte également la performance. Avec de petites charges utiles, le débit est bon, mais le traitement de la CPU est le principal obstacle. À mesure que la taille de la charge utile augmente, vous obtenez un débit global inférieur et l'utilisation du disque augmente également. En fin de compte, une petite écriture s'intègre généralement dans tous les tampons et tout peut être traité assez rapidement. C'est pourquoi il est facile d'obtenir un débit élevé. Pour les charges payantes plus grandes, vous devez allouer des buffers plus grands ou plusieurs buffers. Plus les charges payantes sont grandes, plus de ressources (réseau et disque) sont nécessaires pour servir ces charges payantes. Compression L'utilisation du disque est quelque chose à surveiller de près avec une charge de travail lourde d'écriture. Bien que le stockage devienne constamment moins cher, il n'est toujours pas gratuit. La compression peut aider à garder les choses sous contrôle – choisissez donc votre stratégie de compression avec sagesse.Les vitesses de compression plus rapides sont importantes pour les charges de travail lourdes, mais considérez également vos ressources de CPU et de mémoire disponibles. Assurez-vous de regarder le La compression divise essentiellement vos données en petits blocs (ou morceaux) puis compresse chaque bloc séparément. Lors de l'ajustement de ce paramètre, réalisez que les morceaux plus grands sont meilleurs pour les lectures, tandis que les plus petits sont meilleurs pour les écrits, et prenez en compte la taille de votre charge utile. Paramètre de taille de compression Compassion Pour les bases de données basées sur LSM, la stratégie de compression que vous choisissez affecte également les performances d'écriture. La compression implique la fusion de plusieurs SSTables en moins de fichiers plus organisés, afin d'optimiser les performances de lecture, de récupérer de l'espace disque, de réduire la fragmentation des données et de maintenir l'efficacité globale du système. Lorsque vous choisissez des stratégies de compression, vous pourriez viser l'amplification à faible lecture, ce qui rend les lectures aussi efficaces que possible. Ou, vous pourriez viser l'amplification à faible écriture en évitant que la compression soit trop agressive. Ou, vous pourriez prioriser l'amplification à faible espace et avoir les données de purge de compression aussi efficacement que possible. (et Cassandra propose des choses similaires) : Plusieurs stratégies de compactage Stratégie de compression de taille (STCS): Déclenchée lorsque le système a suffisamment (quatre par défaut) de SSTables de taille similaire. Stratégie de compression nivelée (LCS): Le système utilise de petites SSTables de taille fixe (par défaut 160 Mo) distribuées sur différents niveaux. Stratégie de compactage incrémental (ICS): Partage les mêmes facteurs d'amplification de lecture et d'écriture que STCS, mais il résout son problème d'amplification temporaire de l'espace 2x en brisant d'énormes stables en cours d'exécution SSTable, qui sont composés d'un ensemble trié de SSTables plus petits (1 GB par défaut), non surposés. Stratégie de compression de fenêtre temporelle (TWCS): Conçue pour les données de série temporelle. Pour les charges de travail lourdes à l'écriture, nous avertissons les utilisateurs d'éviter à tout prix la compression équilibrée. Cette stratégie est conçue pour les cas d'utilisation lourds à la lecture. Batché Dans les bases de données comme ScyllaDB et Cassandra, le batchage peut en fait être un peu un piège – en particulier pour les charges de travail lourdes. Si vous êtes habitué à des bases de données relationnelles, le batchage peut sembler être une bonne option pour gérer un volume élevé d’écriture. Mais il peut en fait ralentir les choses si cela n’est pas fait avec soin. Principalement, c’est parce que les lots grands ou non structurés finissent par créer beaucoup de coordination et d’opération réseau entre les nœuds. Cependant, ce n’est pas vraiment ce que vous voulez dans une base de données distribuée comme ScyllaDB. Voici comment penser au battage lorsque vous traitez avec des écrits lourds: Batch par la clé de partition : Groupez vos écrits par la clé de partition de sorte que le batch va à un nœud de coordinateur qui possède également les données. De cette façon, le coordinateur n'a pas à atteindre d'autres nœuds pour obtenir des données supplémentaires. Gardez les lots petits et ciblés : Décomposer les grands lots en plus petits par partition maintient les choses efficaces. Il évite de surcharger le réseau et permet à chaque nœud de travailler uniquement sur les données qu'il possède. Attention aux lots non connectés : considérant que vous suivez les points précédents, il est préférable d’utiliser des lots non connectés. Donc, si vous êtes dans une situation difficile à écrire, structurer vos lots soigneusement pour éviter les retards que les grands lots à nœuds croisés peuvent introduire. Envelopper le Nous avons offert quelques avertissements, mais ne vous inquiétez pas. Il a été facile de compiler une liste de leçons apprises parce que tant d'équipes travaillent avec succès avec des charges de travail lourdes en temps réel. Si vous voulez en savoir plus, voici quelques perspectives de première main des équipes qui ont abordé des défis assez intéressants : Zillow: Consommer des enregistrements de plusieurs producteurs de données, ce qui a entraîné des écrits hors ordre qui pourraient entraîner des mises à jour incorrectes Tractian: se préparer à une croissance de 10x des données haute fréquence écrites à partir de dispositifs IoT Fanatiques: Opérations d'écriture lourdes telles que le traitement des commandes, les paniers et les mises à jour de produits pour ce détaillant de sports en ligne Zillou Traceur Fanatiques Jetez également un coup d'oeil à la vidéo suivante, où nous allons encore plus en profondeur sur ces défis lourds d'écriture et aussi vous traverser ce que ces charges de travail ressemblent sur ScyllaDB.
