เรียนรู้วิธีเพิ่ม Meilisearch เข้ากับ backend ของคุณเพื่อการค้นหาที่รวดเร็วและทนต่อการพิมพ์ผิด: การตั้งค่า การทำดัชนี กฎการจัดลำดับ ตัวกรอง ความปลอดภัย และพื้นฐานการสเกล
การค้นหาทางฝั่งเซิร์ฟเวอร์หมายความว่าคำค้นถูกรันบนเซิร์ฟเวอร์ของคุณ (หรือบริการค้นหาเฉพาะ) ไม่ใช่ในเบราว์เซอร์ แอปของคุณส่งคำขอค้นหา เซิร์ฟเวอร์รันคำค้นบนดัชนี แล้วส่งผลลัพธ์ที่จัดลำดับกลับมา
เรื่องนี้สำคัญเมื่อชุดข้อมูลของคุณใหญ่เกินกว่าจะส่งไปยังไคลเอนต์ทั้งหมด เมื่อคุณต้องการความสม่ำเสมอของความเกี่ยวข้องข้ามแพลตฟอร์ม หรือเมื่อการควบคุมการเข้าถึงเป็นสิ่งที่ไม่สามารถต่อรองได้ (เช่น เครื่องมือภายในที่ผู้ใช้ควรเห็นเฉพาะสิ่งที่อนุญาต) นอกจากนี้ยังเป็นตัวเลือกเริ่มต้นเมื่อคุณต้องการการเก็บสถิติ การล็อก และประสิทธิภาพที่คาดการณ์ได้
ผู้คนไม่ได้คิดถึงเอนจินการค้นหา พวกเขาตัดสินจากประสบการณ์ การไหลของการค้นหาแบบ “ทันที” ที่ดีมักหมายถึง:
ถ้าขาดสิ่งใดสิ่งหนึ่ง ผู้ใช้มักพยายามคำค้นต่าง ๆ เลื่อนมากขึ้น หรือยอมแพ้การค้นหาไปเลย
บทความนี้เป็นการเดินผ่านเชิงปฏิบัติสำหรับการสร้างประสบการณ์นั้นด้วย Meilisearch เราจะครอบคลุมการติดตั้งอย่างปลอดภัย วิธีจัดโครงสร้างและซิงก์ข้อมูลที่ทำดัชนี วิธีปรับความเกี่ยวข้องและกฎการจัดลำดับ วิธีเพิ่มตัวกรอง/การเรียง/ฟาซิท และการคิดเรื่องความปลอดภัยและการสเกลเพื่อให้การค้นหายังคงเร็วเมื่อแอปของคุณเติบโต
Meilisearch เหมาะอย่างยิ่งสำหรับ:
เป้าหมายตลอดคือ: ผลลัพธ์ที่รู้สึกทันที ถูกต้อง และเชื่อถือได้—โดยไม่ทำให้การค้นหาเป็นโปรเจกต์วิศวกรรมขนาดใหญ่
Meilisearch คือเอนจินการค้นหาที่คุณรันคู่กับแอปของคุณ คุณส่งเอกสาร (เช่น สินค้า บทความ ผู้ใช้ หรือบัตรสนับสนุน) และมันสร้างดัชนีที่ปรับแต่งมาเพื่อการค้นหาที่รวดเร็ว backend ของคุณ (หรือ frontend) จะสอบถาม Meilisearch ผ่าน HTTP API แบบเรียบง่ายแล้วได้รับผลลัพธ์ที่จัดลำดับภายในมิลลิวินาที
Meilisearch มุ่งเน้นที่คุณสมบัติที่ผู้ใช้คาดหวังจากการค้นหาร่วมสมัย:
ออกแบบมาให้รู้สึกตอบสนองและยืดหยุ่น แม้คำค้นจะสั้น ผิดเล็กน้อย หรือกำกวม
Meilisearch ไม่ใช่ตัวแทนฐานข้อมูลหลักของคุณ ฐานข้อมูลของคุณยังเป็นแหล่งความจริงสำหรับการเขียน ธุรกรรม และข้อจำกัด Meilisearch เก็บสำเนาของฟิลด์ที่คุณเลือกให้ค้นหา กรอง หรือแสดงได้
โมเดลคิดที่ดีคือ: ฐานข้อมูลเพื่อเก็บและอัปเดตข้อมูล, Meilisearch เพื่อค้นหาอย่างรวดเร็ว
Meilisearch สามารถเร็วมาก แต่ผลลัพธ์ขึ้นกับปัจจัยบางอย่าง:
สำหรับชุดข้อมูลขนาดเล็กถึงกลาง คุณมักรันบนเครื่องเดียวได้ เมื่อดัชนีใหญ่ขึ้น คุณจะต้องคิดอย่างรอบคอบเกี่ยวกับสิ่งที่ทำดัชนีและวิธีซิงก์—ซึ่งเราจะพูดถึงในส่วนถัดไป
ก่อนติดตั้ง ตัดสินใจว่าคุณจะค้นหาอะไรจริง ๆ Meilisearch จะรู้สึก “ทันที” ก็ต่อเมื่อดัชนีและเอกสารสอดคล้องกับวิธีที่ผู้คนเรียกดูแอปของคุณ
เริ่มจากการระบุเอนทิตีที่ต้องการค้นหา—โดยปกติคือ products, articles, users, help docs, locations เป็นต้น ในหลายแอป วิธีที่ชัดเจนคือ หนึ่งดัชนีต่อประเภทเอนทิตี (เช่น products, articles) เพราะจะทำให้กฎการจัดลำดับและตัวกรองคาดการณ์ได้
ถ้าประสบการณ์ผู้ใช้ค้นหาข้ามหลายประเภทในช่องเดียว (“ค้นหาทุกอย่าง”) คุณยังสามารถเก็บดัชนีแยกกันแล้วรวมผลใน backend หรือสร้างดัชนี "global" เฉพาะภายหลัง อย่าบังคับทุกอย่างเข้าไปในดัชนีเดียวถ้าฟิลด์และตัวกรองไม่สอดคล้องกันจริงๆ
แต่ละเอกสารต้องมีตัวระบุที่เสถียร (primary key) เลือกสิ่งที่:\n
id, sku, slug)\n
สำหรับรูปร่างเอกสาร แนะนำให้ใช้ ฟิลด์แบบแบน เมื่อเป็นไปได้ โครงสร้างแบนง่ายต่อการกรองและเรียงลำดับ ฟิลด์ซ้อนเป็นอ็อบเจกต์ก็รับได้เมื่อเป็นกลุ่มที่แน่นและไม่เปลี่ยนแปลงมาก (เช่น author object) แต่หลีกเลี่ยงการซ้อนลึกที่สะท้อนสกีมาเชิงสัมพันธ์ทั้งชุด—เอกสารสำหรับการค้นหาควรถูกออกแบบให้ อ่านได้เร็ว ไม่ใช่เหมือนฐานข้อมูลวิธีปฏิบัติที่ใช้ได้คือแท็กแต่ละฟิลด์ด้วยบทบาท:\n
“ภาษา” อาจหมายถึงหลายสิ่งในข้อมูลของคุณ:\n
lang: "en")\n- โลเคลของผู้ใช้ (ภาษา UI)\n- ฟิลด์ผสมหลายภาษา (ชื่อสินค้าที่เก็บหลายภาษา)\n
ตัดสินใจตั้งแต่ต้นว่าคุณจะใช้ ดัชนีแยกตามภาษา (เรียบง่ายและคาดการณ์ได้) หรือ ดัชนีเดียวที่มีฟิลด์ภาษา (ดัชนีน้อยลง แต่ต้องมีตรรกะมากขึ้น) คำตอบขึ้นกับว่าผู้ใช้ค้นหาภายในภาษาหนึ่งในแต่ละครั้งหรือไม่ และคุณเก็บการแปลอย่างไรการรัน Meilisearch ตรงไปตรงมา แต่ “ปลอดภัยโดยดีฟอลต์” ต้องมีการตัดสินใจบางอย่าง: จะ deploy ที่ไหน จะเก็บข้อมูลอย่างไร และจัดการ master key อย่างไร
การจัดเก็บ: Meilisearch เขียนดัชนีลงดิสก์ วางไดเรกทอรีข้อมูลบน storage ที่เชื่อถือได้และถาวร (ไม่ใช่ storage ของคอนเทนเนอร์ที่หายได้) วางแผนความจุสำหรับการเติบโต: ดัชนีอาจขยายเร็วเมื่อมีฟิลด์ข้อความขนาดใหญ่และแอตทริบิวต์มาก
หน่วยความจำ: จัดสรร RAM เพียงพอให้การค้นหาตอบสนองภายใต้โหลด ถ้าพบการสว็อป ประสิทธิภาพจะเสีย
สำรองข้อมูล: สำรองไดเรกทอรีข้อมูลของ Meilisearch (หรือใช้ snapshot ที่ชั้น storage) ทดสอบการกู้คืนอย่างน้อยหนึ่งครั้ง; การสำรองที่กู้คืนไม่ได้ก็แค่ไฟล์
มอนิเตอร์: ติดตาม CPU, RAM, การใช้ดิสก์ และ I/O ดิสก์ นอกจากนี้มอนิเตอร์สถานะ process และบันทึกข้อผิดพลาด อย่างน้อยตั้งการแจ้งเตือนเมื่อบริการหยุดหรือพื้นที่ดิสก์ใกล้หมด
ให้รัน Meilisearch พร้อม master key เสมอในสภาพแวดล้อมที่ไม่ใช่การพัฒนาเกือบจะทุกรณี เก็บคีย์ใน secret manager หรือระบบจัดเก็บ env ที่เข้ารหัส (ไม่ใส่ใน Git, ไม่เก็บ .env แบบ plain-text ที่ commit เข้า repo)
ตัวอย่าง (Docker):
docker run -d --name meilisearch \
-p 7700:7700 \
-v meili_data:/meili_data \
-e MEILI_MASTER_KEY="$(openssl rand -hex 32)" \
getmeili/meilisearch:latest
นอกจากนี้พิจารณากฎเครือข่าย: ผูกที่อินเทอร์เฟซส่วนตัวหรือจำกัดการเข้าถึงเข้าโดยให้เฉพาะ backend ของคุณเท่านั้นที่สามารถเข้าถึง Meilisearch ได้
curl -s http://localhost:7700/version
การทำดัชนีใน Meilisearch เป็นแบบอะซิงโครนัส: คุณส่งเอกสาร Meilisearch จะคิวงานและก็ต่อเมื่อ task นั้นสำเร็จเอกสารจึงค้นหาได้ ปฏิบัติกับการทำดัชนีเหมือนระบบงาน ไม่ใช่คำขอเดี่ยว
id)curl -X POST 'http://localhost:7700/indexes/products/documents?primaryKey=id' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer YOUR_WRITE_KEY' \
--data-binary @products.json
taskUid ตรวจสอบจนกว่าจะเป็น succeeded (หรือ failed)curl -X GET 'http://localhost:7700/tasks/123' \
-H 'Authorization: Bearer YOUR_WRITE_KEY'
curl -X GET 'http://localhost:7700/indexes/products/stats' \
-H 'Authorization: Bearer YOUR_WRITE_KEY'
ถ้าจำนวนไม่ตรง อย่าเดา—ตรวจรายละเอียดข้อผิดพลาดของ task ก่อน
การแบตช์คือการทำให้ task คาดเดาได้และกู้คืนได้
addDocuments ทำงานเหมือน upsert: เอกสารที่มี primary key เดิมจะถูกอัปเดต เอกสารใหม่จะถูกแทรก ใช้สำหรับการอัปเดตปกติ
ทำ reindex ทั้งหมด เมื่อ:
สำหรับการลบ ให้เรียก deleteDocument(s) โดยตรง มิฉะนั้นระเบียนเก่าอาจคงอยู่
การทำดัชนีควร retry ได้ กุญแจคือ id เอกสารที่เสถียร
taskUid ที่ส่งกลับควบคู่กับ id งานของคุณ และ retry ตามสถานะ taskก่อนข้อมูลจริง ให้ทำดัชนีชุดข้อมูลเล็ก (200–500 รายการ) ที่มีฟิลด์เหมือนจริง ตัวอย่าง: ชุด products ที่มี id, name, description, category, brand, price, inStock, createdAt เพียงพอที่จะยืนยันโฟลว์ task จำนวน และพฤติกรรมอัปเดต/ลบ—โดยไม่ต้องรอการนำเข้าขนาดใหญ่
“ความเกี่ยวข้อง” ก็คือ: อะไรแสดงขึ้นก่อน และเพราะเหตุใด Meilisearch ทำให้สิ่งนี้ปรับได้โดยไม่ต้องให้คุณสร้างระบบสกอร์เอง
การตั้งค่าสองอย่างกำหนดสิ่งที่ Meilisearch สามารถทำกับเนื้อหาของคุณ:
searchableAttributes: ฟิลด์ที่ Meilisearch จะค้นหาเมื่อลูกค้าพิมพ์คำค้น (เช่น: title, summary, tags) ลำดับมีความหมาย: ฟิลด์ที่อยู่ก่อนจะสำคัญกว่าdisplayedAttributes: ฟิลด์ที่ส่งกลับมาในคำตอบ สำคัญเรื่องความเป็นส่วนตัวและขนาด payload—ถ้าฟิลด์ไม่อยู่ในนี้ จะไม่ถูกส่งกลับแนวปฏิบัติพื้นฐานคือทำให้ฟิลด์ที่มีสัญญาณสูงไม่กี่ฟิลด์สามารถค้นหาได้ (title, ข้อความสำคัญ) และเก็บ displayed fields ไว้เฉพาะที่ UI ต้องการ
Meilisearch จัดเรียงเอกสารที่ตรงกันโดยใช้ ranking rules—เป็นท่อของตัว “ตัดสินเมื่อเสมอกัน” แนวคิดคือมันจะชอบ:
คุณไม่ต้องจำรายละเอียดทั้งหมดเพื่อปรับแต่งอย่างมีประสิทธิภาพ; คุณแค่เลือก ฟิลด์ไหนสำคัญ และ เมื่อใดควรใช้การเรียงแบบกำหนดเอง
เป้าหมาย: “การตรงกับ title ควรชนะ” ให้ title อยู่ก่อน:
{
"searchableAttributes": ["title", "subtitle", "description", "tags"]
}
เป้าหมาย: “เนื้อหาใหม่ควรอยู่ก่อน” เพิ่มกฎการเรียงและเรียงที่เวลาคำขอ (หรือกำหนด ranking แบบกำหนดเอง):
{
"sortableAttributes": ["publishedAt"],
"rankingRules": ["sort", "typo", "words", "proximity", "attribute", "exactness"]
}
แล้วเรียก:
{ "q": "release notes", "sort": ["publishedAt:desc"] }
เป้าหมาย: “โปรโมตสินค้ายอดนิยม” ทำให้ popularity เป็น sortable แล้วเรียงตามเมื่อเหมาะสม
เลือก 5–10 คำค้นจริงที่ผู้ใช้พิมพ์ บันทึกผลลัพธ์อันดับต้นก่อนเปลี่ยน จากนั้นเปรียบเทียบหลังการเปลี่ยน
ตัวอย่าง:
"apple" → Apple Watch band, Pineapple slicer, Apple iPhone case"apple" → Apple iPhone case, Apple Watch band, Pineapple slicerถ้าผลหลังตรงกับความตั้งใจของผู้ใช้มากกว่า ให้เก็บการตั้งค่านั้น ถ้าทำให้กรณีพิเศษแย่ลง ให้ปรับทีละอย่าง (ลำดับแอตทริบิวต์ แล้วกฎการเรียง) เพื่อจะได้รู้ว่าการปรับใดทำให้ดีขึ้น
ช่องค้นหาที่ดีไม่ใช่แค่ “พิมพ์คำแล้วได้ผล” ผู้ใช้ยังต้องการจำกัดผล (“เฉพาะสินค้าที่พร้อมจำหน่าย”) และเรียงลำดับ (“ถูกที่สุดก่อน”) ใน Meilisearch ทำได้ด้วย filters, sorting, และ facets
Filter คือกฎที่ใช้กับชุดผลลัพธ์ Facet คือสิ่งที่แสดงใน UI เพื่อช่วยผู้ใช้สร้างกฎเหล่านั้น (มักเป็นกล่องเช็กหรือจำนวน)
ตัวอย่างที่ไม่เชิงเทคนิค:
ผู้ใช้อาจค้นหา “running” แล้วกรองเป็น category = Shoes และ status = in_stock ฟาซิทจะแสดงจำนวนเช่น “Shoes (128)” และ “Jackets (42)” เพื่อให้ผู้ใช้เห็นว่ามีอะไรบ้าง
Meilisearch ต้องให้คุณเปิดใช้งานฟิลด์ที่ใช้สำหรับการกรองและการเรียง
category, status, brand, price, created_at, tenant_idprice, rating, created_at, popularityเก็บรายการนี้ให้กระชับ การทำทุกอย่างเป็น filterable/sortable จะเพิ่มขนาดดัชนีและช้าในการอัปเดต
แม้จะมีการแมตช์ 50,000 รายการ ผู้ใช้เห็นแค่หน้าแรก ใช้หน้าขนาดเล็ก (บ่อยครั้ง 20–50 ผลลัพธ์) ตั้ง limit ที่สมเหตุสมผล และแบ่งหน้าด้วย offset (หรือคุณสมบัติการแบ่งหน้าที่ใหม่กว่า) นอกจากนี้กำหนดความลึกหน้าสูงสุดในแอปของคุณเพื่อป้องกันคำขอที่แพงเกินไป เช่น “หน้า 400”
วิธีที่ชัดเจนในการเพิ่มการค้นหาทางฝั่งเซิร์ฟเวอร์คือปฏิบัติต่อ Meilisearch เป็นบริการข้อมูลเฉพาะด้านอยู่หลัง API ของคุณ แอปของคุณรับคำขอค้นหา เรียก Meilisearch แล้วส่งผลลัพธ์ที่คัดกรองกลับไปยังไคลเอนต์
ทีมส่วนใหญ่จะใช้โฟลว์แบบนี้:
GET /api/search?q=wireless+headphones&limit=20).รูปแบบนี้ทำให้ Meilisearch แทนที่ได้ง่ายและป้องกันโค้ด frontend พึ่งพาโครงสร้างดัชนีโดยตรง
ถ้าคุณกำลังสร้างแอปใหม่ (หรือสร้างเครื่องมือภายในใหม่) และต้องการรูปแบบนี้เร็ว ๆ แพลตฟอร์มสร้างโค้ดอย่าง Koder.ai สามารถช่วย scaffold โฟลว์เต็ม—React UI, Go backend, และ PostgreSQL—แล้วรวม Meilisearch อยู่หลัง endpoint เดียว /api/search เพื่อให้ไคลเอนต์เรียบง่ายและสิทธิ์การเข้าถึงอยู่ฝั่งเซิร์ฟเวอร์
Meilisearch รองรับการสอบถามจากฝั่งไคลเอนต์ แต่การสอบถามจาก backend มักปลอดภัยกว่าเพราะ:
การสอบถามจาก frontend ยังใช้ได้สำหรับข้อมูลสาธารณะที่ใช้คีย์จำกัด แต่ถ้ามีกฎการมองเห็นเฉพาะผู้ใช้ ให้ส่งผ่านเซิร์ฟเวอร์
การจราจรการค้นหามักซ้ำกัน (“iphone case”, “return policy”) เพิ่มการแคชที่เลเยอร์ API ของคุณ:
ปฏิบัติต่อการค้นหาเป็น endpoint ที่เปิดสาธารณะ:
limit สูงสุด และความยาวคำค้นสูงสุดMeilisearch มักถูกวางไว้ "ข้างหลัง" แอปของคุณเพราะมันสามารถส่งข้อมูลธุรกิจที่ละเอียดอ่อนได้อย่างเร็ว ปฏิบัติเหมือนฐานข้อมูล: ล็อกมันไว้ และเปิดเผยเฉพาะสิ่งที่ผู้เรียกควรเห็น
Meilisearch มี master key ที่ทำได้ทุกอย่าง: สร้าง/ลบดัชนี อัปเดตการตั้งค่า และอ่าน/เขียนเอกสาร เก็บไว้เฉพาะฝั่งเซิร์ฟเวอร์
สำหรับแอป ให้สร้าง API keys ที่สิทธิจำกัดและจำกัดดัชนี ตัวอย่างที่พบบ่อย:
หลัก least privilege หมายความว่าถ้าคีย์รั่ว จะไม่สามารถลบข้อมูลหรืออ่านดัชนีที่ไม่เกี่ยวข้องได้
ถ้าคุณให้บริการหลายลูกค้า (เทนแนนท์) มีสองทางเลือกหลัก:
1) หนึ่งดัชนีต่อเทนแนนท์.
ง่ายในการคิดและลดความเสี่ยงการเข้าถึงข้ามเทนแนนท์ ข้อเสีย: มีดัชนีมากขึ้นให้จัดการ และต้องอัปเดตการตั้งค่าอย่างสม่ำเสมอ
2) ดัชนีรวม + ตัวกรอง tenantId.
เก็บฟิลด์ tenantId ในเอกสารทุกชิ้นและบังคับตัวกรองเช่น tenantId = "t_123" สำหรับทุกการค้นหา สามารถสเกลได้ดี แต่ต้องแน่ใจว่าทุกคำขอใช้ตัวกรองเสมอ (ควรใช้คีย์ที่ถูกจำกัดเพื่อไม่ให้ผู้เรียกลบตัวกรองได้)
แม้การค้นหาถูกต้อง ผลลัพธ์อาจรั่วฟิลด์ที่คุณไม่ต้องการแสดง (อีเมล โน้ตภายใน ราคาต้นทุน) กำหนดว่าอะไรดึงกลับได้:
ทำเทสต์ "กรณีแย่สุด" อย่างรวดเร็ว: ค้นหาคำธรรมดาและยืนยันว่าไม่มีฟิลด์ส่วนตัวปรากฏ
ถ้าไม่แน่ใจว่าคีย์ควรอยู่ฝั่งไคลเอนต์หรือไม่ ให้สมมติว่า "ไม่" และเก็บการค้นหาฝั่งเซิร์ฟเวอร์
Meilisearch เร็วเมื่อคุณคำนึงถึงสองงาน: การทำดัชนี (การเขียน) และ คำค้น (การอ่าน) ปัญหาช้าโดยส่วนใหญ่เกิดจากงานทั้งสองแข่งกันใช้ CPU, RAM, หรือดิสก์
โหลดการทำดัชนี อาจพุ่งเมื่อคุณนำเข้าชุดใหญ่ อัปเดตบ่อย หรือเพิ่มฟิลด์ searchable มาก การทำดัชนีเป็นงานพื้นหลัง แต่ยังบริโภค CPU และแบนด์วิดท์ดิสก์ ถ้าคิวงานเพิ่ม การค้นหาอาจเริ่มช้าลงแม้ปริมาณคำค้นไม่เปลี่ยน
โหลดคำค้น โตตามทราฟฟิก แต่ฟีเจอร์ต่าง ๆ ก็เพิ่มงานต่อคำขอ: ตัวกรองมากขึ้น ฟาซิทมากขึ้น ชุดผลลัพธ์ใหญ่ขึ้น และการทนต่อการพิมพ์ผิดที่ละเอียดขึ้น ล้วนเพิ่มงานต่อคำขอ
ดิสก์ I/O เป็นผู้ร้ายเงียบ ดิสก์ช้า (หรือเพื่อนร่วมห้อง noisy neighbors บน shared volume) อาจเปลี่ยน "ทันที" ให้เป็น "ในที่สุด" NVMe/SSD เป็นฐานมาตรฐานสำหรับ production
เริ่มจากการกำหนดขนาดอย่างง่าย: ให้ Meilisearch RAM เพียงพอเพื่อให้ดัชนีอยู่ในหน่วยความจำและ CPU เพียงพอเพื่อรับ QPS สูงสุด จากนั้นแยกความกังวล:
ติดตามชุดสัญญาณเล็ก ๆ:
การสำรองควรเป็นกิจวัตร ใช้ฟีเจอร์ snapshot ของ Meilisearch เป็นตารางเวลา เก็บ snapshot นอกระบบ และทดสอบการกู้คืนเป็นระยะ สำหรับการอัปเกรด อ่าน release notes ทดสอบใน non-prod และวางแผนเวลาสำหรับการ reindex ถ้าการเปลี่ยนเวอร์ชันมีผลต่อพฤติกรรมการทำดัชนี
ถ้าคุณใช้ snapshot ของสภาพแวดล้อมและ rollback ในแพลตฟอร์มแอปของคุณ ให้สอดคล้องการเปิดใช้ search กับวินัยเดียวกัน: snapshot ก่อนเปลี่ยน ยืนยัน health checks และมีทางกลับสู่สถานะที่ใช้งานได้เร็ว
แม้จะรวมได้เรียบร้อย ปัญหาการค้นหามักตกอยู่ในไม่กี่กลุ่มที่ซ้ำได้ ข่าวดีก็คือ Meilisearch ให้การมองเห็นเพียงพอ (tasks, logs, การตั้งค่าที่กำหนดได้) เพื่อดีบักอย่างรวดเร็ว—ถ้าคุณทำอย่างเป็นระบบ
filterableAttributes, หรือเอกสารเก็บค่าในรูปแบบที่ไม่คาดคิด (string vs array vs nested object)sortableAttributes/rankingRules ทำให้รายการผิดขึ้นมาเริ่มจากการตรวจว่า Meilisearch รับการเปลี่ยนแปลงล่าสุดของคุณแล้วหรือไม่
filter, แล้ว sort, แล้ว facets.ถ้าอธิบายผลลัพธ์ไม่ได้ ให้ชะลอการตั้งค่ากลับชั่วคราว: เอา synonyms ออก ลดการปรับแต่ง ranking แล้วทดสอบกับชุดข้อมูลเล็ก ๆ ปัญหาความเกี่ยวข้องซับซ้อนจะเห็นง่ายกว่าบน 50 เอกสารมากกว่า 5 ล้าน
your_index_v2 ขนานไปกับตัวเก่า ตั้งค่าการตั้งค่า แล้วเล่นซ้ำตัวอย่างคำค้นจาก productionfilterableAttributes และ sortableAttributes ตรงกับความต้องการ UIRelated guides: search reliability, indexing patterns, and production rollout tips.
การค้นหาทางฝั่งเซิร์ฟเวอร์หมายถึงคำค้นถูกรันบน backend ของคุณ (หรือบริการค้นหาแยกต่างหาก) แทนที่จะรันในเบราว์เซอร์ เหมาะเมื่อ:
ผู้ใช้สังเกตสี่อย่างทันที:
ถ้าขาดอย่างใดอย่างหนึ่ง ผู้ใช้มักจะพิมพ์คำค้นใหม่ เลื่อนมากขึ้น หรือละทิ้งการค้นหา
ใช้ Meilisearch เป็น ดัชนีการค้นหา ไม่ใช่แหล่งข้อมูลหลัก ฐานข้อมูลของคุณยังคงเป็นแหล่งความจริงสำหรับการเขียน ธุรกรรม และข้อจำกัด Meilisearch เก็บสำเนาของฟิลด์ที่คุณเลือกให้ค้นหา กรอง หรือแสดงได้
โมเดลง่าย ๆ:
ค่าเริ่มต้นที่ค่อนข้างดีคือ หนึ่งดัชนีต่อประเภทเอนทิตี (เช่น products, articles) เพราะจะช่วยให้:
ถ้าต้องการ “ค้นหาทุกอย่าง” คุณสามารถสอบถามหลายดัชนีแล้วรวมผลใน backend หรือสร้างดัชนีรวมภายหลัง
เลือก primary key ที่:
id, sku, slug)ID ที่คงที่ทำให้การอัปโหลดเป็น idempotent: หาก retry จะไม่สร้างระเบียนซ้ำเพราะจะเป็น upsert
แยกฟิลด์ตามจุดประสงค์เพื่อลดการทำดัชนีเกินความจำเป็น:
การกำหนดบทบาทช่วยลดผลลัพธ์ที่เสียง่ายและป้องกันดัชนีใหญ่เกินความจำเป็น
การทำดัชนีเป็นแบบ อะซิงโครนัส: การอัปโหลดเอกสารจะสร้าง task ขึ้นมา เอกสารจะค้นหาได้ก็ต่อเมื่อ task นั้นสำเร็จแล้ว
ลำดับที่ควรทำ:
succeeded หรือ failedถ้าผลดูเก่า ให้ตรวจสอบสถานะ task ก่อน
ใช้ หลายๆ ชุดที่เล็กกว่า ดีกว่าการอัปโหลดครั้งใหญ่เกินไป จุดเริ่มต้นที่แนะนำ:
แบตช์เล็ก retry ง่ายกว่า และหาจุดบกพร่องได้สะดวกกว่า
สองส่วนที่ปรับได้ผลมาก:
searchableAttributes: ฟิลด์ที่ถูกค้นหา และลำดับความสำคัญของมันpublishedAt, price, popularityวิธีปฏิบัติ: เก็บ 5 10 คำค้นของผู้ใช้จริง บันทึกผลก่อนเปลี่ยน ตั้งค่าหนึ่งอย่าง แล้วเปรียบเทียบผลหลังการเปลี่ยน
ปัญหาส่วนใหญ่มาจากการตั้งค่าไม่ครบ:
filterableAttributes เพื่อใช้ตัวกรองsortableAttributes เพื่อใช้การเรียงตรวจสอบรูปแบบค่าฟิลด์ในเอกสาร (string vs array vs nested object) ถ้าตัวกรองล้มเหลว ให้ตรวจสอบสถานะ task ล่าสุดและยืนยันว่าเอกสารมีค่าฟิลด์ที่คาดไว้