SlateDB - Moteur de stockage embarqué basé sur le stockage objet

• Moteur de stockage embarqué construit sur un Log-Structured Merge-tree (LSM-tree)
• Contrairement aux moteurs de stockage LSM-tree existants, SlateDB écrit les données dans un stockage objet (S3, GCS, ABS, MinIO, Tigris, etc.)
• En exploitant le stockage objet, il offre une capacité de stockage illimitée, une haute durabilité et une réplication facile
• Cependant, le stockage objet présente l’inconvénient d’une latence plus élevée et de coûts d’API supérieurs à ceux d’un disque local

Stratégies de SlateDB pour éviter ces inconvénients

• Les écritures sont traitées par lots afin d’atténuer le coût élevé des API d’écriture (PUT)
  • Au lieu d’écrire chaque appel à put() dans le stockage objet, la MemTable est régulièrement flushée vers le stockage objet sous forme de Sorted String Table (SST)
  • L’intervalle de flush est configurable
• Une méthode put asynchrone est fournie afin de réduire également la latence d’écriture
  • Les clients qui privilégient une forte durabilité peuvent faire await dans put jusqu’à ce que la MemTable soit flushée vers le stockage objet (compromis entre latence et durabilité)
  • Les clients qui privilégient une faible latence peuvent ignorer le future renvoyé par put
• Des techniques de cache LSM-tree standard sont utilisées pour réduire la latence de lecture et le coût des API de lecture (GET)
  • Cache de blocs en mémoire, compression, filtre de Bloom, cache disque local pour les SST