Bluesky ย้ายไปใช้ SQLite แบบ single-tenant

 (github.com/bluesky-social)
2 คะแนน โดย GN⁺ 2023-11-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Bluesky ได้ย้ายไปใช้ดาต้าสโตร์ SQLite แบบ single-tenant
  • ตอนนี้ผู้ใช้แต่ละคนจะมีไฟล์ SQLite ของตัวเองสำหรับเก็บรีโพซิทอรีและสถานะบัญชีส่วนตัว
  • ฐานข้อมูลผู้ใช้ถูกจัดเก็บแบบลำดับชั้น
  • คีย์ลงนามรีโพซิทอรีของแต่ละรีโพซิทอรีจะถูกเก็บไว้พร้อมกับไฟล์ SQLite
  • abstraction ที่ใช้โต้ตอบกับข้อมูลผู้ใช้ถูกเปลี่ยนมาเป็น ActorStore
  • ActorStore มีคลาสแยกกันสำหรับการอ่านและการเขียน
  • เนื่องจาก SQLite ไม่รองรับทรานแซกชันพร้อมกัน ActorStore จึงต้องการ "transact" ที่ชัดเจนสำหรับการเขียน
  • มีการคง LRUCache สำหรับคีย์ลงนามและฐานข้อมูลไว้ โดยรองรับ file handle ที่เปิดอยู่ 30k รายการ และคีย์ที่เก็บไว้ในหน่วยความจำ 30k รายการ
  • เมื่อฐานข้อมูลหลุดออกจากแคช file handle จะถูกปิด
  • มีการเพิ่มฐานข้อมูล SQLite แยก 3 ตัวเพื่อจัดการสถานะของบริการ: service DB สำหรับข้อมูลบัญชี invite code refresh token และอื่น ๆ, did cache DB สำหรับแคชการ resolve DID, และ sequencer DB สำหรับประมวลผลการอัปเดตรีโพซิทอรีตามลำดับจากทุกรีโพซิทอรีของบริการ
  • ไฟล์ SQLite เหล่านี้ทำงานในโหมด WAL เพื่อให้รองรับการอ่านพร้อมกันและการทำ streaming replication
  • คาดว่าการ deploy PDS จะมาพร้อมกับ Litestream หรือสิ่งที่คล้ายกัน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-11-08
ความเห็นจาก Hacker News
  • Bluesky ย้ายไปใช้การตั้งค่า SQLite แบบ single-tenant ทำให้เกิดการถกเถียงเกี่ยวกับความท้าทายและข้อดีของแนวทางนี้
  • ผู้ใช้บางส่วนแสดงความกังวลเกี่ยวกับปัญหาที่อาจเกิดขึ้นจากการย้ายข้อมูล เวอร์ชันของสคีมา และความจำเป็นในการรวมข้อมูลในอนาคต
  • คนอื่น ๆ ตั้งข้อสงสัยต่อคำกล่าวอ้างที่ว่า SQLite ไม่รองรับธุรกรรมพร้อมกัน โดยชี้ว่าภายใต้เงื่อนไขบางอย่างนั้นรองรับได้
  • กลยุทธ์อัตราส่วนผู้ใช้ต่อฐานข้อมูลแบบ 1:1 ดูน่าสนใจ และมีคำถามว่าข้อมูลที่ต้องรวมข้ามผู้ใช้จะถูกจัดการอย่างไร
  • ยังมีความสนใจด้วยว่าการตั้งค่านี้จะจัดการการอัปเดตฐานข้อมูลของผู้ใช้อย่างไรเมื่อผู้ใช้อื่นโพสต์เนื้อหาใหม่
  • ผู้ใช้บางส่วนชื่นชมการนำ server SQLite/Litestream มาใช้ โดยมองว่าเป็นตัวเลือกที่คุ้มค่าสำหรับฐานข้อมูลของผู้เช่า
  • มีคำถามว่าข้อมูลประเภทใดถูกเก็บไว้ใน SQLite และประเภทใดไม่ถูกเก็บ โดยผู้ใช้บางคนคาดว่าข้อความระหว่างผู้ใช้จะไม่ถูกเก็บใน SQLite
  • มีข้อเสนอว่าการใช้แฮช MD5 เพื่อให้ได้ไดเรกทอรีปลายทางสองตัวอักษรจะเร็วกว่าและแก้ปัญหาเดียวกันได้เช่นเดียวกับการใช้แฮช SHA256
  • ผู้ใช้บางส่วนมองว่าการย้ายครั้งนี้เป็นก้าวที่ดี และเสนอว่าน่าจะออกจากบริการได้อย่างง่ายดายด้วยการดาวน์โหลดไฟล์ SQLite และสร้างฟรอนต์เอนด์ HTML แบบใช้เฉพาะในเครื่อง
  • มีคำถามว่า Bluesky ยังเป็นแบบเชิญเท่านั้นอยู่หรือไม่