การค้นหาแบบ Full Text ใน Postgres: Elasticsearch เทียบกับทางเลือกอื่น

การค้นหาแบบ Full Text (Full Text Search)

• การค้นหาแบบ Full Text คือเทคนิคในการค้นหารายการจากชุดข้อความตามการมีอยู่ของคีย์เวิร์ดและวลีที่กำหนด
• เสิร์ชเอนจินส่วนใหญ่ เช่น Elasticsearch ใช้อัลกอริทึม BM25 เพื่อจัดอันดับผลการค้นหา
  • BM25 พิจารณาทั้งความถี่ที่คำปรากฏ และความเฉพาะตัวของคำนั้นเมื่อเทียบกับเอกสารทั้งหมด
• การค้นหาแบบ Full Text แตกต่างจากการค้นหาความคล้ายคลึงหรือการค้นหาแบบเวกเตอร์ ซึ่งใช้ค้นหาและจัดอันดับผลลัพธ์ตามความหมายเชิงนัย
• แอปพลิเคชันสมัยใหม่จำนวนมากมักผสานการค้นหาแบบ Full Text และการค้นหาความคล้ายคลึงเข้าด้วยกัน ซึ่งเรียกว่าการค้นหาแบบไฮบริด และช่วยให้ได้ผลลัพธ์ที่แม่นยำยิ่งขึ้น

Postgres FTS

ข้อดี

1. ความเรียบง่าย

   • Postgres FTS ไม่ต้องใช้อินฟราสตรักเจอร์เพิ่มเติม และใช้งานได้กับบริการ Postgres แบบมีผู้ดูแลจัดการทุกประเภท เช่น AWS RDS
   • ในระยะยาว คุณไม่จำเป็นต้องออร์เคสเตรตและดูแลเสิร์ชเอนจินภายนอก ซึ่งช่วยประหยัดทั้งเวลาและภาระในการตัดสินใจได้มาก

2. การค้นหาแบบเรียลไทม์

   • ใน Postgres FTS ข้อมูลสามารถถูกค้นหาได้ทันทีหลัง commit
   • สิ่งนี้มีประโยชน์มากสำหรับองค์กรที่สร้างประสบการณ์การค้นหาสำหรับผู้ใช้ หรือการค้นหาที่ไวต่อ latency เช่น เว็บไซต์อีคอมเมิร์ซหรือฟินเทค

3. ธุรกรรมของ Postgres และ MVCC

   • ธุรกรรมแบบ ACID และการควบคุมการทำงานพร้อมกันหลายเวอร์ชัน (MVCC) ของ Postgres ช่วยรับประกันความน่าเชื่อถือของผลลัพธ์ FTS เมื่อมีการเข้าถึงพร้อมกันและมีการอัปเดตบ่อยครั้ง

ข้อเสีย

1. ฟีเจอร์ไม่ครบถ้วน

   • ชุดความสามารถที่จำกัดของ Postgres FTS อาจเป็นปัจจัยที่ทำให้บางองค์กรตัดออกจากตัวเลือกได้เลย
   • ฟีเจอร์ที่ขาดไป ได้แก่ การให้คะแนนแบบ BM25, การปรับแต่งความเกี่ยวข้อง, tokenizer แบบกำหนดเอง และ faceting

2. ประสิทธิภาพลดลงกับชุดข้อมูลขนาดใหญ่

   • Postgres FTS ทำงานได้ดีกับตารางที่มีข้อมูลระดับหลายล้านแถว แต่เมื่อเป็นตารางระดับหลายสิบล้านแถว ประสิทธิภาพจะลดลงอย่างมาก

3. ภาระเพิ่มเติมของธุรกรรม

   • การสร้างดัชนี GIN บนคอลัมน์จะเพิ่ม latency เล็กน้อยให้กับธุรกรรมที่กระทบคอลัมน์นั้น โดยทั่วไปอยู่ในระดับมิลลิวินาที

สรุปสำคัญ

• Postgres FTS เหมาะอย่างยิ่งสำหรับการค้นหาในตารางขนาดเล็กถึงขนาดกลางที่ไม่ต้องการคำสั่งค้นหา FTS ที่ซับซ้อน
• คำว่า “ขนาดกลาง” และ “ซับซ้อน” ถูกใช้แบบตั้งใจให้กว้าง เพราะขึ้นอยู่กับข้อกำหนดด้านประสิทธิภาพ
• โชคดีที่การทดสอบและการย้ายไปยัง/ออกจาก Postgres FTS ทำได้ง่ายมาก

Elasticsearch

ข้อดี

1. ชุดความสามารถที่ครอบคลุม

   • Elasticsearch รองรับคำสั่งค้นหา FTS ได้แทบทุกแบบ
   • Elastic Query DSL (domain-specific language) ถือเป็นมาตรฐานของความสามารถด้านการค้นหาแบบ Full Text

2. ประสิทธิภาพสูง

   • จากการทดสอบ benchmark, Elasticsearch สามารถคิวรีข้อมูลระดับหลายพันล้านแถวได้ในระดับมิลลิวินาที ด้วยเสิร์ชเอนจิน Lucene ที่ผ่านการใช้งานจริงมาอย่างหนักและสถาปัตยกรรมแบบกระจาย

3. มากกว่าการค้นหา

   • นอกจาก FTS แล้ว Elasticsearch ยังเป็นทั้งเอนจินสำหรับคิวรีเชิงวิเคราะห์, ฐานข้อมูลเวกเตอร์, รวมถึงแพลตฟอร์มด้านความปลอดภัยและ observability
   • หลายองค์กรชื่นชอบความเรียบง่ายจากการรวมหลายบริการไว้ภายใน Elasticsearch

ข้อเสีย

1. ไม่ใช่ data store ที่เชื่อถือได้

   • มีหลายกรณีที่องค์กรเสียใจภายหลังที่ตัดสินใจใช้ Elasticsearch เป็น data store หลัก
   • นี่ไม่ใช่วิธีที่แนะนำ Elasticsearch ขาดทั้งธุรกรรมแบบ ACID และ MVCC ทำให้เกิดความไม่สอดคล้องของข้อมูลและการสูญหายของข้อมูลได้ อีกทั้งยังขาดคุณสมบัติเชิงสัมพันธ์และความสอดคล้องแบบเรียลไทม์ จึงทำให้คิวรีฐานข้อมูลจำนวนมากทำได้ยาก

2. ต้องมี ETL pipeline

   • เนื่องจาก Elasticsearch ไม่ใช่ data store ที่เชื่อถือได้ องค์กรที่ใช้ Postgres จึงมักทำกระบวนการ extract, transform, load (ETL) ข้อมูลจาก Postgres ไปยัง Elasticsearch
   • ความล้มเหลวของ ETL pipeline อาจนำไปสู่ปัญหาในระบบ production ได้หลายรูปแบบ จึงต้องดูแลอย่างระมัดระวังเพื่อให้การเปลี่ยนแปลงในสคีมาของ Postgres ต้นทางไม่ทำให้ pipeline พัง

3. ความสดใหม่ของข้อมูลลดลง

   • งาน ETL ใช้เวลานานและรันเป็นรอบ
   • ข้อมูลที่ไปถึง Elasticsearch มักช้ากว่าใน Postgres อยู่หลายชั่วโมง
   • สำหรับแอปพลิเคชันที่ต้องการค้นหาแบบเรียลไทม์บนตารางของ Postgres เรื่องนี้อาจเป็นข้อห้ามสำคัญ

4. ต้นทุน

   • น่าแปลกที่ได้ยินจากหลายองค์กรว่า Elasticsearch กลายเป็นหนึ่งในรายการค่าใช้จ่ายด้านซอฟต์แวร์ที่ใหญ่ที่สุด
   • เมื่อค่าใช้จ่ายของคลัสเตอร์ Elasticsearch พุ่งสูงขึ้น หลายองค์กรจึงย้ายจาก Elasticsearch Cloud มาสู่การดูแลเอง ซึ่งลดค่าใช้จ่ายบนคลาวด์ได้ แต่ก็สร้างปัญหาใหม่ตามมา
   • Elasticsearch มีชื่อเสียงว่าใช้งาน ปรับจูน และดูแลจัดการได้ยากมาก
   • องค์กรเหล่านี้จึงต้องจ้างวิศวกรราคาแพงมาดูแลคลัสเตอร์ Elasticsearch

สรุปสำคัญ

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

เสิร์ชเอนจินทางเลือก

• ในช่วงไม่กี่ปีที่ผ่านมา มีเสิร์ชเอนจินสมัยใหม่อย่าง Algolia, Meilisearch และ Typesense เกิดขึ้น
• เอนจินเหล่านี้โดยทั่วไปถูกใช้เพื่อสร้างประสบการณ์การค้นหาที่ผู้ใช้เข้าถึงโดยตรง
• ระบบค้นหาของ Hacker News ก็สร้างอยู่บน Algolia
• แต่ละบริการมีจุดเด่นเฉพาะตัวในรายละเอียดปลีกย่อย แต่มีข้อควรระวังสำคัญสำหรับนักพัฒนาที่มองหาโซลูชันค้นหาสำหรับ Postgres
• ไม่มีโซลูชันใดในกลุ่มนี้ที่ถูกสร้างขึ้นมาเพื่อ Postgres โดยเฉพาะ
• ผู้ใช้ Postgres จึงมีแนวโน้มจะพบปัญหาคล้ายกับ Elasticsearch เมื่อใช้บริการเหล่านี้

เป็นไปได้ไหมที่จะได้สิ่งที่ดีที่สุดจากทั้งสองทาง?

• ParadeDB คือเสิร์ชเอนจินแบบ Full Text ที่สร้างมาเพื่อ Postgres
• ParadeDB สร้างบนส่วนขยาย pg_search โดยฝัง Tantivy ซึ่งเป็นทางเลือกของ Lucene ที่พัฒนาด้วย Rust ไว้ภายใน Postgres
• เช่นเดียวกับ Postgres FTS, ParadeDB เชื่อมต่อกับฐานข้อมูล Postgres ที่ดูแลเองอยู่แล้วได้โดยไม่ต้องมีอินฟราสตรักเจอร์เพิ่มเติม
• และเช่นเดียวกับ Elasticsearch, ParadeDB มอบความสามารถของเสิร์ชเอนจินแบบ Full Text ขั้นสูง
• ความเข้ากันได้กับบริการ Postgres แบบมีผู้ดูแลจัดการ เช่น Amazon RDS จะมาในเร็ว ๆ นี้

[galadbran]

พอเห็นว่า Postgres FTS คืออะไร ก็เพิ่งรู้ว่าหมายถึงฟีเจอร์ที่มีมาในตัวนี่เอง

[xguru]

กลุ่มนี้ปรับปรุงอย่างต่อเนื่องและลงบทความที่เกี่ยวข้องมาเรื่อย ๆ เลยมีการแชร์ใน GeekNews หลายครั้งแล้ว

ParadeDB - PostgreSQL for Search
pg_bm25 - ส่วนขยายค้นหาแบบ Full-Text ที่ให้คุณภาพระดับ Elastic บน Postgres

[cometkim]

paradedb, pg_search, pg_bm25 ที่กล่าวถึงในบทความ ล้วนเป็นโปรเจกต์เดียวกันทั้งหมด