Kiến trúc cơ sở dữ liệu cho hàng triệu hàng mới mỗi ngày

Question

Tôi cần triển khai dịch vụ phân tích trang web được phát triển tùy chỉnh cho số lượng lớn các trang web. Đối tượng quan trọng ở đây là:

• website
• khách

Mỗi khách truy cập duy nhất sẽ có có một hàng duy nhất trong cơ sở dữ liệu với thông tin như trang đích, thời gian trong ngày, hệ điều hành, trình duyệt, giới thiệu , IP vv

tôi sẽ cần phải làm các truy vấn tổng hợp trên cơ sở dữ liệu này như 'Đếm tất cả các du khách có Windows là hệ điều hành và xuất phát từ Bing.com'

Tôi có hàng trăm trang web để theo dõi và số lượng khách truy cập cho các trang web đó dao động từ vài trăm một ngày đến vài triệu một ngày. Tổng cộng, tôi hy vọng cơ sở dữ liệu này sẽ tăng khoảng một triệu hàng mỗi ngày.

Câu hỏi của tôi là:

1) MySQL có phải là cơ sở dữ liệu tốt cho mục đích này không?

2) Kiến trúc tốt là gì? Tôi đang nghĩ đến việc tạo một bảng mới cho mỗi trang web. Hoặc có lẽ bắt đầu với một bảng duy nhất và sau đó đẻ trứng một bảng mới (hàng ngày) nếu số hàng trong một bảng hiện có vượt quá 1 triệu (là giả định của tôi đúng). Nỗi lo duy nhất của tôi là nếu một bảng phát triển quá lớn, các truy vấn SQL có thể bị chậm đáng kể. Vì vậy, số lượng hàng tối đa tôi nên lưu trữ cho mỗi bảng là bao nhiêu? Hơn nữa, có một giới hạn về số lượng bảng mà MySQL có thể xử lý.

3) Bạn có nên thực hiện các truy vấn tổng hợp trên hàng triệu hàng không? Tôi đã sẵn sàng chờ một vài giây để nhận kết quả cho các truy vấn như vậy. Nó là một thực hành tốt hay có cách nào khác để thực hiện các truy vấn tổng hợp?

Tóm lại, Tôi đang thử thiết kế một loại thiết lập kho dữ liệu quy mô lớn sẽ viết nặng. Nếu bạn biết về bất kỳ nghiên cứu hoặc báo cáo nào được công bố, điều đó sẽ rất tuyệt vời!

Answer 1

Một số đề xuất trong cơ sở dữ liệu thời trang bất khả tri.

Lý do đơn giản nhất là phân biệt giữa các bảng đọc chuyên sâu và viết chuyên sâu. Có lẽ nên tạo hai lược đồ song song lược đồ hàng ngày/tuần và lược đồ lịch sử. Việc phân vùng có thể được thực hiện một cách thích hợp. Người ta có thể nghĩ về một công việc hàng loạt để cập nhật lược đồ lịch sử với dữ liệu từ lược đồ hàng ngày/hàng tuần. Trong lược đồ lịch sử một lần nữa, bạn có thể tạo các bảng dữ liệu riêng biệt cho mỗi trang web (dựa trên khối lượng dữ liệu).

Nếu tất cả bạn quan tâm nằm trong thống kê tổng hợp một mình (có thể không phải là đúng). Đó là một ý tưởng tốt để có một bảng tóm tắt (hàng tháng, hàng ngày), trong đó tóm tắt được lưu trữ như tổng số khách truy cập unqiue, khách truy cập lặp lại vv; và các bảng tóm tắt này sẽ được cập nhật vào cuối ngày. Điều này cho phép tính toán số liệu thống kê bay với việc chờ cơ sở dữ liệu lịch sử được cập nhật.

Answer 2

Nếu bạn đang nói về khối lượng dữ liệu lớn hơn, hãy xem MySQL partitioning. Đối với những bảng này, một phân vùng theo dữ liệu/thời gian chắc chắn sẽ giúp hiệu suất. Có một bài viết khá về phân vùng here.

Xem xét việc tạo hai cơ sở dữ liệu riêng biệt: một cho tất cả dữ liệu thô cho phép ghi với chỉ mục tối thiểu; một giây để báo cáo bằng cách sử dụng các giá trị tổng hợp; với quy trình lô để cập nhật cơ sở dữ liệu báo cáo từ cơ sở dữ liệu thô, hoặc sử dụng bản sao để thực hiện điều đó cho bạn.

EDIT

Nếu bạn muốn được thực sự thông minh với các báo cáo tổng hợp của bạn, tạo ra một tập hợp các bảng tổng hợp ("hôm nay", "tuần cho đến nay", "tháng cho đến nay", "bởi năm"). Tổng hợp từ dữ liệu thô thành "hôm nay" hàng ngày hoặc trong "thời gian thực"; tổng hợp từ "theo ngày" sang "hàng tuần đến nay" trên cơ sở hàng đêm; từ "tuần cho đến nay" đến "tháng cho đến nay" trên một cơ sở hàng tuần, vv Khi thực hiện truy vấn, tham gia (UNION) các bảng phù hợp với phạm vi ngày bạn đang quan tâm.

EDIT # 2

Thay vì một bảng cho mỗi khách hàng, chúng tôi làm việc với một lược đồ cơ sở dữ liệu cho mỗi khách hàng. Tùy thuộc vào kích thước của máy khách, chúng ta có thể có một vài lược đồ trong một cá thể cơ sở dữ liệu duy nhất, hoặc một cá thể cơ sở dữ liệu chuyên dụng cho mỗi máy khách. Chúng tôi sử dụng các lược đồ riêng biệt để thu thập dữ liệu thô và để tổng hợp/báo cáo cho từng khách hàng. Chúng tôi chạy nhiều máy chủ cơ sở dữ liệu, hạn chế mỗi máy chủ đến một cá thể cơ sở dữ liệu duy nhất. Đối với khả năng phục hồi, cơ sở dữ liệu được nhân rộng trên nhiều máy chủ và tải cân bằng để cải thiện hiệu suất.

Answer 3

Bạn thực sự nên thử nghiệm theo cách của bạn về phía trước sẽ mô phỏng môi trường càng gần càng tốt với môi trường sống, với dữ liệu "giả thực" (định dạng chính xác & chiều dài). Truy vấn điểm chuẩn và các biến thể của cấu trúc bảng. Vì bạn dường như biết MySQL, hãy bắt đầu từ đó. Bạn không nên mất nhiều thời gian để thiết lập một vài kịch bản bắn phá cơ sở dữ liệu của bạn với các truy vấn. Nghiên cứu kết quả của cơ sở dữ liệu của bạn với loại dữ liệu của bạn sẽ giúp bạn nhận ra nơi xảy ra hiện tượng tắc nghẽn.

Không phải là một giải pháp nhưng hy vọng một số giúp đỡ trên đường đi, chúc may mắn :)

Answer 4

Bạn chắc chắn nên xem xét việc tách dữ liệu từ các trang web trên cơ sở dữ liệu hoặc schemas - điều này không chỉ làm cho nó dễ dàng hơn để sao lưu, thả vv một cá nhân trang web/khách hàng nhưng cũng loại bỏ nhiều rắc rối của việc đảm bảo không có khách hàng có thể nhìn thấy bất kỳ dữ liệu khách hàng khác do tai nạn hoặc mã hóa nghèo vv Nó cũng có nghĩa là nó dễ dàng hơn để thực hiện lựa chọn về partitionaing, hơn và trên databae bảng phân vùng cấp cho thời gian hoặc khách hàng, v.v.

Ngoài ra, bạn đã nói rằng khối lượng dữ liệu là 1 triệu hàng mỗi ngày (điều đó không đặc biệt nặng và không yêu cầu sức mạnh to lớn để đăng nhập/lưu trữ, và cũng không thực sự báo cáo (mặc dù nếu bạn đang quảng bá 500 báo cáo lúc nửa đêm bạn có thể đăng nhập). Tuy nhiên bạn cũng nói rằng một số trang web có 1m khách truy cập hàng ngày vì vậy có lẽ bạn con số là quá bảo thủ?

Cuối cùng bạn không nói nếu bạn muốn báo cáo thời gian thực một biểu đồ/opentracker la vv hoặc làm mới theo chu kỳ như phân tích google - điều này sẽ có ảnh hưởng lớn đến mô hình lưu trữ của bạn từ ngày đầu tiên.

M