Caching lặp lại kết quả truy vấn trong MongoDB

Question

Tôi sẽ xây dựng một trang được thiết kế để được "xem" rất nhiều, nhưng ít người dùng hơn sẽ "ghi" vào cơ sở dữ liệu. Ví dụ: chỉ 1 trong 100 người dùng có thể đăng tin tức của anh ấy trên trang web của tôi và phần còn lại sẽ chỉ đọc tin tức.

Trong trường hợp trên, 100 CÂU HỎI NHU CẦU sẽ được thực hiện khi họ truy cập vào trang chủ của tôi trong khi thay đổi cơ sở dữ liệu thực tế ít. Trên thực tế 99 trong số các truy vấn đó là một sự lãng phí năng lượng máy tính. Có bất kỳ phương pháp nào có thể lưu trữ kết quả của truy vấn đầu tiên và khi chúng phát hiện cùng một truy vấn trong một thời gian ngắn, có thể phân phối kết quả được lưu trong bộ nhớ cache không?

Tôi sử dụng MongoDB và Tornado. Tuy nhiên, một số bài viết nói rằng MongoDB không làm bộ nhớ đệm.

Tạo HTML tĩnh, được lưu trong bộ nhớ cache với một cái gì đó như Nginx không được ưa thích, bởi vì tôi muốn hiển thị một trang được cá nhân hóa bởi Tornado mỗi lần.

Answer 1

Tác giả của gói Motor (Mongo + Tornado) đưa ra một ví dụ về bộ nhớ đệm danh sách của mình các loại ở đây: http://emptysquare.net/blog/refactoring-tornado-code-with-gen-engine/

Về cơ bản, ông định nghĩa một danh sách toàn cầu của các loại và truy vấn cơ sở dữ liệu để điền vào nó trong; sau đó, bất cứ khi nào anh ta cần các danh mục trong các trang của mình, anh ta kiểm tra danh sách: nếu nó tồn tại, anh ta sử dụng nó, nếu không, anh ta truy vấn lại và điền nó vào. Anh ta đã thiết lập để vô hiệu hóa danh sách bất cứ khi nào anh ta chèn vào cơ sở dữ liệu , nhưng tùy thuộc vào mức sử dụng của bạn, bạn có thể tạo biến thời gian chờ toàn cầu để theo dõi thời điểm bạn cần truy vấn lại tiếp theo. Nếu bạn đang làm một cái gì đó phức tạp, điều này có thể được ra khỏi bàn tay, nhưng nếu nó chỉ là một danh sách các bài viết gần đây nhất hoặc một cái gì đó, tôi nghĩ rằng nó sẽ là tốt.

Answer 2

Tôi sử dụng MongoDB và Tornado. Tuy nhiên, một số bài viết nói rằng MongoDB không làm bộ nhớ đệm.

Tôi không biết ai nhưng MongoDB có cách để truy vấn bộ nhớ cache, trên thực tế nó sử dụng LRU của hệ điều hành để lưu vào bộ nhớ cache vì nó không tự quản lý bộ nhớ.

Miễn là bộ làm việc của bạn phù hợp với LRU mà không cần hệ điều hành phải lật trang hoặc hoán đổi liên tục, bạn nên đọc truy vấn này từ bộ nhớ nhiều nhất. Vì vậy, có, MongoDB có thể cache nhưng về mặt kỹ thuật nó không; hệ điều hành.

Trên thực tế, 99 trong số các truy vấn đó là lãng phí năng lượng máy tính.

Cơ chế lưu trữ để giải quyết các loại vấn đề này giống nhau trên hầu hết các công nghệ cho dù là MongoDB hay SQL. Tất nhiên, điều này chỉ quan trọng nếu nó là một vấn đề, bạn có lẽ vi tối ưu hóa nếu bạn hỏi tôi; trừ khi bạn nhận được lưu lượng truy cập Facebook hoặc Google hoặc Youtube.

Chủ đề bộ nhớ đệm đi vào một chủ đề lớn nằm trong các truy vấn bộ nhớ đệm trong MongoDB/Memcache/Redis tổng hợp trước để lưu trữ HTML và các tài nguyên web khác để làm ít công việc nhất có thể ở cuối máy chủ.

Kịch bản của bạn, cá nhân như tôi đã nói, có vẻ như bạn đang nghĩ sai về sức mạnh máy tính bị lãng phí. Ngay cả khi bạn đã lưu trữ truy vấn này trong bộ sưu tập/công nghệ khác, bạn có thể sử dụng cùng một lượng năng lượng và tài nguyên để lấy kết quả từ công nghệ đó nếu bạn không bận tâm. Tuy nhiên giả định rằng đi xuống đến bạn có chỉ số đúng, lược đồ, thiết lập, vv

tôi khuyên bạn nên đọc một số liên kết trên thiết kế giản đồ tốt và tạo chỉ mục:

• http://docs.mongodb.org/manual/core/indexes/
• https://docs.mongodb.com/manual/core/data-model-operations/#large-number-of-collections

Tạo HTML tĩnh, được lưu trong bộ nhớ cache với một cái gì đó như Nginx không được ưa thích, bởi vì tôi muốn hiển thị một trang được cá nhân hóa bởi Tornado mỗi lần.

Tôi nghĩ rằng bằng cách cố gắng lo lắng về truy vấn bộ nhớ đệm, bạn đang tối ưu hóa trước, đặc biệt là nếu bạn không muốn cất cánh, 90% tải trên máy chủ của bạn mỗi lần là gì; tải trang của chính nó.

Tôi sẽ tập trung vào giản đồ và chỉ mục của bạn và sau đó lo lắng về bộ nhớ đệm nếu bạn thực sự cần nó.