Les développeurs d'OrioleDB ont analysé l'état actuel de l'API de bas niveau utilisée pour l'accès des extensions aux tables et aux index dans PostgreSQL (API Table/Index Access Method (AM)) et ont proposé des pistes d'amélioration. Depuis l'introduction de cette API dans PostgreSQL 12, les développeurs ont pu créer des mécanismes de stockage alternatifs. Cependant, malgré l'existence de cette API et les limitations connues du mécanisme de stockage intégré, aucun moteur de stockage transactionnel complet, implémenté uniquement sous forme d'extensions, n'a encore été développé.
Les fonctionnalités les plus demandées pour les moteurs de tables alternatifs de PostgreSQL sont :
- Des implémentations MVCC alternatives, par exemple, des systèmes de stockage basés sur un journal UNDO.
- Des tables organisées par index, où l'index n'est pas un complément facultatif à la table qui accélère les requêtes, mais constitue la structure de données principale dans laquelle les données de la table sont stockées.
Les changements nécessaires dans l'API Table/Index AM pour prendre en charge des implémentations MVCC alternatives sont examinés en tenant compte de l'extension OrioleDB, conçue pour corriger les défauts connus du mécanisme de stockage intégré de PostgreSQL. Le problème est que pour une intégration complète d'OrioleDB avec PostgreSQL, des modifications du code de PostgreSQL sont nécessaires, ce qui complique la mise en œuvre du projet et souligne la nécessité de moderniser l'API Table AM actuelle.
L'API Table AM n'impose pas directement une méthode d'implémentation du MVCC. Cependant, les API Table AM et Index AM font l'hypothèse suivante : chaque TID (Tuple/row Identifier) est soit indexé par tous les index, soit pas du tout. Même si l'Index AM a plusieurs références à un même TID (par exemple, GIN), toutes ces références doivent correspondre à la même valeur indexée.
Ce principe a été critiqué pour l'augmentation du nombre d'opérations d'écriture (« write amplification ») — si un attribut indexé est mis à jour, chaque index de la table doit être mis à jour. Pour tirer pleinement parti du journal UNDO ou construire un autre méthode de stockage sans « amplification des écritures » (par exemple, la méthode WARM), il est nécessaire de rompre cette hypothèse.
La Table AM, fondée sur UNDO, qui ne violera pas cette hypothèse, ressemble à la méthode existante HOT (Heap-Only Tuples), à l'exception que les anciennes versions des lignes sont conservées dans le journal UNDO et ne doivent pas tenir sur la même page. Cependant, selon les auteurs, cet avantage n'est pas suffisant pour justifier l'existence d'une Table AM séparée.
Limitations pratiques de l'API existante :
- Lorsqu'une ligne de table est mise à jour, les index sont mis à jour selon le principe du « tout ou rien ».
- L'API Index AM ne permet pas la suppression ciblée de certains tuples. Actuellement, les tuples peuvent être supprimés en masse des index à l'aide des méthodes ambulkdelete et amvacuumcleanup. Tenter de mettre en œuvre la suppression ciblée via cette API entraînerait une faible efficacité, car la plupart des implémentations actuelles doivent scanner l'ensemble de l'index. De plus, l'API ne permet pas de spécifier quels tuples, se référant au même TID, doivent être supprimés. Elle peut seulement les supprimer tous.
- Les index référencent actuellement les lignes de table par numéro de bloc (32 bits) et numéro de décalage (16 bits). Seuls 11 bits du numéro de décalage peuvent être transmis en toute sécurité du TID de la table à toutes les méthodes d'accès à l'index. En outre, des implémentations alternatives de MVCC peuvent nécessiter de stocker une charge utile (payload) supplémentaire avec le TID. Par exemple, dans OrioleDB, un ou plusieurs bits sont nécessaires pour mettre en œuvre des index « delete-marking » ou des informations complètes sur la visibilité.
Deux approches ont été proposées pour surmonter ces limitations en pratique :
Approche 1 : L'API Index AM offre des possibilités pour une implémentation alternative de MVCC.
Alors que la Table AM continue de prendre en charge tous les composants de MVCC, l'Index AM fournit les capacités nécessaires pour une mise en œuvre alternative de MVCC, à savoir : le stockage d'une charge utile (payload) utilisateur avec le TID, une méthode de suppression ciblée et même une méthode de mise à jour ciblée (si le TID dans l'index ne peut pas être modifié, la charge utile utilisateur peut l'être). De plus, comme il est nécessaire de permettre à plusieurs tuples d'index de référencer le même TID, les méthodes API utilisées lors du scan de l'index doivent également être mises à jour.
Approche 2 : Index prenant en charge le MVCC.
Une alternative serait de permettre des index prenant en charge le MVCC. Ainsi, l'« executor » (ou peut-être Table AM) appellerait simplement les méthodes insert() et delete() dans Index AM, tandis qu'Index AM fournirait la possibilité de scanner en tenant compte du MVCC. Cela simplifierait considérablement le scan n'utilisant que les index (index-only). Même tout Table AM pourrait, dans ce cas, devenir une couche intermédiaire, stockant des données dans l'index.
Le diagramme ci-dessous présente un exemple. La valeur de l'index 2 est mise à jour par la transaction 11 de la valeur « A » à la valeur « B ». Par conséquent, la valeur « A » est marquée comme xmax == 11, et la valeur « B » est marquée comme xmin == 11. Il est donc possible de scanner l'index 2 et de ne recevoir que les tuples visibles conformément au MVCC sans vérifications de tas (heap). La collecte des déchets de l'index 2 peut également être effectuée sans utiliser de tas.
Lors de l'intégration de toutes les innovations mentionnées dans l'API des méthodes d'accès aux index, il est peu probable que toutes les index puissent être adaptées en même temps pour prendre en charge toutes les nouvelles fonctionnalités. Il est plus réaliste de permettre plusieurs implémentations pour une méthode d'accès d'index. Par exemple, en plus de l'arbre B ordinaire, l'extension pourrait mettre en œuvre un arbre B alternatif avec prise en charge du MVCC à l'intérieur de l'index et prise en charge des identifiants d'enregistrement de longueur variable.
Ainsi, il est proposé de réviser non seulement l'API Table AM, mais aussi l'API Index AM, qui a fidèlement servi la communauté PostgreSQL pendant de nombreuses années. De plus, il est proposé de diviser Index AM en une couche logique et une couche de mise en œuvre. Cette architecture repensée permettra à PostgreSQL de prendre en charge divers modèles de stockage.
Source : opennet.ru
