Phát hành OpenSearch 3.0 - Tăng cường mạnh mẽ hiệu năng cơ sở dữ liệu vector và hạ tầng tìm kiếm dựa trên AI

 (opensearch.org)
12 điểm bởi GN⁺ 2025-05-09 | 3 bình luận | Chia sẻ qua WhatsApp
  • OpenSearch 3.0 đã chính thức ra mắt, mang lại hiệu năng cao hơn 9,5 lần so với OpenSearch 1.3
  • Bổ sung nhiều tính năng đột phá cho tìm kiếm vector như tăng tốc GPU, tích hợp AI agent, tối ưu lưu trữ
  • Nâng cao hiệu quả và tính linh hoạt trong xử lý dữ liệu với gRPC, streaming Kafka, tự động nhận diện chỉ mục
  • Ở góc độ hạ tầng tìm kiếm, việc áp dụng Lucene 10, Java 21, kiến trúc mô-đun giúp cải thiện khả năng mở rộng trong tương lai và khả năng bảo trì
  • Khẳng định vị thế là nền tảng tìm kiếm thế hệ mới mã nguồn mở dựa trên cộng đồng, đáp ứng nhu cầu tìm kiếm dựa trên AI và RAG ngày càng tăng

OpenSearch 3.0 chính thức ra mắt: tối ưu tìm kiếm vector cho kỷ nguyên AI

  • OpenSearch Software Foundation công bố phiên bản chính thức OpenSearch 3.0, đồng thời cho biết hiệu năng tăng 9,5 lần so với OpenSearch 1.3
  • Cải thiện hiệu năng xử lý dữ liệu vector quy mô lớn vốn cần thiết cho tìm kiếm AI, hệ thống gợi ý, RAG và nhiều ứng dụng khác

Đổi mới trong vector engine: đồng thời đạt hiệu năng và hiệu quả chi phí

  • Tăng tốc GPU (dựa trên NVIDIA cuVS): rút ngắn thời gian xây dựng chỉ mục tối đa 9,3 lần, hỗ trợ xử lý các workload hiệu năng cao
  • Hỗ trợ Model Context Protocol (MCP): cho phép xây dựng giải pháp tìm kiếm linh hoạt thông qua tích hợp với AI agent
  • Tính năng Derived Source: loại bỏ dữ liệu vector trùng lặp, giảm mức sử dụng lưu trữ xuống còn 1/3

Tính năng quản lý dữ liệu: tăng cường tính linh hoạt và khả năng mở rộng

  • Hỗ trợ gRPC: tăng tốc truyền dữ liệu giữa các node và giữa client-server (thử nghiệm)
  • Thu thập dữ liệu theo cơ chế pull: áp dụng cấu trúc để OpenSearch trực tiếp lấy dữ liệu từ các hệ thống streaming bên ngoài như Kafka, Kinesis
  • Tách reader-writer: tách biệt tìm kiếm và indexing để đảm bảo độ ổn định và hiệu năng cho từng tác vụ
  • Tích hợp Apache Calcite: cung cấp tính năng query builder trực quan trong SQL/PPL
  • Nhận diện loại chỉ mục: tự động nhận diện chỉ mục log để cung cấp các tùy chọn phân tích phù hợp

Cải tiến hạ tầng tìm kiếm và lõi nền tảng

  • Nâng cấp lên Lucene 10: cải thiện hiệu năng tác vụ song song và nâng cao năng lực tìm kiếm
  • Runtime hỗ trợ tối thiểu Java 21: có thể tận dụng các tính năng ngôn ngữ và hiệu năng mới nhất
  • Áp dụng hệ thống mô-đun Java: chuyển từ cấu trúc nguyên khối sang nền tảng dựa trên thư viện để nâng cao khả năng bảo trì

Đổi mới bền vững xoay quanh cộng đồng mở

  • OpenSearch là nền tảng tìm kiếm mã nguồn mở dựa trên cộng đồng độc lập thuộc Linux Foundation
  • Có sự tham gia của các doanh nghiệp lớn như AWS, SAP, Uber cùng hàng nghìn người đóng góp
  • Nhấn mạnh khả năng mở rộng phù hợp với kỷ nguyên vector DB và mô hình quản trị minh bạch, hướng tới một hệ sinh thái mà bất kỳ ai cũng có thể tham gia
  • Có thể xem thông tin phát hành chi tiết tại blog chính thức và ghi chú phát hành

Bài viết liên quan

3 bình luận

 
kaydash 2025-05-12

Vì Elasticsearch là AGPL nên tôi ngại dùng, nên vẫn cứ chỉ dùng OpenSearch on-premise thôi.
 
GN⁺ 2025-05-09
Ý kiến trên Hacker News

  • Tôi mới chỉ biết đến OpenSearch gần đây; đây là dự án được fork vào năm 2021 sau khi Elasticsearch thay đổi giấy phép. Tôi tò mò liệu nó vẫn có thể dùng như một lựa chọn thay thế cho Elasticsearch hay không, cũng như so sánh về hiệu năng và tính năng.

    • Tôi đang duy trì một client viết bằng Kotlin cho cả Elasticsearch và OpenSearch (kt-search)

      • Với phần lớn các tính năng được dùng thường xuyên, API vẫn còn tương thích

      • Các tính năng được thêm vào sau khi fork, như tìm kiếm vector, là ngoại lệ

      • Một số tính năng như search_after hoạt động khác nhau giữa hai bên; client sẽ bù phần này

      • Cả hai sản phẩm đều có tính năng truy vấn SQL, nhưng cách triển khai khác nhau

      • Về mặt tính năng, Elastic vẫn nhỉnh hơn, đặc biệt là các tính năng của Kibana phong phú hơn bản fork của Amazon

      • Ở mảng aggregation cũng vậy, Elastic trong vài năm gần đây đã tập trung rất nhiều vào tối ưu hóa và nâng cấp

      • Hiệu năng phụ thuộc vào mục đích sử dụng; cả hai đều dựa trên Lucene (thư viện tìm kiếm mã nguồn mở)

      • Elastic Cloud trên AWS nhỉnh hơn OpenSearch một chút

      • Nếu tự host và tự tuning thì hai sản phẩm trở nên rất giống nhau

      • Elastic 9.0 và OpenSearch 3.0 đều dùng phiên bản Lucene mới, và client của tôi hỗ trợ cả hai

      • Trong số khách hàng tư vấn của tôi, ngày càng nhiều bên thích OpenSearch vì giấy phép mã nguồn mở và sự hỗ trợ từ AWS

      • Nếu muốn chuyển từ Elasticsearch legacy sang OpenSearch thì phải reindex toàn bộ dữ liệu, và có thể cũng phải đổi thư viện; khá phiền, nên tôi mới làm ra kt-search

      • Chúng tôi có nhiều cơ sở dữ liệu Elasticsearch 2.3 cũ, nên đã dựng OpenSearch song song cho từng cơ sở dữ liệu và bulk copy dữ liệu khi dịch vụ khởi động; đến giờ nhìn chung vẫn hài lòng với OpenSearch

      • Cảm ơn vì phần giải thích chi tiết, rất hữu ích

    • Điểm tôi thấy tiếc gần đây ở OpenSearch là không có tính năng enrich processors (có kèm link tài liệu)

      • Nếu chỉ dùng các tính năng tiêu chuẩn để ingest và search tài liệu thì phần lớn vẫn tương thích
      • Các tính năng nâng cao từng có ở bản trả phí thì thường không tương thích hoặc bị thiếu

    • Elasticsearch đã tiến lên bản 9.0 trở lên, và có nhiều hơn OpenSearch tới 27.000 commit

      • Giờ thì khó có thể xem nó là một drop-in replacement nữa
      • Tôi không biết bao nhiêu trong số đó là tính năng cốt lõi, nhưng có thể thấy hai dự án đã khác nhau đến mức nào

    • Từ tháng 9/2024, Elasticsearch đã quay lại giấy phép mã nguồn mở hoàn toàn (AGPLv3)

      • Ý kiến kiểu gợi lại cảm giác từng bị lừa trước đây

      • Elastic Search vẫn là open-core; các tính năng "enterprise" sẽ không bao giờ được đưa vào bản mã nguồn mở, trong khi OpenSearch không có ràng buộc như vậy

    • OpenSearch không phải là bản thay thế "hoàn chỉnh", nhưng gần như tương thích; phiên bản 1.x tương thích với Elasticsearch 7.10

    • Trên cùng phần cứng, OpenSearch chậm hơn đôi chút; nếu cần UI thì nên cẩn thận, bản fork của Kibana chậm và nhiều lỗi

      • Thực tế phức tạp hơn một chút, vì mỗi bên đều có workflow mà mình làm tốt hơn
      • Công ty chúng tôi đã benchmark toàn diện cả hai sản phẩm; nếu quan tâm kết quả thì hãy xem bài blog đó

    • Cái tên OpenSearch ban đầu xuất phát từ một dịch vụ tổng hợp kết quả tìm kiếm cá nhân do A9, công ty con của Amazon, phát triển

      • Nhắc rằng cùng một tên có thể mang nhiều nghĩa khác nhau

  • Bày tỏ sự tiếc nuối về dự án OpenSearch

    • Đây là một dự án mang tính phản xạ, được AWS cùng làm ra để phản ứng với việc Elasticsearch đổi giấy phép

    • Cộng đồng của nó giống như một trò chơi nhiều người chơi nhưng đã vắng bóng người tham gia, thiếu sức sống vốn rất cần cho một dự án mã nguồn mở

    • Tôi chưa từng nghe đến công ty hay khách hàng enterprise nào thay thế Elasticsearch bằng nó; nó vẫn chưa được kiểm chứng và cũng chưa tạo được niềm tin về cam kết dài hạn

    • Các nền tảng SIEM giờ đều đang tự xây nền tảng tìm kiếm riêng

    • Elastic cũng đã tung ra nền tảng SIEM (Elastic Security)

    • Dù Elastic đã tuyên bố lại là mã nguồn mở, ban lãnh đạo sẽ không bỏ chi phí migration sang một bản fork chưa được kiểm chứng, nên mục đích tồn tại của dự án càng trở nên mơ hồ

      • Tôi không muốn quay lại dùng Elastic; trước đây tôi đã tự dùng Lucene–Solr–bản mở rộng tùy chỉnh theo thứ tự đó, còn Elastic Search chỉ cần khi dùng AWS thôi, nhưng sau khi chuyển sang OpenSearch thì dùng cũng ổn

      • Tôi nghĩ Elastic đã bị OpenSearch và AWS gây thiệt hại kinh tế đáng kể trong thời gian dài

  • Có ai đang dùng các tính năng knn và vector của OpenSearch không, và ở môi trường vận hành quy mô lớn thực tế thì thế nào?

    • Tôi không rõ triển khai của OpenSearch ra sao, nhưng từng tự triển khai vector set cho Redis với cấu trúc HNSW

      • Nếu HNSW được triển khai tốt thì nó hoạt động ổn ngay cả ở quy mô khá lớn
      • Tốc độ insert của một HNSW đơn lẻ ở mức vài nghìn bản ghi mỗi giây, còn đọc thì nhanh hơn nhiều (trong môi trường đa lõi)
      • Lần insert hàng loạt đầu tiên có thể rất chậm, nhưng có thể song song hóa
      • Điểm kém hiệu quả của HNSW là dùng nhiều bộ nhớ; nếu lưu trên đĩa thì sẽ phát sinh random seek
      • Với vector nhiều chiều như 1024 chiều, quantization là bắt buộc

    • Nếu số chiều của vector embedding cao thì nên dùng phương pháp approximate nearest neighbor như HNSW hơn là knn thuần túy

      • Tôi đang dùng opensearch cho hybrid search dựa trên văn bản, embedding đa phương thức và metadata
      • Chưa phải vận hành ở quy mô thật sự lớn, nhưng vì là opensearch nên tôi kỳ vọng tốt về khả năng mở rộng

    • Theo kinh nghiệm của tôi thì gần như lúc nào cũng dùng; hiệu năng phụ thuộc vào mô hình embedding và việc tuning index rất quan trọng

      • Khi dùng Lucene HNSW thì sẽ tốn khá nhiều Java Heap RAM
      • Nếu dùng plugin FAISS hay nmslib thì cũng phải chú ý đến JNI RAM
      • Việc mở rộng ANN quy mô lớn trên hơn 100 triệu vector không hề dễ, cần sự tập trung hỗ trợ của cả team

    • Có một caveat đã được chấp nhận: hiệu năng tìm kiếm trên hàng triệu tài liệu là ổn, nhưng khi search KNN thì phải đưa toàn bộ đồ thị embedding lên RAM, nên quản lý RAM là điểm mấu chốt

      • Chất lượng kết quả cuối cùng vẫn phụ thuộc vào chất lượng embedding

  • Tôi muốn một công cụ ingest log đơn giản, có thể parse syslog rồi vẽ/search theo field, nhưng việc cấu hình Opensearch hoặc ELK quá rắc rối

    • Tôi ngạc nhiên vì cả Elastic lẫn Opensearch đều khó đến vậy ngay cả với thiết lập cơ bản

      • Mọi thứ đều xoay quanh cấu hình, nên phải tự ghép recipe

      • Có những công cụ hỗ trợ như opentelemetry, nhưng vẫn còn bất tiện

      • Cả hai công cụ đều có thể dùng khá nhanh nếu chỉ làm theo guideline chính thức; vấn đề là khi cần logic tùy biến

      • Nếu nhu cầu đơn giản thì thậm chí không cần logstash

      • Elastic và opensearch không phù hợp cho app metrics; trường hợp đó nên dùng prometheus và grafana

      • Nếu đầu tư vào hệ sinh thái Elastic (beats, logstash, v.v.) thì có thể cấu hình nhiều index template và pipeline khác nhau

      • Hiện nay nhờ dynamic field mapping mà việc đưa dữ liệu vào/ra Elasticsearch đã trở nên rất dễ

      • Giữ được hiệu năng mới là nỗi lo lớn hơn

    • Bạn đã thử Graylog chưa? Ở chỗ làm của tôi, chúng tôi dùng nó khá ổn
 
davidayo 2025-05-11

OpenSearch xuất hiện vào năm 2021 sau khi Elasticsearch thay đổi giấy phép, với mục tiêu trở thành một giải pháp thay thế tương thích. Dù phần lớn tương thích, đặc biệt là phiên bản 1.x với Elasticsearch 7.10, nhưng nó không phải là một giải pháp thay thế hoàn toàn theo kiểu drop-in. Elasticsearch đã tiếp tục phát triển hơn nữa, sở hữu nhiều tính năng và tối ưu hóa hơn, đặc biệt ở Kibana và các phép tổng hợp. Hiệu năng phụ thuộc vào từng ứng dụng, vì cả hai đều được xây dựng trên Lucene. Một số người dùng thấy OpenSearch chậm hơn và các bản fork của Kibana của nó có lỗi. Mặc dù Elasticsearch đã quay lại mã nguồn mở (AGPLv3) vào tháng 9 năm 2024, một số người vẫn thích OpenSearch vì tính chất thực sự mã nguồn mở và sự hỗ trợ từ AWS. Dù tìm kiếm vector là một điểm khác biệt quan trọng, các triển khai quy mô lớn đòi hỏi phải quản lý RAM cẩn thận. Cuối cùng, lựa chọn phụ thuộc vào nhu cầu cụ thể, vì cả hai đều có điểm mạnh và điểm yếu. Tôi đang làm việc về OpenSearch với Davidayo https://www.davidayo.com công cụ AI mạnh mẽ "AskPromptAI" https://askpromptai.com.