MongoDB Atlas Search เร็วขึ้นสูงสุด 4.9 เท่า และ Vector Search 5.5 เท่าใน MongoDB 9.0.7 เปิดใช้เองไม่ต้องแก้แอป ตามเบนช์มาร์กของ MongoDB
โดย กองบรรณาธิการ THAI DATA อ่าน 4 นาที
สรุปประเด็นสำคัญ
- MongoDB เผยแพร่บล็อกวิศวกรรมเมื่อ 11 พฤศจิกายน 2026 ว่าปรับขั้น document lookup จน $search เร็วขึ้นสูงสุด 4.9 เท่า และ $vectorSearch เร็วขึ้น 5.5 เท่า โดยไม่เปลี่ยนอัลกอริทึมการค้นหา
- ที่ผลลัพธ์ 10,000 เอกสาร ค่ามัธยฐานของ Atlas Search ลดจากราว 2.6 วินาที เหลือ 527 มิลลิวินาที และ Atlas Vector Search ลดจาก 3.1 วินาที เหลือ 561 มิลลิวินาที
- ภายใต้ 16 ไคลเอนต์พร้อมกัน เบนช์มาร์กให้ throughput สูงขึ้นราว 2.75 เท่า และ latency มัธยฐานต่ำลงราว 3 เท่า
- ต้นเหตุคือการสร้าง query plan และขอทรัพยากร collection ซ้ำทุกเอกสาร MongoDB พบว่าใช้ราว 30% ของเวลา CPU บน mongod จึงแคช SBE plan และจัดชุดค้นหาแบบ batch
- การปรับนี้เปิดใช้เป็นค่าเริ่มต้นใน MongoDB 9.0.7 ไม่ต้องเขียนคิวรีใหม่หรือสร้างดัชนีใหม่ และตัวเลขทั้งหมดมาจากเบนช์มาร์กของ MongoDB เอง
MongoDB เผยแพร่บล็อกวิศวกรรมเมื่อ 11 พฤศจิกายน 2026 ว่าการปรับขั้น document lookup ทำให้ MongoDB Atlas Search ($search) เร็วขึ้นสูงสุด 4.9 เท่า และ Atlas Vector Search ($vectorSearch) เร็วขึ้น 5.5 เท่า โดยไม่เปลี่ยนอัลกอริทึมการค้นหา การปรับนี้เปิดเป็นค่าเริ่มต้นใน MongoDB 9.0.7 ไม่ต้องแก้แอป ตัวเลขทั้งหมดมาจากเบนช์มาร์กที่ MongoDB วัดเอง ยังไม่มีผลวัดจากบุคคลที่สาม
หน้าผลิตภัณฑ์ MongoDB Search ของบริษัทระบุว่า Search และ Vector Search เปิดให้ใช้ทั่วไป (GA) ทั้งใน Enterprise Advanced และ Community Edition และให้ใช้ API เดียวกันทั้งงานฐานข้อมูลและงานค้นหา การเร่งความเร็วของ MongoDB Atlas Search ในข่าวนี้จึงเกี่ยวข้องกับผู้ใช้หลายรูปแบบการติดตั้ง
MongoDB Atlas Search ทำงานสองขั้น และขั้นที่สองคือคอขวด
MongoDB อธิบายว่าเมื่อรันคิวรี $search หรือ $vectorSearch มีสองขั้นทำงานร่วมกัน ขั้นแรก mongot ซึ่งเป็นโปรเซสค้นหาที่ใช้ Apache Lucene ค้นและจัดอันดับเอกสารที่ตรงที่สุด ขั้นที่สอง mongod จับคู่ผลการค้นหากับเอกสาร BSON ในคอลเลกชันด้วย _id แล้วส่งผ่านขั้นอื่นของไปป์ไลน์ต่อ ขั้นหลังนี้เรียกว่า document materialization ซึ่งทำงานผ่านขั้นภายในชื่อ $_internalSearchIdLookup
MongoDB พบว่าการค้นหาเองถูกปรับปรุงมามากแล้ว แต่ document lookup กลายเป็นคอขวด เพราะการดำเนินการเดิมสร้างและรันซับไปป์ไลน์ใหม่ทุกเอกสารที่ mongot ส่งกลับ ทั้งที่เปลี่ยนเฉพาะค่า _id แต่ละครั้ง MongoDB ต้องแยกวิเคราะห์คิวรี ปรับไปป์ไลน์ สร้างแผนการรัน ขอทรัพยากรคอลเลกชัน ผูกเคอร์เซอร์ รันการค้น แล้วคืนทรัพยากร คิวรีที่ได้ 1,000 เอกสารจึงวนรอบนี้ 1,000 ครั้ง
MongoDB วัดโปรไฟล์ของงาน Vector Search ใน MongoDB Atlas Search ที่เป็นตัวแทน พบว่าราว 30% ของเวลา CPU บน mongod หมดไปกับการสร้างแผนคิวรีและขอทรัพยากรคอลเลกชัน แทนที่จะอ่านเอกสาร
สองการปรับที่ทำให้ MongoDB Atlas Search เร็วขึ้น
MongoDB ออกแบบ $_internalSearchIdLookup ใหม่รอบสองแนวทาง
- ใช้แผน SBE แบบผูกพารามิเตอร์ซ้ำ ตัวรันใหม่ชื่อ SbeSingleDocumentLookupExecutor สร้างแผน lookup บน Slot-Based Execution (SBE) engine ครั้งเดียว แคชไว้ และผูกค่า _id ใหม่ในแต่ละรอบ การดึง 1,000 เอกสารจึงใช้แผนเดียวแทน 1,000 แผน
- รวม lookup เป็นชุด ขั้น BatchedEnrichmentStage พักผลการค้นไว้แล้วประมวลผลภายในขอบเขตทรัพยากรเดียว ตัวอย่างของ MongoDB คือ 1,000 เอกสารที่ batch ละ 100 ขอทรัพยากรคอลเลกชันเพียง 10 ครั้งแทน 1,000 ครั้ง
จำนวนการ lookup ยังเพิ่มตามจำนวนผลลัพธ์ แต่ค่าใช้จ่ายซ้ำซ้อนในการเตรียมงานลดลงมาก
ตัวเลขจากเบนช์มาร์กของ MongoDB Atlas Search
MongoDB ทดสอบผลลัพธ์ขนาด 100, 1,000 และ 10,000 เอกสาร และรายงานว่า latency ลดลงทุกขนาด ยิ่งผลลัพธ์มากยิ่งเร็วขึ้น
| งาน | ก่อน (มัธยฐาน) | หลังใน MongoDB 9.0 | เร็วขึ้น |
|---|---|---|---|
| Atlas Search ($search) ผลลัพธ์ 10,000 เอกสาร | ราว 2.6 วินาที | 527 มิลลิวินาที | 4.9 เท่า |
| Atlas Vector Search ($vectorSearch) ผลลัพธ์ 10,000 เอกสาร | 3.1 วินาที | 561 มิลลิวินาที | 5.5 เท่า |
ภายใต้ไคลเอนต์ 16 ตัวที่รันงาน $search พร้อมกัน MongoDB รายงาน throughput สูงขึ้นราว 2.75 เท่า และ latency มัธยฐานต่ำลงราว 3 เท่า MongoDB ยังเตือนว่าตัวเลข CPU ราว 30% จากโปรไฟล์กับตัวเลข latency ที่ลดเกือบ 80% จากเบนช์มาร์กเป็นการวัดคนละงาน ไม่ควรนำมาเทียบเป็นสัดส่วนกันตรง ๆ
งานจริงของลูกค้า MongoDB Atlas Search ได้ประโยชน์แค่ไหน
เพื่อดูผลกับงานจริง MongoDB วิเคราะห์การรัน Atlas Vector Search จำนวน 163.8 ล้านครั้งบน 610 คลัสเตอร์ของลูกค้าตลอด 90 วัน พบว่าอย่างน้อย 40% ของคลัสเตอร์ใช้ limit ระหว่าง 21 ถึง 50 และอย่างน้อย 17% ใช้ limit เกิน 100 งานเหล่านี้ได้ประโยชน์มากเพราะต้อง materialize เอกสารจำนวนมากต่อคิวรี MongoDB ระบุว่าการปรับนี้ เปิดเป็นค่าเริ่มต้นใน MongoDB 9.0.7 ไม่ต้องเขียนคิวรีใหม่ สร้างดัชนีใหม่ หรือใช้ไวยากรณ์ใหม่ และไปป์ไลน์ $search กับ $vectorSearch เดิมได้ประโยชน์เมื่อรันบนการตั้งค่าที่รองรับ
สิ่งที่ทีมข้อมูลควรทำกับ MongoDB Atlas Search
- ตรวจรุ่น MongoDB ว่าถึง 9.0.7 หรือไม่ ผู้ใช้ Atlas ควรดูรุ่นที่คลัสเตอร์รันอยู่ ส่วนผู้ที่ติดตั้งเองต้องวางแผนอัปเกรด
- วัดซ้ำกับงานของตัวเอง เพราะผลของ MongoDB Atlas Search ขึ้นกับขนาดผลลัพธ์ ตัวเลข 4.9 และ 5.5 เท่ามาจากเบนช์มาร์กของ MongoDB ที่ผลลัพธ์ 10,000 เอกสาร งานที่ limit น้อยย่อมได้ผลน้อยกว่า
- ดู limit ที่แอปใช้จริง เพราะ MongoDB ระบุว่ายิ่งผลลัพธ์มากยิ่งเห็นผล
- เทียบ latency และ CPU ของ mongod ก่อนและหลังอัปเกรด เพื่อยืนยันว่า MongoDB Atlas Search บนข้อมูลจริงเร็วขึ้นตามที่ผู้ผลิตรายงาน
- ตรวจการตั้งค่าที่รองรับ เพราะ MongoDB ระบุว่าประโยชน์เกิดบนการตั้งค่าที่รองรับ ให้เทียบกับเอกสารของ MongoDB ก่อนวางแผน
บริการของ THAI DATA CLOUD ที่เกี่ยวข้อง
องค์กรที่ใช้ฐานข้อมูลค้นหาและเวกเตอร์กับแอป AI ต้องมีคนดูแลทั้งรอบอัปเกรดและการวัดประสิทธิภาพหลังอัปเกรด Managed Cloud Services ของ THAI DATA CLOUD ดูแลตั้งแต่ติดตั้ง บริหาร ไปจนถึง Monitoring ระบบคลาวด์ขององค์กรตลอด 24 ชั่วโมง ให้ทีมข้อมูลโฟกัสงานพัฒนาได้ (THAI DATA CLOUD เป็นผู้ดำเนินงานเว็บไซต์นี้)
ติดตามข่าวข้อมูลและฐานข้อมูลอื่น ๆ ได้ที่หมวด Data
คำถามที่พบบ่อย
MongoDB Atlas Search เร็วขึ้นเท่าไรใน MongoDB 9.0.7?
ตามเบนช์มาร์กของ MongoDB ที่ผลลัพธ์ 10,000 เอกสาร MongoDB Atlas Search ($search) เร็วขึ้นสูงสุด 4.9 เท่า โดยค่ามัธยฐานลดจากราว 2.6 วินาทีเหลือ 527 มิลลิวินาที ส่วน Vector Search ($vectorSearch) เร็วขึ้น 5.5 เท่า จาก 3.1 วินาทีเหลือ 561 มิลลิวินาที ตัวเลขเหล่านี้เป็นผลวัดของ MongoDB เอง
ทำไม MongoDB Atlas Search จึงเร็วขึ้นโดยไม่เปลี่ยนอัลกอริทึม?
MongoDB พบว่าขั้น document lookup สร้าง query plan และขอทรัพยากร collection ใหม่ทุกครั้งที่ mongod ดึงเอกสารตาม _id จาก mongot กินราว 30% ของเวลา CPU จึงเปลี่ยนให้สร้างแผนครั้งเดียวด้วย SBE plan ที่ผูกพารามิเตอร์ _id ใหม่ และขอทรัพยากรเป็นชุด (batch) แทนทีละเอกสาร
ต้องแก้แอปหรือสร้างดัชนีใหม่หรือไม่?
ไม่ต้อง MongoDB ระบุว่าการปรับ document lookup เปิดใช้เป็นค่าเริ่มต้นใน MongoDB 9.0.7 ไม่ต้องเขียนคิวรีใหม่ สร้างดัชนีค้นหาใหม่ หรือใช้ไวยากรณ์ใหม่ ไปป์ไลน์ $search และ $vectorSearch ที่มีอยู่ได้ประโยชน์เมื่อรันบนการตั้งค่าที่รองรับ
งานแบบไหนได้ประโยชน์จากการปรับของ MongoDB Atlas Search มากที่สุด?
งานที่ดึงผลลัพธ์จำนวนมากต่อคิวรี MongoDB ระบุว่ายิ่งผลลัพธ์มากยิ่งเร็วขึ้น และจากการวิเคราะห์ Vector Search 163.8 ล้านครั้งบน 610 คลัสเตอร์ใน 90 วัน อย่างน้อย 40% ของคลัสเตอร์ใช้ limit 21 ถึง 50 และอย่างน้อย 17% ใช้ limit เกิน 100
แหล่งอ้างอิง
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- องค์กรและบริษัท
- MongoDB9
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ