Bluesky migre vers SQLite à locataire unique

• Bluesky a migré vers un datastore SQLite à locataire unique.
• Désormais, chaque utilisateur possède son propre fichier SQLite pour stocker son dépôt et l’état privé de son compte.
• Les bases de données utilisateur sont stockées de manière hiérarchique.
• La clé de signature de dépôt de chaque repository est stockée avec le fichier SQLite.
• L’abstraction qui interagit avec les données utilisateur a été remplacée par ActorStore.
• ActorStore dispose de classes distinctes pour la lecture et l’écriture.
• Comme SQLite ne prend pas en charge les transactions concurrentes, ActorStore nécessite un "transact" explicite pour l’écriture.
• Un LRUCache pour les clés de signature et les bases de données est maintenu, permettant 30k handles de fichiers ouverts et 30k clés conservées en mémoire.
• Lorsqu’une base de données sort du cache, son handle de fichier est fermé.
• Trois bases de données SQLite distinctes ont été introduites pour gérer l’état du service : une service DB pour les informations de compte, les codes d’invitation, les refresh tokens, etc., une did cache DB pour mettre en cache la résolution des DID, et une sequencer DB pour traiter séquentiellement les mises à jour des repositories de l’ensemble des dépôts du service.
• Ces fichiers SQLite fonctionnent en mode WAL afin de permettre les lectures concurrentes et la réplication par flux.
• Le déploiement de PDS devrait être livré avec Litestream ou un outil similaire.

[GN⁺]

Avis sur Hacker News

• Bluesky a migré vers une configuration SQLite mono-locataire, ce qui a lancé une discussion sur les défis et les avantages de cette approche.
• Certains utilisateurs expriment des inquiétudes sur les problèmes potentiels liés à la migration des données, aux versions de schéma et aux futurs besoins d’agrégation des données.
• D’autres remettent en cause l’affirmation selon laquelle SQLite ne prend pas en charge les transactions simultanées, en soulignant que c’est possible dans certaines conditions.
• La stratégie d’un ratio 1:1 entre utilisateur et base de données semble intéressante, et des questions ont été soulevées sur la manière dont les données à agréger entre utilisateurs seront gérées.
• Il y a aussi de l’intérêt pour la façon dont cette configuration gérera les mises à jour de la base de données d’un utilisateur lorsque d’autres publient de nouveaux contenus.
• Certains saluent l’adoption de SQLite/Litestream côté serveur, en y voyant un choix rentable pour des bases de données par tenant.
• Des questions ont été posées sur les types de données stockés dans SQLite et ceux qui ne le sont pas, certains supposant que les messages entre utilisateurs n’y sont pas stockés.
• Une suggestion avance que l’utilisation d’un hachage MD5 pour obtenir des répertoires cibles à deux caractères serait plus rapide qu’un hachage SHA256 tout en résolvant le même problème.
• Certains voient cette migration comme une évolution positive et suggèrent qu’il deviendrait facile de quitter le service en téléchargeant le fichier SQLite et en créant un frontend HTML uniquement local.
• Une question est posée sur le fait de savoir si Bluesky est toujours accessible uniquement sur invitation.