5

Tôi có một danh sách người dùng mà chỉ quản trị viên mới có thể xem (= vài lần đọc). Danh sách này cũng hiển thị số lượng người dùng trong kho dữ liệu. Bởi vì danh sách có thể phát triển lớn hơn 1000 suy nghĩ đầu tiên của tôi là để tránh một số đếm bình thường() và thay vào đó sử dụng một truy cập bị phân mảnh.Làm cách nào để tạo bộ đếm linh hoạt với hơn 1000 hàng nhưng ít lần đọc trong Google App Engine?

Tuy nhiên, vấn đề là quản trị viên cũng có quyền truy cập vào các bộ lọc tìm kiếm khác nhau (trong GUI), chẳng hạn như chỉ xem người dùng nam/nữ, v.v. Điều quan trọng là số lượng phản ánh các bộ lọc này, để họ có thể nhận được số lượng người dùng nữ, người dùng nam và vô số các kết hợp khác.

Vì lý do này, các bộ đếm được phân loại và các bộ đếm đồng thời cao mà không có sharding dường như không phải là một ý tưởng hay, vì tôi cần phải tạo bộ đếm cho mọi bộ lọc tìm kiếm.

Tôi có nên tạo một vòng lặp của phương thức count(), chẳng hạn như được mô tả here hoặc thực tiễn này không tốt? Tôi sẽ làm như thế nào?

Lưu ý rằng bộ đếm này dành cho giao diện quản trị và sẽ có số lần đọc rất hạn chế. Điều này thực sự là một trường hợp khi tôi muốn hy sinh một số hiệu suất đọc cho tính linh hoạt và chính xác. Mặc dù nó có thể phát triển vượt quá 1000, nhưng nó không được dự kiến ​​sẽ lớn hơn 10 000.

Trả lời

2

"Vòng đếm" là chậm, nhưng những ngày này bạn có thể làm tốt hơn một chút với cursors. Bình thường, tôi khuyên bạn nên chuẩn hóa tất cả các bộ lọc "đã lọc", nhưng điều đó làm chậm quá trình thêm và xóa người dùng (và có thể là thay đổi nhân khẩu học), vì vậy, với trường hợp sử dụng cụ thể của bạn với khối lượng đọc rất thấp, bạn có thể tránh xa phương pháp "vòng lặp đếm" (cộng thêm con trỏ ;-).

+0

Cảm ơn câu trả lời của bạn! Có, tôi bị cám dỗ bởi cách tiếp cận này vì tôi sẽ có rất ít lần đọc và tôi thậm chí không chắc danh sách sẽ vượt quá 1000. Khi bạn nói về con trỏ, bạn có nghĩa là tôi nên sử dụng con trỏ để quyết định vị trí tiếp theo()? – Aneon

2

Tôi đã thử hai cách tiếp cận:

1) Viết nhiệm vụ của riêng tôi mà truy vấn lưu trữ dữ liệu (truy vấn là một truy vấn giảm dần key) với một giới hạn nhất định của các tổ chức (nói 50). Sau đó nó enqueues nhiệm vụ tiếp theo để bắt đầu truy vấn nơi nó rời đi. Mỗi nhiệm vụ enqueues một trong những kế tiếp đi qua nó hai tham số (nơi nó cuối trái còn lại như một con trỏ và một tổng chạy của số thực thể nó đã thấy).

2) Cách tiếp cận này dễ dàng hơn nhiều - và đó là sử dụng thư viện Mapreduce do Google cung cấp cho appengine. Nó chạy hoàn toàn trong không gian người dùng, do đó bạn chỉ cần tải xuống và xây dựng thư viện và đưa nó vào dự án của bạn. Về cơ bản, nó sẽ xử lý lặp qua tất cả các thực thể mà bạn chỉ định và cho phép bạn viết một trình xử lý để làm gì với mỗi thực thể (như tăng bộ đếm). Xem chi tiết tại đây: mapreduce.appspot.com - thậm chí họ còn có một ứng dụng mẫu thực hiện những gì bạn đang yêu cầu. Vấn đề duy nhất với điều này là kết quả sẽ xuất hiện trong trình duyệt của bạn và không nhất thiết phải được lưu trữ trong kho dữ liệu trừ khi bạn tự làm điều đó.

+0

Cách tiếp cận thứ hai được mô tả ở đây, sử dụng mapreduce để tính toán lại, một cách thường xuyên, tất cả các số liệu thống kê quan trọng, có vẻ như là cách tiếp cận tốt nhất. –

+0

Ồ, tôi chưa bao giờ nghe nói về MapReduce trước đây, sẽ phải xem xét điều đó. Cách tiếp cận này sẽ cho tôi độ chính xác đầy đủ hay nó sẽ cần phải được cập nhật định kỳ (như các bộ đếm đồng thời cao mà không có sharding sử dụng hàng đợi nhiệm vụ)? Và nó đòi hỏi tôi phải thiết lập tất cả các kết hợp bộ lọc có thể tôi muốn để có thể đếm bằng tay? – Aneon

+0

Vâng, nếu số lượng thực thể bạn đang thay đổi trong quá trình giảm bản đồ, những thực thể đó sẽ không được tính. Bản đồ giảm về cơ bản có một ảnh chụp tại một thời điểm nhất định. Trong sẽ KHÔNG cung cấp cho bạn một số thời gian thực của số lượng các thực thể bạn có tại bất kỳ thời điểm nào.Tôi sử dụng nó để tạo ra số liệu thống kê vào cuối mỗi ngày. – aloo

Các vấn đề liên quan