Bluesky migriert auf Single-Tenant-SQLite

• Bluesky ist auf einen Single-Tenant-SQLite-Datenspeicher migriert.
• Jetzt hat jeder Nutzer seine eigene SQLite-Datei, in der sein Repository und sein privater Account-Status gespeichert werden.
• Die Nutzerdatenbanken werden hierarchisch gespeichert.
• Der Repository-Signaturschlüssel jedes Repositories wird zusammen mit der SQLite-Datei gespeichert.
• Die Abstraktion für die Interaktion mit Nutzerdaten wurde auf ActorStore umgestellt.
• ActorStore hat unterschiedliche Klassen für Lese- und Schreibzugriffe.
• Da SQLite keine gleichzeitigen Transaktionen unterstützt, benötigt ActorStore für Schreibvorgänge explizite „Transacts“.
• Für Signaturschlüssel und Datenbanken wird ein LRUCache vorgehalten, der 30k offene File-Handles und 30k im Speicher gehaltene Schlüssel erlaubt.
• Fällt eine Datenbank aus dem Cache, wird der File-Handle geschlossen.
• Zur Verwaltung des Service-Status wurden drei separate SQLite-Datenbanken eingeführt: eine Service-DB für Account-Informationen, Einladungscodes, Refresh-Tokens usw., eine DID-Cache-DB zum Caching der DID-Auflösung sowie eine Sequencer-DB, um Repository-Updates aus allen Repositories des Dienstes sequenziell zu verarbeiten.
• Diese SQLite-Dateien laufen im WAL-Modus, um gleichzeitige Lesezugriffe und Streaming-Replikation zu ermöglichen.
• Es wird erwartet, dass PDS-Deployments zusammen mit Litestream oder etwas Ähnlichem ausgeliefert werden.

[GN⁺]

Hacker-News-Kommentare

• Bluesky ist auf ein Single-Tenant-SQLite-Setup umgestiegen, was eine Diskussion über die Herausforderungen und Vorteile dieses Ansatzes ausgelöst hat.
• Einige Nutzer äußern Bedenken hinsichtlich möglicher Probleme bei Datenmigrationen und Schema-Versionen sowie des künftigen Bedarfs an Datenaggregation.
• Andere stellen die Behauptung infrage, dass SQLite keine gleichzeitigen Transaktionen unterstützt, und weisen darauf hin, dass dies unter bestimmten Bedingungen doch möglich ist.
• Die Strategie eines 1:1-Verhältnisses von Nutzer zu Datenbank wirkt interessant, und es wurden Fragen aufgeworfen, wie Daten behandelt werden, die über mehrere Nutzer hinweg aggregiert werden müssen.
• Es besteht auch Interesse daran, wie dieses Setup Aktualisierungen an der Datenbank eines Nutzers verarbeitet, wenn andere Nutzer neue Inhalte veröffentlichen.
• Einige Nutzer loben die Einführung von Server-SQLite/Litestream und bezeichnen dies als kosteneffiziente Wahl für Tenant-Datenbanken.
• Es wurden Fragen dazu gestellt, welche Arten von Daten in SQLite gespeichert werden und welche nicht; einige Nutzer vermuten, dass Nachrichten zwischen Nutzern nicht in SQLite gespeichert werden.
• Es gibt den Vorschlag, statt eines SHA256-Hashes einen MD5-Hash zu verwenden, um Zielverzeichnisse mit zwei Zeichen zu erhalten, da dies schneller wäre und dasselbe Problem lösen würde.
• Einige Nutzer sehen diese Migration als positiven Schritt und schlagen vor, dass man den Dienst einfach verlassen könnte, indem man die SQLite-Datei herunterlädt und ein rein lokales HTML-Frontend erstellt.
• Es gibt eine Frage dazu, ob Bluesky noch immer nur per Einladung zugänglich ist.