Hệ thống lưu trữ đồng thời cao

Hãy tưởng tượng yêu cầu của bạn là bạn có 3 bảng lớn (dữ liệu có cấu trúc) với khoảng 30 tỷ hàng trong mỗi (tổng kích thước 4TB) và nhiều người dùng đồng thời của bạn (là các luồng os song song trên các máy LAN từ xa) sẽ cần đọc một phần của dữ liệu thông qua các truy vấn TỰ NHIÊN ở đâu và đồng thời rất cao, giả sử 10.000 lần đọc đồng thời và người dùng cũng cần chèn (không cập nhật) dữ liệu vào các bảng này đồng thời giống như 2000 nhà văn đồng thời (trên toàn bộ mạng LAN của trung tâm dữ liệu) . Người dùng sẽ muốn đọc và chèn càng nhanh càng tốt mẫu lưu trữ này trong đó mỗi lần đọc và ghi sẽ xảy ra trong phạm vi ms đến 1 giây.

Những công nghệ nào bạn đề nghị để đáp ứng yêu cầu như vậy? Có bất kỳ lưu trữ dữ liệu hoặc lưu trữ giá trị khóa có thể làm điều này? Đám mây KHÔNG phải là một lựa chọn.

Một số làm rõ:

Người dùng KHÔNG phải xem dữ liệu ngay lập tức và tính nhất quán cuối cùng có thể chấp nhận được. Dữ liệu được truy cập thông qua bất kỳ trình điều khiển nào mà bộ lưu trữ có thể cung cấp và người dùng lại chỉ là các luồng chạy trên các máy từ xa của trung tâm dữ liệu. Các truy vấn chủ yếu giống như CHỌN NHÓM Ở ĐÂU.

Dữ liệu ở định dạng bảng và mỗi hàng khoảng 60 byte.

Không có tùy chọn đám mây nơi tôi không thể sử dụng DynamoDB hoặc các giải pháp tương tự. Tôi phải có khả năng lưu trữ nội bộ trong trung tâm dữ liệu.

Tất cả dữ liệu của các bảng có thể được đọc tất cả thời gian và mô hình sử dụng là không thể đoán trước. Không có tham gia hoặc truy vấn siêu dài. Không cần DR nhưng cần có HA hợp lý nhưng không cần phải cầu kỳ. Mỗi người đọc đang nhận được một loạt các hàng dựa trên mệnh đề where và các hàng không thực sự liên quan. Chúng tôi có thể có chiều dài cố định cho mỗi hàng nhưng tôi hy vọng lớp lưu trữ sẽ lo lắng về nó.

Ngoài ra, mối quan tâm lớn nhất của tôi là tất cả những bài viết đồng thời đang xảy ra với các lần đọc đồng thời.

Những hiểu biết của bạn về điều này được đánh giá cao.

Và hơn nữa, tôi có ba trong số các bảng đó với mỗi 30 tỷ hàng chứa các loại đối tượng khác nhau

Nếu tính nhất quán cuối cùng có thể chấp nhận được và tất cả các truy vấn của bạn là tổng hợp thì có lẽ hệ thống OLAP có độ trễ thấp có thể phù hợp với bạn. Yêu cầu của bạn nghe hơi giống một nền tảng giao dịch thuật toán. Kiểu kiến ​​trúc này thường được sử dụng trong các hệ thống sàn giao dịch có yêu cầu thực hiện các tính toán phân tích thống kê tổng hợp về dữ liệu cập nhật.

Nếu bạn có thể phân vùng dữ liệu theo ngày và các hàng cũ không được cập nhật thì bạn có thể xây dựng hệ thống OLAP lai bằng máy chủ OLAP thông thường như dịch vụ Phân tích Microsoft được hỗ trợ bởi nền tảng RDBMS thông thường. Có thể thực hiện việc này để đối phó với ~ 4TB dữ liệu và cả SQL Server và SSAS sẽ thực hiện các cụm đĩa chia sẻ. Các hệ thống OLAP tương tự (ví dụ Oracle / Hyperion Essbase) có sẵn từ các nhà cung cấp khác.

Các máy chủ OLAP hoạt động bằng cách lưu giữ dữ liệu trong một cửa hàng riêng, cùng với các tập hợp. Hầu hết sẽ hỗ trợ dữ liệu phân vùng. Ngoài ra, hầu hết cũng sẽ làm việc trong chế độ ROLAP, nơi họ đưa ra các truy vấn đối với cơ sở dữ liệu cơ bản. Điều quan trọng cần lưu ý là chiến lược lưu trữ có thể được quản lý theo từng phân vùng và bạn có thể chuyển đổi phân vùng từ phân vùng này sang phân vùng khác theo chương trình,

Trong mô hình này, dữ liệu lịch sử được lưu trữ trong các phân vùng MOLAP với các tập hợp dữ liệu cũng được duy trì. Nếu một truy vấn có thể được thỏa mãn từ các tập hợp thì máy chủ sẽ sử dụng chúng. Các tổng hợp có thể được điều chỉnh cho phù hợp với các truy vấn và các tổng hợp chính xác sẽ giảm đáng kể số lượng tính toán cần thiết để giải quyết truy vấn. Các truy vấn tổng hợp rất nhạy có thể với loại hệ thống này.

Dữ liệu thời gian thực có thể được thực hiện bằng cách duy trì một phân vùng nhỏ hàng đầu - cho tháng hiện tại, ngày hoặc thậm chí giờ nếu cần thiết. Máy chủ OLAP sẽ đưa ra các truy vấn đối với cơ sở dữ liệu; nếu phân vùng này đủ nhỏ, DBMS sẽ có thể đáp ứng nhanh chóng. Một quy trình thông thường tạo ra các phân vùng hàng đầu mới và chuyển đổi các giai đoạn lịch sử đã đóng thành MOLAP. Các phân vùng cũ hơn có thể được hợp nhất, cho phép quản lý dữ liệu lịch sử tại bất kỳ hạt nào mong muốn.

Các máy khách ghi vào cơ sở dữ liệu chỉ cần viết thẳng ra RDBMS bên dưới. Nếu dữ liệu lịch sử vẫn tĩnh, họ sẽ chỉ ghi vào phân vùng hàng đầu. 4TB là dung lượng thực tế để sử dụng SSD nếu bạn cần thêm hiệu năng DBMS. Ngay cả các nhà cung cấp chính cũng có các dịch vụ dựa trên SSD với các đơn vị SLC nhanh hơn như là một tùy chọn.