FalkorDB เขียนใหม่ เป็น Rust แล้ว เราอัปของจริง แล้ววัดเอง

เมื่อวานมีคนถามสั้นๆ ว่า FalkorDB ที่ใช้กันอยู่ เปลี่ยนเป็น Rust แล้วจริงไหม

คำถามแบบนี้ตอบจากความทรงจำได้ไว แต่ตอบผิดก็ไว เลยไปเปิดดูของจริง แล้วพบว่าคำตอบคือ "จริง แต่ยังไม่ใช่ตัวที่คุณกำลังรันอยู่" และระหว่างที่ไล่ดู ก็เจอว่าฐานข้อมูลของเราเองตกรุ่นไปสองเวอร์ชันย่อยโดยไม่มีใครสังเกต

บทความนี้เล่าสองอย่างที่พันกันอยู่ อย่างแรกคือ Rust rewrite ของจริงเป็นยังไง วัดจากของที่รันได้จริงไม่ใช่จากประกาศ อย่างที่สองคือ วิธีอัปเครื่องยนต์ฐานข้อมูลที่มีข้อมูลอยู่ข้างในโดยไม่ต้องภาวนา ซึ่งเป็นส่วนที่เอาไปใช้กับฐานข้อมูลตัวไหนก็ได้ ไม่ใช่แค่ตัวนี้

ช่วงที่ 1FalkorDB เป็น Rust แล้วจริงไหม

จริง แต่ยังเป็นรุ่นทดลอง ทีมเขาเขียนเองในบล็อกวันที่ 3 สิงหาคม 2026 ว่า "the Rust engine is still a preview. Before we call it the official version we want it hitting workloads we didn't think of" แปลตรงตัวคือ ยังไม่ประกาศเป็นตัวจริงจนกว่าจะเจองานแบบที่คนเขียนคิดไม่ถึง

ขนาดของงานที่เขาบอกไว้ 80,000 บรรทัด Rust ผ่าน pull request 357 ครั้ง ชุดทดสอบกลางของภาษาที่ใช้ถามกราฟ 1,585 เคส และเทสต์ของตัวเองอีก 1,322 เคสเขียวหมด สิ่งที่เขาชูไม่ใช่ความเร็ว เพราะความเร็วเสมอกับ C เขาชูว่า ทีมกล้าแก้ของมากขึ้น เพราะระบบชนิดข้อมูลของ Rust จับพลาดให้ตั้งแต่ตอนคอมไพล์

รายละเอียดที่สำคัญกับคนที่จะย้ายจริง คือรูปแบบไฟล์ RDB เข้ากันได้ระดับไบต์กับ v19 ของ C แปลว่าไม่ต้องส่งออกแล้วนำเข้าใหม่ สลับเครื่องยนต์แล้วเปิดไฟล์เดิมได้เลย

แล้วตัวที่เรารันอยู่ล่ะ

เปิดดูแล้วสะดุด คอนเทนเนอร์ของเราขึ้นว่า Up 7 weeks โมดูลรายงานเวอร์ชัน 4.18.10 ขณะที่ tag latest บน Docker Hub ตอนนั้นคือ v4.20.1 ลงวันที่ 15 กรกฎาคม

เจ็ดสัปดาห์ที่ผ่านมาไม่มีใครแตะ ไม่มีอะไรพัง และไม่มีอะไรบอกว่าเราตกรุ่น ของแบบนี้ไม่ส่งเสียง มันแค่ค่อยๆ ห่างออกไป

ช่วงที่ 2ชื่อ tag หลอกได้ พิสูจน์จากตัวไฟล์

พอไปไล่ดู tag ทั้งหมด 567 อัน เจอของที่น่าสนใจกว่าตัวข่าว

สังเกตบรรทัดบนสุด edge ซึ่งเป็นชื่อที่คนทั่วไปหยิบไปใช้เวลาจะลองของใหม่ กลายเป็น Rust ไปแล้วเงียบๆ ส่วนตัว C ถูกย้ายไปอยู่ชื่อใหม่ที่ต้องรู้ก่อนถึงจะพิมพ์ถูก

ตรงนี้คือจุดที่ควรหยุดคิดหนึ่งจังหวะ ถ้าเชื่อชื่อ tag แล้วสรุปว่ารันอะไรอยู่ ก็เท่ากับเชื่อป้ายที่คนอื่นเปลี่ยนได้ตลอดเวลา

วิธีที่เชื่อได้ คือถามตัวไฟล์

ตัวโปรแกรมที่คอมไพล์ออกมาจาก Rust จะมีร่องรอยของเครื่องมือที่ใช้สร้างติดค้างอยู่ในไฟล์ ค้นเจอได้ตรงๆ

grep -aoE '/rustc/[0-9a-f]{8}|cargo/registry' falkordb.so

ผลที่ได้จากสองตัว

• edge-rs คืน /rustc/8bab26f4 และ cargo/registry
• edge-c คืนแค่ GCC: (Ubuntu 11.4.0) ไม่มีร่องรอย Rust เลย

ตัวที่สองสำคัญกว่าตัวแรก เพราะนี่คือตัวเทียบ ถ้าคำสั่งค้นหาพิมพ์ผิดหรือไฟล์อ่านไม่ได้ ผลจะว่างเปล่าทั้งคู่ แล้วเราจะอ่าน "ไม่เจอ Rust" เป็น "นี่คือตัว C" ทั้งที่จริงคือ "ตัวค้นหาพัง" การที่ฝั่ง C คืนบรรทัด GCC ออกมา แปลว่าคำสั่งทำงานอยู่จริง

ช่วงที่ 3อัปเกรดฐานข้อมูล ที่มีข้อมูลจริง ต้องทำอะไรบ้าง

สามอย่าง สำรองก่อน ซ้อมบนสำเนาก่อน แล้วบังคับให้ตัวตรวจพิสูจน์ว่าของเปลี่ยนจริง สามข้อนี้ใช้ได้กับฐานข้อมูลทุกตัว ไม่ใช่แค่ตัวนี้ ที่เหลือคือรายละเอียดว่าแต่ละข้อทำยังไงให้ไม่หลอกตัวเอง

ฐานข้อมูลที่จะอัปมีของอยู่ข้างใน 3,011 โหนด 7,751 เส้นเชื่อม กระจายใน 11 กราฟ ตัวเลขสองตัวแรกคือสิ่งที่จะใช้ตัดสินว่าสำเร็จหรือไม่สำเร็จ ไม่ใช่คำว่า "ดูโอเค"

1. สำรอง แล้วพิสูจน์ว่าสำรองใช้ได้

สั่งเขียนของลงดิสก์ให้สดก่อนคัดลอก แล้วคัดทั้งโฟลเดอร์ออกมา ตรงนี้มีกับดักที่เจอกับตัว คำสั่งสั่งบันทึกรอบแรกถูกปฏิเสธเพราะมีงานเขียนดิสก์อีกตัวทำงานค้างอยู่ ข้อความที่ได้กลับมาคือ Another child process is active ถ้าไม่อ่านบรรทัดนั้น ก็จะได้สำเนาที่เก่ากว่าที่คิดสองชั่วโมงโดยไม่รู้ตัว

และสำเนาที่ยังไม่เคยเปิดใช้ ไม่ใช่สำเนา เป็นโฟลเดอร์ที่เราหวังว่าจะใช้ได้ต่างหาก ก่อนลบสำเนาซ้ำทิ้ง เราเอาตัวที่จะเก็บไปเปิดในคอนเทนเนอร์ทดลองแยก แล้วนับโหนดได้ 3,011 ตรงกัน ถึงกล้าลบตัวเก่า

2. ซ้อมบนสำเนา ทั้งสองทาง ที่โปรแกรมจะเปิดไฟล์

ฐานข้อมูลตระกูลนี้เปิดข้อมูลกลับมาได้สองทาง ทางภาพนิ่ง (RDB) กับทางบันทึกคำสั่ง (AOF) ซ้อมรอบแรกเราได้ผลสวยงาม โหนดครบ อ่านภาษาไทยได้ แต่พอไปอ่านบันทึกการรันจริงๆ ก็เห็นว่าโหลดมาทาง RDB ขณะที่ตัวจริงเปิด AOF อยู่

แปลว่าที่ซ้อมมา ไม่ใช่เส้นทางที่ของจริงจะเดิน ซ้อมผ่านแต่ซ้อมผิดข้อสอบ

รอบสองจึงบังคับเปิด AOF แต่กลับได้ appendonly no ทั้งที่ใส่ค่าไปแล้ว สาเหตุคือ image ตัวนี้มีสคริปต์เปิดเครื่องของตัวเองที่กลืนค่าที่ต่อท้ายคำสั่ง ต้องส่งผ่านตัวแปรสภาพแวดล้อมชื่อ REDIS_ARGS เท่านั้น รอบสามถึงได้ appendonly yes จริง แล้วบันทึกการรันขึ้นว่าโหลดจากไฟล์ AOF สมใจ

สิ่งที่ทำให้จับได้ไม่ใช่ความรอบคอบ แต่เป็นการเช็คค่าที่ตั้งไปว่าลงจริงไหมก่อนอ่านผล ถ้าไม่เช็ค เราจะได้ผลเขียวจากการทดลองที่ไม่เคยเกิดขึ้น

3. บังคับให้ตัวตรวจ พิสูจน์ว่าของเปลี่ยนจริง

ตอนสลับตัวจริง สคริปต์พิมพ์ออกมาว่า SWAP_OK จำนวนโหนดตรง ทุกอย่างดูดี

แต่มันไม่จริงเลยสักบรรทัด

คำสั่งสร้างคอนเทนเนอร์ใหม่ล้มเหลวด้วยข้อความ no configuration file provided: not found เพราะไฟล์ตั้งค่าใช้ชื่อที่ไม่ใช่ชื่อมาตรฐาน ต้องระบุด้วยตัวเลือก -f ผลคือคอนเทนเนอร์เดิมยังอยู่ ไม่มีอะไรเปลี่ยน จำนวนโหนดตรงเพราะเป็นตัวเดิมที่ไม่เคยถูกแตะ และบรรทัดล่าสุดของบันทึกการรันเป็นของ 25 กรกฎาคม

สคริปต์รอบสองจึงบังคับสามข้อ ต้องเทียบรหัสคอนเทนเนอร์ก่อนกับหลังว่าเปลี่ยนจริง ต้องเจอร่องรอย Rust ในไฟล์ และจำนวนโหนดกับเส้นเชื่อมต้องตรงเป๊ะ ข้อไหนไม่ผ่านให้ย้อนกลับอัตโนมัติทันที คราวนี้ผ่านจริง รหัสคอนเทนเนอร์เปลี่ยน ร่องรอย Rust มา ข้อมูล 3,011 กับ 7,751 ครบ และข้อความภาษาไทยอ่านกลับมาได้ปกติ

ตัวตรวจที่บอกว่า "สำเร็จ" ได้โดยไม่ต้องมีอะไรเกิดขึ้น ไม่ใช่ตัวตรวจ เป็นข้อความให้กำลังใจต่างหาก

ของแถมที่ไม่ได้ตามหา

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

เจ็ดสัปดาห์ที่คิดว่าปลอดภัย จริงๆ คือเจ็ดสัปดาห์ที่ไม่มีใครลองทำให้มันหาย

ช่วงที่ 4สิ่งที่ Rust ไม่ได้เปลี่ยน

เหตุผลที่ไปลองตั้งแต่แรก คือเรามีอาการค้างอยู่อย่างหนึ่ง บางข้อมูลถูกปฏิเสธด้วยข้อความว่ารับได้เฉพาะค่าพื้นฐานเท่านั้น ในใจคิดว่าเครื่องยนต์ใหม่อาจแก้ให้

เลยยิงชุดทดสอบเดียวกันใส่ทั้งสองตัว ค่าธรรมดา ค่าภาษาไทย รายการของค่าธรรมดา ค่าซ้อนชั้น รายการของค่าซ้อนชั้น และเคสสุดท้ายคือคำสั่งที่จงใจเขียนผิดไวยากรณ์เพื่อดูว่าตัวตรวจยังมีชีวิต

ข้อความปฏิเสธเหมือนกันคำต่อคำทั้งสองเครื่องยนต์ การอัปเกรดไม่ได้แตะปัญหาที่เราหวังว่าจะแก้เลย เพราะรากของอาการไม่ได้อยู่ที่ฐานข้อมูล อยู่ที่ชั้นบนที่ส่งข้อมูลรูปแบบผิดลงมาต่างหาก

บทเรียนที่แพงกว่าตัวอาการ คืออย่าอัปเกรดเพื่อแก้บั๊กที่ยังไม่รู้ว่าอยู่ตรงไหน ถ้าไม่ได้ทดสอบเทียบไว้ก่อน เราจะอัปเสร็จ เห็นอาการยังอยู่ แล้วสรุปผิดอีกชั้นว่าเครื่องยนต์ใหม่ไม่ดี

ตัวล่อที่ทำให้ เจอของที่ตั้งใจหา

เคสสุดท้ายในตารางคือคำสั่งที่เขียนผิดไวยากรณ์ ใส่ไว้เพื่อให้ต้องมีอย่างน้อยหนึ่งช่องที่เป็นสีแดง ผลรอบแรกคือทั้งตารางเขียวหมดรวมทั้งช่องนั้น แปลว่าตัวอ่านผลตายอยู่ (คำสั่งแปลงข้อความโดนเครื่องหมายคำพูดกินไปจนได้ค่าว่าง)

รอบสองฝั่ง C แดงแล้ว แต่ฝั่ง Rust ยังเขียว พอเปิดดูข้อความดิบถึงเจอของจริง

• C ตอบ errMsg: Invalid input at end of input...
• Rust ตอบ Encountered unhandled type in inlined properties.

ข้อความฝั่ง Rust ไม่มีคำว่า error อยู่ในนั้นเลย ตัวอ่านผลที่มองหาคำว่า error หรือ errMsg จึงอ่านความผิดพลาดเป็นความสำเร็จ ตรวจซ้ำแล้วทั้งคู่ส่งกลับมาเป็นความผิดพลาดจริงในระดับโปรโตคอล โปรแกรมที่เรียกใช้ผ่านไลบรารีมาตรฐานจึงปลอดภัย ที่ตาบอดคือสคริปต์ตรวจสุขภาพที่เขียนด้วยการค้นคำเท่านั้น

ถ้าคุณมีสคริปต์เฝ้าระวังที่ตัดสินด้วยการค้นคำว่า error ในผลลัพธ์ ตอนนี้มันตาบอดกับเครื่องยนต์ใหม่แล้ว

ช่วงที่ 5เอาไปใช้ กับงานของคุณ

ควรย้ายไป Rust ตอนนี้ไหม

ถ้าเป็นระบบที่ลูกค้าใช้อยู่ ยังไม่ควร เจ้าของบอกเองว่าเป็นรุ่นทดลอง และ tag edge-rs เป็นชื่อที่ถูกสร้างใหม่ทุกวัน ของที่คุณทดสอบวันนี้กับของที่ขึ้นพรุ่งนี้อาจไม่ใช่ตัวเดียวกัน

ถ้าจะลองจริง ล็อกด้วย digest ไม่ใช่ tag เพราะ digest เปลี่ยนไม่ได้ ของที่รันจึงระบุตัวได้เสมอ ส่วนของเราเลือกย้ายเพราะเป็นระบบภายในที่หยุดได้ มีสำเนาที่พิสูจน์แล้วว่ากู้ได้ และมีทางถอยกลับที่ทดสอบไว้ก่อน

ห้าข้อที่เอาไปใช้ได้เลย

1. สำเนาที่ยังไม่เคยเปิด ไม่ใช่สำเนา เปิดในกล่องแยกแล้วนับของให้ตรงก่อน ถึงจะเรียกว่าสำรองแล้ว
2. ซ้อมให้ตรงเส้นทางที่ของจริงจะเดิน ถ้าตัวจริงเปิดไฟล์ทาง AOF แล้วคุณซ้อมทาง RDB คุณซ้อมคนละข้อสอบ อ่านบันทึกการรันว่าโหลดมาจากไหนจริงๆ
3. ค่าที่ตั้งไป ต้องเช็คว่าลงจริงก่อนอ่านผล ตัวล่อที่ติดตั้งไม่สำเร็จ ให้ผลหน้าตาเหมือนตัวล่อที่ผ่านทุกประการ
4. ตัวตรวจต้องยืนยันว่าของเปลี่ยนจริง ไม่ใช่แค่ว่าผลลัพธ์ยังดี รหัสคอนเทนเนอร์ ลายนิ้วมือของไบนารี วันที่ในบันทึกการรัน สามอย่างนี้โกหกยากกว่าคำว่า OK
5. อย่าอัปเกรดเพื่อแก้บั๊กที่ยังไม่รู้ตำแหน่ง ทดสอบอาการนั้นกับของใหม่ในกล่องแยกก่อน จะได้ไม่ต้องเดาสองชั้นทีหลัง

เริ่มจากตรงไหนดี

ถ้าอยากลองวันนี้โดยไม่แตะของจริง หยิบสำเนาข้อมูลของคุณไปเปิดในคอนเทนเนอร์แยกสักตัว แล้วนับของให้ตรงกับต้นฉบับ แค่ขั้นนี้ขั้นเดียวก็ตอบได้แล้วว่าสำรองที่มีอยู่ใช้ได้จริงหรือเปล่า ซึ่งเป็นคำถามที่คนส่วนใหญ่ตอบได้ตอนที่สายไปแล้ว

ส่วนเรื่องว่ากราฟแบบนี้เอาไปใช้เก็บความจำของ AI agent ยังไง ทั้งชั้นที่อยู่เหนือฐานข้อมูลและจุดที่มันพังเงียบๆ เราเขียนไว้แล้วที่ ชั้นความจำของ AI agent ที่เราใช้จริง

ที่มาและอ้างอิง

• FalkorDB, Rewriting FalkorDB in Rust: Make It Work, Make It Stable, Then Make It Fast (3 ส.ค. 2026) ตัวเลข 80,000 บรรทัด · pull request 357 ครั้ง · TCK 1,585 · flow 1,322 · ประโยค "still a preview" · RDB เข้ากันได้กับ v19
• FalkorDB/falkordb-rs-next-gen ที่เก็บโค้ดของเครื่องยนต์ Rust ปิดเป็นอ่านอย่างเดียวเมื่อ 30 ก.ค. 2026
• Docker Hub · falkordb/falkordb tags วันที่และขนาดของ edge / edge-rs / edge-c / latest ดึงเมื่อ 4 ส.ค. 2026
• ตัวเลข 3,011 โหนด · 7,751 เส้นเชื่อม · 11 กราฟ · ลายนิ้วมือ /rustc/8bab26f4 · ตารางทดสอบทั้งหกเคส วัดเองจากการอัปจริงเมื่อ 4 ส.ค. 2026 ไม่ใช่ตัวเลขที่ยกมาจากที่อื่น