Tại sao số lượt xem tin nhắn bị chậm trên hầu hết các trang web?


10

Lưu ý cách xem số lượng video youtube luôn bị lag? Ví dụ: một video có 1000 lượt bình luận và vẫn có 500 lượt truy cập và sẽ có 10000 lượt truy cập sau nhiều giờ.

Youtube không đơn độc trong việc này. Hầu hết các bảng thông báo được triển khai theo cách đó và số lượt xem được cập nhật như sau mỗi 10 phút hoặc lâu hơn.

Có ai biết lý do đằng sau này?

Cảm ơn.

Câu trả lời:


20

Ghi lại các khung nhìn rất đơn giản, chỉ cần thêm một hàng vào một bảng biểu thị hành động "xem". Điều này rất nhanh vì không yêu cầu khóa trong cơ sở dữ liệu, bạn chỉ cần thêm một hàng vào cuối một đống.

Tổng hợp rằng vào tổng số lượt xem yêu cầu một cái gì đó giống như làm điều SELECT COUNT(*) FROM ...đó có nghĩa là bạn phải khóa bảng trong khi quá trình tính toán đang diễn ra. Ngoài ra, UPDATE ... SET num_views = num_views + 1cũng yêu cầu bạn khóa hàng cụ thể đó mỗi khi ai đó xem nó.

Vì vậy, từ quan điểm về khả năng mở rộng, sẽ hiệu quả hơn khi thêm một hàng mỗi khi ai đó xem video và sau đó thực hiện SELECT COUNT(*) FROM ...cứ sau mười phút.

Lưu ý Tôi thực sự không biết kiến ​​trúc của YouTube hoặc thậm chí họ có sử dụng cơ sở dữ liệu quan hệ để lưu trữ dữ liệu của họ hay không, nhưng dù họ sử dụng thì nguyên tắc có thể giống nhau: chèn dữ liệu là rẻ, tổng hợp các giá trị là (tương đối) đắt .


4
Nó không sử dụng BigTable với phần còn lại của Google phải không?
TheLQ

@Dean Harding Cảm ơn, nhưng không có nghĩa là bảng sẽ có hàng tỷ, nếu không phải là hàng nghìn tỷ bản ghi cho một trang web ngay cả với lưu lượng truy cập vừa phải, ít youtube hơn? Với các bản ghi lớn như vậy, tôi nghi ngờ rằng CHỌN COUNT (*) sẽ có tác động đến hiệu suất đối với DB ngay cả khi nó chỉ chạy sau mỗi 10 phút. Điều này cũng sẽ cần thêm không gian đĩa cho cơ sở dữ liệu và sao lưu. Tôi không nói rằng khóa bảng trên mỗi trang hit là tốt hơn, nhưng tôi chỉ thấy khó hiểu làm thế nào các trang web lớn sẽ xử lý dữ liệu lớn như vậy.
Tom Tucker

Đây không phải là lần đầu tiên tôi nghe điều này. Điều thực sự làm tôi bối rối, đó là việc tăng một bộ đếm theo cách an toàn chủ đề là khó hơn hoặc tốn kém hơn so với việc thêm vào danh sách. Nếu bạn có thể giải quyết cái sau, cái trước sẽ thực sự dễ dàng.
back2dos

2
@Tom Tucker: có, nhưng chúng ta đang nói về Google ở ​​đây, hãy nhớ rằng :-) Một cách mà tôi đã giải quyết vấn đề này ở quy mô nhỏ hơn là một khi tôi đã hoàn thành việc tổng hợp, tôi sẽ cắt ngắn bảng tổng hợp dữ liệu được tính toán từ. Vì vậy, bạn không bao giờ nhận được nhiều hơn một giờ (hoặc bất cứ khoảng thời gian nào bạn cập nhật) dữ liệu "thô".
Dean Harding

4
Ngoài ra, hãy nhớ rằng dữ liệu trong bảng "hành động" của bạn có thể được sử dụng nhiều hơn là chỉ tính "số lượt xem". Bạn cũng có thể sử dụng nó để triển khai các khối IP (nghĩa là "không quá 1 bình luận cứ sau 10 giây từ cùng một IP", v.v.). Bạn cũng có thể tạo các biểu đồ hiển thị số lượt xem theo thời gian và các loại điều khác mà đơn giản num_views = num_views + 1không cho phép.
Dean Harding

8

Nhiều khả năng giá trị đã được lưu trữ ở đâu đó trên đường đi để bạn thấy dữ liệu cũ. Bởi vì điều này không quan trọng đối với dữ liệu này là chính xác, các nhà phát triển đã quyết định ưu tiên hiệu suất hơn là cập nhật dữ liệu. Bạn thực sự sẽ không muốn truy cập cơ sở dữ liệu và đếm số hàng cho mỗi lần truy cập trên trang web chỉ để cập nhật con số này để họ không, họ chỉ lưu trữ bộ đệm trong một thời gian.


4

Để các trang web lớn mở rộng quy mô, họ phải thực hiện bộ nhớ đệm ở một số giai đoạn. Đó có thể là bộ đệm ẩn trang, bộ đệm ẩn trang phụ và / hoặc bộ nhớ đệm ghi. Bạn có thể có một sự kết hợp của tất cả chúng có hiệu lực. Ví dụ: nếu trang youtube được lưu trong bộ nhớ cache cho đến khi nhận xét mới được thêm vào, bạn sẽ thấy một số độ trễ cho đến khi ai đó đăng nhận xét.

Có một số cách đo lượt xem trang:

  • Lưu trữ nó trong cơ sở dữ liệu dưới dạng bản ghi: dễ chèn, tuy nhiên đây là chi phí bảo trì chính cho các bản ghi chỉ cung cấp số đếm.
  • Lưu trữ nó trong cơ sở dữ liệu dưới dạng bản ghi và cuộn số đếm theo định kỳ: dễ dàng chèn, xử lý hàng loạt để thu thập các số liệu bạn muốn và tự dọn sạch.
  • Cập nhật một cột đếm trong cơ sở dữ liệu: tốn kém để cập nhật (giả sử khóa hàng), không có chi phí bảo trì, hiệu suất tiêu cực khi giao dịch với nhiều người yêu cầu cùng một trang cùng một lúc.
  • Xử lý tệp nhật ký truy cập khi cuộn qua: không có dữ liệu bổ sung trong cơ sở dữ liệu, tất cả quá trình xử lý được thực hiện theo lô ngoại tuyến và thống kê tóm tắt bạn muốn được cập nhật khi đến lúc.

Trong số các mục ở trên, tất cả ngoại trừ một tùy chọn cho thấy rằng các cập nhật sẽ được thực hiện theo đợt. Số lượt xem không thực sự là một thuộc tính quan trọng về thời gian, vì vậy điều này là ổn. Tuy nhiên, khiến mọi người chờ đợi để xem video trên YouTube vì cơ sở dữ liệu phụ trợ không thể theo kịp một hành động quan trọng về thời gian. Điều đó có nghĩa là việc cập nhật một cột trong cơ sở dữ liệu sẽ không hoạt động đối với một trang web lớn như YouTube. Cá nhân tôi sẽ không ngạc nhiên nếu họ chọn phương án cuối cùng. Các máy chủ web sẽ ghi lại toàn bộ thông tin cho mỗi lần truy cập, bao gồm cả IP bạn đang sử dụng, cách bạn được giới thiệu đến trang, v.v.


Không bao giờ nghĩ đến giải pháp cuối cùng - rất thông minh! Điều đó một mình có giá trị +1.
Tom Tucker

1
Chúng tôi đã sử dụng phương pháp đó để xử lý danh sách trang "phổ biến nhất" cho ngày / tuần / tháng. Chúng tôi đã tính tổng số lên đến một tệp thuộc tính đơn giản trong nhiều ngày, tuần và tháng. Ngày hiện tại sẽ được xử lý lại mỗi giờ và các tệp tóm tắt còn lại được xử lý như băng dự phòng của ông / bố / con trai. Về cơ bản, chúng tôi cần không quá 8 tệp tóm tắt (tóm tắt hàng tuần và tệp tóm tắt cho mỗi ngày trong tuần hiện tại).
Berin Loritsch

Điều đó tương tự như cách RRDTool hoạt động, mặc dù RRDTool phức tạp hơn nhiều so với giải pháp của bạn với sự đơn giản thanh lịch của nó.
Jörg W Mittag

0

Điều này có thể là do một số lý do. Tất cả nắm rõ các thuật toán được sử dụng bởi mỗi trang web tương ứng. Trừ khi ai đó ở đây thực sự là một nhà phát triển YouTube, tôi nghi ngờ bạn sẽ nhận được câu trả lời chính xác ở đây.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.