Có thể lưu trữ ~ 3,5TB dữ liệu và chèn khoảng 1K / giây 24x7, đồng thời truy vấn với tốc độ không được chỉ định, với SQL Server, nhưng có nhiều câu hỏi hơn:
- bạn có yêu cầu về tính khả dụng nào cho việc này? Thời gian hoạt động 99,999% hay là đủ 95%?
- bạn có yêu cầu về độ tin cậy nào? Việc thiếu phụ trang có khiến bạn mất 1 triệu đô la không?
- bạn có yêu cầu về khả năng phục hồi nào? Nếu một ngày nào đó bạn mất dữ liệu thì có vấn đề gì không?
- bạn có yêu cầu nhất quán nào? Bài viết có cần được đảm bảo để hiển thị trong lần đọc tiếp theo không?
Nếu bạn cần tất cả những yêu cầu này, tôi đã nhấn mạnh, mức tải bạn đề xuất sẽ tốn hàng triệu USD cho phần cứng và giấy phép trên một hệ thống quan hệ, bất kỳ hệ thống nào, bất kể bạn thử mánh lới quảng cáo nào (sharding, phân vùng, v.v.). Theo định nghĩa của chúng, một hệ thống nosql sẽ không đáp ứng được tất cả những yêu cầu này.
Vì vậy, rõ ràng là bạn đã nới lỏng một số yêu cầu này. Có một hướng dẫn trực quan tuyệt vời so sánh các dịch vụ nosql dựa trên mô hình 'chọn 2 trong 3' tại Hướng dẫn trực quan cho Hệ thống NoSQL:
Sau khi OP cập nhật nhận xét
Với SQL Server, điều này sẽ được triển khai ngay lập tức:
- một bảng được nhóm (GUID, thời gian) khóa. Có, sẽ bị phân mảnh, nhưng phân mảnh có ảnh hưởng đến quá trình đọc trước hay không và chỉ cần đọc trước cho các lần quét phạm vi đáng kể. Vì bạn chỉ truy vấn GUID và phạm vi ngày cụ thể, nên việc phân mảnh sẽ không quan trọng lắm. Có, là một khóa rộng, vì vậy các trang không phải là lá sẽ có mật độ khóa kém. Có, nó sẽ dẫn đến hệ số lấp đầy kém. Và có, có thể xảy ra hiện tượng tách trang. Bất chấp những vấn đề này, với các yêu cầu, vẫn là lựa chọn khóa cụm tốt nhất.
- phân vùng bảng theo thời gian để bạn có thể thực hiện xóa hiệu quả các bản ghi đã hết hạn thông qua cửa sổ trượt tự động. Tăng cường điều này bằng cách xây dựng lại phân vùng chỉ mục trực tuyến của tháng trước để loại bỏ yếu tố lấp đầy kém và phân mảnh do phân nhóm GUID giới thiệu.
- bật tính năng nén trang. Vì các nhóm khóa được gom lại theo GUID trước nên tất cả các bản ghi của GUID sẽ nằm cạnh nhau, tạo cơ hội tốt cho việc nén trang để triển khai tính năng nén từ điển.
- bạn sẽ cần một đường dẫn IO nhanh cho tệp nhật ký. Bạn quan tâm đến thông lượng cao, chứ không phải độ trễ thấp để nhật ký theo kịp với 1K lần chèn / giây, vì vậy việc loại bỏ là điều bắt buộc.
Mỗi phân vùng và nén trang đều yêu cầu SQL Server Phiên bản Doanh nghiệp, chúng sẽ không hoạt động trên Phiên bản Tiêu chuẩn và cả hai đều khá quan trọng để đáp ứng các yêu cầu.
Lưu ý thêm, nếu các bản ghi đến từ trang web máy chủ Web front-end, tôi sẽ đặt Express trên mỗi máy chủ web và thay vì INSERT ở back end, tôi sẽ SEND thông tin đến phần cuối, sử dụng kết nối / giao dịch cục bộ trên Express được đặt chung với máy chủ web. Điều này mang lại một câu chuyện về tính khả dụng tốt hơn nhiều cho giải pháp.
Vì vậy, đây là cách tôi sẽ làm điều đó trong SQL Server. Tin tốt là những vấn đề bạn sẽ gặp phải đã được hiểu rõ và các giải pháp đã được biết đến. điều đó không nhất thiết có nghĩa là điều này tốt hơn những gì bạn có thể đạt được với Cassandra, BigTable hoặc Dynamo. Tôi sẽ để một người nào đó dễ hiểu hơn về những thứ không-sql-ish để tranh luận về trường hợp của họ.
Lưu ý rằng tôi chưa bao giờ đề cập đến mô hình lập trình, hỗ trợ .Net và những thứ tương tự. Tôi thành thật nghĩ rằng chúng không liên quan trong các đợt triển khai lớn. Chúng tạo ra sự khác biệt rất lớn trong quá trình phát triển, nhưng một khi được triển khai thì không quan trọng tốc độ phát triển ra sao, nếu chi phí ORM giết chết hiệu suất :)
