Đối với một điều, Map/Reduce trong MongoDB không được thực hiện cho các truy vấn đặc biệt, có chi phí đáng kể cho M/R. Ngay cả một hoạt động M/R rất đơn giản trên một tập dữ liệu nhỏ có thể mất hàng trăm mili giây vì chi phí trên. Tôi không thể nói nhiều về hiệu suất của M/R so với khung tổng hợp trên các tập dữ liệu lớn trong thực tế, nhưng về mặt lý thuyết, các hoạt động M/R trên một cơ sở dữ liệu lớn sẽ nhanh hơn vì các phân đoạn có thể chạy hoạt động chủ yếu song song.
Với tính linh hoạt, vì M/R thực sự chạy các phương thức javascript, bạn có toàn bộ sức mạnh của ngôn ngữ theo ý của mình. Ví dụ: giả sử bạn muốn nhóm một số dữ liệu bằng cosin của giá trị của trường. Vì không có toán tử $cos trong khung kết hợp, cũng không phải là cách có ý nghĩa để tạo các nhóm rời rạc từ các số liên tục (giống như $truncate), khung tổng hợp sẽ không giúp ích trong trường hợp đó.
Vì vậy, trong Tóm lại, tôi muốn nói với các trường hợp sử dụng nằm
- giữ kết quả của M/R trong một bộ sưu tập riêng biệt và cập nhật nó bất cứ lúc nào (bằng cách sử dụng tham số
out và sáp nhập các kết quả)
- Truy vấn phức tạp trên các tập dữ liệu được phân đoạn lớn
- Các truy vấn phức tạp đến mức bạn không thể sử dụng khung tổng hợp. Tôi muốn nói đó là một dấu hiệu khá chắc chắn về lỗ hổng thiết kế trong cấu trúc dữ liệu, nhưng về nguyên tắc, nó có thể giúp