ทีมวิศวกรเบื้องหลังบริการโฮสต์วิดีโอได้เปลี่ยนดัชนี (index) จาก SQLite FTS5 ไปใช้คลัสเตอร์ OpenSearch ซึ่งช่วยลดจำนวนการค้นหาที่ไม่พบผลลัพธ์ (zero-result queries) จาก 12% เหลือเพียง 1.4% และเพิ่มอัตราการคลิกจากการค้นหา (search-to-click rate) ขึ้น 9% ในขณะที่ยังคงรักษาความหน่วง (latency) ให้ต่ำกว่า 28 ms
ทำไมการเปลี่ยนผ่านจึงกลายเป็นเรื่องเร่งด่วน
ส่วนขยายการค้นหาข้อความแบบเต็มรูปแบบ (full-text search extension หรือ FTS5) ของ SQLite นั้นมีความน่าสนใจ เพราะมันจัดเก็บอยู่ในไฟล์เดียวกับข้อมูลส่วนที่เหลือ ไม่มีค่าใช้จ่ายด้านลิขสิทธิ์ และสามารถคืนค่าผลลัพธ์ที่ตรงกันได้ทันทีสำหรับการจับคู่โทเคน (token) ที่แม่นยำ อย่างไรก็ตาม บันทึก (logs) ของแพลตฟอร์มแสดงให้เห็นว่าการค้นหาของผู้ใช้ประมาณ 12% ไม่พบผลลัพธ์ใดๆ เลย สาเหตุหลักมาจากคำที่สะกดผิด เช่น “intersteller” หรือ “avengrs endgame” ซึ่งเป็นลักษณะการพิมพ์ผิดที่มักเกิดขึ้นบ่อยบนคีย์บอร์ดมือถือ
การแก้ปัญหาเฉพาะหน้าอย่างรวดเร็วด้วยการใช้ trigrams (เศษเสี้ยวตัวอักษร 3 ตัว) ช่วยลดอัตราการค้นหาที่ไม่พบผลลัพธ์ลงเหลือ 7% แต่ก็นำมาซึ่งปัญหาสองประการ ประการแรก ขนาดของดัชนีพุ่งสูงขึ้นกว่าสามเท่าจากขนาดเดิม ส่งผลให้ค่าใช้จ่ายในการจัดเก็บข้อมูลเพิ่มขึ้นและทำให้การอัปเดตช้าลง ประการที่สอง ความเกี่ยวข้อง (relevance) ลดลง เนื่องจากการจับคู่แบบคลุมเครือ (fuzzy matching) ให้ผลลัพธ์ที่เป็นวิดีโอที่ไม่เกี่ยวข้องกันปนกันมาจนดูสับสน แทนที่จะช่วยนำทางผู้ใช้
ทีมงานจึงสรุปว่าจำเป็นต้องใช้ Search Engine ที่สร้างขึ้นมาเพื่อการนี้โดยเฉพาะ ซึ่งมีความสามารถในการรองรับคำที่พิมพ์ผิด (typo-tolerance) ในตัว และมีระบบการให้คะแนนความเกี่ยวข้อง (relevance scoring) ที่ซับซ้อน
การสร้าง OpenSearch pipeline
ใช้ SQLite เป็นแหล่งข้อมูลหลัก (Source of Truth)
OpenSearch ทำหน้าที่เป็นตัวสำเนา (replica) แบบอ่านอย่างเดียวที่สามารถสร้างใหม่ได้เสมอ ข้อมูลเมทาดาตา (metadata) ของวิดีโอทั้งหมดจะยังคงอยู่ใน SQLite ทำให้สามารถสร้างดัชนีการค้นหาใหม่ได้โดยไม่ต้องเสี่ยงต่อการสูญเสียข้อมูล และเมื่อคลัสเตอร์ OpenSearch ขัดข้อง แอปพลิเคชันจะสลับกลับไปใช้เอนจิน FTS5 เดิมโดยอัตโนมัติ
การจัดลำดับความเกี่ยวข้องด้วย “should” query
แทนที่จะพึ่งพาเพียงการจับคู่แบบคลุมเครือ (fuzzy matching) เพียงอย่างเดียว การค้นหาจะใช้การรวมกันของ 3 เงื่อนไข (clauses):
- การจับคู่แบบวลีที่แม่นยำ (Exact phrase match) – ให้คะแนน (boost) สูงสุด เพื่อตอบแทนผู้ใช้ที่พิมพ์ชื่อเรื่องได้อย่างถูกต้อง
- มีคำครบทุกคำ (All terms present) – ให้คะแนนระดับปานกลาง สำหรับการค้นหาที่มีคำครบทุกคำแต่ไม่จำเป็นต้องเรียงตามลำดับ
- การจับคู่แบบคลุมเครือ (Fuzzy match) – ให้คะแนนต่ำสุด ทำหน้าที่เป็นตาข่ายรองรับ (safety net) สำหรับโทเคนที่มีการสะกดผิด
ลำดับชั้นนี้ช่วยรักษาความแม่นยำ (precision) สำหรับการค้นหาที่พิมพ์มาอย่างถูกต้อง ในขณะที่ยังคงมีระบบสำรองที่ยืดหยุ่นสำหรับคำที่พิมพ์ผิด
การปรับแต่งค่า fuzzy settings
การกำหนดค่า prefix length เป็น 1 บังคับให้ตัวอักษรแรกของแต่ละคำต้องตรงกันก่อนที่ตรรกะแบบ fuzzy จะเริ่มทำงาน กฎนี้ช่วยให้การค้นหายังคงรวดเร็วและป้องกันไม่ให้จำนวนคำที่อาจเป็นไปได้เพิ่มขึ้นมากเกินไปจนทำให้หน่วยความจำทำงานหนักเกินไป นอกจากนี้ ทีมงานยังจำกัดจำนวนสูงสุดของการขยายคำ (term expansions) ซึ่งเป็นอีกหนึ่งมาตรการป้องกันการใช้ทรัพยากรที่เกินควบคุม
กลยุทธ์การซิงโครไนซ์ (Synchronisation strategy)
มี 3 กระบวนการที่ทำงานเสริมกันเพื่อรักษาดัชนีของ OpenSearch ให้สอดคล้องกับ SQLite:
- Cron job เพื่อซิงค์ข้อมูลใหม่
- การตรวจสอบความต่างรายคืน (Nightly diff pass) – สแกนหาความไม่สอดคล้องที่อาจหลุดรอดจากการอัปเดตแบบเพิ่มส่วน (incremental updates)
- การสร้างดัชนีใหม่ทั้งหมดรายสัปดาห์ (Weekly full rebuild) – ทำงานผ่าน index alias จากนั้นจึงสลับ alias ในการทำงานเพียงครั้งเดียว เพื่อรับประกันว่าจะไม่มีช่วงเวลาที่ระบบหยุดทำงาน (zero downtime)
ผลลัพธ์ที่วัดผลได้หลังจากผ่านไปสองสัปดาห์
- การค้นหาที่ไม่พบผลลัพธ์ลดลงจาก 12% เหลือ 1.4%
- อัตราการเปลี่ยนจากค้นหาเป็นการคลิก (Search-to-click conversion) เพิ่มขึ้น 9%
- ค่ามัธยฐานของความหน่วง (Median latency) ยังคงต่ำกว่า 28 ms ซึ่งอยู่ในเกณฑ์เป้าหมายประสบการณ์ผู้ใช้ของแพลตฟอร์ม
ข้อควรระวังและประเด็นโต้แย้ง
การย้ายระบบนี้ไม่ใช่การอัปเกรดแบบ plug-and-play ทีมงานเน้นย้ำว่าไม่ควรนำ Search Engine มาแทนที่ฐานข้อมูลหลัก โดย SQLite ยังคงเป็นแหล่งจัดเก็บข้อมูลที่เชื่อถือได้ (authoritative store) สำหรับเมทาดาตาวิดีโอทั้งหมด
บทสรุป
การเพิ่มความสามารถในการรองรับคำที่พิมพ์ผิดผ่าน Search Engine ที่สร้างขึ้นมาโดยเฉพาะ ได้เปลี่ยนจุดที่ผู้ใช้มักจะไปต่อไม่ได้ (dead-end) ให้กลายเป็นประสบการณ์ที่ราบรื่นและรวดเร็ว กรณีศึกษานี้แสดงให้เห็นว่าสถาปัตยกรรมที่มีระเบียบวินัย ทั้งการรักษาฐานข้อมูลเชิงสัมพันธ์ (relational store) ให้เป็นแหล่งข้อมูลหลัก การจัดลำดับความเกี่ยวข้อง และการควบคุมตรรกะแบบ fuzzy สามารถสร้างผลลัพธ์ที่วัดผลได้โดยไม่สูญเสียความเสถียรของระบบ