การบันทึกเหตุการณ์ (event sourcing) เป็นรูปแบบการออกแบบที่ทรงพลังมาอย่างยาวนานสำหรับการสร้างระบบที่ยืดหยุ่น ทว่ากลับมีสิ่งน่าประหลาดใจคือการขาดแคลนโซลูชันโอเพนซอร์สที่ถูกสร้างขึ้นมาโดยเฉพาะ ในขณะที่ฐานข้อมูลทั่วไปสามารถถูกบังคับให้เก็บเหตุการณ์ได้ แต่พวกมันมักขาดการรับประกันเฉพาะด้านและลักษณะประสิทธิภาพที่จำเป็นสำหรับสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์อย่างจริงจัง ช่องว่างในระบบนิเวศนี้ทำให้ทีมพัฒนาจำนวนมากต้องสร้างโซลูชันของตัวเองหรือยอมประนีประนอมในด้านฟังก์ชันการทำงาน
ชุมชนให้การตอบรับอย่างอบอุ่นกับแนวทางโอเพนซอร์สของ SierraDB
ชุมชนนักพัฒนาได้ตอบรับกับการมาถึงของ SierraDB อย่างกระตือรือร้น โดยเฉพาะอย่างยิ่งการชื่นชมในธรรมชาติแบบโอเพนซอร์สและขั้นตอนการติดตั้งที่ตรงไปตรงมา ความคิดเห็นหนึ่งได้สะท้อนความรู้สึกที่หลายคนมีต่อภาพรวมของเครื่องมือการบันทึกเหตุการณ์ในปัจจุบันได้อย่างแม่นยำ:
มันน่าแปลกใจสำหรับผมเสมอที่สถาปัตยกรรมระบบจัดเก็บเหตุการณ์ไม่ถูกใช้งานอย่างกว้างขวางมากขึ้น บทความนี้พูดถูกมากเกี่ยวกับเหตุผล: มันไม่มีวิธีใดที่ชัดเจนเลยสำหรับการเริ่มต้นใช้ในโปรเจกต์ใหม่
ความหงุดหงิดใจกับสถานะปัจจุบันของเครื่องมือการบันทึกเหตุการณ์นี้สะท้อนไปทั่วทั้งการอภิปราย นักพัฒนากำลังค้นหาโซลูชันที่รวมเอาพลังของการบันทึกเหตุการณ์เข้ากับความเรียบง่ายของเวิร์กโฟลว์การพัฒนาสมัยใหม่ ความสามารถที่จะรันแค่ docker compose up แล้วเริ่มทำงานกับเหตุการณ์ได้นั้น ถือเป็นก้าวสำคัญของความสะดวกในการเข้าถึง
คำสั่งเริ่มต้นใช้งานด่วน:
docker run -p 5050:5050 sqwewe/sierradb
redis-cli -p 9090
> CAPPEND user-123 UserCreated '{"name": "Alice"}'
> CSCAN user-123 *```
|  |
|:--:|
|*Partition Explorer ของ SierraDB ช่วยให้ผู้ใช้สามารถเรียกดูและจัดการ event ข้าม partition ต่างๆ ได้ ช่วยเพิ่มความสะดวกในการเข้าถึงสำหรับนักพัฒนา* |
### การเปรียบเทียบทางเทคนิคจุดประกายการอภิปรายเรื่องสถาปัตยกรรม
ความคิดเห็นต่างๆ เปิดเผยการเปรียบเทียบอย่างรอบคอบระหว่าง SierraDB กับโซลูชันที่มีอยู่เช่น XTDB และ SlateDB ในขณะที่ XTDB ตอบโจทย์ความต้องการในการจัดเก็บเหตุการณ์บางส่วน สมาชิกในชุมชนตั้งข้อสังเกตว่า SierraDB ได้แก้ไขปัญหาด้านสถาปัตยกรรมที่แตกต่างออกไป โดยเฉพาะอย่างยิ่งรอบๆ เรื่องการฉายภาพที่ผู้ใช้กำหนดได้ (user-defined projections) และการขยายขนาดแบบหลายพาร์ติชัน การอภิปรายนี้เน้นย้ำให้เห็นว่าแนวทางของ SierraDB ในการใช้พาร์ติชันคงที่พร้อมกับหมายเลขลำดับที่ไม่ขาดตอน (gapless sequence numbers) นั้นให้การรับประกันเรื่องลำดับที่แข็งแกร่ง ในขณะที่ยังคงความสามารถในการขยายขนาดในแนวนอน
การเลือกใช้โปรโตคอล RESP3 ได้รับการตอบรับเป็นอย่างดีโดยเฉพาะในด้านการลดความซับซ้อนของไคลเอ็นต์ เนื่องจากภาษาโปรแกรมเกือบทุกภาษามีไลบรารีไคลเอ็นต์สำหรับ Redis นักพัฒนาสามารถเริ่มใช้ SierraDB ได้ทันทีโดยไม่ต้องเขียนไดรเวอร์แบบกำหนดเอง การตัดสินใจออกแบบนี้ช่วยลดอุปสรรคในการเริ่มต้นได้อย่างมาก และแสดงให้เห็นถึงความมุ่งมั่นของ SierraDB ต่อประสบการณ์ของนักพัฒนา
**คุณสมบัติหลักของ SierraDB:**
- สร้างด้วย Rust เพื่อประสิทธิภาพที่คาดการณ์ได้โดยไม่มีการหยุดชะงักจาก garbage collection
- ใช้โปรโตคอล RESP3 เพื่อความเข้ากันได้กับ Redis clients ที่มีอยู่
- การขยายแนวนอนผ่านพาร์ติชันเชิงตรรกะที่กำหนดไว้ (32 ถึง 1024+ พาร์ติชัน)
- การจัดเก็บแบบ append-only พร้อมหมายเลขลำดับที่ไม่มีช่องว่างในแต่ละพาร์ติชัน
- มีระบบ subscriptions ในตัวสำหรับการสตรีมอีเวนต์
- การตกลงร่วมกันแบบกระจายด้วยการเขียนแบบ quorum-based และการอ่านแบบโลคัล
|  |
|:--:|
| *Projection Runner ใน SierraDB ช่วยให้นักพัฒนาสามารถเขียนและรัน projections แบบกำหนดเองบน events ได้ ซึ่งแสดงให้เห็นถึงความยืดหยุ่นและประสิทธิภาพของเครื่องมือนี้* |
### ความกังวลในทางปฏิบัติและทิศทางในอนาคต
คำถามจากชุมชนได้เผยให้เห็นข้อพิจารณาที่สำคัญในทางปฏิบัติ ความสามารถในการสร้างสแนปชอต (snapshotting) กลายเป็นหัวข้อหลัก โดยนักพัฒนาสงสัยว่า SierraDB จัดการกับความท้าทายในการเล่นซ้ำสตรีมเหตุการณ์ขนาดใหญ่เมื่อเวลาผ่านไปอย่างไร คำตอบจากผู้ดูแลเน้นย้ำถึงจุดสนใจปัจจุบันที่ประสิทธิภาพของฐานข้อมูลหลัก ในขณะที่ยอมรับว่าการสร้างสแนปชอตเป็นสิ่งเสริมที่มีศักยภาพในอนาคต
การอภิปรายยังกล่าวถึงกลยุทธ์การปรับใช้งาน โดยบางคนคาดว่าจะมีการกำหนดค่า Kubernetes เนื่องจากธรรมชาติแบบกระจายของ SierraDB อย่างไรก็ตาม แนวทางแบบ Docker-first นั้นสมเหตุสมผลในฐานะตัวเลือกพื้นฐานที่รองรับได้กว้างขวางที่สุด across container runtimes เพื่อให้มั่นใจในความสามารถในการเข้าถึงโดยไม่ขึ้นกับความชอบในแพลตฟอร์มการจัดการ
**เปรียบเทียบกับโซลูชันที่มีอยู่:**
| โซลูชัน | ภาษา | ใบอนุญาต | จุดเด่นหลัก |
|----------|----------|---------|-------------------|
| SierraDB | Rust | Open Source | สร้างขึ้นเฉพาะทางพร้อม horizontal scaling |
| KurrentDB | .NET | Commercial | มีชื่อเสียงแต่มีข้อกังวลเรื่องใบอนุญาต |
| AxonServer | Java | Commercial | เน้นองค์กรขนาดใหญ่ |
| Postgres-based | Various | Open Source | ดัดแปลงจากระบบทั่วไปสำหรับ events |
### ก้าวสู่ความพร้อมสำหรับการใช้งานจริง
SierraDB เป็นจุดหมายสำคัญในวิวัฒนาการของระบบจัดเก็บเหตุการณ์โอเพนซอร์ส การผสมผสานระหว่างลักษณะประสิทธิภาพของ Rust การตัดสินใจด้านสถาปัตยกรรมที่รอบคอบในเรื่องการแบ่งพาร์ติชันและการทำสำเนา และความสามารถในการใช้งานได้ทันทีผ่าน RESP3 สร้างเป็นแพ็คเกจที่น่าสนใจ แม้โปรเจกต์จะยอมรับว่าข้อมูลเอกสารและการทดสอบจำเป็นต้องได้รับการพัฒนาต่อไป แต่สถาปัตยกรรมหลักดูมีเสถียรภาพและออกแบบมาอย่างดี
การตอบรับในเชิงบวกจากชุมชนชี้ให้เห็นว่า SierraDB กำลังแก้ไขจุดเจ็บปวดจริงที่นักพัฒนาเคยประสบกับโซลูชันที่มีอยู่ ขณะที่โปรเจกต์ยังคงวิวัฒนาการต่อไป มันมีศักยภาพที่จะกลายเป็นระบบจัดเก็บเหตุการณ์โอเพนซอร์สตัวหลักสำหรับทีมที่กำลังสร้างระบบที่ขับเคลื่อนด้วยเหตุการณ์ และต้องการทั้งประสิทธิภาพและเครื่องมือที่เป็นมิตรกับนักพัฒนา
การเดินทางจากแนวคิดสู่ฐานข้อมูลที่พร้อมสำหรับการใช้งานจริงนั้นท้าทาย แต่รากฐานที่มั่นคงและการมีส่วนร่วมของชุมชนของ SierraDB ทำให้มันอยู่ในตำแหน่งที่ดีสำหรับการเติบโตในอนาคต สำหรับนักพัฒนาที่รอคอยระบบจัดเก็บเหตุการณ์ที่พร้อมใช้งานครบครัน โดยไม่ต้องใช้ลิขสิทธิ์ที่ซับซ้อนหรือการปรับแต่งอย่างมาก SierraDB เสนอเส้นทางข้างหน้าที่น่าหวัง
อ้างอิง: [SierraDB: A Distributed Event Store Built in Rust](https://tqwewe.com/blog/building-sierradb/)