Lưu trữ dữ liệu nào là tốt nhất cho kịch bản của tôi?

Tôi đang làm việc trên một ứng dụng liên quan đến việc thực hiện cập nhật / chọn truy vấn trong cơ sở dữ liệu rất cao.

Tôi có một bảng cơ sở (A) sẽ có khoảng 500 bản ghi cho một thực thể trong một ngày. Và đối với mọi người dùng trong hệ thống, một biến thể của thực thể này được tạo dựa trên một số tùy chọn của người dùng và chúng được lưu trữ trong một bảng khác (B). Điều này được thực hiện bởi một công việc định kỳ chạy vào nửa đêm hàng ngày.

Vì vậy, nếu có 10.000 người dùng và 500 hồ sơ trong bảng A, sẽ có 5 triệu hồ sơ trong bảng B cho ngày hôm đó. Tôi luôn giữ dữ liệu trong một ngày trong các bảng này và vào nửa đêm, tôi lưu trữ dữ liệu lịch sử vào HBase. Thiết lập này đang hoạt động tốt và cho đến nay tôi không gặp vấn đề gì về hiệu năng.

Gần đây đã có một số thay đổi trong yêu cầu kinh doanh và bây giờ một số thuộc tính trong bảng cơ sở A (cho 15 - 20 bản ghi) sẽ thay đổi cứ sau 20 giây và dựa vào đó tôi phải tính toán lại một số giá trị cho tất cả các bản ghi biến thể trong bảng B cho tất cả người sử dụng. Mặc dù chỉ có 20 bản ghi chính thay đổi, tôi cần phải tính toán lại và cập nhật 200.000 bản ghi người dùng mất hơn 20 giây và sau đó bản cập nhật tiếp theo xảy ra cuối cùng dẫn đến tất cả các truy vấn Chọn được xếp hàng. Tôi nhận được khoảng 3 nhận yêu cầu / 5 giây từ người dùng trực tuyến, kết quả là 6-9 Chọn truy vấn. Để đáp ứng yêu cầu api, tôi luôn sử dụng các trường trong bảng B.

Tôi có thể mua thêm sức mạnh xử lý và giải quyết tình huống này nhưng tôi quan tâm đến việc có một hệ thống được thu nhỏ đúng cách có thể xử lý cả triệu người dùng.

Bất cứ ai ở đây có thể đề nghị một sự thay thế tốt hơn? Có nosql + cơ sở dữ liệu quan hệ giúp tôi ở đây? Có bất kỳ nền tảng / kho dữ liệu nào sẽ cho phép tôi cập nhật dữ liệu thường xuyên mà không bị khóa và đồng thời cho tôi sự linh hoạt khi chạy các truy vấn chọn trên các trường khác nhau trong một thực thể không?

Có vẻ như bảng Blà một loại bộ đệm. Nhưng đó là loại bộ đệm làm giảm năng suất ..

Ngay cả khi bạn có 25 truy vấn mỗi giây, bạn vẫn có thể từ chối việc sử dụng bảngB và tính toán câu trả lời cho mỗi yêu cầu.

Dù sao , nếu bạn có độ trễ 30 giây khi cập nhật 20 bản ghi - đó là lỗi trong kiến ​​trúc phần mềm (tôi sai, nếu DB của bạn tính 10 ^ 100 dấu PI đầu tiên cho mỗi bản ghi).

Như tôi biết, DB quan hệ không có truy vấn SQL xấu, có chỉ mục và có ít hơn 1 000 000 bản ghi sẽ hoạt động hoàn hảo cho hầu hết tất cả các truy vấn.

Cố gắng từ chối sử dụng bảng Bvà thêm các chỉ mục thích hợp vào bảng của bạn A(hầu hết các cơ sở dữ liệu hiện đại đều có công cụ trợ giúp). Tiếp theo: cố gắng tối ưu hóa cấu trúc dữ liệu (bảng A) và truy vấn (sử dụng trình phân tích truy vấn hoặc với các chuyên gia SQL) để tăng tốc tính toán. Nếu bạn sẽ cập nhật chỉ 20 bản ghi - sự tồn tại của các chỉ mục sẽ không gây hại cho năng suất của quá trình cập nhật , nhưng cải thiện đáng kể tốc độ chọn .

Câu hỏi thực sự là hệ thống nào tính toán bản ghi để chèn vào B và kích thước của dữ liệu B.

Bất kỳ cơ sở dữ liệu nào (ví dụ MSSQL) sẽ có thể xử lý khối lượng chèn mà bạn đang nói về không có vấn đề gì khi cho rằng đối tượng không lớn.

Cập nhật có thể bởi một vấn đề khó khăn hơn, nhưng với việc lập chỉ mục và khóa đúng, một lần nữa không phải là một vấn đề lớn.

99% khi tôi thấy một vấn đề như thế này là do bản ghi B được tính bởi một Proc được lưu trữ. Điều này đặt tất cả tải trên máy chủ db

Nếu đây là trường hợp, giải pháp là chuyển mã này sang dịch vụ ngoại tuyến có thể được gọi thông qua hệ thống xếp hàng.

Vì vậy, bản cập nhật của bạn Một thông báo sẽ kích hoạt một quy trình worker sẽ lặp qua người dùng và tạo một thông báo B cập nhật cho mỗi người dùng

Một tiến trình công nhân thứ hai B sẽ chọn bản cập nhật Người dùng X với dữ liệu Một sự kiện tạo bản ghi B và cập nhật DB

Điều này có thể được thu nhỏ bằng cách thêm nhiều hộp có nhân viên xếp hàng vào chúng, do đó bạn có càng nhiều sức mạnh xử lý đằng sau phép tính, để db của bạn tự do tập trung vào các bản cập nhật và chọn.

bạn có thể tối ưu hóa hơn nữa bằng cách tách các lựa chọn khỏi bản cập nhật / chèn. có một DB mới nhận được tất cả các yêu cầu được chọn làm nô lệ sao chép DB cũ nhận được tất cả các bản cập nhật.

Nếu bạn đang chạy trong Amazon, tôi sẽ xem xét DynamoDB. Đó là bộ nhớ flash dựa. Đây là một liên kết đến nó: https://aws.amazon.com/dynamodb/ .

Bạn đang sử dụng loại RDBMS nào? Bạn có thể tăng hiệu suất bằng cách sử dụng UDF hoặc trường được tính toán trong chế độ xem. Bạn đang chạy tính toán trong cơ sở dữ liệu thông qua một truy vấn cập nhật duy nhất hoặc bạn chọn dữ liệu ra khỏi cơ sở dữ liệu, chạy các tính toán trong một quy trình khác và sau đó tải chúng trở lại?

Oracle được cấu hình theo mặc định để sử dụng chế độ chụp nhanh, nghĩa là các hàng không bị khóa trong quá trình cập nhật và các lựa chọn đồng thời có được giá trị ban đầu. SQL Server được cấu hình theo mặc định với sự tương tranh bi quan, do đó các lựa chọn đồng thời sẽ chặn cho đến khi cập nhật hoàn tất. Một số phiên bản của SQL Server có thể được đưa vào chế độ chụp nhanh, tuy nhiên, nó làm tăng đáng kể sự căng thẳng trên bảng tạm thời.

Bạn đang chạy trong môi trường nào? Nếu đó là RDBMS trên phiên bản EC2 ở Amazon thì hãy thử đặt các tệp dữ liệu DB vào đĩa flash cục bộ. Tôi đã thấy một sự khác biệt lớn trong việc di chuyển các tệp từ EBS sang đĩa cục bộ.