OpenSearch 3.0 เปิดตัวแล้ว - ยกระดับประสิทธิภาพฐานข้อมูลเวกเตอร์และโครงสร้างพื้นฐานการค้นหาที่ขับเคลื่อนด้วย AI อย่างมาก

 (opensearch.org)
12 คะแนน โดย GN⁺ 2025-05-09 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • OpenSearch 3.0 เปิดตัวอย่างเป็นทางการ พร้อมมอบ ประสิทธิภาพที่ดีขึ้น 9.5 เท่าเมื่อเทียบกับ OpenSearch 1.3
  • เพิ่มฟีเจอร์นวัตกรรมมากมายสำหรับการค้นหาเวกเตอร์ เช่น การเร่งความเร็วด้วย GPU, การเชื่อมต่อกับ AI agent, การเพิ่มประสิทธิภาพด้านสตอเรจ
  • เสริมประสิทธิภาพและความยืดหยุ่นของการประมวลผลข้อมูลด้วย gRPC, Kafka streaming, การระบุดัชนีอัตโนมัติ
  • ในด้านโครงสร้างพื้นฐานการค้นหา มีการใช้ Lucene 10, Java 21, สถาปัตยกรรมแบบโมดูลาร์ เพื่อปรับปรุงความสามารถในการขยายตัวในอนาคตและการบำรุงรักษา
  • วางตำแหน่งเป็น แพลตฟอร์มการค้นหาโอเพนซอร์สยุคถัดไปที่ขับเคลื่อนโดยชุมชนโอเพนซอร์ส เพื่อตอบสนองความต้องการการค้นหาบน AI และ RAG ที่เพิ่มขึ้น

OpenSearch 3.0 เปิดตัวอย่างเป็นทางการ: ปรับแต่งการค้นหาเวกเตอร์สำหรับยุค AI

  • OpenSearch Software Foundation เปิดเผย OpenSearch 3.0 เวอร์ชันทางการ พร้อมประกาศว่า ประสิทธิภาพดีขึ้น 9.5 เท่าเมื่อเทียบกับ OpenSearch 1.3
  • ปรับปรุง ประสิทธิภาพการประมวลผลข้อมูลเวกเตอร์ขนาดใหญ่ ที่จำเป็นสำหรับ AI search, ระบบแนะนำ, RAG และงานลักษณะใกล้เคียงกัน

นวัตกรรมของเอนจินเวกเตอร์: ได้ทั้งประสิทธิภาพและความคุ้มค่าด้านต้นทุน

  • การเร่งความเร็วด้วย GPU (อิง NVIDIA cuVS): ลดเวลาในการสร้างดัชนีได้สูงสุด 9.3 เท่า รองรับเวิร์กโหลดสมรรถนะสูง
  • รองรับ Model Context Protocol (MCP): สามารถสร้างโซลูชันการค้นหาที่ยืดหยุ่นผ่านการเชื่อมต่อกับ AI agent
  • ฟีเจอร์ Derived Source: ลดการใช้สตอเรจลง 1/3 ด้วยการกำจัดข้อมูลเวกเตอร์ที่ซ้ำซ้อน

ความสามารถด้านการจัดการข้อมูล: เพิ่มความยืดหยุ่นและการขยายตัว

  • รองรับ gRPC: เพิ่มความเร็วในการส่งข้อมูลระหว่างโหนด และระหว่างไคลเอนต์กับเซิร์ฟเวอร์ (experimental)
  • การดึงข้อมูลแบบ Pull-based: ใช้โครงสร้างที่ OpenSearch ดึงข้อมูลเข้ามาโดยตรง จากระบบสตรีมมิงภายนอก เช่น Kafka และ Kinesis
  • การแยก Reader-Writer: แยกงานค้นหาออกจากงานทำดัชนี เพื่อคงเสถียรภาพและประสิทธิภาพของแต่ละงาน
  • ผสานรวม Apache Calcite: เพิ่มความสามารถ query builder ที่ใช้งานตรงไปตรงมา ใน SQL/PPL
  • การตรวจจับประเภทดัชนี: ระบุดัชนีล็อกโดยอัตโนมัติ และเสนอออปชันวิเคราะห์ที่เหมาะสม

การปรับปรุงโครงสร้างพื้นฐานการค้นหาและแกนหลักของแพลตฟอร์ม

  • อัปเกรดเป็น Lucene 10: เพิ่มประสิทธิภาพของงานแบบขนานและยกระดับความสามารถด้านการค้นหา
  • รองรับ Java 21 เป็นรันไทม์ขั้นต่ำ: ใช้ประโยชน์จากฟีเจอร์ภาษาและประสิทธิภาพล่าสุดได้
  • นำ Java module system มาใช้: เปลี่ยนจากโครงสร้างแบบ monolithic ไปสู่รูปแบบที่อิงไลบรารี เพื่อเพิ่มความสามารถในการบำรุงรักษา

นวัตกรรมที่ยั่งยืนโดยมีชุมชนโอเพนเป็นศูนย์กลาง

  • OpenSearch คือแพลตฟอร์มการค้นหาโอเพนซอร์สที่ขับเคลื่อนโดย ชุมชนอิสระภายใต้ Linux Foundation
  • มีบริษัทหลักอย่าง AWS, SAP, Uber และผู้มีส่วนร่วมหลายพันคนเข้าร่วม
  • เน้นย้ำการขยายตัวให้สอดคล้องกับยุคของ vector DB และธรรมาภิบาลที่โปร่งใส โดยมุ่งสู่ ระบบนิเวศที่ทุกคนสามารถมีส่วนร่วมได้
  • สามารถดูข้อมูลการเปิดตัวโดยละเอียดได้จากบล็อกทางการ และrelease notes

บทความที่เกี่ยวข้อง

3 ความคิดเห็น

 
kaydash 2025-05-12

เพราะ Elasticsearch เป็น AGPL เลยรู้สึกกลัวที่จะใช้ ก็เลยใช้แต่ OpenSearch แบบ on-premises มาโดยตลอด
 
GN⁺ 2025-05-09
ความคิดเห็นจาก Hacker News

  • เพิ่งมารู้จัก OpenSearch ว่าเป็นโปรเจกต์ที่ fork ออกมาในปี 2021 หลัง Elasticsearch เปลี่ยนไลเซนส์ จึงสงสัยว่ายังใช้แทน Elasticsearch ได้อยู่หรือไม่ และอยากรู้ความต่างด้านประสิทธิภาพกับฟีเจอร์

    • กำลังดูแล client สำหรับทั้ง Elasticsearch และ OpenSearch ที่เขียนด้วย Kotlin (kt-search)

      • API ยังเข้ากันได้อยู่สำหรับฟีเจอร์ที่ใช้กันบ่อยส่วนใหญ่

      • ข้อยกเว้นคือฟีเจอร์ที่เพิ่มเข้ามาหลังการ fork เช่น vector search

      • บางฟีเจอร์อย่าง search_after ทำงานต่างกัน และ client จะช่วยชดเชยส่วนนี้

      • ทั้งสองตัวมีความสามารถด้าน SQL query แต่แนวทางการ implement ต่างกัน

      • ในแง่ฟีเจอร์ Elastic ยังนำอยู่ โดยเฉพาะความสามารถของ Kibana ที่ครบกว่าฝั่ง fork ของ Amazon

      • ด้าน aggregation ก็เช่นกัน Elastic ทุ่มกับการ optimize และอัปเกรดมาหลายปี

      • ประสิทธิภาพขึ้นอยู่กับลักษณะงาน เพราะทั้งคู่สร้างบน Lucene (ไลบรารีค้นหาโอเพนซอร์ส)

      • Elastic Cloud บน AWS ดีกว่า OpenSearch บน AWS เล็กน้อย

      • ถ้าโฮสต์เองและจูนเอง ทั้งสองตัวจะใกล้เคียงกันมาก

      • ทั้ง Elastic 9.0 และ OpenSearch 3.0 ใช้ Lucene เวอร์ชันใหม่ และ client รองรับทั้งคู่

      • ลูกค้าที่ปรึกษาหลายรายเริ่มชอบ OpenSearch มากกว่าเพราะไลเซนส์โอเพนซอร์สและการซัพพอร์ตจาก AWS

      • ถ้าจะย้ายจาก Elasticsearch รุ่นเก่าไป OpenSearch ต้อง reindex ข้อมูลทั้งหมด และอาจต้องเปลี่ยนไลบรารีด้วย ค่อนข้างยุ่งยาก นี่จึงเป็นเหตุผลที่สร้าง kt-search ขึ้นมา

      • มีฐานข้อมูล Elasticsearch 2.3 เก่าอยู่หลายตัว จึงตั้ง OpenSearch แบบขนานสำหรับแต่ละฐาน แล้วคัดลอกข้อมูลแบบ bulk ตอนเริ่มบริการ จนถึงตอนนี้ก็พอใจกับ OpenSearch โดยรวม

      • ขอบคุณสำหรับคำอธิบายละเอียด และเห็นว่ามีประโยชน์มาก

    • สิ่งที่เสียดายล่าสุดใน OpenSearch คือไม่มีความสามารถ enrich processors (มีลิงก์เอกสารประกอบ)

      • ถ้าใช้แค่การ ingest เอกสารและความสามารถค้นหามาตรฐาน ส่วนใหญ่ยังเข้ากันได้
      • แต่ฟีเจอร์ขั้นสูงที่เคยมีในเวอร์ชันเสียเงิน มักจะไม่เข้ากันหรือหายไป

    • ตอนนี้ Elasticsearch พัฒนาไปถึงเวอร์ชัน 9.0+ แล้ว และมี commit มากกว่า OpenSearch อยู่ 27,000 ครั้ง

      • จึงเริ่มยากที่จะเรียกว่าเป็น drop-in replacement
      • ไม่แน่ใจว่ามีกี่รายการที่เป็นฟีเจอร์แกนหลัก แต่ก็บอกได้ว่าทั้งสองโปรเจกต์แยกทางกันไปมากแค่ไหน

    • ตั้งแต่เดือนกันยายน 2024 Elasticsearch ได้กลับไปใช้ไลเซนส์โอเพนซอร์สเต็มรูปแบบอีกครั้ง (AGPLv3)

      • มีความเห็นแนวรำลึกถึงประสบการณ์ที่เคยโดนหลอกมาก่อน

      • แต่ Elastic Search ก็ยังเป็น open-core อยู่ ฟีเจอร์ระดับ “enterprise” จะไม่มีวันถูกรวมในเวอร์ชันโอเพนซอร์ส ขณะที่ OpenSearch ไม่มีข้อจำกัดแบบนี้

    • OpenSearch ไม่ใช่ตัวแทนแบบ “ครบถ้วน” แต่ก็เข้ากันได้เกือบทั้งหมด โดยเวอร์ชัน 1.x เข้ากันได้กับ Elasticsearch 7.10

    • บนฮาร์ดแวร์เดียวกัน OpenSearch ช้ากว่านิดหน่อย ถ้าต้องใช้ UI ต้องระวัง เพราะ Kibana fork ช้าและบั๊กเยอะ

      • ความจริงซับซ้อนกว่านั้นเล็กน้อย เพราะทั้งสองตัวมี workflow ที่เด่นคนละแบบ
      • ที่บริษัทมีการ benchmark ทั้งสองตัวแบบค่อนข้างครอบคลุม ถ้าอยากดูผลก็แนะนำให้ไปอ่านบล็อกโพสต์นั้น

    • ชื่อ OpenSearch เดิมมาจากบริการรวมผลการค้นหาส่วนตัวที่พัฒนาโดย A9 บริษัทลูกของ Amazon

      • ชี้ว่าชื่อเดียวกันอาจมีหลายความหมายได้

  • แสดงความเสียดายต่อโปรเจกต์ OpenSearch

    • เป็นโปรเจกต์เชิงตอบโต้ที่ทำร่วมกับ AWS หลังไม่พอใจการเปลี่ยนไลเซนส์ของ Elasticsearch

    • ชุมชนเหมือนเกมมัลติเพลเยอร์ที่ไม่มีคนเล่น ขาดพลังชีวิตที่จำเป็นต่อโปรเจกต์โอเพนซอร์ส

    • ไม่เคยได้ยินว่ามีบริษัทหรือองค์กรรายใหญ่ไหนแทนที่ Elastic Search ด้วยมันได้จริง จึงยังไม่ถูกพิสูจน์ และความเชื่อมั่นต่อ commitment ระยะยาวก็ยังต่ำ

    • แต่ละแพลตฟอร์ม SIEM เองก็กำลังสร้างแพลตฟอร์มค้นหาของตัวเองกันอยู่

    • ฝั่ง Elastic ก็ออกแพลตฟอร์ม SIEM (Elastic Security) เช่นกัน

    • แม้ Elastic จะประกาศว่าโอเพนซอร์สอีกครั้ง แต่ผู้บริหารคงไม่ยอมจ่ายต้นทุน migration ไปยัง fork ที่ยังไม่พิสูจน์ตัวเอง ทำให้จุดมุ่งหมายของโปรเจกต์ยิ่งไม่ชัด

      • ไม่อยากกลับไปใช้ Elastic อีก เคยใช้เองมาตั้งแต่ Lucene–Solr–รุ่นขยายเอง และจริงๆ Elasticsearch จำเป็นแค่ตอนใช้ AWS เท่านั้น แต่หลังย้ายมา OpenSearch ก็ใช้งานได้โอเค

      • มองว่า Elastic โดน OpenSearch และ AWS กระทบทางเศรษฐกิจอย่างหนักมาระยะหนึ่ง

  • อยากรู้ว่ามีใครใช้ความสามารถ knn และ vector ของ OpenSearch อยู่บ้างไหม และในงาน production ขนาดใหญ่เป็นอย่างไร

    • ไม่รู้รายละเอียด implementation ของ OpenSearch แต่เคยทำ vector set สำหรับ Redis เองด้วยโครงสร้าง HNSW

      • ถ้า implement HNSW ดี มันทำงานได้ดีแม้ในสเกลค่อนข้างใหญ่
      • ความเร็ว insert ของ HNSW เดี่ยวๆ อยู่ระดับหลายพันรายการต่อวินาที ส่วนการอ่านจะเร็วกว่าเยอะ (ในสภาพแวดล้อมแบบ multi-core)
      • การ insert ปริมาณมากครั้งแรกอาจช้ามาก แต่สามารถทำแบบขนานได้
      • จุดที่ HNSW ไม่มีประสิทธิภาพคือใช้หน่วยความจำมาก และถ้าเก็บลงดิสก์จะเกิด random seek
      • เวกเตอร์มิติสูง เช่น 1024 มิติ จำเป็นต้องทำ quantization

    • ถ้ามิติของ vector embedding สูง แนะนำให้ใช้วิธี approximate nearest neighbor อย่าง HNSW มากกว่าตัว knn เอง

      • ตัวเองใช้ opensearch กับ hybrid search ที่อิงทั้ง text, multimodal embedding และ metadata
      • ยังไม่ถึงขั้น production เต็มตัวขนาดใหญ่ แต่คาดหวังเชิงบวกเรื่องการสเกลเพราะเป็น opensearch

    • จากประสบการณ์ส่วนตัว ใช้อยู่ตลอด ประสิทธิภาพขึ้นกับ embedding model และการจูน index สำคัญมาก

      • ถ้าใช้ Lucene HNSW จะกิน Java Heap RAM มาก
      • ถ้าใช้ปลั๊กอิน FAISS หรือ nmslib ก็ต้องระวัง JNI RAM ด้วย
      • การสเกล ANN ขนาดใหญ่เกิน 100 ล้านเวกเตอร์ไม่ใช่เรื่องง่าย และต้องให้ทีมโฟกัสจริงจัง

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

      • คุณภาพผลลัพธ์สุดท้ายขึ้นกับคุณภาพ embedding อยู่ดี

  • อยากได้เครื่องมือ ingest log ที่ parse syslog และทำกราฟ/ค้นหาตามฟิลด์ได้แบบง่ายๆ แต่การตั้งค่า Opensearch หรือ ELK กลับยุ่งยากเกินไป

    • แปลกใจเหมือนกันที่ทั้ง Elastic และ Opensearch ตั้งค่าแม้แต่พื้นฐานแบบนี้ยังยากกว่าที่คิด

      • ทุกอย่างขับเคลื่อนด้วยการตั้งค่า จึงต้องประกอบ recipe เอง

      • แม้จะมีเครื่องมือช่วยอย่าง opentelemetry แต่ก็ยังไม่สะดวกอยู่ดี

      • ถ้าทำตามแนวทางทางการของทั้งสองตัว ก็เริ่มใช้งานได้เร็ว ปัญหาจริงอยู่ตอนต้องมี custom logic

      • ถ้าความต้องการเรียบง่าย ก็ทำได้โดยไม่ต้องใช้ logstash

      • Elastic และ opensearch ไม่ค่อยเหมาะกับ app metrics ถ้าเป็นงานนั้นแนะนำ prometheus กับ grafana

      • ถ้าลงทุนกับ ecosystem ของ Elastic (beats, logstash ฯลฯ) ก็จะจัดการ index template และ pipeline ได้หลายแบบ

      • ตอนนี้ด้วย dynamic field mapping ทำให้การรับส่งข้อมูลกับ Elasticsearch ง่ายขึ้นมาก

      • เรื่องที่น่าปวดหัวกว่าคือการรักษาประสิทธิภาพ

    • มีคนถามว่าเคยลอง Graylog หรือยัง ที่ทำงานของเขาใช้อยู่และถือว่าโอเคมาก
 
davidayo 2025-05-11

OpenSearch เกิดขึ้นในปี 2021 หลังจาก Elasticsearch เปลี่ยนไลเซนส์ โดยมีเป้าหมายที่จะเป็นตัวทดแทนที่เข้ากันได้ แม้จะเข้ากันได้ค่อนข้างมาก โดยเฉพาะเวอร์ชัน 1.x กับ Elasticsearch 7.10 แต่ก็ไม่ใช่โซลูชันแบบแทนที่ได้ทันทีอย่างสมบูรณ์ Elasticsearch ได้พัฒนาต่อไปอีกและมีฟีเจอร์กับการปรับแต่งที่มากกว่า โดยเฉพาะใน Kibana และ aggregations ประสิทธิภาพขึ้นอยู่กับแอปพลิเคชัน โดยทั้งสองสร้างบน Lucene ผู้ใช้บางรายพบว่า OpenSearch ช้ากว่าและฟอร์กของ Kibana มีบั๊ก แม้ Elasticsearch จะกลับมาเป็นโอเพนซอร์สอีกครั้ง (AGPLv3) ในเดือนกันยายน 2024 แต่บางคนก็ยังชอบ OpenSearch เพราะความเป็นโอเพนซอร์สอย่างแท้จริงและการรองรับจาก AWS แม้การค้นหาแบบเวกเตอร์จะเป็นจุดแตกต่างสำคัญ แต่การใช้งานในสเกลใหญ่ต้องบริหาร RAM อย่างรอบคอบ ท้ายที่สุดแล้ว การเลือกใช้งานขึ้นอยู่กับความต้องการเฉพาะ โดยทั้งสองมีทั้งจุดแข็งและจุดอ่อน ผมกำลังทำงานกับ OpenSearch ร่วมกับ Davidayo https://www.davidayo.com เครื่องมือ AI ทรงพลัง "AskPromptAI" https://askpromptai.com.