Có bao nhiêu mảnh trong Máy ứng dụng của Google bị ngăn chặn?

Question

Tôi đã đọc hôm nay về sharded counters in Google App Engine. Bài báo nói rằng bạn nên mong đợi tối đa ở mức khoảng 5/cập nhật mỗi giây cho mỗi thực thể trong kho dữ liệu. Nhưng có vẻ như với tôi rằng giải pháp này không 'quy mô' trừ khi bạn có một số cách để biết có bao nhiêu cập nhật bạn đang làm mỗi giây. Ví dụ, bạn có thể phân bổ 10 mảnh, nhưng sau đó sẽ bắt đầu nghẹt thở ở 50 bản cập nhật mỗi giây.

Vậy làm cách nào để bạn biết tốc độ cập nhật sắp tới và cách bạn cung cấp số đó trở lại số lượng phân đoạn?

Tôi đoán là cùng với bộ đếm, bạn có thể lưu giữ một số hồ sơ về hoạt động gần đây và nếu bạn phát hiện thấy tăng đột biến, bạn có thể tăng số lượng phân đoạn. Đó có phải là cách nó được thực hiện? Và nếu có, tại sao nó không được thực hiện trong mã mẫu? (Câu hỏi cuối cùng có thể không trả lời được.) Có thực tiễn phổ biến hơn để theo dõi hoạt động của trang web và cập nhật số lượng phân đoạn khi lưu lượng truy cập tăng lên, trái ngược với việc thực hiện tự động trong mã không?

Cập nhật: Hậu quả thực tế của việc có quá ít mảnh vỡ và nghẹt thở là gì? Điều đó có nghĩa là trang web không phản hồi hoặc có thể mất cập nhật phản đối vì hết thời gian chờ không?

---

Là một sang một bên, this question nói về việc thực hiện các quầy mà không có sharding, nhưng một trong những câu trả lời ngụ ý rằng thậm chí memcache cần phải được phân bổ nếu lưu lượng truy cập cao. Vì vậy, vấn đề phân bổ và điều chỉnh phân đoạn này có vẻ quan trọng.

Answer 1

Điều này rõ ràng là đơn giản hơn để theo dõi mức độ phổ biến của trang web của bạn theo cách thủ công và tăng số lượng phân đoạn nếu cần. Tôi đoán rằng hầu hết các trang web đều có cách tiếp cận này. Làm theo cách lập trình sẽ không chỉ khó, nhưng có vẻ như nó sẽ thêm một số tiền không thể chấp nhận để lưu giữ hồ sơ của tất cả hoạt động gần đây và cố gắng phân tích nó để tự động điều chỉnh số lượng mảnh bạn đang sử dụng.

Tôi thích phương pháp đơn giản hơn là chỉ hơi sai một chút ở phía cao với số lượng phân đoạn bạn chọn.

Bạn chính xác về hậu quả thực tế của việc có quá ít phân đoạn. Cập nhật một thực thể kho dữ liệu thường xuyên hơn mức có thể mà ban đầu sẽ gây ra một số yêu cầu phải mất một thời gian dài (trong khi viết thử lại). Nếu bạn có đủ trong số họ chồng chất lên, sau đó họ sẽ bắt đầu thất bại khi yêu cầu hết thời gian. Điều này chắc chắn sẽ dẫn đến quầy bị mất. Ngược lại, trang của bạn sẽ chậm đến nỗi người dùng nên bắt đầu rời khỏi đó, nên giảm áp lực lên kho dữ liệu :).

Answer 2

Để giải quyết phần cuối cùng của câu hỏi: Giá trị memcache của bạn sẽ không yêu cầu sharding. Một máy chủ memcache duy nhất có thể xử lý hàng chục nghìn QPS của các bản tải xuống và cập nhật, do đó, không có ứng dụng lớn đáng tin cậy nào cần phải phân mảnh các khóa memcache của nó.

Answer 3

Tại sao không thêm vào số lượng phân đoạn khi ngoại lệ bắt đầu xảy ra?

Dựa trên GAE Example này:

try{ 
    Transaction tx = ds.beginTransaction(); 
    // increment shard 
    tx.commit();   
} catch(DatastoreFailureException e){ 
    // Datastore is struggling to handle the current load, increase it/double it 
    addShards(getShardCount()); 

} catch(DatastoreTimeoutException to){ 
    // Datastore is struggling to handle the current load, increase it/double it 
    addShards(getShardCount()); 

} catch (ConcurrentModificationException cm){ 
    // Datastore is struggling to handle the current load, increase it/double it 
    addShards(getShardCount());    

}