Câu hỏi đầu tiên nên là:bạn sẽ làm gì với dữ liệu đó? Nếu bạn không có yêu cầu kinh doanh rõ ràng, đừng làm điều đó.
Tôi đã làm một cái gì đó tương tự và sau 3 năm chạy có khoảng 20% "dữ liệu hợp lệ" và phần còn lại là "các phiên bản trước". Và nó là 10 triệu + 40 triệu bản ghi. Trong ba năm qua, chúng tôi đã có 2 (hai) yêu cầu điều tra lịch sử thay đổi và cả hai lần yêu cầu đều ngớ ngẩn - chúng tôi ghi lại dấu thời gian của sự thay đổi kỷ lục và chúng tôi được yêu cầu kiểm tra xem mọi người có làm việc ngoài giờ (sau 5 giờ chiều) hay không.
Bây giờ, chúng tôi đang mắc kẹt với cơ sở dữ liệu quá khổ chứa 80% dữ liệu mà không ai cần.
CHỈNH SỬA:
Vì bạn đã yêu cầu các giải pháp khả thi, tôi sẽ mô tả những gì chúng tôi đã làm. Nó hơi khác so với giải pháp bạn đang xem xét.
- Tất cả các bảng đều có khóa chính thay thế.
- Tất cả các khóa chính được tạo từ một dãy đơn. Điều này hoạt động tốt vì Oracle có thể tạo và lưu các số vào bộ nhớ cache, vì vậy không có vấn đề về hiệu suất ở đây. Chúng tôi sử dụng ORM và chúng tôi muốn mỗi đối tượng trong bộ nhớ (và bản ghi tương ứng trong cơ sở dữ liệu) có số nhận dạng duy nhất
- Chúng tôi sử dụng ORM và ánh xạ thông tin giữa bảng và lớp cơ sở dữ liệu ở dạng thuộc tính.
Chúng tôi ghi lại tất cả các thay đổi trong một bảng lưu trữ với các cột sau:
- id (khóa chính thay thế)
- dấu thời gian
- bảng gốc
- id của bản ghi gốc
- id người dùng
- loại giao dịch (chèn, cập nhật, xóa)
- ghi dữ liệu dưới dạng trường varchar2
- đây là dữ liệu thực tế ở dạng các cặp tên trường / giá trị.
Điều hoạt động theo cách này:
- ORM có chèn / cập nhật và xóa các kết hợp.
- chúng tôi đã tạo một lớp cơ sở cho tất cả các đối tượng nghiệp vụ của chúng tôi ghi đè các lệnh chèn / cập nhật và xóa
- lệnh chèn / cập nhật / xóa tạo chuỗi ở dạng các cặp tên trường / giá trị bằng cách sử dụng phản xạ. Mã tìm kiếm thông tin ánh xạ và đọc tên trường, giá trị liên quan và loại trường. Sau đó, chúng tôi tạo một cái gì đó tương tự như JSON (chúng tôi đã thêm một số sửa đổi). Khi chuỗi đại diện cho trạng thái hiện tại của đối tượng được tạo, nó sẽ được chèn vào bảng lưu trữ.
- khi đối tượng mới hoặc được cập nhật được lưu vào bảng cơ sở dữ liệu, nó sẽ được lưu vào bảng đích của đối tượng đó và đồng thời chúng tôi chèn một bản ghi có giá trị hiện tại vào bảng lưu trữ.
- khi đối tượng bị xóa, chúng tôi sẽ xóa nó khỏi bảng đích của đối tượng đó và đồng thời chúng tôi chèn một bản ghi vào bảng lưu trữ có loại giao dịch ="DELETE"
Chuyên gia:
- chúng tôi không có bảng lưu trữ cho mỗi bảng trong cơ sở dữ liệu. Chúng tôi cũng không cần phải lo lắng về việc cập nhật bảng lưu trữ khi lược đồ thay đổi.
- bản lưu trữ hoàn chỉnh được tách biệt với "dữ liệu hiện tại", do đó, bản lưu trữ không áp đặt bất kỳ hiệu suất nào trên cơ sở dữ liệu. Chúng tôi đặt nó vào không gian bảng riêng biệt trên đĩa riêng và nó hoạt động tốt.
- chúng tôi đã tạo 2 biểu mẫu để xem kho lưu trữ:
- trình xem chung có thể liệt kê bảng lưu trữ theo bộ lọc trên bảng lưu trữ. Dữ liệu bộ lọc người dùng có thể nhập trên biểu mẫu (khoảng thời gian, người dùng, ...). Chúng tôi hiển thị từng bản ghi trong tên trường / giá trị của biểu mẫu và mỗi thay đổi được mã hóa bằng màu sắc. Người dùng có thể xem tất cả các phiên bản cho mỗi bản ghi và họ có thể biết ai và khi nào đã thực hiện các thay đổi.
- trình xem hóa đơn - biểu mẫu này phức tạp, nhưng chúng tôi đã tạo biểu mẫu hiển thị hóa đơn rất giống với biểu mẫu nhập hóa đơn ban đầu, nhưng với một số nút bổ sung có thể hiển thị các thế hệ khác nhau. Nó đã mất nhiều nỗ lực để tạo ra hình thức này. Biểu mẫu đã được sử dụng một vài lần và sau đó bị lãng quên vì nó không cần thiết trong quy trình làm việc hiện tại.
- mã để tạo các bản ghi lưu trữ nằm trong một lớp C #. Không cần kích hoạt trên mọi bảng trong cơ sở dữ liệu.
- hiệu suất rất tốt. Vào thời điểm cao điểm, hệ thống được sử dụng bởi khoảng 700-800 người dùng. Đây là ứng dụng ASP.Net. Cả ASP.Net và Oracle đều đang chạy trên một XEON kép với RAM 8Gb.
Nhược điểm:
- định dạng lưu trữ bảng đơn khó đọc hơn so với giải pháp khi có một bảng lưu trữ cho mỗi bảng dữ liệu.
- khó tìm kiếm trên trường không phải id trong bảng lưu trữ - chúng tôi chỉ có thể sử dụng
LIKEtoán tử trên chuỗi.
Vì vậy, một lần nữa, hãy kiểm tra các yêu cầu về lưu trữ . Đây không phải là nhiệm vụ nhỏ nhặt, nhưng lợi ích và việc sử dụng có thể là tối thiểu.
