gestion de l'espace disque physique de cassandra

Question

Récemment, j'ai regardé Cassandra du point de vue de notre nouveau projet et j'ai beaucoup appris de cette communauté et de son wiki. Mais je n'ai rien trouvé sur la façon dont les mises à jour sont gérées dans Cassandra en termes de gestion de l'espace disque physique bien qu'elles semblent être très similaires à la gestion des suppressions d'enregistrements en utilisant le compactage. Supposons qu'il y ait 100 enregistrements avec 5 valeurs de colonne chacune. Lorsque toutes les modifications seront vidées, tous les enregistrements seront écrits de manière adjacente et lorsque l'opération de suppression est terminée, elle est marquée dans la table Mémoire et l'enregistrement physique est supprimé après un certain temps. mettre en configuration ou quand il est plein. Et le processus de compactage revendique l'espace. Maintenant, la question est que d'un côté étant schema moins il n'y a pas de nombre fixe de colonnes au début mais de l'autre côté quand le processus de compactage a lieu alors ... met-il des disques adjacents sur disque comme RDBMS traditionnel pour accélérer le processus de lecture comme pour SGBDR est facile car ils doivent allouer une quantité d'espace fixe selon le type de données de déclaration de colonnes.

Mais comment Cassandra effectue-t-il exactement le placement des enregistrements sur le disque dans le processus de compactage (à la fois pour la mise à jour/suppression) pour accélérer les lectures? Une autre question liée au compactage est que lorsqu'il n'y a pas de requêtes de suppression mais qu'il y a une requête de mise à jour qui met à jour un enregistrement existant avec des données de longueur variable ou insère une nouvelle colonne alors comment le compactage rend son espace disponible sur disque lignes de données déjà existantes?

Answer 1

Les lignes et les colonnes sont stockées dans un ordre trié dans un SSTable. Cela permet un compactage de plusieurs SSTables pour produire un nouveau SSTable (trié) avec uniquement des E/S disque séquentielles. Ce nouveau SSTable sera sorti dans un nouveau fichier et libérer de l'espace sur les disques. Ce processus ne dépend pas du nombre de lignes de colonnes, mais de leur stockage dans un ordre trié. Donc oui, dans tous les SSTables (même ceux qui résultent des compactions), les lignes et les colonnes seront organisées dans un ordre trié sur le disque. Quoi de plus, comme vous le suggérez dans votre question, les mises à jour ne sont pas différentes des insertions - elles n'écrasent pas la valeur sur le disque, mais sont stockées dans une Memtable, puis sont stockées dans un nouveau SSTable. Lorsque le nouveau SSTable sera finalement compacté avec le SSTable contenant la valeur d'origine, la nouvelle valeur annulera l'ancienne - c'est-à-dire que l'ancienne valeur ne sera pas sortie du compactage. Les horodatages sont utilisés pour décider quelles valeurs sont les plus récentes.

Les suppressions sont traitées de la même manière, insérées efficacement dans un "anti-value", ou pierre tombale. La limitation de ce processus est que cela peut nécessiter des frais généraux importants. Les suppressions sont effectivement paresseuses, donc l'espace n'est libéré que plus tard. De même, bien que la sortie du compactage puisse avoir la même taille que l'entrée, les anciens SSTables ne peuvent pas être supprimés tant que le nouveau n'est pas terminé, ce qui peut réduire l'utilisation du disque à 50%. Dans le système décrit ci-dessus, les nouvelles valeurs d'une clé existante peuvent être de taille différente de la clé existante sans remplissage à une longueur prédéterminée, car la nouvelle valeur n'est pas écrite sur l'ancienne valeur à la mise à jour, mais à un nouveau SSTable.