Tìm kiếm API so với Tìm kiếm Solr của Apache

Tôi đã sử dụng mô-đun Tìm kiếm Solr của Apache trong Drupal 6 và đang xem API Tìm kiếm để cài đặt Drupal 7. Tôi đã thấy một số cuộc thảo luận ở đây nhưng tôi đang tìm kiếm bất kỳ lý do cho việc chọn cái này hay cái khác.

Có một lý do để chọn cái này hơn cái kia không? Nếu vậy, tại sao và tại sao không? Tôi đã nghe nói có thể có các vấn đề phức tạp và / hoặc các vấn đề về hiệu suất với API tìm kiếm. Điều này có đúng không?

Kể từ năm 2015, chúng tôi có thể so sánh các mô-đun Tìm kiếm API với Apache Solr Search với các số:

                   | Apache Solr Search  | Search API
Posted in:         | 2007                | 2010
Downloads:         | >2k                 | >20k
Reported installs: | >21k                | >64k
Total bugs:        | >1200               | >600
Active bugs:       | >200                | >170
Commits:           | >1.3k               | >1.5k

trong đó chỉ ra sự lựa chọn rõ ràng. API tìm kiếm được phát triển 3 năm sau đó và nó đã tìm cách tận dụng lợi thế của đối thủ cạnh tranh.

Hơn nữa, API tìm kiếm cung cấp một kiến ​​trúc rất khác biệt và linh hoạt hơn và nó được duy trì tích cực hơn. Điều quan trọng hơn, nó đã hỗ trợ cho Drupal 8 và Solr 5.x mới nhất mà Apachesolr chưa có.

API tìm kiếm bắt đầu mới và nó linh hoạt hơn trong cấu hình của nó, bao gồm hỗ trợ Lượt xem (đối với Apachesolr, bạn cần mô-đun bổ sung). Ngoài ra còn có rất nhiều mô-đun mở rộng chức năng của nó.

Thứ hai để tránh một số vấn đề được cộng đồng giải quyết hai lần do sự khác biệt về kiến ​​trúc của các mô-đun này, hiện tại có một số nỗ lực kết hợp giữa hai dự án này, chẳng hạn như:

• tạo cách phổ biến để hiển thị các khối mặt thông qua API Facet (còn được gọi là bộ lọc),
• một lược đồ chung và các tệp cấu hình solrconfig.xml,
• cả hai nhà bảo trì đã làm việc cùng nhau và di chuyển các lớp kết nối từ mô đun Tìm kiếm Solr của Apache sang API tìm kiếm.

^{Nguồn: Battleplan for Search & Solr trong Drupal 8 tại Acquia}

Lưu ý, không nên sử dụng cả hai mô-đun trong cùng một môi trường.

Để biết thêm phân tích kỹ thuật về sự khác biệt, xin vui lòng kiểm tra các chi tiết dưới đây.

API tìm kiếm

Tổng quan về API:

• Khung để dễ dàng tạo các tìm kiếm
• Tóm tắt từ các nguồn dữ liệu và triển khai phụ trợ
• Hệ sinh thái rộng lớn với các phần mở rộng, ví dụ: phụ trợ
• Tích hợp API khía cạnh

• Dựa nhiều vào API thực thể

  • Cung cấp siêu dữ liệu
  • Được sử dụng cho cấu hình chỉ mục và máy chủ

Tính năng mở rộng:

• Tự động tìm kiếm API
• Tài liệu đính kèm
• Tìm kiếm đã lưu
• Vị trí
• Những con đường đẹp
• Thanh trượt (Phạm vi API tìm kiếm)
• và nhiều thứ khác nữa.

Cấu trúc cơ bản:

Tính năng chỉ mục:

• Các nguồn dữ liệu khác nhau
• Một nguồn dữ liệu: thực thể

• Dựa trên API thực thể:

  • Mỗi thuộc tính có thể được lập chỉ mục
  • Thuộc tính của các thực thể liên quan có thể được lập chỉ mục

Cách định cấu hình chỉ mục của bạn - các trường:

Lượt xem API tìm kiếm:

• Hỗ trợ lượt xem đầy đủ
• Hiển thị bất kỳ thuộc tính nào của một thực thể
• Sử dụng bất kỳ trường được lập chỉ mục nào làm bộ lọc, đối số hoặc sắp xếp
• Hầu hết các mã dựa trên tích hợp lượt xem của Entity API

• Theo mặc định: dữ liệu được truy xuất thông qua tải thực thể

  • Có thể bỏ qua ("Lấy dữ liệu từ cài đặt Solr" trong máy chủ)
• Thay thế: Tìm kiếm trang API

Tìm kiếm công thức API:

• Móc CRUD cho các chỉ mục và máy chủ

• Móc để thêm

  • nguồn dữ liệu
  • phụ trợ
  • thay đổi dữ liệu
  • bộ xử lý

• Móc bắn khi lập chỉ mục

• Hook bị bắn khi thực hiện tìm kiếm

Apachesolr

Tính năng mở rộng:

• Tệp đính kèm (không hỗ trợ phương tiện, mã hóa tùy chỉnh cho tệp đính kèm cho các thực thể khác)
• Vị trí (địa lý Apachesolr, vị trí Apachesolr)

Bí quyết Apachesolr:

• Nền tảng tìm kiếm doanh nghiệp nguồn mở
• Quỹ Apache
• Tìm kiếm toàn văn bản, đánh dấu, tìm kiếm theo khía cạnh, phân cụm, xử lý tài liệu phong phú
• Phân phối
• Nhân rộng / mở rộng
• Java
• REST HTTP và các câu trả lời bằng XML / JSON và một số thứ khác
• Không liên quan

Nguồn: Tìm kiếm API vs Apachesolr slideshow

Xem thêm:

• Khi nào mô-đun tìm kiếm Drupal cốt lõi có giá trị sử dụng?
• Những lợi thế của việc sử dụng Apache Solr so với mô-đun tìm kiếm cốt lõi là gì?

Tôi đã thử sử dụng cả hai và tôi có thể nói điều này: nó phụ thuộc vào tình huống của bạn.

Hiện tại, phiên bản 7 ổn định của mô-đun Tích hợp ApacheSolr chỉ có thể lập chỉ mục các nút. Vì vậy, nếu bạn có các thực thể không phải là nút mà bạn cần lập chỉ mục, bạn phải sử dụng bản vá đa năng vẫn đang tiến hành cho nó. Tích hợp ApacheSolr có thể lưu trữ rất nhiều dữ liệu nội dung khác nhau khi được cấu hình đúng.

API tìm kiếm thực hiện chỉ mục và có rất nhiều nội dung tuyệt vời được viết cho nó. Tuy nhiên, API tìm kiếm chỉ tìm nạp id của dữ liệu bạn đang tìm kiếm. Điều này có nghĩa là tải thêm bất kỳ dữ liệu nào ngoài ID sẽ yêu cầu thực thể_load, nhấn vào cơ sở dữ liệu của bạn hoặc bất kỳ lớp bộ đệm nào bạn đặt vào vị trí. Đối với các trang web nặng tìm kiếm, đây có thể không phải là giải pháp tối ưu nhất.

Dưới đây là một bài thuyết trình tuyệt vời được đưa ra tại drupalcon chicago về mô-đun Tích hợp ApacheSolr, phút 16 để đề cập đến API tìm kiếm.

Tôi nghĩ rằng bạn thực sự phải thử cả hai và đưa ra quyết định sáng suốt. Nhưng hãy cân nhắc mạnh mẽ rằng apachesolr vẫn chưa có bản beta cho Drupal 8.

Trong API tìm kiếm, bạn không thể kết hợp các thực thể trên cùng một chỉ mục SearchAPI. Vì vậy, Hồ sơ, Người dùng, Nút nằm trên các chỉ mục khác nhau. Có một mô-đun để cho phép tìm kiếm multiindex, nó không đáp ứng nhu cầu của tôi, nhưng YMMV. Nếu bạn có nhiều loại nội dung và nhiều trường trên cùng một chỉ mục, định nghĩa chỉ mục có thể trở nên khá khó sử dụng. (NB SearchAPI D8 báo cáo để hỗ trợ tìm kiếm đa chỉ mục)

Apachesolr cho phép chỉnh sửa các trường trên cơ sở từng nội dung có thể dễ dàng hơn, nhưng không có khả năng thêm nội dung liên quan vào tài liệu, trên thực tế dự kiến ​​sẽ phải viết một số mã tùy chỉnh để bao gồm thông tin từ bộ sưu tập trường, tài liệu tham khảo và một số khác lĩnh vực. Apachesolr D7 không hỗ trợ ajax, trừ khi bạn sử dụng chế độ xem, nhưng sử dụng chế độ xem bạn sẽ mất các khía cạnh. Điều đó nói rằng ... sửa đổi thông tin được lưu trữ trong chỉ mục là khá dễ dàng nếu bạn hài lòng mã hóa trong hook.

Ý tưởng tìm kiếm id thực thể và sau đó hiển thị từng cái riêng lẻ (có thể được sử dụng bởi cả hai mô-đun) dường như là một cơn ác mộng về hiệu suất, nhưng, nếu bạn lưu trữ bộ đệm, thực thể của bạn sẽ hiển thị hiệu quả hơn so với kết xuất từ ​​phản hồi solr.