Litestream v0.5.0

 (fly.io)
1 คะแนน โดย GN⁺ 2025-10-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Litestream v0.5.0 เป็นอัปเดตที่ช่วยเพิ่ม ความยืดหยุ่นในการกู้คืนของแอปพลิเคชันที่ใช้ SQLite อย่างมาก
  • เพิ่ม ฟอร์แมตไฟล์ LTX แบบใหม่ เพื่อรองรับ การกู้คืนแบบ Point-In-Time Recovery (PITR) ที่มีประสิทธิภาพและการบีบอัดข้อมูล
  • ยกเลิกแนวคิด generation ระหว่างหลายอินสแตนซ์ของ Litestream เพื่อให้การจัดการและการปฏิบัติการง่ายขึ้น
  • รองรับ JetStream และ เปลี่ยนไปใช้ไดรเวอร์ Go SQLite รุ่นใหม่ ทำให้สภาพแวดล้อมด้านการพัฒนาและการผสานรวมสะดวกยิ่งขึ้น
  • ในอนาคตมีแผนเพิ่มฟีเจอร์ที่ทรงพลังยิ่งขึ้น เช่น read replica แบบอิง VFS

ภาพรวมและการอัปเดตสำคัญ

  • Litestream เป็น เครื่องมือสำรองและกู้คืนสำหรับแอปพลิเคชัน SQLite ที่เป็นโอเพนซอร์สและมีจุดเด่นตรงที่สามารถรันได้ทุกที่
  • การกู้คืนจากความล้มเหลวของเซิร์ฟเวอร์ ทำได้ง่าย จึงช่วยรับประกันความปลอดภัยสำหรับการสร้างแอปพลิเคชันแบบ full-stack ที่ใช้ SQLite เป็นฐาน
  • เวอร์ชันล่าสุด (v0.5.0) รองรับ การปรับปรุงความเร็ว และ Point-In-Time Recovery (PITR)

ทิศทางการพัฒนาของ LiteFS และ Litestream

  • โปรเจกต์หลักที่เกี่ยวข้องกับ SQLite ซึ่งพัฒนาโดย Ben Johnson แห่ง Fly.io คือ Litestream และ LiteFS
  • LiteFS มุ่งเน้นการทำ live replication ระดับทรานแซกชันภายในฐานข้อมูล โดยใช้ระบบไฟล์ FUSE
  • แต่ความต้องการของตลาดกลับมุ่งไปที่ Litestream ที่ใช้งานง่ายกว่าในการปฏิบัติการ ทำให้บทเรียนทางเทคนิคที่ได้จาก LiteFS ถูกนำกลับมาปรับใช้กับ Litestream

การนำฟอร์แมตไฟล์ LTX มาใช้

  • เพื่อแก้ข้อจำกัดและความไม่มีประสิทธิภาพของวิธีสำรองข้อมูลแบบ ระดับเพจของ SQLite เดิม จึงมีการนำ LTX (ฟอร์แมตแบบอิงทรานแซกชัน) มาใช้

  • LTX มีความสามารถในการ จัดการช่วงของเพจตามลำดับทรานแซกชัน และ รวมย่อเพจที่ซ้ำกัน (compaction)

    • ตัวอย่าง: สามารถนำไฟล์ LTX หลายไฟล์มาใช้ตามลำดับจากใหม่ไปเก่า โดยสะท้อนเฉพาะเพจที่ซ้ำกันในเวอร์ชันล่าสุด เพื่อกู้คืนสถานะสุดท้ายของฐานข้อมูลได้อย่างรวดเร็ว
    • ผ่านโครงสร้างลำดับชั้นของไฟล์ สามารถรวมไฟล์ LTX ในช่วง 30 วินาที, 5 นาที, 1 ชั่วโมง เพื่อ ลดจำนวนไฟล์ที่ต้องใช้ในการกู้คืนลงอย่างมาก

  • ความเร็วในการกู้คืนข้อมูล ถูกจำกัดเพียงด้วยปริมาณงาน I/O เท่านั้น

การยกเลิกแนวคิด generation

  • Litestream สามารถรันและล้มเหลวได้เหมือน โปรเซส Unix ทั่วไป และเมื่อการทำงานหยุดลงอาจเกิดความไม่สอดคล้องในการซิงก์ข้อมูล
  • ก่อนหน้านี้เพื่อป้องกันการชนกันระหว่างหลายอินสแตนซ์ จึงมีการใช้แนวทางการจัดการที่เรียกว่า generation
  • แต่เมื่อเปลี่ยนมาใช้ LTX ก็สามารถ กู้คืนโดยอิง Transaction ID ได้ ทำให้ไม่จำเป็นต้องจัดการ generation ที่ซับซ้อนอีกต่อไป

การอัปเกรดเป็น Litestream v0.5.0

  • เนื่องจากฟอร์แมตไฟล์มีการเปลี่ยนแปลงมาก จึงไม่สามารถกู้คืนโดยตรงจาก WAL segment ของ v0.3.x ได้
  • การอัปเกรดทำได้ง่าย โดยใช้วิธี รันเวอร์ชันใหม่ → สร้างไฟล์ LTX แบบใหม่ และไฟล์ WAL เดิมก็ยังถูกเก็บไว้ตามเดิม
  • ยังคงความเข้ากันได้ของไฟล์คอนฟิก
  • การเปลี่ยนแปลงสำคัญ: ตอนนี้ อนุญาตให้มีปลายทางการทำ replication ได้เพียงหนึ่งรายการต่อหนึ่งฐานข้อมูล ซึ่งเป็นการตัดสินใจเพื่อให้ง่ายต่อการพัฒนาและหลีกเลี่ยงการชนกันของ replication
  • คำสั่งยังคงเหมือนเดิม แต่เปลี่ยนไปใช้วิธีอ้างอิงตาม Transaction ID (TXID)

การปรับปรุงอื่น ๆ

  • ไลบรารีฟอร์แมตไฟล์ LTX เพิ่ม การบีบอัดระดับเพจ และ ดัชนี ทำให้สามารถเข้าถึงเพจแบบเลือกเฉพาะภายในไฟล์ขนาดใหญ่และขยายฟังก์ชันได้
  • ในอนาคตจะสามารถเพิ่มฟีเจอร์อย่าง การคิวรีข้อมูล ณ ช่วงเวลาที่กำหนด ได้
  • ถอดการพึ่งพา CGO และเปลี่ยน Go SQLite driver ไปใช้ modernc.org/sqlite ทำให้ ได้ประโยชน์ด้านการ build อัตโนมัติและสภาพแวดล้อม cross-compilation
  • มีการเพิ่มชนิด replica ที่รองรับ JetStream รวมถึงอัปเดตไคลเอนต์สำหรับ S3/Google Storage/Azure Blob Storage และรองรับ S3 API เวอร์ชันใหม่

แผนในอนาคต

  • กำลังพัฒนาฟีเจอร์ Litestream VFS สำหรับสภาพแวดล้อม read replica (target)
  • ฟีเจอร์นี้จะทำให้สามารถ อ่านเฉพาะเพจที่ต้องใช้จาก S3 ได้ทันที เพื่อสร้าง replica ได้อย่างรวดเร็ว
  • ตอนนี้มีโปรโตไทป์แล้ว และกำลังจะเปิดเผยต่อสาธารณะ

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

  • Litestream VFS
    12 คะแนน · 1 ความคิดเห็น · 2025-12-13

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

 
GN⁺ 2025-10-04
ความคิดเห็นบน Hacker News

  • ประสบการณ์ฝั่งนักพัฒนาตอน deploy แอป SQLite บน Fly.io ยังน่าผิดหวังอยู่พอสมควร พยายามรันแอป Rails โปรดักชันอยู่นานหลายชั่วโมงแต่เจอปัญหาหลากหลายทั้งการ initial database, migration, สถานะที่เขียนได้ ฯลฯ ต้นตอจริง ๆ คือ eager loading ของ gem ที่ตัวเองทำขึ้นมา แต่เพราะมี runner ซ้อนกันหลายชั้นเลยวินิจฉัยได้ยาก อยากให้ปรับปรุง DX มากกว่านี้ แต่ก็คิดว่าสำหรับ Fly.io คงไม่ใช่เรื่องลำดับความสำคัญนัก เพราะลูกค้ารายใหญ่คงไม่ได้ใช้ workload แบบนี้ เลยสงสัยว่าคนที่เคย deploy แอป SQLite ในโปรดักชันใช้โฮสต์ไหนกันบ้าง

    • ปีที่แล้วเพิ่งตั้งค่าแอป Rails 8 ใหม่บน Fly โดยใช้ PG เป็นที่เก็บข้อมูลหลัก แต่ฐานข้อมูล solid stack รองใช้ SQLite มีปัญหาเล็กน้อยฝั่ง Rails เกี่ยวกับ solid queue migration แต่ไม่ใช่ปัญหาฝั่ง Fly ตอนนี้กำลังพิจารณาย้าย PG หลักมาเป็น SQLite ด้วย และปัจจุบันก็ใช้งาน SQLite ได้ดีในบางส่วนแล้ว

    • ฉันใช้ SQLite กับแอปคอนโซลในโปรดักชัน โดยวาง DB ไว้บนไฟล์แชร์ไดรฟ์

  • ดีใจมากที่ Fly กลับมาพัฒนา Litestream ต่ออีกครั้งหลังหยุดไป 2 ปี ฉันใช้ Litestream แทบทุกครั้งและพอใจมาก ค่าใช้งานจริงถูกกว่าสโลแกนโฆษณาที่ว่า “ไม่กี่เพนนีต่อวัน” มาก ตอนใช้ Litestream replicate ไป S3 กับแอปโปรดักชันจริง ค่าใช้จ่ายต่อเดือนจริงอยู่ที่ราว 2–3 เซนต์ (0.02–0.03 ดอลลาร์) แชร์ลิงก์ ประสบการณ์ที่เกี่ยวข้อง

  • น่าสนใจที่ Litestream กำลังจะรองรับปลายทางแบบ s3-compatible ทั้งหมด ตอนนี้ฉันยังใช้โซลูชัน SFTP อยู่ เพราะไม่อยากใช้บริการ cloud object storage ที่ฮาร์ดโค้ดมา ขอบคุณทีมพัฒนาด้วย แชร์ ลิงก์ PR และ ลิงก์ไกด์

  • อยากลองใช้ Litestream เร็ว ๆ นี้ เลยสงสัยว่ามี benchmark หรือเดโมเรื่องเวลา restore จริงไหม แต่ก่อนเคยทำ S3 backup เอง ตอนนั้น restore 1,000 แถวด้วย Litestream ใช้เวลาตั้ง 20 นาที รู้สึกว่าไม่ค่อย optimized เท่าไร เลยอยากรู้ว่าตอนนี้ความเร็วในการ restore ดีขึ้นแค่ไหนแล้ว

  • สงสัยว่า Litestream มีข้อได้เปรียบอะไรเมื่อเทียบกับ sqlite.org/rsync

    • จุดต่างของ Litestream คือไม่ต้องมี “เซิร์ฟเวอร์” อยู่ปลายทางอีกฝั่ง แค่มี object storage ก็พอ ซึ่งอาจถูกกว่าด้านต้นทุน

    • Litestream ทำ Point In Time Recovery ได้ ไม่ได้มีแค่ replica ณ เวลาปัจจุบัน แต่สามารถ restore กลับไปจาก snapshot ในช่วงเวลาใดก็ได้

  • มีเรื่องน่าสนใจเกี่ยวกับ LiteFS กับ Litestream คือ “เสียงตอบรับจากตลาดคือคำตอบ! ผู้ใช้ชอบ Litestream มากกว่า” พูดตรง ๆ ว่า Litestream ใช้งานง่ายกว่าและเข้าใจง่ายกว่า เลยกลับมาโฟกัสทางนี้อีกครั้ง

    • ฉันก็คิดว่าสมเหตุสมผล LiteFS ต้องรันและ mount custom filesystem ที่อิงกับ FUSE แต่ Litestream แค่มี Go binary ตัวเดียวที่ชี้ไปยังไฟล์ SQLite DB และไฟล์ WAL ที่เกี่ยวข้องก็พอ

  • แชร์ลิงก์เกี่ยวกับ Litestream Revamped และกระทู้พูดคุยบน Hacker News
    บล็อก
    กระทู้ HN

  • เรากำลัง deploy แอปภายในองค์กรไปยัง remote fleet ภายนอกที่มีอินเทอร์เน็ตไม่เสถียร ทำให้สร้างระบบเก็บข้อมูลได้ยาก เลยสงสัยว่า Litestream จัดการ backup ในสภาพแวดล้อมที่ไม่เสถียรแบบนี้อย่างไร และสามารถรวมหลาย backup เข้าเป็น DB กลางเพื่อ query ได้ไหม

  • ขอเตือนเล็กน้อย ครั้งหนึ่งเคยย้ายแอปธุรกิจแบบ legacy ไป Azure โดยมีโครงสร้างที่รัน local MSSQL server คู่กับแอปด้วย คล้ายกับแพตเทิร์นของ Litestream แอปถูกพัฒนาโดยสมมติว่าเข้าถึงแบบ local ได้เสมอ (latency ต่ำกว่า 1ms) เลยมีปัญหา N+1 query หนักมากอยู่ทุกที่ ผลคือแทบเป็นไปไม่ได้ที่จะเปลี่ยนไปใช้อีกสถาปัตยกรรมหนึ่ง ถ้ากังวลว่าจะใช้โฮสต์แบบนี้แล้วไปชนเพดานการสเกลในภายหลัง ก็ไม่ค่อยแนะนำ แต่ในทางปฏิบัติ เครื่องเดียวก็ไปได้ไกลมาก อาจไม่ใช่ปัญหาใหญ่ก็ได้

    • ทุกวันนี้ single instance รองรับ RAM มากกว่า 20TB และหลายร้อยคอร์ได้แล้ว ฉันคิดว่าตัวเลือกนี้ยังแข่งขันได้มาก และถ้าจับคู่กับ cell architecture แยกตามผู้ใช้/tenant ก็อาจยิ่งมีประสิทธิภาพ

    • ฉันก็เคยทำงานกับผลิตภัณฑ์ที่แอปเซิร์ฟเวอร์กับฐานข้อมูลอยู่ใน rack เดียวกัน โครงสร้าง latency ต่ำคล้ายกัน พอผลิตภัณฑ์นั้นประสบความสำเร็จ จำนวน N+1 query ก็พุ่งไปถึงหลักพัน ทำให้ 1ms กลายเป็น 500ms+ ได้ไม่ยาก ทุกสองเดือนต้องกลับไปไล่หาคอขวดใน NewRelic แล้วแก้กันใหม่ เป็นแอป Rails เลยเกิดปัญหา N+1 ได้ง่าย แต่ก็แก้ค่อนข้างง่ายเหมือนกัน

    • แนวปฏิบัติด้าน query ที่ไม่ดี สุดท้ายแล้วต้องสร้างปัญหาเข้าสักวันอยู่ดี ไม่น่าจะนับเป็นข้อเสียของแนวทางนี้โดยตรง

    • จริง ๆ แล้วมองว่า trade-off ไม่ได้ใหญ่ขนาดนั้น เพราะสุดท้ายการใช้บริการแบบนี้ก็แค่ทำให้เห็นชัดขึ้นว่าโค้ดของตัวเองมีปัญหาแค่ไหน เป็นปัญหาของโค้ด ไม่ใช่ของบริการ

    • ถามว่า N+1 คืออะไร

  • ชอบ Litestream มาก ใช้งานง่ายและไม่เคยเจอ crash เลย แนะนำให้ใช้เป็นบริการ systemd unit ไม่ได้ใช้แค่เป็นเครื่องมือ backup แต่ใช้ทำ database mirroring ด้วย และก็กำลังรอฟีเจอร์ read-replica ที่จะออกมาในอนาคต