Nói chung, đối với một tập dữ liệu có cấu trúc như vậy, tôi nghi ngờ bạn có thể viết một định dạng dữ liệu tùy chỉnh nhanh hơn cho hầu hết các hoạt động hàng ngày (tức là dữ liệu nhỏ kéo từ thời gian tùy ý). Lợi ích của việc chuyển sang một công cụ DB tiêu chuẩn có thể có trong một số tính năng bổ sung, ví dụ như các truy vấn đặc biệt, nhiều truy cập, sao chép, tính khả dụng, v.v ... Việc thuê trợ giúp để duy trì một kho lưu trữ dữ liệu dựa trên tiêu chuẩn cũng dễ dàng hơn.
Nếu tôi được yêu cầu thiết lập cơ sở dữ liệu để lưu trữ dữ liệu đó, tôi sẽ làm như sau:
Lược đồ đề xuất
(1) Dữ liệu cốt lõi được đặt vào nhiều (1000)) các bảng riêng lẻ, mỗi bảng chứa hai cột:
- thời gian: có thể là kiểu dữ liệu SQL DATETIME hoặc kiểu số từ một số epoch (đây là khóa chính)
- value: gõ như phù hợp với dữ liệu của bạn. Tôi sẽ mặc định là float chính xác duy nhất, tuy nhiên loại dữ liệu điểm cố định có thể phù hợp hơn cho các giao dịch tài chính. Điều này có lẽ là không được hiểu.
Các bảng này sẽ trở nên khá lớn và bạn có thể muốn phân vùng chúng theo cách thủ công theo (ví dụ) năm. Nhưng bạn sẽ phải kiểm tra hiệu năng hệ thống và điều chỉnh cho phù hợp.
Các bảng này cần tên duy nhất và có một vài tùy chọn. Chúng có thể là con người có thể đọc được (ví dụ: nyse_goog_dailyhighs_2010) hoặc (sở thích của tôi) ngẫu nhiên. Dù bằng cách nào, một tập hợp các bảng siêu dữ liệu là bắt buộc và tên bảng ngẫu nhiên ngăn các nhà phát triển suy luận bất cứ điều gì vào tên mà không có nghĩa là được suy ra.
(2) Dữ liệu meta được lưu trữ trong các bảng riêng biệt, theo yêu cầu của ứng dụng :
Cần có một bảng hoặc bộ bảng bổ sung để theo dõi siêu dữ liệu. Các bảng này sẽ chứa dữ liệu về trao đổi, công cụ, giá trị, tần suất, phạm vi ngày, xuất xứ (dữ liệu đến từ đâu), cộng với bất cứ thứ gì bạn cần. Chúng được ánh xạ tới tên bảng dữ liệu.
Nếu có đủ dữ liệu, việc tra cứu này thực sự có thể cung cấp tên bảng và tên cơ sở dữ liệu, cho phép một loại bảo vệ dữ liệu tự thực hiện (nếu đó là cách sử dụng đúng thuật ngữ). Nhưng tôi sẽ giữ nó trong dự trữ.
Sau đó, ở lớp ứng dụng, tôi sẽ truy vấn các bảng siêu dữ liệu để xác định vị trí của dữ liệu của mình và sau đó thực hiện các truy vấn tương đối đơn giản trên các bảng dữ liệu lớn để lấy dữ liệu của tôi.
Ưu điểm:
Kinh nghiệm (tương đối hạn chế) của tôi là cơ sở dữ liệu thường có thể xử lý một số lượng lớn các bảng nhỏ dễ dàng hơn một số lượng nhỏ các bảng lớn. Cách tiếp cận này cũng cho phép bảo trì dễ dàng hơn (ví dụ: xóa dữ liệu cũ, xây dựng lại bảng bị hỏng, tạo / tải lại từ bản sao lưu, thêm một thực thể mới). Điều này hoàn toàn tách rời các loại dữ liệu khác nhau, nếu (ví dụ) bạn có dữ liệu ở các mức khác nhau hoặc yêu cầu các loại dữ liệu khác nhau.
Khái niệm bảng mỏng này cũng sẽ cho phép truy cập đĩa nhanh cho những gì tôi nghi ngờ là truy vấn phổ biến nhất, một phạm vi dữ liệu liền kề từ một thực thể duy nhất. Hầu hết các ứng dụng dữ liệu là I / O đĩa giới hạn, vì vậy điều này đáng để xem xét. Như một nhà bình luận đã ngụ ý, đây là một ứng dụng lý tưởng cho cơ sở dữ liệu hướng theo cột, nhưng tôi vẫn chưa tìm thấy một sản phẩm hướng cột nào đủ để tôi đặt cược sự nghiệp của mình. Lược đồ này trở nên khá gần.
Nhược điểm:
Khoảng một nửa dung lượng ổ đĩa của bạn được dành riêng để lưu trữ tem thời gian, khi thực sự 100 hoặc 1000 bảng sẽ có cùng dữ liệu chính xác trong cột dấu thời gian. (Trong thực tế đây là một yêu cầu nếu bạn muốn thực hiện các phép nối bảng dễ dàng).
Lưu trữ tên bảng và thực hiện tra cứu động đòi hỏi rất nhiều sự phức tạp của ứng dụng và các thao tác chuỗi, loại này làm cho tôi co rúm lại. Nhưng nó vẫn có vẻ tốt hơn so với các lựa chọn thay thế (thảo luận dưới đây).
Cân nhắc:
Hãy cẩn thận làm tròn trong lĩnh vực thời gian của bạn. Bạn muốn các giá trị của mình đủ tròn để kích hoạt các phép nối (nếu phù hợp), nhưng đủ chính xác để không mơ hồ.
Hãy cẩn thận về múi giờ và thời gian tiết kiệm ánh sáng ban ngày. Đây là những khó khăn để kiểm tra. Tôi sẽ thực thi một yêu cầu UTC trên kho lưu trữ dữ liệu (có thể khiến tôi không phổ biến) và xử lý các chuyển đổi trong ứng dụng.
Biến thể:
Một số biến thể mà tôi đã xem xét là:
Gấp dữ liệu: Nếu các mốc thời gian cách đều nhau, thì hãy sử dụng một cột dấu thời gian và (ví dụ) 10 cột dữ liệu. Dấu thời gian bây giờ đề cập đến thời gian của cột dữ liệu đầu tiên và các cột dữ liệu được giả định cách đều nhau giữa dấu thời gian đó và cột tiếp theo. Điều này giúp tiết kiệm rất nhiều dung lượng lưu trữ trước đây được sử dụng để lưu trữ dấu thời gian, với chi phí truy vấn đáng kể và / hoặc độ phức tạp của ứng dụng. Phạm vi tiếp giáp, các truy vấn thực thể duy nhất hiện yêu cầu truy cập đĩa ít hơn.
Đa luồng: Nếu biết nhiều chuỗi thời gian sử dụng cùng một chuỗi thời gian, thì hãy sử dụng một dấu thời gian và (ví dụ) 10 cột dữ liệu như được mô tả ở trên. Nhưng bây giờ mỗi cột đại diện cho một chuỗi thời gian khác nhau. Điều này đòi hỏi phải cập nhật bảng siêu dữ liệu, đây không phải là tra cứu tên bảng và tên cột. Không gian lưu trữ được giảm. Truy vấn vẫn đơn giản. Tuy nhiên, phạm vi liền kề, các truy vấn thực thể đơn lẻ hiện yêu cầu truy cập đĩa nhiều hơn đáng kể.
Bảng Mega: Đưa khái niệm "đa plexing" đến mức cực đoan và đặt tất cả dữ liệu vào một bảng duy nhất, một lần chuỗi thời gian trên mỗi cột. Điều này đòi hỏi một lượng lớn truy cập đĩa cho phạm vi liền kề, các truy vấn thực thể đơn lẻ và là một cơn ác mộng bảo trì. Ví dụ: thêm một thực thể mới bây giờ yêu cầu lệnh MODIFY TABLE trên bảng nhiều TB.
Để thảo luận thêm về định dạng này, hãy xem các câu trả lời khác nhau trong:
Quá nhiều cột trong MySQL
Bảng được chuẩn hóa hoàn toàn:
Thay vì sử dụng nhiều bảng 2 cột, bạn có thể sử dụng bảng một, ba cột, trong đó các cột là thời gian, dữ liệu và giá trị. Bây giờ các bảng siêu dữ liệu của bạn chỉ cần tra cứu các giá trị ID, thay vì các tên tab hoặc tên cột, cho phép đẩy nhiều logic hơn vào các truy vấn SQL, thay vì lớp ứng dụng.
Khoảng 2/3 Dung lượng hiện được sử dụng với các cột chuẩn hóa, do đó, điều này sẽ sử dụng rất nhiều dung lượng đĩa.
Bạn có thể sử dụng một thứ tự khóa chính là (dataid, dấu thời gian) cho các truy vấn thực thể đơn lẻ, liền kề nhanh. Hoặc, bạn có thể sử dụng thứ tự khóa chính là (dấu thời gian. Dataid) để chèn nhanh hơn.
Tuy nhiên, ngay cả sau khi xem xét các biến thể này, kế hoạch cho sự phát triển tiếp theo của tôi là rất nhiều bảng, mỗi cột có hai cột. Điều đó, hoặc phương pháp sẽ sớm được đăng bởi một người khôn ngoan hơn tôi :).