Tôi tin rằng tất cả các cơ sở dữ liệu NoSQL chính sẽ hỗ trợ yêu cầu đó, đặc biệt nếu bạn không thực sự có một lượng lớn dữ liệu (đặt ra câu hỏi, tại sao lại sử dụng NoSQL?).
Điều đó nói rằng, gần đây tôi đã phải thiết kế và làm việc với cơ sở dữ liệu NoSQL cho dữ liệu chuỗi thời gian để có thể cung cấp một số đầu vào cho thiết kế đó, sau đó có thể ngoại suy cho tất cả những người khác.
Cơ sở dữ liệu đã chọn của chúng tôi là Cassandra và thiết kế của chúng tôi như sau:
- Một không gian phím duy nhất cho tất cả 'ký hiệu'
- Mỗi biểu tượng là một hàng mới
- Mỗi mục nhập thời gian là một cột mới cho hàng có liên quan đó
- Mỗi giá trị (có thể nhiều hơn một giá trị) là một phần giá trị của mục nhập thời gian
Điều này cho phép bạn đạt được mọi thứ bạn yêu cầu, đặc biệt nhất là đọc dữ liệu cho một ký hiệu và sử dụng một phạm vi nếu cần (lệnh gọi phạm vi cột). Mặc dù bạn đã nói rằng hiệu suất không quan trọng, nhưng đó là đối với chúng tôi và điều này cũng khá hiệu quả - tất cả dữ liệu cho bất kỳ biểu tượng đơn lẻ nào đều được sắp xếp theo định nghĩa (sắp xếp tên cột) và luôn được lưu trữ trên cùng một nút (không có giao tiếp nút chéo cho các truy vấn đơn giản ). Cuối cùng, thiết kế này chuyển dịch tốt sang các cơ sở dữ liệu NoSQL khác có các cột động.
Hơn nữa, đây là một số thông tin về cách sử dụng MongoDB (và các bộ sưu tập có giới hạn nếu cần) cho cửa hàng chuỗi thời gian: MongoDB dưới dạng Cơ sở dữ liệu chuỗi thời gian
Cuối cùng, đây là cuộc thảo luận về SQL và NoSQL cho chuỗi thời gian: https://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql
Tôi có thể thêm vào cuộc thảo luận đó những điều sau:
- Đường cong học tập cho NoSQL sẽ cao hơn, bạn không nhận được tính linh hoạt và chức năng bổ sung miễn phí về 'chi phí mềm'. Ai sẽ hỗ trợ cơ sở dữ liệu này hoạt động?
- Nếu bạn mong đợi chức năng này sẽ phát triển trong tương lai (khi có nhiều trường hơn được thêm vào mỗi mục nhập thời gian hoặc dung lượng lớn hơn nhiều về số lượng ký hiệu hoặc kích thước chuỗi thời gian của ký hiệu), thì hãy chắc chắn sử dụng NoSQL. Lợi ích về tính linh hoạt là rất lớn và khả năng mở rộng bạn nhận được (với thiết kế ở trên) trên cả cơ sở 'mỗi biểu tượng' và 'số lượng ký hiệu' hầu như không bị giới hạn (tôi nói gần như không bị ràng buộc - số cột tối đa trên hàng là hàng tỷ, tối đa Tôi tin rằng các hàng trên mỗi không gian chính là không bị giới hạn).
