Hiệu suất MongoDB

Trong khi cải thiện hiệu suất tổng thể cho Parqet, một công ty khởi nghiệp công nghệ tài chính để trực quan hóa danh mục đầu tư và sự giàu có của bạn, tôi đã học được khá nhiều điều. Hôm nay, tôi muốn chia sẻ những bài học đó và đưa ra một số mẹo để cải thiện hiệu suất MongoDB

Một số mẫu mã sẽ bằng JavaScript/TypeScript, tuy nhiên, chúng cũng có thể áp dụng cho các ngôn ngữ khác. Hãy đi sâu vào ngay

dụng cụ

Để tối ưu hóa hiệu suất của truy vấn MongoDB, trước tiên bạn cần hiểu hiệu suất hiện tại của mình. Để làm như vậy, bạn nên đo lường hoặc trực quan hóa việc thực hiện truy vấn của mình

Tương tự như các cơ sở dữ liệu khác, MongoDB có chức năng Giải thích. Điều này cho phép bạn hiểu sâu về kế hoạch thực hiện và hiệu suất của truy vấn của mình. Có một số công cụ giúp bạn

MongoDB La bàn

MongoDB Compass là một GUI đa nền tảng, được phát triển bởi MongoDB Inc. Cá nhân tôi luôn sử dụng nó và rất có thể khuyên dùng nó để phân tích hiệu suất truy vấn hoặc thực hiện các tác vụ cơ sở dữ liệu phổ biến khác

Khi kết nối với cơ sở dữ liệu của bạn, hãy chọn “Giải thích rõ ràng” để kiểm tra hiệu suất truy vấn của bạn và nhận một số thông tin chi tiết về những gì truy vấn đã thực hiện chính xác

MongoDB La bàn. giải thích kế hoạch

Hình ảnh trực quan giúp bạn hiểu các giai đoạn mà truy vấn của bạn trải qua, giai đoạn nào mất nhiều thời gian nhất, có bao nhiêu tài liệu đã được kiểm tra, nếu một chỉ mục được sử dụng, v.v. Thật tuyệt vời để gỡ lỗi các truy vấn

Bạn có thể làm tương tự trong chế độ xem tổng hợp bằng cách nhấn nút “Giải thích”

MongoDB La bàn. Giải thích tập hợp

Bản đồ MongoDB

MongoDB Atlas, dịch vụ đám mây chính thức dành cho MongoDB cung cấp một số hiểu biết sâu sắc về hiệu suất và thậm chí cố gắng cung cấp cho bạn một số lời khuyên về cách cải thiện hiệu suất truy vấn. Atlas Profiler cung cấp cho bạn thông tin chi tiết về các khóa được kiểm tra, thời gian thực hiện, …

Bản đồ MongoDB. Hồ sơ

Ngoài ra, Atlas cũng cố gắng tư vấn cho bạn cách đạt được một số hiệu suất (bớt tra cứu, thêm chỉ mục,…)

Bản đồ MongoDB. Cố vấn hiệu suất

Mặc dù điều này sẽ không khắc phục được các truy vấn của chúng tôi, nhưng nó sẽ cho chúng tôi thấy các nút cổ chai và cho chúng tôi một điểm khởi đầu tốt

Vỏ MongoDB

Trong trường hợp bạn cảm thấy thoải mái với CLI, bạn có thể thích MongoDB Shell. Bằng cách thêm explain() vào truy vấn của bạn, bạn có thể nhận được thông tin chi tiết về truy vấn của mình

Giám sát

Sau khi bạn triển khai các thay đổi, bạn nên tiếp tục theo dõi tải CPU, lưu trữ, thời gian truy vấn, … để đảm bảo rằng các thay đổi của bạn thực sự có lợi

Tôi chắc chắn rằng có những công cụ độc quyền khác (không phải do MongoDB phát triển), tôi chưa bao giờ phải sử dụng một công cụ nào. Bạn có bất kỳ trải nghiệm tích cực nào với các công cụ khác để tối ưu hóa hiệu suất truy vấn của mình hoặc có được một số thông tin chi tiết không?

tôi muốn nghe về nó

chỉ số

Các trường bạn truy vấn phải được bao phủ bởi một Chỉ mục

Thay vì đi qua từng hàng (quét bộ sưu tập) và kiểm tra xem truy vấn của bạn có khớp với hàng hay không, một chỉ mục sẽ tăng tốc quá trình. Xem tài liệu chính thức để hiểu sâu hơn về cách thức hoạt động của chỉ mục

MongoDB thêm một chỉ mục trên trường _id theo mặc định. Bên cạnh đó, bạn cần thêm các chỉ mục vào bộ sưu tập của mình. Hãy lấy một bộ sưu tập mẫu với một triệu mục nhập. Cấu trúc dữ liệu của chúng tôi trông như thế này

tài liệu mẫu

Trước tiên hãy truy vấn dữ liệu mà không có bất kỳ chỉ mục nào. Tìm nội dung phù hợp với ISIN

db.assets.find({ isin: "US123456890" })

Truy vấn không có chỉ mục

Truy vấn mất tổng cộng 398 mili giây (xem “Thời gian thực hiện truy vấn thực tế (ms)”). Bạn có thể thấy rằng MongoDB đã phải trải qua một triệu mục để tìm nội dung. Hãy thêm một chỉ mục thích hợp và thử lại

db.assets.createIndex({ isin: 1 }) // ascending

Truy vấn với chỉ mục

Như bạn có thể thấy, hiệu suất truy vấn tăng lên rất nhiều (dưới mili giây — nó chỉ hiển thị 0 mili giây), vì các truy vấn của chúng tôi được bao phủ bởi một chỉ mục

Hạn chế khi thêm một chỉ mục bao gồm giảm hiệu suất ghi và tăng dung lượng lưu trữ. Bạn nên ghi nhớ điều đó và không lập chỉ mục cho mọi lĩnh vực mà nhân loại biết đến. Tuy nhiên, các trường thường được truy vấn chắc chắn phải được bao phủ bởi một chỉ mục

chỉ số hợp chất

Khi truy vấn nhiều trường, MongoDB sẽ cố gắng hết sức để làm việc với các chỉ mục hiện có và tối ưu hóa truy vấn của bạn. Khi bạn có nhiều trường thường được truy vấn cùng nhau, bạn nên sử dụng Chỉ mục tổng hợp. Chỉ mục tổng hợp là một chỉ mục dựa trên nhiều trường. Giả sử bạn thường truy vấn ngày IPO và ngày chia cổ tức

Không có truy vấn phức hợp (một chỉ mục vào ngày IPO)

db.assets.createIndex({ ipoDate: -1 })

Truy vấn không có chỉ mục phức hợp

Mặc dù chúng tôi đạt được một chỉ mục, MongoDB vẫn phải vượt qua ~568. 000 mục nhập, vì những mục nhập đó khớp với tiêu chí ngày IPO. Hãy thêm một chỉ số phức hợp bao trùm cả hai trường

db.assets.createIndex({ ipoDate: -1, "dividends.date": -1 })

Truy vấn với chỉ mục phức hợp

Với chỉ mục phức hợp, MongoDB chỉ xem qua ~9150 tài liệu (tất cả các tài liệu phù hợp). Tổng thời gian thực hiện truy vấn cũng tăng từ 1800 mili giây lên 755 mili giây. Chưa tối ưu, nhưng đã là một cải tiến tuyệt vời rồi

Mảng lập chỉ mục

Cũng có thể lập chỉ mục các trường trong mảng. Lưu ý rằng bạn không thể thêm chỉ mục ghép trên hai trường mảng. Khi sử dụng truy vấn $exists

Bạn có thể thêm chỉ mục vào myArray.0 để bao hàm truy vấn bằng chỉ mục. Khi thường truy vấn một thuộc tính bên trong một mảng

Bạn có thể thêm một chỉ mục vào myArray.myProperty và nó sẽ sử dụng chỉ mục khi khớp với thuộc tính bên trong mảng

dự đoán

Theo mặc định, MongoDB sẽ trả về toàn bộ tài liệu. Phép chiếu cho phép bạn giảm bớt, thêm hoặc sửa đổi tài liệu trước khi tìm nạp chúng. Điều này cho phép bạn tối ưu hóa tải trọng tài liệu và tăng tối đa hiệu suất truy vấn

Xóa các trường khỏi tài liệu

Xóa nhiều trường khỏi tài liệu

Khi xóa các trường, tất cả các trường khác sẽ vẫn hiện diện

Bao gồm rõ ràng một lĩnh vực

Khi bao gồm một trường bằng cách sử dụng : 1, các trường khác sẽ bị bỏ qua. MongoDB sẽ luôn bao gồm trường _id trừ khi bạn sử dụng rõ ràng _id1 trong phép chiếu của mình

Thêm trường

Phép chiếu cũng cho phép bạn thêm các trường vào tài liệu, tôi. e. tính toán một giá trị dựa trên các trường khác

Phép chiếu này bổ sung thêm _id2 được tính toán dựa trên các trường giá cuối cùng và giá trị vốn hóa thị trường

Giảm mảng

Các phép chiếu khá linh hoạt, vì vậy bạn cũng có thể trả về một tập hợp con của một mảng, nếu bạn chỉ quan tâm đến một vài mục đầu tiên

Đó chỉ là một vài ví dụ về cách sử dụng phép chiếu để giảm hoặc tăng tải trọng tài liệu trước khi tìm nạp

Chúng tôi nhận thấy rằng điều này có tác động lớn đến tính ổn định của các truy vấn của chúng tôi. Hiệu suất trở nên dễ đoán hơn, đặc biệt là với các tài liệu có thể có nhiều dữ liệu trong một tài liệu

Truy vấn được bảo hiểm

Các truy vấn của bạn có thể siêu nhanh, tuy nhiên, MongoDB vẫn phải đọc dữ liệu thực từ đĩa để truy xuất nó. Mặc dù cách này nhanh nhưng vẫn có một cách khác để làm cho nó nhanh hơn nữa

Khi bạn chỉ quan tâm đến một tập hợp con các thuộc tính từ tài liệu của mình và tất cả các trường được bao phủ bởi một chỉ mục hoặc chỉ mục phức hợp, MongoDB thực sự có thể đọc dữ liệu khỏi chỉ mục, cải thiện hơn nữa hiệu suất truy vấn. Đây được gọi là một

Điều này có thể chỉ giúp bạn tiết kiệm một vài phần nghìn giây, nhưng vẫn đáng xem nếu bạn thực sự muốn tận dụng từng chút hiệu suất

Cấu trúc dữ liệu

Chúng tôi đang xử lý cơ sở dữ liệu NoSQL không liên quan — mặc dù có thể kết hợp dữ liệu (sử dụng _id3), bạn nên tránh sử dụng nó khi có thể, vì nó không hiệu quả như vậy. Do đó, bạn cần suy nghĩ về cấu trúc dữ liệu của mình và lý tưởng nhất là nhóm dữ liệu liên quan vào một tài liệu duy nhất

Bạn có thể gặp phải những tình huống mà cách thích hợp duy nhất để tối ưu hóa hiệu suất truy vấn là thay đổi cấu trúc dữ liệu của bạn. Thay đổi cấu trúc dữ liệu có thể tốn nhiều công sức, vì vậy đáng để dành thời gian suy nghĩ kỹ hơn về cấu trúc dữ liệu

Tạo dữ liệu “lượt xem”

Khi bạn không cần dữ liệu trong thời gian thực, bạn cũng có thể sử dụng tập hợp để kết hợp dữ liệu từ nhiều tập hợp thành một tập hợp duy nhất, giúp cải thiện đáng kể hiệu suất truy vấn. Hãy tưởng tượng có các bộ sưu tập sau

Một danh mục đầu tư có n cổ phần và một cổ phần có một tài sản. Chúng tôi muốn truy vấn danh mục đầu tư cho nội dung để kiểm tra xem danh mục đầu tư có chứa nội dung cụ thể không

Bạn có thể thực hiện tra cứu trên hai bộ sưu tập - mặc dù điều đó sẽ không nhanh lắm và CPU rất mạnh. Mặc dù bạn có thể tranh luận rằng cấu trúc dữ liệu phải khác ngay từ đầu, đôi khi chúng ta không thể đơn giản thay đổi cấu trúc dữ liệu từ các hệ thống đang chạy, ít nhất là không dễ dàng như vậy

Hãy tổng hợp dữ liệu (i. e. hàng giờ) và viết nó vào một bộ sưu tập riêng biệt, có thể truy vấn được và cũng có thể hưởng lợi từ các chỉ mục mà không cần thực hiện bất kỳ tra cứu nào khi đang di chuyển

Truy vấn sau đây nhóm tất cả các mã định danh nội dung trên mỗi danh mục đầu tư và ghi chúng vào một bộ sưu tập _id4 riêng biệt

Bây giờ chúng tôi có thể truy vấn bộ sưu tập _id4 mới. Mặc dù dữ liệu không có sẵn trong thời gian thực, nhưng hiệu suất truy vấn có thể tăng từ 1–2 giây lên vài mili giây. Với MongoDB Atlas, bạn cũng có thể chạy nó như một công việc CRON

đọc tùy chọn

Nếu không được cấu hình khác, thao tác đọc thường được thực hiện trên nút chính của cụm

Khi tần suất dữ liệu không quan trọng (chậm trễ vài mili giây hoặc giây cũng được), bạn có thể yêu cầu MongoDB đọc dữ liệu từ một nút phụ một cách rõ ràng

Mặc dù điều này sẽ không tăng hiệu suất truy vấn của bạn lên gấp 10 lần, nhưng điều này sẽ giúp tải của bạn được cân bằng đồng đều hơn trên cụm của bạn, làm cho các truy vấn ổn định hơn và có thể dự đoán được

Dưới đây là ảnh chụp màn hình trước và sau khi sử dụng tùy chọn đọc một cách có ý thức và ưu tiên đọc từ phiên bản thứ cấp (sao chép) cho một loạt truy vấn. Quyền chính nằm ở ngoài cùng bên phải. Sau khi thay đổi một loạt các truy vấn được sử dụng thường xuyên thành một tùy chọn đọc khác, tải sẽ cân bằng hơn trên toàn cụm

Bản đồ MongoDB. Tác động của tùy chọn đọc (tải đều hơn)

Để biết các tùy chọn bổ sung cho tùy chọn đọc, hãy xem tài liệu chính thức

Viết mối quan tâm

Trong một thiết lập theo cụm, theo mặc định, tất cả các thao tác ghi được ghi vào nút chính và oplog — từ đó, các thao tác sẽ được áp dụng cho các nút bản sao

Thao tác ghi yêu cầu xác nhận từ nút chính. Với ghi không quan trọng, bạn cũng có thể bỏ qua xác nhận (lưu ý rằng bạn sẽ không được thông báo trong trường hợp không thành công)

_id6

Tùy thuộc vào nhu cầu của bạn, bạn có thể tăng đáng kể thông lượng dữ liệu bằng cách thay đổi mối quan tâm ghi. Sử dụng một cách thận trọng, mặc dù. Để biết các tùy chọn bổ sung cho vấn đề ghi, hãy xem tài liệu chính thức

Tối ưu hóa tổng hợp của bạn

Mặc dù Tổng hợp là một tính năng rất mạnh, nhưng bạn có thể dễ dàng làm hỏng hiệu suất

Cách tốt nhất để cải thiện các tập hợp của bạn là đánh giá chúng và kiểm tra các kế hoạch thực hiện để có thể tối ưu hóa. Cố gắng giảm dữ liệu trước (tôi. e. bằng cách nhóm hoặc sử dụng bộ lọc _id7), trước khi thực hiện tra cứu hoặc áp dụng thêm các đột biến. Tôi không thể cung cấp cho bạn mẹo hiệu suất chung vì các tập hợp mang tính cá nhân cao

Thông qua MongoDB Atlas Profiler, chúng tôi đã xem xét các tập hợp mất nhiều thời gian nhất để thực thi và tối ưu hóa chúng (thêm chỉ mục, giảm tải trọng, lọc, nhóm, tái cấu trúc dữ liệu, …)

Trong một số trường hợp, nó thậm chí có thể tăng hiệu suất, khi bạn không thực hiện mọi thứ trong một tập hợp lớn mà là nhiều truy vấn và có thể một số mã trong ứng dụng của bạn để xử lý

Nén

Nếu không được cấu hình, MongoDB sẽ gửi/nhận dữ liệu không nén. Như bạn có thể biết, dữ liệu văn bản không nén có khả năng lớn hơn ~80–90% so với JSON nén, nghĩa là bạn sẽ tìm nạp nhiều dữ liệu hơn và tải mạng của bạn tăng lên

Nén luôn là sự đánh đổi giữa tốc độ, tài nguyên xử lý (CPU) và kích thước/tải mạng. MongoDB hỗ trợ các thuật toán nén sau

• ZLib
• ZStd
• vui nhộn

Bạn có thể cho MongoDB biết nên sử dụng kiểu nén nào khi kết nối với máy chủ bằng cách thêm tham số truy vấn _id8

_id9

Trình điều khiển MongoDB đã xử lý việc này cho bạn, đây là một ví dụ về cách sử dụng Snappy của Google với trình điều khiển Node

Không có câu trả lời chung về thuật toán nén nào là tốt nhất. Một số thuật toán nhanh hơn, một số ít tốn CPU hơn, một số có kích thước dữ liệu nhỏ hơn. Nó phụ thuộc vào dữ liệu của bạn và các kiểu truy cập — vì vậy bạn nên thực hiện các điểm chuẩn và tìm ra thuật toán nào phù hợp nhất

Chúng tôi đã sử dụng Snappy (vì chúng tôi cũng sử dụng Snappy khi ghi vào Redis). Tải mạng giảm đáng kể và tăng hiệu suất

tìm nạp song song

Truy vấn của bạn thực thi trong 3 mili giây, nhưng ứng dụng của bạn vẫn mất 500 mili giây để lấy dữ liệu?

Bạn đã sử dụng tính năng nén và chiếu để giảm lượng dữ liệu gửi đến ứng dụng của mình. Một cách nữa để cải thiện hiệu suất là song song hóa yêu cầu của bạn

Nếu bạn biết mình sẽ truy vấn dữ liệu trong 25 năm, bạn có thể chia nó thành các phần 5 năm và gửi song song tất cả năm yêu cầu. MongoDB có thể dễ dàng xử lý 5 truy vấn đó và ứng dụng của bạn cũng vậy. Thận trọng khi sử dụng vì bạn có thể dễ dàng làm quá tải ứng dụng của mình hoặc MongoDB, khi bạn có quá nhiều mục trong khối của mình

Chúng tôi có thể giảm tổng thời gian truy vấn bằng một số truy vấn truy xuất > 6000 hàng xuống 3–4 x bằng cách chia nhỏ yêu cầu và đưa ra các yêu cầu song song

Tổng hợp kết nối

Hầu hết, nếu không muốn nói là tất cả, trình điều khiển MongoDB hỗ trợ kết nối tổng hợp

Với tổng hợp kết nối, ứng dụng giữ kết nối với MongoDB mở, chờ truy vấn, tăng tốc truy vấn, vì có thể bỏ qua giai đoạn kết nối ban đầu. Tùy thuộc vào thiết lập và nhu cầu của bạn, bạn có thể sửa đổi kích thước nhóm trong ứng dụng của mình và có thể cải thiện thông lượng

Với cấu hình này, ứng dụng của chúng tôi sẽ có ít nhất 50 kết nối mở và có thể mở rộng tới 250. Nếu tất cả 250 kết nối đang được sử dụng, ứng dụng của bạn sẽ đợi bất kỳ kết nối nào không hoạt động, trước khi thực hiện truy vấn

Ngoài ra, hãy nhớ rằng nếu ứng dụng của bạn được nhóm lại, mọi phiên bản sẽ có các cài đặt này. Nếu bạn đặt kích thước nhóm tối thiểu là 250 và bạn có 4 phiên bản đang chạy và thực hiện triển khai xanh lục-xanh lam, thì bạn có thể có 6–8 phiên bản đang chạy trong một thời gian và đã sử dụng tối thiểu 1500–2000 kết nối. Khi sử dụng MongoDB Atlas, hãy kiểm tra giới hạn kết nối của bạn, dựa trên gói của bạn

Cấu hình máy khách nâng cao

Tùy thuộc vào nền tảng của bạn, có thể đáng để xem xét các tùy chọn cấu hình máy khách. Ví dụ: trong trường hợp trình điều khiển Node MongoDB, bạn có thể tắt xác thực UTF-8 để cải thiện hiệu suất

Kiểm tra tài liệu của trình điều khiển MongoDB cụ thể của bạn để biết các loại tùy chọn này. Đảm bảo đọc tác động của tùy chọn, vì hiệu suất đạt được có thể có những nhược điểm khác (kiểm tra xem chúng có ảnh hưởng đến bạn không)

Sharding và Replication

Khi mở rộng quy mô tài nguyên máy chủ và tối ưu hóa các truy vấn không còn tác động lớn nữa và bạn có hàng tỷ hàng, bạn có thể muốn xem xét Sharding

Sharding phân phối dữ liệu của bạn trên nhiều máy hỗ trợ bộ dữ liệu rất lớn và thông lượng cao. Sharding giúp bạn mở rộng quy mô khi dữ liệu của bạn tăng lên. Với sharding, bạn cần thêm tài nguyên máy tính và lưu trữ, mặc dù vậy, bạn sẽ phải trả tiền

Vì chi phí cho việc này quá cao đối với chúng tôi, chúng tôi đã bỏ qua nó, vì vậy tôi không thể cung cấp cho bạn bất kỳ hiểu biết cá nhân nào

Chuỗi thời gian

MongoDB giới thiệu bộ sưu tập TimeSeries với phiên bản 5. 0. Họ cũng nhận được rất nhiều tình cảm trong 6. dòng phát hành x. Khi xử lý dữ liệu TimeSeries, bạn có thể nên sử dụng loại bộ sưu tập TimeSeries, thay vì bộ sưu tập thông thường

Lưu ý rằng bạn phải chọn loại bộ sưu tập ngay từ đầu, sau đó bạn không thể chuyển sang bộ sưu tập TimeSeries. Nếu bạn muốn chuyển bộ sưu tập của mình sang TimeSeries, bạn cần di chuyển dữ liệu, có một ví dụ trong tài liệu chính thức

Mặc dù MongoDB TimeSeries chắc chắn phù hợp hơn với dữ liệu chuỗi thời gian so với các bộ sưu tập thông thường, nhưng MongoDB chắc chắn không phải là cơ sở dữ liệu TimeSeries nhanh nhất hiện có

Chúng tôi đã đánh giá chuỗi thời gian MongoDB và so sánh nó với Redis TimeSeries. Thời gian trung bình để tìm nạp dữ liệu với Redis Timeseries là ~1–2ms, với MongoDB là 20–30ms. Mặc dù 20–30 mili giây không chậm, nhưng nó vẫn chậm hơn 10–20 lần đối với trường hợp sử dụng của chúng tôi và do quá trình sao chép ảnh hưởng đến một trong những dữ liệu được truy vấn nhiều nhất của chúng tôi, chúng tôi đã quyết định không sử dụng MongoDB cho điều đó trong tương lai

Tìm kiếm bản đồ

Trong trường hợp bạn cần tìm kiếm toàn văn mạnh mẽ và linh hoạt, MongoDB cung cấp Tìm kiếm Atlas

Tuy nhiên, tính năng này chỉ khả dụng trên Atlas chứ không phải khi bạn tự lưu trữ phiên bản cộng đồng của MongoDB. Với việc khóa nhà cung cấp này, tôi chỉ có thể khuyên bạn nên sử dụng tính năng này nếu bạn chắc chắn rằng bạn sẽ không sớm hoặc không bao giờ di chuyển thiết lập MongoDB của mình khỏi Atlas

Chúng tôi đã tích hợp tìm kiếm Atlas và không chỉ cải thiện hiệu suất tìm kiếm mà cả kết quả tìm kiếm. Trước đây, chúng tôi đã có một Chỉ mục văn bản đơn giản, cũng cung cấp một số loại tìm kiếm toàn văn bản, nhưng gần như không mạnh bằng Tìm kiếm Atlas

Điều thú vị về Tìm kiếm Atlas là bạn có thể xác định các chỉ số tìm kiếm của mình dựa trên các bộ sưu tập hiện tại của mình, điều này cắt đứt hoàn toàn nỗ lực phát triển để tích hợp. Điều duy nhất bạn phải làm là viết một truy vấn tổng hợp để truy vấn chỉ mục tìm kiếm

Lưu trữ các truy vấn của bạn

Mặc dù đây không phải là một mẹo hiệu suất MongoDB, nhưng đây có phải là một đề cập đáng trân trọng không. Tuy nhiên, vì hướng dẫn này chủ yếu nói về hiệu suất, nên chúng tôi không thể bỏ qua thực tế rằng bộ nhớ đệm có thể là một trong những cách tốt nhất để cải thiện hiệu suất ứng dụng của bạn. Lưu trữ dữ liệu của bạn trong bộ nhớ đệm hoặc trong bộ đệm được phân phối như Redis có thể giúp dữ liệu của bạn truy cập dưới một phần nghìn giây mọi lúc

Bộ nhớ đệm không miễn phí. Sự phức tạp được thêm vào về cơ sở hạ tầng và mã ứng dụng, các chiến lược vô hiệu hóa bộ nhớ đệm và bộ đệm và độ mới của dữ liệu cần được xem xét

Chúng tôi đã kiểm tra các bộ sưu tập thường xuyên nhất (hấp dẫn nhất) và cố gắng giới thiệu hoặc cải thiện các chiến lược bộ nhớ đệm của mình để truy vấn MongoDB ít hơn. Atlas cũng cung cấp cho bạn một số thông tin chi tiết thú vị theo thời gian thực về các bộ sưu tập hấp dẫn nhất của bạn

Bản đồ MongoDB. Số liệu thời gian thực Tổng kết

Nó là một bọc. Tôi đã cố gắng tóm tắt những điều tôi học được và những điều tôi thấy có tác động nhất khi tối ưu hóa hiệu suất truy vấn MongoDB. Tôi hy vọng bạn đã học được điều gì đó từ những gì tôi học được, ngay cả khi đó chỉ là một gợi ý về nơi cần tìm tiếp theo

Một số gợi ý bổ sung

• Tài liệu MongoDB. Tối ưu hóa hiệu suất truy vấn
• Tài liệu MongoDB. Hướng dẫn thực hành tốt nhất cho hiệu suất MongoDB
• Nhà phát triển MongoDB. Câu hỏi điều chỉnh hiệu suất MongoDB

Điều tác động nhất mà bạn đã làm để cải thiện hiệu suất MongoDB là gì?

MongoDB có hiệu suất cao không?

Làm cách nào để cải thiện hiệu suất trong MongoDB?

MongoDB có nhanh hơn SQL không?

MongoDB có nhanh và có thể mở rộng không?