พื้นที่จัดเก็บ SQLite แบบหน่วงเวลาเป็นศูนย์ใน Durable Object ทุกตัว

 (simonwillison.net)
2 คะแนน โดย GN⁺ 2024-10-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

  • Zero-latency SQLite storage in every Durable Object

    • Kenton Varda แนะนำแพลตฟอร์ม Durable Object เวอร์ชันถัดไปของ Cloudflare โดยแพลตฟอร์มนี้เพิ่งอัปเกรดจากที่เก็บคีย์/ค่าไปเป็นระบบเชิงสัมพันธ์เต็มรูปแบบบน SQLite
    • สำหรับข้อมูลพื้นฐานที่เป็นประโยชน์เกี่ยวกับ Durable Objects เวอร์ชันแรก สามารถดู Cloudflare’s durable multiplayer moat ของ Paul Butler ได้ ซึ่งได้รับความนิยมในการสร้างแอปพลิเคชันทำงานร่วมกันแบบเรียลไทม์บนพื้นฐาน WebSocket
    • Durable Objects แบบใหม่ที่ใช้ SQLite มีองค์ประกอบด้านการออกแบบระบบกระจายที่น่าสนใจ และเสนอแนวทางที่น่าดึงดูดในการออกแบบแอปพลิเคชันขนาดใหญ่

  • แนวคิดหลักของ Durable Objects

    • Durable Object วางตรรกะของแอปพลิเคชันไว้บนโฮสต์กายภาพเดียวกันกับข้อมูล จึงให้ประสิทธิภาพการอ่านและเขียนที่รวดเร็วมาก
    • อ็อบเจ็กต์หนึ่งตัวทำงานบนเธรดเดียวของเครื่องเดียว จึงมีข้อจำกัดด้าน throughput หากต้องรองรับทราฟฟิกมากขึ้นก็สร้างอ็อบเจ็กต์เพิ่ม เหมาะที่สุดเมื่อแต่ละหน่วยสถานะมีทราฟฟิกต่ำพอที่อ็อบเจ็กต์เดียวจะจัดการได้

  • ตัวอย่างระบบจองเที่ยวบิน

    • เที่ยวบินแต่ละเที่ยวสามารถแมปไปยัง Durable Object เฉพาะที่มีฐานข้อมูล SQLite ของตัวเองได้ โดยแต่ละสายการบินจะมีฐานข้อมูลใหม่ถูกสร้างขึ้นหลายพันรายการต่อวัน
    • แต่ละ DO มีชื่อเฉพาะ และเครือข่ายของ Cloudflare จะทำการ route คำขอไปยังอ็อบเจ็กต์นั้นไม่ว่าจะอยู่ที่ใดในโลก

  • รายละเอียดทางเทคนิค

    • ได้แรงบันดาลใจจาก Litestream โดยแต่ละ DO จะสตรีมลำดับของรายการ WAL ไปยัง object storage อย่างต่อเนื่อง ซึ่งจะถูกรวมเป็นแบตช์ทุก ๆ 16MB หรือทุก ๆ 10 วินาที
    • เพื่อรับประกันความทนทานของข้อมูลภายในช่วงเวลา 10 วินาที การเขียนจะถูกส่งไปยัง replica ห้าชุดในศูนย์ข้อมูลใกล้เคียงทันทีที่ commit และเมื่อมีการยืนยันครบสามชุดจึงจะถือว่าการเขียนสำเร็จ

  • การออกแบบ JavaScript API

    • ออกแบบให้เป็นแบบ blocking แทนที่จะเป็น asynchronous เพื่อให้การทำงานด้าน persistence แบบ single-thread ที่รวดเร็ว
    • มีตัวอย่างที่ตั้งใจแสดงรูปแบบคิวรี N+1 ซึ่ง SQLite สามารถจัดการได้ดี

  • Storage Relay Service

    • เป็นระบบพื้นฐานของ Durable Objects และรองรับระบบ D1 SQLite เดิมของ Cloudflare มานานกว่าหนึ่งปีแล้ว

  • ตำแหน่งที่ Durable Objects ถูกสร้างขึ้น

    • เมื่อ Durable Objects ถูกสร้างแล้วจะไม่ย้ายตำแหน่ง โดยค่าเริ่มต้นจะถูก instantiate ในศูนย์ข้อมูลที่รับคำขอ get() ครั้งแรก
    • หากต้องการสร้าง Durable Objects ในตำแหน่งอื่นด้วยตนเอง สามารถระบุพารามิเตอร์ locationHint แบบไม่บังคับให้กับ get() ได้

  • เว็บไซต์ where.durableobjects.live

    • เป็นเว็บไซต์สำหรับติดตามว่ามีการสร้าง DO ที่ตำแหน่งใดในเครือข่าย Cloudflare

สรุปโดย GN⁺

  • Durable Objects ของ Cloudflare ที่ใช้ SQLite เป็นฐาน เปิดความเป็นไปได้ใหม่ในการออกแบบแอปพลิเคชันขนาดใหญ่ โดยวางข้อมูลและตรรกะของแอปพลิเคชันไว้บนโฮสต์กายภาพเดียวกันเพื่อให้ได้ประสิทธิภาพที่รวดเร็ว
  • ระบบนี้มีประโยชน์อย่างยิ่งกับแอปพลิเคชันทำงานร่วมกันแบบเรียลไทม์ และให้ความยืดหยุ่นในการจัดการหน่วยสถานะที่หลากหลาย
  • Durable Objects สร้าง replica ในหลายศูนย์ข้อมูลเพื่อรับประกันความทนทานของข้อมูล ซึ่งช่วยเพิ่มเสถียรภาพและความน่าเชื่อถือ
  • เทคโนโลยีนี้น่าสนใจสำหรับนักพัฒนาที่สนใจการออกแบบระบบกระจายขนาดใหญ่ โดยระบบที่มีความสามารถคล้ายกัน ได้แก่ Amazon’s DynamoDB และ Google’s Firestore

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

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

 
GN⁺ 2024-10-15
ความคิดเห็นจาก Hacker News

  • API สำหรับการเขียนเป็นแบบ synchronous แต่มีความสามารถรอแบบ asynchronous ที่ซ่อนอยู่ หากการเขียนล้มเหลว runtime จะเปลี่ยน response เป็น HTTP failure ทำให้สามารถ batch การเขียนได้โดยอัตโนมัติและสมมติว่าเขียนสำเร็จ

    • ไม่มี read transaction จึงยากที่จะได้ snapshot ของช่วงเวลาใดช่วงเวลาหนึ่ง
    • แต่ละ runtime instance ถูกจำกัด RAM ไว้ที่ 128MB
    • WebSockets สามารถ hibernate ได้ และในช่วงนั้นจะไม่มีค่าใช้จ่าย ทำให้ client ยังรักษาการเชื่อมต่อไว้ได้แม้ DO จะกำลังหลับอยู่
    • มีความสามารถ RPC อัตโนมัติ จึงสื่อสารกับ DO อื่นหรือ worker ได้เหมือนการเรียก JS ปกติ โดย runtime จะจัดการ serialization และ parsing ให้

  • แต่ละ DO จะสตรีมลำดับของรายการ WAL ไปยัง object storage โดยจะ batch ทุก 16MB หรือทุก 10 วินาที

    • ในระดับทั่วโลก อาจใช้เวลาถึง 10 วินาทีกว่าการเขียนจะถูกอ่านได้
    • จึงยากที่จะมาแทนคลัสเตอร์ฐานข้อมูลที่จัดวางตามภูมิภาค

  • ชอบดีไซน์ของ Durable Object เข้าใจกลไกภายในได้ง่าย

    • DO เหมาะกับการสร้างประสบการณ์เรียลไทม์ที่เร็วและต้นทุนต่ำ แต่ทำงานด้าน analytics และการทำภาพรวมได้ยาก
    • เมื่อเก็บข้อมูลไว้ใน SQLite ก็ต้อง query SQLite instance เล็ก ๆ จำนวนมากแล้วรวมผลลัพธ์เข้าด้วยกัน

  • เข้าใจได้ยากว่า Durable Objects อยู่ตำแหน่งทางกายภาพที่ไหน

    • สงสัยว่าอยู่ในภูมิภาคที่เกิดการเรียก API หรือไม่
    • สงสัยว่า DO จะย้ายไปตำแหน่งอื่นโดยอัตโนมัติได้หรือไม่

  • เทคโนโลยีคลาวด์ใหม่ ๆ เข้าใจได้ยาก

    • แม้จะมีประสบการณ์พัฒนาเว็บมากกว่า 15 ปี แต่ก็รู้สึกว่าเทคโนโลยีลักษณะนี้อาจไม่เหมาะกับตัวเอง

  • สงสัยว่าจะจัดการ schema migration อย่างไร

    • หากฐานข้อมูลมีแยกตาม tenant การใช้การเปลี่ยน schema กับแต่ละ DO น่าจะทำได้ยาก

  • ดีไซน์ของ DO น่าสนใจ แต่คิดว่าเหมาะแค่กับระบบโหลดสูงมากหรือโปรเจกต์ทดลอง

    • ในงานจริงต้องการระบบที่ผ่านการพิสูจน์แล้ว และ DO ยังไม่สุกงอมพอ

  • ประทับใจกับดีไซน์ของ DO คิดว่าวิธีจัดการงานซับซ้อนในสเกลเล็กคล้ายกับโครงสร้างของผลิตภัณฑ์จริง

  • สังเกตว่า CF สนับสนุนให้นักพัฒนาใช้ DO

    • การเชื่อมต่อ WebSocket ของ worker จะ timeout หลัง 30 วินาที และมีการแนะนำให้ใช้ DO

  • สงสัยว่า DO ตรงกับ "model" ในสถาปัตยกรรม MVC หรือไม่

    • สงสัยว่าจะใช้ DO แยกตาม tenant และ query หรือ join ข้าม DO ทั้งหมดได้อย่างไร