Bluesky, single-tenant SQLite पर माइग्रेट हुआ

 (github.com/bluesky-social)
2 पॉइंट द्वारा GN⁺ 2023-11-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Bluesky single-tenant SQLite datastore पर माइग्रेट हो गया है.
  • अब हर उपयोगकर्ता के पास अपनी repository और निजी account state को स्टोर करने के लिए अपनी खुद की SQLite फ़ाइल होती है.
  • उपयोगकर्ता databases को hierarchical तरीके से स्टोर किया जाता है.
  • हर repository की repo signing key SQLite फ़ाइल के साथ स्टोर की जाती है.
  • उपयोगकर्ता डेटा के साथ इंटरैक्ट करने वाली abstraction को ActorStore में बदला गया है.
  • ActorStore में read और write के लिए अलग-अलग classes हैं.
  • क्योंकि SQLite concurrent transactions को सपोर्ट नहीं करता, इसलिए ActorStore को write के लिए स्पष्ट "transact" की आवश्यकता होती है.
  • signing keys और databases के लिए LRUCache बनाए रखा जाता है, जो 30k खुले file handles और memory में रखी गई 30k keys की अनुमति देता है.
  • जब कोई database cache से बाहर हो जाता है, तो file handle बंद कर दिया जाता है.
  • service state को मैनेज करने के लिए तीन अलग SQLite databases जोड़े गए हैं: account information, invite codes, refresh tokens आदि के लिए service DB, DID resolution को cache करने के लिए did cache DB, और service की सभी repositories से repository updates को क्रमवार process करने के लिए sequencer DB.
  • ये SQLite फ़ाइलें concurrent reads और streaming replication की अनुमति देने के लिए WAL mode में चलती हैं.
  • उम्मीद है कि PDS deployments Litestream या उसके समान किसी चीज़ के साथ ship किए जाएंगे.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-11-08
Hacker News की राय
  • Bluesky के single-tenant SQLite सेटअप पर माइग्रेट करने से इस approach की चुनौतियों और फायदों पर चर्चा शुरू हुई है।
  • कुछ उपयोगकर्ताओं ने डेटा माइग्रेशन, schema versioning से जुड़ी संभावित समस्याओं और भविष्य में डेटा aggregation की ज़रूरत को लेकर चिंता जताई।
  • अन्य लोगों ने इस दावे पर सवाल उठाया कि SQLite concurrent transactions को support नहीं करता, और कहा कि कुछ विशेष परिस्थितियों में यह support करता है।
  • प्रति उपयोगकर्ता एक database की 1:1 ratio वाली रणनीति दिलचस्प लगती है, और इस पर सवाल उठे कि उपयोगकर्ताओं के बीच aggregate होने वाले डेटा को कैसे संभाला जाएगा।
  • इस setup में यह भी रुचि है कि जब दूसरे उपयोगकर्ता नया content पोस्ट करेंगे तो किसी उपयोगकर्ता के database के updates को कैसे handle किया जाएगा।
  • कुछ उपयोगकर्ताओं ने server SQLite/Litestream अपनाने की सराहना की और इसे tenant databases के लिए cost-effective विकल्प बताया।
  • यह सवाल भी उठा कि SQLite में किस प्रकार का डेटा store किया जाता है और क्या नहीं, और कुछ उपयोगकर्ताओं ने अनुमान लगाया कि उपयोगकर्ताओं के बीच messages SQLite में store नहीं होते।
  • एक सुझाव यह भी है कि दो-अक्षरीय target directory पाने के लिए MD5 hash का उपयोग, SHA256 hash की तुलना में तेज़ होगा और वही समस्या हल कर देगा।
  • कुछ उपयोगकर्ताओं ने इस माइग्रेशन को सकारात्मक कदम माना और सुझाव दिया कि SQLite file डाउनलोड करके और local-only HTML front end बनाकर सेवा को आसानी से छोड़ा जा सकता है।
  • यह भी पूछा गया कि क्या Bluesky अभी भी केवल invite-only है।