Bạn đã tách máy khách thành một máy riêng biệt với máy chủ chưa? Đó là bước đầu tiên, nhỏ, trong việc mở rộng quy mô.
Bạn có các truy vấn sao chép và chỉ đọc được gửi đến Slaves không? Điều đó có thể cho phép đọc không giới hạn mở rộng quy mô. (Nhưng điều này không giải quyết câu hỏi CẬP NHẬT, ngoài việc giảm tải cho Master.)
115 IOP trên một đĩa duy nhất, đang quay, sẽ bão hòa khá nhiều. innodb_flush_log_at_trx_commit mặc định là 1, dẫn đến ít nhất 1 IOP cho mỗi giao dịch. Một số giải pháp tạm thời (cho đến khi lưu lượng truy cập của bạn tăng thêm 10 lần) ...
SSD - có thể 1000 IOP.
Cập nhật hàng loạt (chẳng hạn như được đề cập bởi @N. B). Điều này làm giảm 100 lần số lần "xả".
innodb_flush_log_at_trx_commit =2 - để loại bỏ hầu như các lỗi (mất an toàn).
Nhưng - Ngay cả khi bạn có thể thực hiện CẬP NHẬT đủ nhanh, bạn cũng không cần phải đọc các giá trị? Đó là, sẽ có sự tranh chấp. Có bao nhiêu CHỌN trên cùng một bàn bạn đang làm gì? 100 / giây có thể ổn; 1000 / giây có thể gây ra nhiều nhiễu đến mức nó sẽ không hoạt động.
Bàn lớn bao nhiêu? Để bất kỳ điều gì trong số này hoạt động, nó cần phải đủ nhỏ để được lưu vào bộ nhớ cache mọi lúc.
Reddit là một cách tiếp cận khác - nắm bắt các bản cập nhật ở đó. Sau đó, liên tục lấy ra số lượng tích lũy và thực hiện CẬP NHẬT cần thiết.
Sharding - Đây là nơi bạn chia nhỏ dữ liệu trên nhiều máy. Tách trên một băm hoặc tra cứu (hoặc kết hợp cả hai) của userid là phổ biến. Sau đó CẬP NHẬT cần tìm ra máy nào cần cập nhật, sau đó thực hiện hành động ở đó. Nếu bạn có 10 mảnh (máy), bạn có thể duy trì tốc độ cập nhật gần gấp 10 lần. Cuối cùng, đây là cách duy nhất mà tất cả những người có trình độ cao có thể xử lý hơn 100 triệu người dùng và hàng tỷ truy vấn / ngày.
PARTITIONing không có khả năng hữu ích. Mã cắt tỉa phân vùng chưa đủ hiệu quả để tránh tốn quá nhiều chi phí cho một truy vấn nhỏ như vậy.
