สร้าง Postgres ด้วย Rust — แนวทางที่ใช้ LLVM ของฐานข้อมูล

• Turso ขยายโครงสร้างแบบ LLVM ของฐานข้อมูล โดยเชื่อมต่อ ฟรอนต์เอนด์ที่เข้ากันได้กับ Postgres เข้ากับคอร์ฐานข้อมูลที่พัฒนาด้วย Rust ทำให้เอนจินประมวลผลเดียวรองรับภาษาฐานข้อมูลได้หลายแบบ
• แปลง Postgres SQL เป็น AST กลางแล้วคอมไพล์เป็น VDBE bytecode พร้อมผนวก pgmicro ที่ใช้พิสูจน์ความเป็นไปได้เข้ากับโค้ดหลักเพื่อใช้เป็นฐานการพัฒนาอย่างเป็นทางการ
• คอร์เดิมรองรับความเข้ากันได้กับไฟล์ SQLite, การเขียนพร้อมกันแบบ MVCC, การทำงานแบบ asynchronous, ระบบชนิดข้อมูลที่หลากหลาย และ materialized view ที่อัปเดตอัตโนมัติ โดยตรวจสอบความน่าเชื่อถือด้วยเทคนิคการทดสอบหลายรูปแบบ
• ออกแบบมาให้รันแบบ embedded หรือไฟล์เดี่ยวได้ทั้งบนเบราว์เซอร์ มือถือ และอุปกรณ์หลากหลายประเภท ขณะเดียวกันก็เปิดให้แอปเดิม, ORM และ psql เชื่อมต่อผ่าน Postgres wire protocol ได้
• แทนที่จะมุ่งสู่ความเข้ากันได้ 100% ระบบนี้เน้นฟีเจอร์แกนหลักที่ใช้งานแพร่หลายเพื่อให้แอปเดิมส่วนใหญ่ทำงานได้โดยไม่ต้องแก้ไข พร้อมพิจารณาใช้ WASM และชั้นความเข้ากันได้ กับส่วนขยายและ PL/pgSQL และพัฒนาภายใต้ไลเซนส์ MIT

---

เหตุผลที่สร้าง Postgres บน Turso

• Turso คือคอร์ฐานข้อมูลสมัยใหม่ที่เขียนด้วย Rust และกำลังสร้างฐานข้อมูลที่เข้ากันได้กับ Postgres บนคอร์นี้ขึ้นมาใหม่ตั้งแต่ต้น
• เป้าหมายระยะยาวไม่ใช่แค่ย้าย Postgres เดิมมาเป็น Rust แต่คือการสร้างฐานข้อมูลใหม่ที่มี สถาปัตยกรรมสมัยใหม่
  • ไม่ใช้โปรเซสแยกต่อหนึ่งการเชื่อมต่อ
  • รันแบบ embedded ภายในเบราว์เซอร์ได้
  • จัดการฐานข้อมูลหนึ่งชุดในรูปไฟล์เดี่ยวได้
  • materialized view อัปเดตอัตโนมัติโดยไม่ต้องมีงานแยก
• แนวทางคือสร้าง โครงสร้างคอมไพล์ที่สลับฟรอนต์เอนด์ได้ โดยเชื่อมหลายฟรอนต์เอนด์เข้ากับคอร์ที่เสถียรเพียงตัวเดียว
  • SQLite คือฟรอนต์เอนด์ตัวแรก
  • Postgres คือฟรอนต์เอนด์ทางการตัวถัดไป
  • ในอนาคตอาจเพิ่มฟรอนต์เอนด์อย่าง MySQL, Redis หรือฐานข้อมูลเชิงทดลองได้
• ผลลัพธ์ปัจจุบันยังไม่ใช่ผลิตภัณฑ์ที่เสร็จสมบูรณ์ แต่เป็นขั้น ฐานการพัฒนาที่สามารถรันได้จริง

จากการเขียน SQLite ใหม่ สู่คอร์ฐานข้อมูลร่วม

• เดิมที Turso เป็นโครงการเขียน SQLite ใหม่ทั้งหมดด้วย Rust และสถาปัตยกรรมสมัยใหม่ พร้อมคง ความเข้ากันได้ระดับไฟล์ ที่เปิดและสร้างไฟล์ SQLite ได้
• และมีความสามารถที่ก้าวเลยขอบเขตของ SQLite ไปแล้ว
  • รองรับการเขียนพร้อมกันด้วย MVCC แบบเดียวกับ Postgres
  • มีระบบชนิดข้อมูลที่หลากหลายคล้าย Postgres
  • ทำงานแบบ asynchronous เต็มรูปแบบ จึงเหมาะทั้งกับ native execution และสภาพแวดล้อมจำกัดอย่างเบราว์เซอร์
  • materialized view อัปเดตอัตโนมัติแบบเรียลไทม์ จึงไม่ต้องใช้ cron สำหรับ REFRESH MATERIALIZED VIEW หรือชุด trigger ร่วมกัน
• ต่อให้เพิ่มฟรอนต์เอนด์ Postgres เข้ามา เป้าหมายเดิมของ Turso และ SQLite ก็ไม่เปลี่ยน
  • ยังคงมุ่งสู่ความเข้ากันได้กับ SQLite อย่างสมบูรณ์และการขยายฟีเจอร์สำหรับ workload ในอนาคต
  • และยังใช้ชุดทดสอบของ Postgres ช่วยพัฒนาฟีเจอร์ที่จำเป็นได้ ทำให้พัฒนาได้เร็วขึ้น

ความน่าเชื่อถือและโมเดลการมีส่วนร่วมแบบเปิด

• เพื่อจำลองความแข็งแกร่งของ SQLite โครงการนี้มองว่า ความน่าเชื่อถือคือฟีเจอร์ของผลิตภัณฑ์
  • ใช้ deterministic simulation test
  • ทำการทดสอบด้วย Antithesis
  • ใช้ Oracle test, fuzzing และเทคนิคเชิงรูปนัยควบคู่กัน
• ปัจจุบัน Turso มีผู้มีส่วนร่วมมากกว่า 260 คน และดำเนินโมเดล Open Contribution ที่เปิดให้คนนอกมีส่วนร่วมกับทิศทางโครงการได้
• โครงการมุ่งสู่สภาพแวดล้อมแบบ Linux kernel ที่ให้ความสำคัญกับโค้ดและมาตรฐานคุณภาพสูง โดยผู้ร่วมพัฒนาที่ทำงานต่อเนื่องจะมีส่วนร่วมในการตัดสินใจของโครงการด้วย
• ยอมรับ contribution ที่สร้างด้วย AI เช่นกัน แต่ต้องมีคุณภาพเพียงพอ และมนุษย์ต้องตรวจโค้ดอย่างละเอียดพร้อมเข้าใจสถาปัตยกรรม

VDBE virtual machine ภายใน SQLite

• SQLite ไม่ได้เป็นชั้นเดียวที่รัน SQL โดยตรง แต่มีโครงสร้าง virtual machine ที่คอมไพล์ SQL แบบภาษาถิ่นของ SQLite เป็น VDBE bytecode แล้วจึงประมวลผล
• VDBE ไม่ใช่ bytecode ทั่วไปแบบ JVM, .NET หรือ WASM แต่เป็นชุดคำสั่งระดับสูงที่เฉพาะกับฐานข้อมูล เช่น ค้นหารายการใน B-tree
• แม้ภาษาของ bytecode นี้จะไม่มีสเปกสาธารณะหรืออินเทอร์เฟซแบบโมดูลาร์ แต่มีอยู่จริงภายใน SQLite และ Turso ก็ใช้การออกแบบเดียวกัน
• เพื่อพิสูจน์ความทั่วไปของ Turso VDBE ทีมได้ใช้ C-to-VDBE compiler ขนาดเล็กแปลง Doom
  • คอมไพล์ Turso engine จริงเป็น WASM แล้วรัน VDBE bytecode ของ Doom ในแท็บเบราว์เซอร์
  • รัน Doom ด้วยวิธีเดียวกับที่ฐานข้อมูลประมวลผล SELECT
  • ประมวลผลแต่ละเฟรมเป็นหนึ่งแถวผลลัพธ์
  • แสดงพื้นที่หน่วยความจำเป็น blob ที่อ่านและเขียนได้
  • ดู implementation ได้ที่ repository turso-vdbe-doom-example

โครงสร้างคอมไพล์ของฟรอนต์เอนด์ Postgres

• ความพยายามเดิมในการเชื่อม SQLite กับ Postgres มักพึ่ง การแปลชั้น query ที่แปลง query ของ Postgres ให้เป็น query ของ SQLite เพราะโครงสร้างแบบ monolithic ของ SQLite ทำให้แนวทางอื่นทำได้ยาก และความต่างของพฤติกรรมภายนอกระหว่างสองฐานข้อมูลก็ทำให้เกิด impedance mismatch สูง
• ภายในแล้ว ฐานข้อมูล SQL ส่วนใหญ่ทำงานพื้นฐานคล้ายกันโดยยึด B-tree และชุดดัชนีเป็นแกน
• โครงสร้างการจัดเก็บของ Postgres และ SQLite มีความต่างชัดเจน
  • Postgres เก็บแถวใน heap file และใช้ B-tree index แยกต่างหาก รวมถึง tuple version, TID และ vacuum
  • SQLite จัดกลุ่มข้อมูลไว้ใน B-tree
• ความต่างเหล่านี้ส่วนใหญ่เกิดจากวิธีจัดวางไบต์ลงบนดิสก์ และชุดปฏิบัติการที่ Postgres ต้องการนั้นสามารถแทนด้วย VDBE เดิม หรือรองรับได้ด้วยการขยายคำสั่ง VDBE
• ในโครงสร้างใหม่นี้ สามารถสลับฟรอนต์เอนด์ของฐานข้อมูลได้
  1. แปลงภาษา Postgres เป็น AST กลาง
  2. คอมไพล์ AST เป็น bytecode ของ Turso
  3. ให้คอร์ร่วมของ Turso ประมวลผล bytecode
• การทดลองแรกเพื่อพิสูจน์ความเป็นไปได้ทำผ่าน pgmicro และภายหลังได้รวมผลลัพธ์เข้ากับโค้ดหลักของ Turso เพื่อเปลี่ยนเป็นโครงการทางการ

รูปแบบการรันและกรณีใช้งาน

• เป้าหมายคือส่งมอบ SQL ของ Postgres และพฤติกรรมฐานข้อมูลเดียวกันในหลายรูปแบบโดยไม่ต้องมีเซิร์ฟเวอร์
  • รันฐานข้อมูลที่เข้ากันได้กับ Postgres จริงในแท็บเบราว์เซอร์
  • ให้เอเจนต์สร้างฐานข้อมูลใหม่สำหรับผู้ใช้แต่ละคน และจัดการแต่ละชุดเป็นไฟล์เดียว
  • ให้แอปแบบ local-first ดาวน์โหลดข้อมูล Postgres มาเป็นไฟล์เดี่ยวแล้วซิงก์กลับภายหลัง
  • รันแบบ embedded เหมือน SQLite บนมือถือและอุปกรณ์หลากหลายประเภท
• มีแผนรองรับความสามารถในการซิงก์ฐานข้อมูล Turso เดิมไปยังไฟล์ภายในเครื่องใน Turso/Postgres ด้วย
• ไม่ได้มีแค่การรันแบบ embedded และไฟล์เดี่ยว แต่รวมถึง wire protocol และการทำเซิร์ฟเวอร์ ด้วย จึงเชื่อมต่อกับแอปเดิม, ORM และ psql ได้
• ในระยะใกล้ ฟรอนต์เอนด์ทางการที่ทีม Turso จะพัฒนาเองคือ SQLite และ Postgres ส่วนฟรอนต์เอนด์อื่นจะเปิดโครงสร้างไว้ให้ผู้ร่วมพัฒนาภายนอกสร้างได้

วิธีรันตอนนี้และการมีส่วนร่วม

• ยังไม่มีแพ็กเกจที่ปล่อยแจก แต่สามารถ build และรันจากซอร์สได้โดยตรง

  cd postgres/cli && cargo run
  

• ฟรอนต์เอนด์ Postgres ไม่ได้พัฒนาใน repository แยก แต่ถูกพัฒนาเป็นฟรอนต์เอนด์ทางการภายในโค้ดทรีของ Turso ตั้งแต่วันแรก
• การพัฒนาและการมีส่วนร่วมทำผ่าน Turso GitHub repository

เป้าหมายและขอบเขตของความเข้ากันได้

• เนื่องจาก Postgres ซับซ้อนกว่า SQLite มาก โครงการนี้จึงไม่ตั้ง ความเข้ากันได้ 100% เป็นเป้าหมายบังคับ
• แต่จะเน้นรองรับฟีเจอร์หลักและฟีเจอร์ที่ใช้งานแพร่หลายให้เพียงพอ เพื่อให้ผู้ใช้ส่วนใหญ่รันแอปได้โดยไม่ต้องแก้ไข
• เมื่อฟีเจอร์สมัยใหม่ขัดกับความเข้ากันได้แบบ 1:1 จะพิจารณาเป็นรายฟีเจอร์
  • materialized view ของ Turso ใช้วิธีอัปเดตอัตโนมัติแบบเรียลไทม์
  • ยังไม่แน่ชัดว่าจะต้องแยกทำวิธีเดิมที่ไม่อัปเดตอัตโนมัติเพื่อความเข้ากันได้เต็มรูปแบบหรือไม่
• เมื่อขอบเขตฟีเจอร์เพิ่มขึ้น Turso/Postgres อาจใกล้เคียงกับ ฐานข้อมูลที่มีเอกลักษณ์ของตัวเอง มากกว่าจะเป็นเพียงสำเนาของ Postgres

การใช้ AI และความเร็วในการพัฒนา

• โครงการใช้เครื่องมือ AI อย่างจริงจัง แต่ไม่ละเว้น การตรวจโค้ดและความเข้าใจสถาปัตยกรรม
• มองว่าในองค์ประกอบสำคัญอย่างฐานข้อมูล เครื่องมือ AI ยังไม่ถึงระดับที่จะรับผิดชอบการตรวจสอบแทนได้
• ความเร็วต่อหนึ่งคอมมิตอาจช้ากว่าวิธีรัน Fable ตลอด 24 ชั่วโมง แต่โครงการเริ่มต้นจากคอร์ฐานข้อมูลที่ใช้งานได้จริงและผ่านการทดสอบอย่างกว้างขวางแล้ว
• แทนที่จะเปลี่ยนเร็วแล้วทำระบบพัง โครงการเลือกแนวทาง ทำให้ถูกต้องแม้จะช้ากว่า
• การทำฟีเจอร์ทั้งหมดให้เสร็จต้องใช้เวลา และบางฟีเจอร์อาจต้องผ่านกระบวนการพัฒนายาวนานจนกว่าสถาปัตยกรรมที่เหมาะสมจะลงตัว

PL/pgSQL และส่วนขยาย

• PL/pgSQL ไม่ใช่องค์ประกอบที่ทำไม่ได้เพราะมันเป็นภาษาเชิงกระบวนการ แต่แทนที่จะเขียนใหม่แบบตรงตัว มีแนวโน้มว่าจะจัดทำ ภาษาเชิงกระบวนการแยกต่างหากพร้อมชั้นความเข้ากันได้ มากกว่า
• มี proof of concept สำหรับการโหลดส่วนขยายบางประเภทของ Postgres ผ่านคอนเทนเนอร์ WASM แล้ว
  • ส่วนขยายที่ใช้เฉพาะสัญลักษณ์ที่คอนเทนเนอร์ WASM จัดให้ สามารถโหลดได้ตามต้องการ
  • มีต้นทุนด้านประสิทธิภาพจากการรัน WASM
  • และยังไม่ใช่วิธีที่ยืนยันเป็นดีไซน์สุดท้าย
• โครงการมองว่าระบบส่วนขยายที่เปิดให้รันโค้ดใดก็ได้โดยไม่มีข้อจำกัดไม่ใช่แนวทางที่พึงประสงค์
• แม้บางส่วนขยายอาจไม่สามารถรองรับได้ แต่ส่วนขยายจำนวนมากน่าจะโหลดได้หากคอมไพล์เป็น WASM

กำหนดการโดยประมาณและกลยุทธ์โอเพนซอร์ส

• แทนที่จะสร้างฐานข้อมูลใหม่ทั้งหมดตั้งแต่ต้น โครงการเริ่มจากคอร์ที่ทำงานได้จริง ผ่านการทดสอบแล้ว และแชร์โครงสร้างภายในกับ Postgres อยู่มากพอสมควร
• แม้การทำฟีเจอร์ทั้งหมดของ Postgres อาจใช้เวลานาน แต่คาดว่าสามารถส่งมอบ ชุดย่อยของฟีเจอร์ที่ใหญ่พอและใช้งานได้จริง ได้ภายในไม่กี่เดือน
• นักพัฒนาหลักสองคนมีอายุราว 44 ปีในตอนนี้ และยังพัฒนาได้อีกอย่างน้อย 20 ปี จึงไม่เร่งให้ต้องทำฟีเจอร์ทั้งหมดให้เสร็จโดยเร็ว
• ความเร็วและขอบเขตการพัฒนาจริงขึ้นอยู่กับการมีส่วนร่วมจากชุมชนอย่างมาก
  • ตอนรองรับหลายโปรเซสสำหรับภาษาถิ่น SQLite ทีมไม่มีเครื่อง Windows จึงเว้น implementation ของ Windows ไว้
  • ต่อมานักพัฒนาภายนอกคนหนึ่งที่ใช้งาน Turso อย่างหนักเกิดความสนใจและทำ Windows support เสร็จภายในหนึ่งสัปดาห์
• ฟรอนต์เอนด์เชิงทดลองอาจพัฒนานอกโค้ดทรีได้ แต่ฟรอนต์เอนด์ Postgres ทางการจะใช้ ไลเซนส์ MIT แบบเดียวกับ Turso เดิม

[GN⁺]

ความคิดเห็นจาก Lobste.rs

• ดูเหมือนว่าฐานข้อมูล SQL แทบทั้งหมดจะคอมไพล์คิวรีไปยัง เครื่องเสมือน (VM) อยู่แล้ว
  ในแง่นี้ การยก SQLite ขึ้นมาเป็นกรณีพิเศษก็ดูแปลกอยู่พอสมควร

  • ฐานข้อมูลส่วนใหญ่จะสร้าง ต้นไม้ของการดำเนินการเชิงสัมพันธ์ และมีอินเทอร์เฟซแบบ push หรือ pull สำหรับแต่ละการดำเนินการ
    ตรงกันข้าม SQLite จะคอมไพล์คิวรีเป็น ไบต์โค้ดเชิงคำสั่ง ที่มีตัวแปรและลูป

• ในฐานะผู้พัฒนา pgwire รู้สึกยินดีที่ Turso นำ pgwire กลับมาใช้อีกครั้งกับ ฐานข้อมูลที่เข้ากันได้กับ PostgreSQL

• สงสัยว่าทำไมบริษัทถึงตัดสินใจว่าจำเป็นต้อง เปลี่ยนทิศทาง

• สงสัยว่าพวกเขาทำ การนำ SQLite มาเขียนใหม่ เสร็จแล้ว หรือยกเลิกไปแล้ว
  https://lobste.rs/s/rxdnnq/introducing_first_alpha_turso_next

  • https://github.com/tursodatabase/turso/…
    ดูเหมือนว่ายังคงรักษาเป้าหมายนั้นไว้ ขณะเดียวกันก็เพิ่ม ฟรอนต์เอนด์ อื่นเข้ามาระหว่างทาง

• เป็นบทความที่น่าสนใจมาก และน่าอายที่มันถูก รายงานอย่างไม่เป็นธรรม

  • นี่คือ เทคโนโลยีที่อาจสร้างแรงกระเพื่อมครั้งใหญ่ ถึงขั้นเปลี่ยนเกมสำหรับโปรเจกต์งานของผมได้สักวัน
    มันไม่ใช่ “off-topic” หรือ “spam” เลยแม้แต่น้อย จึงไม่เข้าใจเลยว่าทำไมถึงถูกรายงานแบบนั้น
    หรือเพราะมีขีดอยู่ตัวหนึ่งในบทความ คนเลยสรุปว่าเป็นขยะจาก AI ก็ไม่รู้ รู้สึกเหมือนผู้คนกำลังเสียสติกันไปจริง ๆ
    วัฒนธรรมการรายงานของเว็บไซต์นี้แย่มากขึ้นเรื่อย ๆ และอยากให้ผู้ดูแลลงมือจัดการ ถ้าแบนคนไม่กี่คนที่รายงานอย่างมุ่งร้าย ที่เหลือก็คงจะยับยั้งชั่งใจมากขึ้น
  • ตอนนี้การ รายงานอย่างไม่เป็นธรรม กลายเป็นวัฒนธรรมของที่นี่ไปแล้ว

• ผมไม่ชอบท่าทีของ Turso มานานแล้วที่ชอบ วางตัวเป็นผู้สืบทอดของ SQLite และด้วยเหตุนี้จึงตั้งใจไว้ตั้งแต่หลายปีก่อนว่าจะไม่แตะซอฟต์แวร์ของพวกเขาเลย
  แต่ถ้าพวกเขาสามารถให้ materialized view แบบรีเฟรชอัตโนมัติ ที่เร็วและถูกได้นอกเหนือจาก SQL Server ผมก็คงอาจจะลงเอยด้วยการใช้อยู่ดี