Giải pháp MySQL cho 1 triệu lần nhấp/ngày

Question

Chúng tôi đang chạy máy chủ quảng cáo OpenX tùy chỉnh trên cơ sở dữ liệu MySQL được xấp xỉ. 1 triệu lần nhấp/ngày. Chúng tôi cần lưu trữ tất cả thông tin nhấp chuột này và hiển thị số liệu thống kê dựa trên thông tin đó.

Ngay bây giờ, tất cả thông tin nhấp chuột được tổng hợp cứ sau 2 ngày và thông tin nhấp chuột cụ thể sẽ bị xóa. Nhưng chúng tôi muốn cung cấp cho các chi nhánh của chúng tôi một tính năng mới cho phép họ đặt id theo dõi động (TID) và về cơ bản, theo dõi nhấp chuột và chuyển đổi của họ dựa trên điều này. Vì vậy, vấn đề là bảng nhấp chuột của chúng tôi sẽ tăng trưởng tối thiểu 1 triệu mục mỗi ngày và chúng tôi cần có thể tìm kiếm bảng này và hiển thị tất cả các lần nhấp cho một người dùng trong một khoảng thời gian cụ thể, được nhóm theo TID tôi đã đề cập ở trên hoặc tìm kiếm bằng TID.

Tôi đã xem xét phân vùng MySQL và có vẻ như là giải pháp tốt, nhưng tôi không chắc liệu nó có hoạt động tốt trên cơ sở dữ liệu HUGE (có thể là hàng tỷ mục nhập) hay không.

Bạn nghĩ phương pháp tiếp cận chính xác cho vấn đề này là gì?

EDIT:

Dựa trên câu trả lời của bạn, tôi là bây giờ nghĩ đến việc một giải pháp hỗn hợp.

Chúng tôi đã có một "LIVE" bảng mà từ đó các mục sẽ bị xóa khi nhấp chuột được tổng hợp tại thời gian bảo trì, mà trông giống như sau:

Bảng: nhấp chuột

viewer_id | ... | date_time | affiliate_id | ... | tid

(tôi bỏ qua các cột mà là không quan trọng vào thời điểm này)

Tại thời gian bảo trì, tôi có thể di chuyển tất cả mọi thứ vào một bảng hàng tháng mà trông gần như giống nhau, nói Bảng: clicks_2012_11, trong đó có chỉ số cho DATE_TIME, affiliate_id và tid và được phân chia bởi các affiliate_id.

Vì vậy, bây giờ, khi một chi nhánh muốn xem thống kê của mình cho 2 tháng qua, tôi biết tôi phải nhìn vào bên trong các Bảng: clicks_2012_10 và Bảng: clicks_2012_11 (Tôi sẽ có khoảng thời gian giới hạn tối đa là 2 tháng). Bởi vì tôi có các bảng được phân đoạn bởi affiliate_id, chỉ những phân vùng cần thiết mới được tìm kiếm từ 2 bảng và bây giờ tôi có thể liệt kê tất cả các TID có hoạt động bất kỳ trong 2 tháng qua.

Bạn nghĩ gì về phương pháp này? Có bất kỳ vấn đề rõ ràng? Tôi có quá phức tạp những thứ không có lý do vững chắc không?

Answer 1

Không có gì vốn có trong các bảng lớn (thậm chí là "lớn") khiến MySQL thất bại.bảng lớn chủ yếu là một vấn đề về:

• không gian đĩa
sử dụng
• cache (bạn có khả năng không để có thể chạy trong bộ nhớ)
• bảo dưỡng (thay đổi sơ đồ, xây dựng lại, ...)

Bạn cần giải quyết tất cả những điều này.

Phân vùng chủ yếu hữu ích cho việc duy trì dữ liệu hàng loạt, chẳng hạn như thả toàn bộ phân vùng. Nó chắc chắn không phải là một thực hành tốt nhất để phân vùng các bảng lớn theo mặc định trên một số cột. Phân vùng luôn được giới thiệu vì một lý do cụ thể.

Answer 2

Tối ưu hóa để chèn và tối ưu hóa để truy xuất thường loại trừ lẫn nhau. Bạn có thể tốt hơn với hai bảng:

live data: no (or minimal) keys, myisam to remove transaction overhead, etc... 
historical data: indexed up the wazoo, with data moved over from the live data on a periodic basis.