go-mysql-server - เอนจินฐานข้อมูลที่เขียนด้วย Go ล้วนและเข้ากันได้กับ MySQL

 (github.com/dolthub)
6 คะแนน โดย GN⁺ 2024-04-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เอนจินฐานข้อมูลที่เข้ากันได้กับ MySQL ซึ่งเขียนด้วย Go ล้วน
  • เป็นเอนจิน SQL ที่ไม่ยึดติดกับแหล่งข้อมูลใดแหล่งข้อมูลหนึ่ง และใช้ไวยากรณ์กับโปรโตคอลของ MySQL เพื่อรันคิวรีกับแหล่งข้อมูลที่กำหนด
  • มาพร้อม implementation ของฐานข้อมูล in-memory แบบเรียบง่าย และสามารถสร้างแบ็กเอนด์ของตนเองเพื่อคิวรีแหล่งข้อมูลที่ต้องการได้

ความเข้ากันได้

  • ยกเว้นข้อจำกัดบางประการ go-mysql-server สามารถใช้แทน MySQL ได้
  • ไลบรารีไคลเอนต์ เครื่องมือ คิวรี ไวยากรณ์ SQL และฟังก์ชัน SQL ที่ทำงานบน MySQL ควรจะทำงานบน go-mysql-server ได้เช่นกัน
  • หากพบความแตกต่างของฟีเจอร์ โปรดรายงานเป็น issue

ขอบเขตของโปรเจ็กต์

  • เซิร์ฟเวอร์และเอนจิน SQL สำหรับคิวรีแหล่งข้อมูล
  • implementation ของแบ็กเอนด์ฐานข้อมูล in-memory ที่เหมาะสำหรับใช้ในการทดสอบ
  • อินเทอร์เฟซที่สามารถใช้สร้าง implementation ของแบ็กเอนด์ใหม่ เพื่อคิวรีแหล่งข้อมูลของตนเอง
  • หากคำนึงถึงข้อควรระวังบางอย่างและใช้ implementation ฐานข้อมูลแบบเต็ม ก็สามารถใช้แทนฐานข้อมูล MySQL ได้

กรณีใช้งานหลักของ go-mysql-server:

  1. ใช้ implementation ฐานข้อมูล memory ที่มีมาให้ในตัวเพื่อแทน MySQL ในสภาพแวดล้อมการทดสอบของ Go
  2. ทำให้เข้าถึงแหล่งข้อมูลใดก็ได้ผ่าน SQL query โดยการ implement อินเทอร์เฟซบางส่วน

การใช้เซิร์ฟเวอร์ทดสอบ in-memory

  • เซิร์ฟเวอร์ทดสอบ in-memory สามารถใช้แทนเซิร์ฟเวอร์ MySQL จริงในการทดสอบได้
  • สามารถเริ่มเซิร์ฟเวอร์ได้ด้วยโค้ดตัวอย่างที่ให้มา
  • เมื่อเซิร์ฟเวอร์ทำงานแล้ว จะเชื่อมต่อได้ผ่าน MySQL client, Go MySQL connector หรือ mysql shell เป็นต้น

ข้อจำกัดของ implementation ฐานข้อมูล in-memory

  • implementation ฐานข้อมูล in-memory ที่ให้มานั้นมีไว้เพื่อใช้สำหรับการทดสอบ
  • ข้อจำกัดที่ทราบแล้ว:
    • ไม่ thread-safe เพื่อหลีกเลี่ยงปัญหาด้าน concurrency ควรจำกัดคำสั่ง DDL และ DML ให้อยู่ใน goroutine เดียว
    • ไม่รองรับ transaction คำสั่งอย่าง START TRANSACTION, ROLLBACK, COMMIT จะไม่ทำงาน
    • implementation ของดัชนีไม่มีประสิทธิภาพ การค้นหาด้วยดัชนีและการ join จะทำ full table scan กับตารางภายใน

การสร้างแบ็กเอนด์แบบกำหนดเอง

  • สามารถสร้างแบ็กเอนด์สำหรับคิวรีแหล่งข้อมูลของตนเองได้โดย implement อินเทอร์เฟซบางส่วน
  • ดูคำแนะนำโดยละเอียดได้จากคู่มือแบ็กเอนด์

โปรเจ็กต์ที่ขับเคลื่อนด้วย go-mysql-server

  • dolt
  • gitbase (ยุติการพัฒนาแล้ว)
  • หากกำลังสร้างแบ็กเอนด์ฐานข้อมูลด้วย go-mysql-server โปรดแจ้งให้ทราบ

ไลเซนส์

  • Apache License 2.0

ความเห็นของ GN⁺

  • go-mysql-server เป็นเอนจินฐานข้อมูลขนาดเบาที่เข้ากันได้กับ MySQL และเขียนด้วย Go ซึ่งดูมีประโยชน์สำหรับการใช้แทน MySQL ในสภาพแวดล้อมทดสอบ หรือสำหรับคิวรีแหล่งข้อมูลแบบกำหนดเองด้วย SQL
  • เนื่องจากมุ่งเป้าไปที่ความเข้ากันได้กับ MySQL จึงคาดว่าน่าจะนำไปใช้กับแอปพลิเคชันที่อิง MySQL เดิมได้โดยไม่ต้องแก้ไขมาก
  • อย่างไรก็ตาม โปรเจ็กต์นี้ยังอยู่ในช่วงทดลอง โดยเฉพาะ implementation แบบ in-memory ที่ยังเหมาะกับงานทดสอบเท่านั้น ดังนั้นหากจะใช้ใน production ก็ควรระวังเรื่องประสิทธิภาพและความเสถียร
  • สำหรับนักพัฒนาแบ็กเอนด์ ความสามารถในการ implement อินเทอร์เฟซด้วยตนเองเพื่อเชื่อมต่อแหล่งข้อมูลที่ต้องการน่าจะเป็นจุดที่น่าสนใจ ควรดูตัวอย่างจากโปรเจ็กต์จริงอย่าง Dolt
  • ฐานข้อมูลที่เข้ากันได้กับ MySQL ในลักษณะใกล้เคียงกันมี TiDB, CockroachDB เป็นต้น แต่ go-mysql-server มีข้อดีตรงที่สามารถสร้างแบ็กเอนด์ได้อย่างอิสระ ขณะเดียวกันก็มีข้อเสียคือมีต้นทุนเพิ่มเติมในการพัฒนาแบ็กเอนด์

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

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

 
GN⁺ 2024-04-10
ความคิดเห็นบน Hacker News
  • ในฐานะเอนจินคิวรีที่ขับเคลื่อน Dolt นั้น go-mysql-server คือส่วนที่สำคัญที่สุด
  • เขียนโค้ดส่วนใหญ่ของ Dolt เอง แต่ไม่ใช่ผู้เขียนดั้งเดิม เรื่องราวเบื้องหลังการเริ่มต้นโปรเจ็กต์น่าสนใจ
  • ไอเดียของ Dolt น่าสนใจ แต่ persistence layer สำคัญเกินไปและแตกต่างมากจนยังไม่พอสำหรับสร้างธุรกิจบนมัน แต่ถ้า DB กระแสหลักนำไปใช้ก็น่าจะดี
  • หากการรองรับจาก MySQL ไปสู่ PostgreSQL และ SQLite พัฒนาขึ้น ก็จะทำให้รองรับ DB engine หลายตัวใน WordPress เป็นต้นได้
  • ดูเหมือนจะเป็น wire-protocol proxy จาก MySQL ไปยัง SQL โดย DB ที่ proxy ตามค่าเริ่มต้นคือ Dolt และคาดว่าน่าจะถูกแยกออกมาจาก Dolt
  • Go อาจดีกว่า แต่จากมุมมองของนักพัฒนา C# ก็ยังกังวลกับการทำ DB บนภาษาแบบ GC เพราะต้องสู้กับ GC และเขียนโค้ดแบบ allocation ต่ำจำนวนมากที่ไม่ค่อยชัดเจน อาจพอใช้ได้กับทีมเล็ก แต่จะหาคนที่มีทักษะเหมาะสมมาร่วมทีมน่าจะยาก
  • ความเข้ากันได้และฟีเจอร์ยังจำกัดมาก จึงใช้งานในโปรดักชันได้ยาก (ไม่รองรับทรานแซกชัน, การทำดัชนีไม่มีประสิทธิภาพ เป็นต้น) และก็สงสัยว่ารองรับ trigger หรือ stored procedure หรือไม่
  • สงสัยว่าจะยากแค่ไหนถ้าใช้เป็นตัวแทน MySQL แบบ in-memory สำหรับทดสอบโปรเจ็กต์ Rails เนื่องจากชั้น DB สำคัญจึงต้องระวังในโปรดักชัน แต่ถ้าช่วยให้การทดสอบเร็วขึ้นได้ก็น่าสนใจ
  • TiDB เป็น DB แบบกระจายที่เข้ากันได้กับ MySQL ซึ่งเขียนด้วย Go และ Rust ส่วน StarRocks เป็น DB สำหรับ OLAP ที่เข้ากันได้กับ MySQL ซึ่งเขียนด้วย Java และ C++ แต่โปรเจ็กต์นี้ดูเหมือนจะมองจากอีกมุมหนึ่ง เนื่องจากไลบรารี MySQL ของ Vitess ใช้งานยาก จึงอาจนำไปใช้สร้างชั้น abstraction อย่าง ORM ได้
  • เห็นการทำอิมพลีเมนเทชันแบบนี้แล้วน่าทึ่ง แต่ก็ยังสงสัยว่าจะมี use case จริงหรือไม่
  • มีข้อเสนอว่าแทนที่จะยึดตาม MySQL ควรปฏิบัติตามมาตรฐาน SQL จะดีกว่าหรือไม่