Câu hỏi hay, tôi cũng đang xem xét vấn đề này.
Tạo phiên bản mới sau mỗi lần thay đổi
Tôi đã xem qua mô-đun Phiên bản của trình điều khiển Mongoid cho Ruby. Bản thân tôi chưa sử dụng nó, nhưng từ những gì tôi có thể tìm thấy, nó thêm số phiên bản cho mỗi tài liệu. Các phiên bản cũ hơn được nhúng vào chính tài liệu. Hạn chế lớn là toàn bộ tài liệu được sao chép trên mỗi lần thay đổi , điều này sẽ dẫn đến nhiều nội dung trùng lặp được lưu trữ khi bạn đang xử lý các tài liệu lớn. Tuy nhiên, cách tiếp cận này vẫn tốt khi bạn đang xử lý các tài liệu có kích thước nhỏ và / hoặc không cập nhật tài liệu thường xuyên.
Chỉ lưu trữ các thay đổi trong phiên bản mới
Một cách tiếp cận khác sẽ là chỉ lưu trữ các trường đã thay đổi trong một phiên bản mới . Sau đó, bạn có thể 'làm phẳng' lịch sử của mình để tạo lại bất kỳ phiên bản nào của tài liệu. Tuy nhiên, điều này khá phức tạp vì bạn cần theo dõi các thay đổi trong mô hình của mình và lưu trữ các bản cập nhật và xóa theo cách mà ứng dụng của bạn có thể tạo lại tài liệu cập nhật. Điều này có thể phức tạp, vì bạn đang xử lý các tài liệu có cấu trúc hơn là các bảng SQL phẳng.
Lưu trữ các thay đổi trong tài liệu
Mỗi trường cũng có thể có một lịch sử riêng. Theo cách này, việc tạo lại tài liệu cho một phiên bản nhất định sẽ dễ dàng hơn nhiều. Trong ứng dụng của mình, bạn không phải theo dõi các thay đổi một cách rõ ràng mà chỉ cần tạo một phiên bản mới của thuộc tính khi bạn thay đổi giá trị của nó. Một tài liệu có thể trông giống như sau:
{
_id: "4c6b9456f61f000000007ba6"
title: [
{ version: 1, value: "Hello world" },
{ version: 6, value: "Foo" }
],
body: [
{ version: 1, value: "Is this thing on?" },
{ version: 2, value: "What should I write?" },
{ version: 6, value: "This is the new body" }
],
tags: [
{ version: 1, value: [ "test", "trivial" ] },
{ version: 6, value: [ "foo", "test" ] }
],
comments: [
{
author: "joe", // Unversioned field
body: [
{ version: 3, value: "Something cool" }
]
},
{
author: "xxx",
body: [
{ version: 4, value: "Spam" },
{ version: 5, deleted: true }
]
},
{
author: "jim",
body: [
{ version: 7, value: "Not bad" },
{ version: 8, value: "Not bad at all" }
]
}
]
}
Mặc dù vậy, việc đánh dấu một phần của tài liệu là đã bị xóa trong một phiên bản vẫn còn hơi khó xử. Bạn có thể giới thiệu một state trường cho các phần có thể bị xóa / khôi phục khỏi ứng dụng của bạn:
{
author: "xxx",
body: [
{ version: 4, value: "Spam" }
],
state: [
{ version: 4, deleted: false },
{ version: 5, deleted: true }
]
}
Với mỗi cách tiếp cận này, bạn có thể lưu trữ phiên bản cập nhật và được làm phẳng trong một bộ sưu tập và dữ liệu lịch sử trong một bộ sưu tập riêng biệt. Điều này sẽ cải thiện thời gian truy vấn nếu bạn chỉ quan tâm đến phiên bản mới nhất của tài liệu. Nhưng khi bạn cần cả phiên bản mới nhất và dữ liệu lịch sử, bạn sẽ cần thực hiện hai truy vấn thay vì một. Vì vậy, lựa chọn sử dụng một bộ sưu tập duy nhất so với hai bộ sưu tập riêng biệt sẽ phụ thuộc vào tần suất ứng dụng của bạn cần các phiên bản lịch sử .
Hầu hết câu trả lời này chỉ là một đống suy nghĩ của tôi, tôi chưa thực sự thử bất kỳ câu trả lời nào trong số này. Nhìn lại nó, tùy chọn đầu tiên có lẽ là giải pháp dễ nhất và tốt nhất, trừ khi chi phí của dữ liệu trùng lặp là rất quan trọng đối với ứng dụng của bạn. Tùy chọn thứ hai khá phức tạp và có lẽ không đáng để bạn nỗ lực. Tùy chọn thứ ba về cơ bản là tối ưu hóa của tùy chọn hai và sẽ dễ thực hiện hơn, nhưng có lẽ không đáng để nỗ lực triển khai trừ khi bạn thực sự không thể sử dụng tùy chọn một.
Mong nhận được phản hồi về vấn đề này và giải pháp của những người khác cho vấn đề :)
