Solr so với ElasticSearch [đã đóng]

Sự khác biệt kiến ​​trúc cốt lõi giữa các công nghệ này là gì?

Ngoài ra, những trường hợp sử dụng thường phù hợp hơn cho từng trường hợp?

Cập nhật

Bây giờ phạm vi câu hỏi đã được sửa, tôi cũng có thể thêm một vài điều về vấn đề này:

Có nhiều so sánh giữa Apache Solr và ElasticSearch có sẵn, vì vậy tôi sẽ tham khảo những cái mà tôi thấy hữu ích nhất cho bản thân mình, tức là bao gồm các khía cạnh quan trọng nhất:

• Bob Yoplait đã liên kết câu trả lời của kimchy với ElasticSearch, Sphinx, Lucene, Solr, Xapian. Mà phù hợp cho việc sử dụng? , trong đó tóm tắt lý do tại sao anh ấy tiếp tục và tạo ra Tìm kiếm đàn hồi , theo ý kiến ​​của anh ấy cung cấp một mô hình phân tán vượt trội hơn nhiều và dễ sử dụng so với Solr.

• Tìm kiếm thời gian thực của Ryan Sonnek : Solr vs ElSTERearch cung cấp một phân tích / so sánh sâu sắc và giải thích lý do tại sao anh ấy chuyển từ Solr sang ElasticSeach, mặc dù đã là một người dùng Solr vui vẻ - anh ấy tóm tắt như sau:

  Solr có thể là vũ khí được lựa chọn khi xây dựng các ứng dụng tìm kiếm tiêu chuẩn , nhưng Elaticsearch đưa nó lên một tầm cao mới với kiến trúc để tạo các ứng dụng tìm kiếm thời gian thực hiện đại . Percolation là một tính năng thú vị và sáng tạo, tự tay thổi bay Solr ra khỏi nước. Elaticsearch có khả năng mở rộng, tốc độ và một giấc mơ để tích hợp . Adios Solr, thật tuyệt khi biết bạn. [nhấn mạnh của tôi]

• Bài viết trên Wikipedia về ElasticSearch trích dẫn một so sánh từ tạp chí iX tiếng Đức, liệt kê những ưu điểm và nhược điểm, trong đó tóm tắt khá nhiều điều đã được nói ở trên:

  Ưu điểm :

  • Tìm kiếm đàn hồi được phân phối. Không có dự án riêng biệt cần thiết. Các bản sao cũng gần thời gian thực, được gọi là "Nhân rộng đẩy".
  • ElasticSearch hỗ trợ đầy đủ cho việc tìm kiếm thời gian thực của Apache Lucene.
  • Xử lý đa nhiệm không phải là một cấu hình đặc biệt, trong đó với Solr, việc thiết lập nâng cao hơn là cần thiết.
  • ElasticSearch giới thiệu khái niệm về Gateway, giúp sao lưu toàn bộ dễ dàng hơn.

  Nhược điểm :

  • Chỉ có một nhà phát triển chính [không áp dụng được nữa theo tổ chức GitHub hiện tại , ngoài việc có một cơ sở giao dịch khá tích cực ở nơi đầu tiên]
  • Không có tính năng tự động kích hoạt [không áp dụng nữa theo API khởi động chỉ mục mới ]

Trả lời ban đầu

Chúng là những công nghệ hoàn toàn khác nhau giải quyết các trường hợp sử dụng hoàn toàn khác nhau, do đó không thể so sánh tất cả theo bất kỳ cách có ý nghĩa nào:

• Apache Solr - Apache Solr cung cấp các khả năng của Lucene trong một máy chủ tìm kiếm nhanh, dễ sử dụng với các tính năng bổ sung như faceting, khả năng mở rộng và nhiều hơn nữa

• Amazon ElastiCache - Amazon ElastiCache là một dịch vụ web giúp dễ dàng triển khai, vận hành và mở rộng quy mô bộ đệm trong bộ nhớ trong đám mây.

  • Xin lưu ý rằng Amazon ElastiCache tuân thủ giao thức với Memcached, một hệ thống lưu trữ đối tượng bộ nhớ được áp dụng rộng rãi, do đó mã, ứng dụng và các công cụ phổ biến mà bạn sử dụng hiện nay với môi trường Memcached hiện tại sẽ hoạt động trơn tru với dịch vụ (xem Memcached để biết chi tiết).

[nhấn mạnh của tôi]

Có lẽ điều này đã bị nhầm lẫn với hai công nghệ liên quan sau đây bằng cách này hay cách khác:

• Tìm kiếm đàn hồi - Đó là một Công cụ tìm kiếm mã nguồn mở (Apache 2), phân tán, RESTful, được xây dựng dựa trên Apache Lucene.

• Amazon CloudSearch - Amazon CloudSearch là một dịch vụ tìm kiếm được quản lý hoàn toàn trong đám mây cho phép khách hàng dễ dàng tích hợp chức năng tìm kiếm nhanh và có khả năng mở rộng cao vào các ứng dụng của họ.

Các dịch vụ Solr và ElasticSearch nghe có vẻ giống nhau ngay từ cái nhìn đầu tiên và cả hai đều sử dụng cùng một công cụ tìm kiếm phụ trợ, cụ thể là Apache Lucene .

Mặc dù Solr cũ hơn, khá linh hoạt và trưởng thành và được sử dụng rộng rãi, nhưng ElasticSearch đã được phát triển đặc biệt để giải quyết các thiếu sót của Solr với các yêu cầu về khả năng mở rộng trong môi trường đám mây hiện đại, khó giải quyết Solr .

Do đó, có thể hữu ích nhất khi so sánh ElasticSearch với Amazon CloudSearch được giới thiệu gần đây (xem bài đăng giới thiệu Bắt đầu tìm kiếm trong một giờ với giá dưới 100 đô la / tháng ), bởi vì cả hai đều yêu cầu bảo hiểm các trường hợp sử dụng tương tự về nguyên tắc.

Tôi thấy một số câu trả lời ở trên hiện đã lỗi thời. Từ góc nhìn của tôi và tôi làm việc với cả Solr (Đám mây và không phải đám mây) và ElasticSearch hàng ngày, đây là một số khác biệt thú vị:

• Cộng đồng: Solr có cộng đồng người dùng, nhà phát triển và cộng tác viên lớn hơn, trưởng thành hơn. ES có một cộng đồng người dùng nhỏ hơn nhưng tích cực và cộng đồng người đóng góp ngày càng tăng
• Trưởng thành: Solr trưởng thành hơn, nhưng ES đã phát triển nhanh chóng và tôi cho rằng nó ổn định
• Hiệu suất: khó đánh giá. Tôi / chúng tôi chưa thực hiện các tiêu chuẩn hiệu suất trực tiếp. Một người tại LinkedIn đã so sánh Solr với ES với Sensei một lần, nhưng kết quả ban đầu nên được bỏ qua vì họ đã sử dụng thiết lập không chuyên gia cho cả Solr và ES.
• Thiết kế: Mọi người yêu thích Solr. API Java có phần dài dòng, nhưng mọi người thích cách nó kết hợp với nhau. Rất tiếc, mã Solr không phải lúc nào cũng rất đẹp. Ngoài ra, ES có tích hợp, sao chép thời gian thực, tài liệu và định tuyến tích hợp. Mặc dù một số điều này tồn tại trong Solr cũng vậy, nó cảm thấy hơi giống như một suy nghĩ sau.
• Hỗ trợ: có các công ty cung cấp hỗ trợ tư vấn và công nghệ cho cả Solr và ElasticSearch. Tôi nghĩ rằng công ty duy nhất cung cấp hỗ trợ cho cả hai là Sematext (tiết lộ: Tôi là người sáng lập Sematext)
• Khả năng mở rộng: cả hai có thể được thu nhỏ thành các cụm rất lớn. ES dễ mở rộng hơn phiên bản Solr 4.0 trước Solr, nhưng với Solr 4.0 thì không còn như vậy nữa.

Để biết thông tin chi tiết hơn về chủ đề Solr so với ElasticSearch, hãy xem https://sematext.com/blog/solr-vs-elaticsearch-part-1-overview/ . Đây là bài đăng đầu tiên trong loạt bài đăng từ Sematext thực hiện so sánh Solr trực tiếp và trung tính so với ElasticSearch. Tiết lộ: Tôi làm việc tại Sematext.

Tôi thấy rằng rất nhiều người ở đây đã trả lời câu hỏi ElasticSearch vs Solr này về các tính năng và chức năng nhưng tôi không thấy nhiều cuộc thảo luận ở đây (hoặc ở nơi khác) về cách họ so sánh về hiệu suất.

Đó là lý do tại sao tôi quyết định tiến hành điều tra của riêng tôi . Tôi đã sử dụng một dịch vụ vi mô nguồn dữ liệu không đồng nhất đã được mã hóa đã sử dụng Solr cho tìm kiếm thuật ngữ. Tôi đã tắt Solr cho ElasticSearch sau đó tôi chạy cả hai phiên bản trên AWS với một ứng dụng kiểm tra tải đã được mã hóa và nắm bắt các số liệu hiệu suất để phân tích tiếp theo.

Đây là những gì tôi tìm thấy. ElasticSearch có thông lượng cao hơn 13% khi nói đến lập chỉ mục tài liệu nhưng Solr nhanh hơn mười lần. Khi truy vấn các tài liệu, Solr có thông lượng gấp năm lần và nhanh hơn năm lần so với Tìm kiếm đàn hồi.

Vì lịch sử lâu đời của Apache Solr, tôi nghĩ một điểm mạnh của Solr là hệ sinh thái của nó . Có nhiều plugin Solr cho các loại dữ liệu và mục đích khác nhau.

Nền tảng tìm kiếm trong các lớp sau từ dưới lên trên:

• Dữ liệu
  • Mục đích: Thể hiện các loại dữ liệu và nguồn khác nhau
• Xây dựng tài liệu
  • Mục đích: Xây dựng thông tin tài liệu để lập chỉ mục
• Lập chỉ mục và tìm kiếm
  • Mục đích: Xây dựng và truy vấn một chỉ mục tài liệu
• Tăng cường logic
  • Mục đích: Logic bổ sung để xử lý các truy vấn và kết quả tìm kiếm
• Dịch vụ nền tảng tìm kiếm
  • Mục đích: Thêm các chức năng bổ sung của lõi công cụ tìm kiếm để cung cấp nền tảng dịch vụ.
• Ứng dụng giao diện người dùng
  • Mục đích: Giao diện hoặc ứng dụng tìm kiếm của người dùng cuối

Bài viết tham khảo: Tìm kiếm doanh nghiệp

Tôi đã tạo một bảng về sự khác biệt lớn giữa elaticsearch và Solr và splunk, bạn có thể sử dụng nó như bản cập nhật năm 2016:

Tôi đã làm việc trên cả tìm kiếm solr và co giãn cho các ứng dụng .Net. Sự khác biệt chính mà tôi đã phải đối mặt là

Tìm kiếm đàn hồi:

• Nhiều mã hơn và ít cấu hình hơn, tuy nhiên vẫn có sự thay đổi nhưng vẫn là thay đổi mã
• đối với các loại phức tạp, hãy nhập trong các loại tức là các loại lồng nhau (không thể đạt được trong solr)

Solr:

• ít mã hơn và cấu hình nhiều hơn và do đó ít bảo trì hơn
• để nhóm các kết quả trong khi truy vấn (rất nhiều công việc cần đạt được trong tìm kiếm co giãn trong thời gian ngắn không theo cách thẳng)

Mặc dù tất cả các liên kết trên đều có giá trị và đã mang lại lợi ích lớn cho tôi trong quá khứ, khi một nhà ngôn ngữ học "tiếp xúc" với các công cụ tìm kiếm Lucene khác nhau trong 15 năm qua, tôi phải nói rằng phát triển tìm kiếm đàn hồi rất nhanh trong Python. Điều đó đang được nói, một số mã cảm thấy không trực quan với tôi. Vì vậy, tôi đã tiếp cận với một thành phần của ngăn xếp ELK, Kibana, từ góc độ nguồn mở, và thấy rằng tôi có thể tạo ra mã hơi khó hiểu của el elearch trong Kibana. Ngoài ra, tôi cũng có thể kéo các truy vấn của Chrome Sense vào Kibana. Nếu bạn sử dụng Kibana để đánh giá es, nó sẽ tăng tốc độ đánh giá của bạn hơn nữa. Phải mất hàng giờ để chạy trên các nền tảng khác, chúng tôi đã chạy và chạy JSON trong Sense trên đỉnh của elaticsearch (giao diện RESTful) trong vài phút ở mức tồi tệ nhất (bộ dữ liệu lớn nhất); trong vài giây tốt nhất Tài liệu về elaticsearch, trong khi hơn 700 trang, không trả lời các câu hỏi mà tôi thường có sẽ được giải quyết trong tài liệu SOLR hoặc Lucene khác, điều này rõ ràng mất nhiều thời gian hơn để phân tích. Ngoài ra, bạn có thể muốn xem Tổng hợp trong tìm kiếm co giãn, đã đưa Faceting lên một cấp độ mới.

Bức tranh lớn hơn: nếu bạn đang làm khoa học dữ liệu, phân tích văn bản hoặc ngôn ngữ học tính toán, elaticsearch có một số thuật toán xếp hạng dường như đổi mới tốt trong lĩnh vực truy xuất thông tin. Nếu bạn đang sử dụng bất kỳ thuật toán TF / IDF, Tần số văn bản / Tần số tài liệu nghịch đảo, elaticsearch sẽ mở rộng thuật toán của năm 1960 này lên một cấp độ mới, thậm chí sử dụng BM25, Best Match 25 và các thuật toán Xếp hạng liên quan khác. Vì vậy, nếu bạn đang chấm điểm hoặc xếp hạng các từ, cụm từ hoặc câu, elaticsearch thực hiện việc ghi điểm này một cách nhanh chóng, mà không cần chi phí lớn cho các phương pháp phân tích dữ liệu khác mà phải mất hàng giờ - một cách tiết kiệm thời gian khác. Với es, kết hợp một số điểm mạnh của việc ghép từ các tập hợp với cách tính điểm và xếp hạng liên quan đến dữ liệu JSON thời gian thực, bạn có thể tìm thấy một kết hợp chiến thắng,

Lưu ý: đã thấy một cuộc thảo luận tương tự về các tổng hợp ở trên, nhưng không phải về các tổng hợp và tính điểm liên quan - lời xin lỗi của tôi cho bất kỳ sự chồng chéo nào. Tiết lộ: Tôi không làm việc cho đàn hồi và sẽ không thể hưởng lợi trong tương lai gần từ công việc tuyệt vời của họ do một con đường kiến ​​trúc khác, trừ khi tôi làm một số công việc từ thiện với elaticsearch, đó sẽ không phải là một ý tưởng tồi

Hãy tưởng tượng trường hợp sử dụng:

1. Rất nhiều (100+) chỉ mục tìm kiếm nhỏ (10Mb-100Mb, 1000-100000).
2. Họ đang sử dụng bởi rất nhiều ứng dụng (microservice)
3. Mỗi ứng dụng có thể sử dụng nhiều hơn một chỉ mục
4. Nhỏ theo chỉ số kích thước, có. Nhưng tải rất lớn (hàng trăm yêu cầu tìm kiếm mỗi giây) và các yêu cầu rất phức tạp (nhiều tập hợp, điều kiện, v.v.)
5. Thời gian chết không được phép
6. Tất cả điều đó là làm việc lâu năm, và không ngừng phát triển.

Ý tưởng để có cá thể ES riêng cho mỗi chỉ số - là chi phí rất lớn trong trường hợp này.

Dựa trên kinh nghiệm của tôi, loại trường hợp sử dụng này rất phức tạp để hỗ trợ với Elaticsearch.

Tại sao?

ĐẦU TIÊN.

Vấn đề chính là sự coi thường tương thích trở lại cơ bản.

Thay đổi đột phá là rất mát mẻ! (Lưu ý: hãy tưởng tượng máy chủ SQL yêu cầu bạn thực hiện một thay đổi nhỏ trong tất cả các câu lệnh SQL của bạn, khi được nâng cấp ... không thể tưởng tượng được. Nhưng đối với ES thì bình thường)

Khấu hao sẽ giảm trong phiên bản lớn tiếp theo là rất gợi cảm! (Lưu ý: bạn biết, Java chứa một số khấu hao, đã hơn 20 năm tuổi, nhưng vẫn hoạt động trong phiên bản Java thực tế ...)

Và không chỉ vậy, đôi khi bạn thậm chí còn có một cái gì đó không được ghi lại (cá nhân chỉ bắt gặp một lần nhưng ...)

Vì thế. Nếu bạn muốn nâng cấp ES (vì bạn cần các tính năng mới cho một số ứng dụng hoặc bạn muốn sửa lỗi) - bạn đang ở trong địa ngục. Đặc biệt nếu đó là về nâng cấp phiên bản lớn.

API khách hàng sẽ không tương thích trở lại. Cài đặt chỉ mục sẽ không tương thích trở lại. Và nâng cấp tất cả các ứng dụng / dịch vụ cùng một lúc với nâng cấp ES là không thực tế.

Nhưng bạn phải làm điều đó theo thời gian. Không con cach nao khac.

Chỉ số hiện tại được tự động nâng cấp? - Đúng. Nhưng nó không giúp bạn khi bạn cần thay đổi một số cài đặt chỉ mục cũ.

Để sống với điều đó, bạn cần liên tục đầu tư rất nhiều sức mạnh vào ... khả năng tương thích về phía trước của các ứng dụng / dịch vụ của bạn với các bản phát hành ES trong tương lai. Hoặc bạn cần xây dựng (và dù sao cũng liên tục hỗ trợ) một số loại phần mềm trung gian giữa ứng dụng / dịch vụ và ES, cung cấp cho bạn API khách hàng tương thích trở lại. (Và, bạn không thể sử dụng Transport Client (vì nó yêu cầu nâng cấp jar cho mọi nâng cấp ES phiên bản nhỏ) và thực tế này không giúp cuộc sống của bạn dễ dàng hơn)

Có vẻ đơn giản và rẻ tiền? Không, không phải vậy. Cách xa nó. Bảo trì liên tục cơ sở hạ tầng phức tạp dựa trên ES, là cách đắt đỏ trong tất cả các giác quan có thể.

THỨ HAI. API đơn giản? Chà ... thực sự không. Khi bạn thực sự sử dụng các điều kiện và tập hợp phức tạp .... Yêu cầu JSON với 5 cấp độ lồng nhau là bất cứ điều gì, nhưng không đơn giản.

Thật không may, tôi không có kinh nghiệm với SOLR, không thể nói bất cứ điều gì về nó.

Nhưng Sphinxsearch tốt hơn nhiều trong kịch bản này, vì SphinxQL hoàn toàn tương thích trở lại.

Lưu ý: Sphinxsearch / Manticore thực sự thú vị. Nó không dựa trên Lucine, và kết quả là khác biệt nghiêm trọng. Chứa một số tính năng độc đáo từ hộp mà ES không có và phát điên nhanh với các chỉ mục kích thước nhỏ / trung bình.

Nếu bạn đã sử dụng SOLR, hãy kiên trì. Nếu bạn đang bắt đầu, hãy tìm kiếm Đàn hồi.

Các vấn đề lớn nhất đã được khắc phục trong SOLR và nó khá chín chắn.

Tôi đã sử dụng Elaticsearch được 3 năm và Solr được khoảng một tháng, tôi cảm thấy cụm elaticsearch khá dễ cài đặt so với cài đặt Solr. Elaticsearch có một kho tài liệu trợ giúp với lời giải thích tuyệt vời. Một trong những trường hợp sử dụng tôi đã bị mắc kẹt với Biểu đồ tổng hợp có sẵn trong ES tuy nhiên không tìm thấy trong Solr.

Tôi chỉ sử dụng Tìm kiếm đàn hồi. Vì tôi thấy solr rất khó để bắt đầu. Tính năng tìm kiếm đàn hồi:

1. Dễ dàng để bắt đầu, rất ít thiết lập. Ngay cả một người mới có thể thiết lập một cụm từng bước.
2. API Restful đơn giản sử dụng truy vấn NoQuery. Và nhiều thư viện ngôn ngữ để dễ dàng truy cập.
3. Tài liệu tốt, bạn có thể đọc cuốn sách :. Có một phiên bản web trên trang web chính thức.

Thêm một tài liệu lồng nhau trong solr rất phức tạp và tìm kiếm dữ liệu lồng nhau cũng rất phức tạp. nhưng Tìm kiếm đàn hồi dễ dàng để thêm tài liệu lồng nhau và tìm kiếm