Một cách tốt để lưu trữ một số lượng lớn các cột là gì?

Tôi có một vấn đề quyết định làm thế nào để lưu trữ dữ liệu này trong cơ sở dữ liệu của tôi. Bất kỳ đề xuất về cách tốt nhất để làm điều đó? Tôi không biết nhiều về cơ sở dữ liệu, tôi có thể thêm vào.

Tôi có dữ liệu được định dạng như vậy, nhưng thay vì 4, số lượng cột xấp xỉ 240, vì vậy mỗi ngày có 240 giá trị duy nhất được liên kết với nó:

Date/Time 200,00 202,50 205,00  
2010.11.12  13:34:00  45,8214 43,8512  41,5369   
2010.11.12  13:35:00  461,9364  454,2612  435,5222 

Ngoài ra, các hàng được liên kết với DataSites.

Suy nghĩ đầu tiên của tôi là có một bảng như vậy: DataID (pk), DataSiteID, ParameterID, Date, Value, với một chỉ mục trên DataSite, Parameter và Date. ParameterID đề cập đến một bảng khác lưu trữ các tiêu đề cột đầu vào (200,00 202,50 205,00 ...).

Suy nghĩ thứ hai của tôi chỉ đơn giản là có một bảng với tất cả 240 cột lẻ. Tôi đã nghĩ ra một vài cách khác, nhưng chúng cũng không đạt yêu cầu.

Vấn đề tôi gặp phải với giải pháp đầu tiên của mình (không phải là vấn đề lớn như vậy, nhưng tôi không thích nó), đó là Ngày và DataSiteID sẽ được lặp lại cho tất cả 240 giá trị trong hàng đầu vào đó, vì vậy nó sử dụng khá nhiều không gian thêm.

Sẽ có khoảng 40gb dữ liệu một năm tới (ở định dạng văn bản trên) và dữ liệu sẽ được tìm kiếm theo DataSite, Parameter và Date. Lượng dữ liệu đến nhiều khả năng sẽ tăng gấp bốn lần trong một năm hoặc lâu hơn.

Bất kỳ ý tưởng tốt? Cảm ơn, James

chỉnh sửa: Đây là dữ liệu chuỗi thời gian, với các cột được đo ở các bước sóng khác nhau. Dữ liệu sẽ muốn được phân tích trong một phạm vi bước sóng tương đối hẹp. Cũng có thể có thêm các bước sóng được thêm vào tại một số điểm trong tương lai.

chỉnh sửa: Cảm ơn các bạn đã trả lời, tôi thực sự đánh giá cao nó :) Tôi nghĩ rằng tôi có thể tìm thấy thời gian để chạy một số thử nghiệm với 500gb hoặc hơn dữ liệu thử nghiệm. Tôi sẽ đăng lại với bất kỳ kết luận nào;)

Bạn có thể tạo ra một trường hợp, nhưng nếu dữ liệu sẽ được sử dụng để phân tích và bạn thường muốn xem nhiều cột từ dữ liệu đó cùng một lúc, hãy đi với bảng rộng. Hãy chắc chắn rằng bạn biết giới hạn số lượng cột và kích thước hàng cơ sở dữ liệu của bạn. Hãy chắc chắn rằng bạn có được các kiểu dữ liệu đúng. Nếu nhiều cột là null, SQL Server cho phép bạn tối ưu hóa bảng cho điều đó. Bạn cũng có thể xem xét sử dụng giải pháp NOSQL (Không chỉ SQL) để phân tích loại dữ liệu này.

Nếu dữ liệu này sẽ ít để phân tích, bạn có thể muốn bình thường hóa nó như đã nêu trong câu hỏi của bạn.

Tôi đã có một tình huống rất giống với bạn, 257 trường với 30-50gb mỗi năm. Tôi cuối cùng chỉ đơn giản là một bảng lớn dài trong SQL Server. Dữ liệu của tôi đã được truy vấn một chút công bằng nhưng chủ yếu là vào ngày và nó hoạt động tốt.

Tôi có thể chia dữ liệu thành các mâm cặp nhỏ hơn (nhóm 50 hoặc hơn), nhưng trong trường hợp này thực sự không có nhiều lợi thế cho nó nên tôi đã tự cứu mình.

Nếu bây giờ tôi cảm thấy thích thú, tôi có thể xem xét một tùy chọn NoQuery phù hợp hơn về mặt lý thuyết, nhưng với dữ liệu quan trọng, việc thử những thứ mới không phải lúc nào cũng tuyệt vời cho các dây thần kinh.

Vì vậy, để trả lời muộn màng câu hỏi của riêng tôi (dự án không bao giờ được tiến hành cuối cùng), khi tôi có được thời gian rảnh rỗi, tôi đã lấp đầy một bảng thử nghiệm với 500gb dữ liệu với bảng được sắp xếp như sau:

Suy nghĩ đầu tiên của tôi là có một bảng như vậy: DataID (pk), DataSiteID, ParameterID, Date, Value, với một chỉ mục trên DataSite, Parameter và Date. ParameterID đề cập đến một bảng khác lưu trữ các tiêu đề cột đầu vào (200,00 202,50 205,00 ...).

Thiết lập cơ sở dữ liệu là cài đặt PostgreSQL tiêu chuẩn trên máy lõi kép cũ với 3gb ram. Tôi đã chạy khoảng một chục truy vấn khác nhau chỉ đơn giản là chọn dữ liệu theo Ngày dữ liệu và ParameterID, tính trung bình dữ liệu trong khoảng thời gian 1 giờ, khoảng thời gian 1 ngày và chèn các khối dữ liệu mới. Từ bộ nhớ, tất cả các truy vấn mất ít hơn một giây để thực hiện. Nó chắc chắn nhanh hơn nhiều so với tôi mong đợi và khá hữu dụng. Một điều mà tôi đã không nghĩ tới là với bảng được lập chỉ mục theo cách này, tệp chỉ mục cũng gần 500gb, do đó, có một bảng rộng 240 cột thay vào đó chắc chắn sẽ tiết kiệm rất nhiều dung lượng đĩa.

Trong Postgres, tôi sẽ giải quyết vấn đề này một cách tao nhã bằng một kiểu mảng hoặc một varray trong Oracle.

Tôi không biết liệu nó có hữu ích cho vấn đề của bạn không, nhưng đối với các cột tôi không cần phải thực hiện các yêu cầu trực tiếp (cols mà tôi không bao giờ đặt trong điều kiện WHERE của mình) và chỉ cung cấp thông tin khi tôi muốn tất cả thông tin về một số các hàng cụ thể, tôi kết hợp chúng trong một trường blog được định dạng JSON.

Có lẽ tôi sẽ đưa ra quyết định cuối cùng của thiết kế phụ thuộc vào việc phân phối tham số được truy vấn. Đó là, nếu có một vài tham số được truy vấn gần như độc quyền, tôi sẽ đặt các giá trị của chúng vào một bảng nóng và các giá trị còn lại vào một bảng lạnh khác .

Otoh, nếu phân phối truy vấn của họ nhiều hơn hoặc ít hơn, tôi sẽ tải một tập hợp mẫu có giá trị vài ngày vào một bảng trong đó một bản ghi giữ tất cả các giá trị để xem tỷ lệ giữa các bản ghi / khối db (hoặc nếu thậm chí có một vấn đề chuỗi liên kết , có khả năng). Tùy thuộc vào đó tôi sẽ làm một quyết định thiết kế hơn nữa.

Chà, sau khi đọc nó, có lẽ tôi sẽ thực hiện cả hai cách tiếp cận cho một sự mong muốn song song.

Tôi đã đọc lại câu hỏi - nếu tôi có câu này đúng, thì trong mỗi bản ghi bạn nhận làm đầu vào, có các giá trị khác nhau được theo dõi (dựa trên ParameterID):

ParameterID đề cập đến một bảng khác lưu trữ các tiêu đề cột đầu vào (200,00 202,50 205,00 ...).

... Tôi không biết đủ về cách bạn tương tác với dữ liệu, nhưng tôi có xu hướng đi với một tùy chọn khác - có một bảng riêng cho mỗi ID tham số, và sau đó nếu cần có chế độ xem sẽ nối các tham số khác nhau theo ngày và vị trí vào bảng rộng hơn (240 cột); nếu điều quan trọng là giữ DataID có thể truy cập được trong chế độ xem, thì bạn có thể sử dụng UNIONthay vì a JOIN, nhưng các cột sẽ được dân cư thưa thớt.