elaticsearch vs MongoDB để lọc ứng dụng [đã đóng]

Câu hỏi này là về việc đưa ra lựa chọn kiến ​​trúc trước khi đi sâu vào chi tiết thử nghiệm và thực hiện. Đó là về sự phù hợp, về khả năng mở rộng và hiệu suất, của elaticsearch so với MongoDB, cho một mục đích cụ thể.

Theo giả thuyết, cả hai lưu trữ các đối tượng dữ liệu có các trường và giá trị và cho phép truy vấn phần thân của các đối tượng đó. Vì vậy, có lẽ việc lọc ra các tập hợp con của các đối tượng theo các trường được chọn đặc biệt, là một cái gì đó phù hợp cho cả hai.

Ứng dụng của tôi sẽ xoay quanh việc chọn đối tượng theo tiêu chí. Nó sẽ chọn các đối tượng bằng cách lọc đồng thời nhiều hơn một trường, đặt khác nhau, tiêu chí lọc truy vấn của nó thường bao gồm bất kỳ nơi nào giữa 1 và 5 trường, có thể nhiều hơn trong một số trường hợp. Trong khi đó, các trường được chọn làm bộ lọc sẽ là tập hợp con của số lượng trường lớn hơn nhiều. Hình dung khoảng 20 tên trường hiện có và mỗi truy vấn là một nỗ lực để lọc các đối tượng theo một số trường trong số 20 trường tổng thể đó (Có thể ít hơn hoặc hơn 20 tên trường tổng thể hiện có, tôi chỉ sử dụng số này để thể hiện tỷ lệ các trường đến các trường được sử dụng làm bộ lọc trong mọi truy vấn riêng biệt). Việc lọc có thể bằng sự tồn tại của các trường đã chọn, cũng như theo các giá trị trường, ví dụ: lọc ra các đối tượng có trường A và trường B của chúng nằm giữa x và y,

Ứng dụng của tôi sẽ liên tục thực hiện kiểu lọc này, trong khi đó sẽ không có gì hoặc rất ít hằng số về các trường được sử dụng để lọc bất cứ lúc nào. Có lẽ trong các chỉ số tìm kiếm cần phải được xác định, nhưng thậm chí có thể không có chỉ số tốc độ ngang bằng với MongoDB.

Theo dữ liệu vào cửa hàng, không có chi tiết đặc biệt nào về điều đó .. các đối tượng sẽ gần như không bao giờ thay đổi sau khi được chèn. Có lẽ các đối tượng cũ sẽ cần phải được loại bỏ, tôi muốn giả sử cả hai cửa hàng dữ liệu hỗ trợ hết hạn xóa nội dung hoặc bởi một truy vấn được thực hiện bởi ứng dụng. (Ít thường xuyên hơn, các đối tượng phù hợp với một truy vấn nhất định cũng sẽ cần phải được loại bỏ).

Bạn nghĩ sao? Và, bạn đã thử nghiệm khía cạnh này?

Tôi quan tâm đến hiệu suất và khả năng mở rộng của nó, của mỗi trong hai kho lưu trữ dữ liệu, cho loại nhiệm vụ này. Đây là loại câu hỏi mong muốn về kiến ​​trúc và chi tiết về các tùy chọn dành riêng cho cửa hàng hoặc nền tảng truy vấn sẽ khiến nó được kiến ​​trúc tốt được chào đón như một minh chứng cho một gợi ý hoàn toàn có thể nghĩ ra.

Cảm ơn!

Trước hết, có một sự khác biệt quan trọng cần thực hiện ở đây: MongoDB là một cơ sở dữ liệu mục đích chung, Elaticsearch là một công cụ tìm kiếm văn bản phân tán được hỗ trợ bởi Lucene. Mọi người đã nói về việc sử dụng Elaticsearch như một cơ sở dữ liệu mục đích chung nhưng biết rằng đó không phải là thiết kế ban đầu của nó. Tôi nghĩ rằng cơ sở dữ liệu và các công cụ tìm kiếm NoQuery có mục đích chung đang hướng tới hợp nhất nhưng vì thế, cả hai đến từ hai phe rất khác nhau.

Chúng tôi đang sử dụng cả MongoDB và Elaticsearch trong công ty của tôi. Chúng tôi lưu trữ dữ liệu của mình trong MongoDB và chỉ sử dụng Elaticsearch cho các khả năng tìm kiếm toàn văn của nó. Chúng tôi chỉ gửi một tập hợp con của các trường dữ liệu mongo mà chúng tôi cần truy vấn để co giãn. Trường hợp sử dụng của chúng tôi khác với trường hợp của bạn ở chỗ dữ liệu Mongo của chúng tôi luôn thay đổi: một bản ghi hoặc một tập hợp con của các bản ghi, có thể được cập nhật nhiều lần trong ngày và điều này có thể yêu cầu lập chỉ mục lại bản ghi đó thành co giãn. Vì lý do đó, sử dụng co giãn làm kho lưu trữ dữ liệu duy nhất không phải là một lựa chọn tốt cho chúng tôi, vì chúng tôi không thể cập nhật các trường chọn; chúng ta sẽ cần lập chỉ mục lại toàn bộ tài liệu. Đây không phải là giới hạn đàn hồi, đây là cách Lucene hoạt động, công cụ tìm kiếm cơ bản đằng sau đàn hồi. Trong trường hợp của bạn, thực tế là hồ sơ đã thắng ' T được thay đổi một khi được lưu trữ giúp bạn không phải lựa chọn đó. Phải nói rằng, nếu an toàn dữ liệu là một mối quan tâm, tôi sẽ suy nghĩ kỹ về việc sử dụng Elaticsearch làm cơ chế lưu trữ duy nhất cho dữ liệu của bạn. Nó có thể đến đó vào một lúc nào đó nhưng tôi không chắc nó đã ở đó.

Về tốc độ, không chỉ là Đàn hồi / Lucene ngang bằng với tốc độ truy vấn của Mongo, trong trường hợp của bạn có "rất ít hằng số về các trường được sử dụng để lọc bất cứ lúc nào", đó có thể là các lệnh của cường độ nhanh hơn, đặc biệt là khi các bộ dữ liệu trở nên lớn hơn. Sự khác biệt nằm ở việc triển khai truy vấn cơ bản:

• Đàn hồi / Lucene sử dụng Mô hình không gian vectơ và các chỉ mục đảo ngược cho Truy xuất thông tin , đây là những cách hiệu quả cao để so sánh độ tương tự của bản ghi với truy vấn. Khi bạn truy vấn đàn hồi / Lucene, nó đã biết câu trả lời; hầu hết công việc của nó nằm ở việc xếp hạng kết quả cho bạn theo những kết quả phù hợp nhất với các thuật ngữ truy vấn của bạn. Đây là một điểm quan trọng: công cụ tìm kiếm, trái ngược với cơ sở dữ liệu, không thể đảm bảo cho bạn kết quả chính xác; họ xếp hạng kết quả theo mức độ gần với truy vấn của bạn. Nó chỉ xảy ra rằng hầu hết các lần, kết quả gần chính xác.
• Cách tiếp cận của Mongo là một cửa hàng dữ liệu có mục đích chung hơn; nó so sánh các tài liệu JSON với nhau. Bạn có thể đạt được hiệu suất tuyệt vời từ nó bằng mọi cách, nhưng bạn cần phải cẩn thận tạo các chỉ mục của mình để phù hợp với các truy vấn bạn sẽ chạy. Cụ thể, nếu bạn có nhiều trường mà bạn sẽ truy vấn, bạn cần phải cẩn thận tạo các khóa ghép của mìnhđể họ giảm dữ liệu sẽ được truy vấn nhanh nhất có thể. Ví dụ: khóa đầu tiên của bạn sẽ lọc phần lớn tập dữ liệu của bạn, khóa thứ hai của bạn sẽ tiếp tục lọc những gì còn lại, v.v. Nếu các truy vấn của bạn không khớp với các khóa và thứ tự của các khóa đó trong các chỉ mục được xác định, hiệu suất của bạn sẽ giảm đi một chút. Mặt khác, Mongo là một cơ sở dữ liệu thực sự, vì vậy nếu độ chính xác là những gì bạn cần, câu trả lời mà nó sẽ đưa ra sẽ được đưa ra.

Để hết hạn các bản ghi cũ, Đàn hồi có tính năng TTL tích hợp. Mongo chỉ giới thiệu nó như phiên bản 2.2 tôi nghĩ.

Vì tôi không biết các yêu cầu khác của bạn như kích thước dữ liệu, giao dịch, độ chính xác dự kiến ​​hoặc bộ lọc của bạn sẽ trông như thế nào, thật khó để đưa ra bất kỳ đề xuất cụ thể nào. Hy vọng, có đủ ở đây để giúp bạn bắt đầu.