Rõ ràng đây là một câu hỏi cũ, nhưng tôi đã gặp nó khi tôi đang nghiên cứu MongoDB cho dữ liệu thời gian. Tôi nghĩ rằng có thể đáng để chia sẻ cách tiếp cận sau để phân bổ trước các tài liệu hoàn chỉnh và thực hiện các thao tác cập nhật, trái ngược với các thao tác chèn mới. Lưu ý, phương pháp này đã được ghi lại ở đây và ở đây.
Hãy tưởng tượng bạn đang lưu trữ dữ liệu mỗi phút. Xem xét cấu trúc tài liệu sau:
{
timestamp: ISODate("2013-10-10T23:06:37.000Z"),
type: ”spot_EURUSD”,
value: 1.2345
},
{
timestamp: ISODate("2013-10-10T23:06:38.000Z"),
type: ”spot_EURUSD”,
value: 1.2346
}
Điều này có thể so sánh với cách tiếp cận quan hệ tiêu chuẩn. Trong trường hợp này, bạn tạo một tài liệu cho mỗi giá trị được ghi lại, điều này gây ra rất nhiều thao tác chèn. Chúng ta có thể làm tốt hơn. Hãy xem xét những điều sau:
{
timestamp_minute: ISODate("2013-10-10T23:06:00.000Z"),
type: “spot_EURUSD”,
values: {
0: 1.2345,
…
37: 1.2346,
38: 1.2347,
…
59: 1.2343
}
}
Bây giờ, chúng tôi có thể viết một tài liệu và thực hiện 59 lần cập nhật. Điều này tốt hơn nhiều vì các bản cập nhật là nguyên tử, các bản ghi riêng lẻ nhỏ hơn và có các lợi ích khác về hiệu suất và tính đồng thời. Nhưng điều gì sẽ xảy ra nếu chúng ta muốn lưu trữ cả ngày, chứ không chỉ toàn bộ giờ, trong một tài liệu. Sau đó, điều này sẽ yêu cầu chúng tôi đi dọc 1440 mục nhập để nhận được giá trị cuối cùng. Để cải thiện điều này, chúng tôi có thể mở rộng thêm những điều sau:
{
timestamp_hour: ISODate("2013-10-10T23:00:00.000Z"),
type: “spot_EURUSD”,
values: {
0: { 0: 1.2343, 1: 1.2343, …, 59: 1.2343},
1: { 0: 1.2343, 1: 1.2343, …, 59: 1.2343},
…,
22: { 0: 1.2343, 1: 1.2343, …, 59: 1.2343},
23: { 0: 1.2343, 1: 1.2343, …, 59: 1.2343}
}
}
Sử dụng phương pháp lồng ghép này, giờ đây chúng ta chỉ phải đi bộ, tối đa là 24 + 60 để nhận được giá trị cuối cùng trong ngày.
Nếu chúng tôi tạo tài liệu với tất cả các giá trị được điền trước bằng đệm, chúng tôi có thể chắc chắn rằng tài liệu sẽ không thay đổi kích thước và do đó sẽ không bị di chuyển.
