Tôi được yêu cầu phát triển lưu trữ dữ liệu cho dữ liệu chuỗi thời gian, mặc dù nghiên cứu quan trọng tôi không chắc chắn về mô hình dữ liệu và công nghệ lưu trữ được chọn.

Về dữ liệu

Dữ liệu nguồn sẽ được lưu trữ trong bộ lưu trữ dữ liệu được cung cấp bởi các đơn vị đo vật lý. Mỗi đơn vị có thể có hoặc không có một tập hợp con các biến khác nhau với tối đa 300 biến trên mỗi trạm đo (ví dụ: loại nhiên liệu, mức tiêu thụ nhiên liệu, tốc độ) trong khi số lượng tín hiệu khác nhau trên tất cả các trạm là theo thứ tự 1500. tập hợp con dự kiến ​​của các biến trên mỗi trạm được biết trước. Tuy nhiên, các cảm biến bổ sung có thể được thêm vào một trạm theo thời gian (có thể cần thay đổi lược đồ theo thời gian). Tất cả các trạm cung cấp dữ liệu với tốc độ khác nhau, từ 20Hz đến 0,2Hz.

Ngoài ra, có một lượng dữ liệu meta hợp lý có sẵn cho tất cả các trạm đo mà chúng tôi sẽ có khoảng 500 cuối cùng.

Dữ liệu thường đi theo đợt và không phải là luồng "thời gian thực". Các kích cỡ lô khác nhau từ các lô hàng giờ đến hàng tháng.

Về các truy vấn

Việc truy vấn dữ liệu được thực hiện vì hai lý do chính, báo cáo và phân tích thống kê về dữ liệu của một trạm đo lường đơn lẻ cũng như so sánh giữa các trạm. Khoảng 80% các truy vấn có liên quan đến dữ liệu xuất hiện trong 30 ngày qua. Truy vấn được thực hiện trên cơ sở hàng ngày do đó SELECTtải vượt quá INSERTtải.

Các truy vấn lý tưởng như

SELECT var1, var2, ... varN FROM station_data WHERE station_id=X OR station_id=Y AND TIMESTAMP BETWEEN ... AND ...;

có thể dễ dàng truy cập dữ liệu cho những người không chuyên về SQL. Hơn nữa, các số liệu tổng hợp dựa trên thời gian đơn giản nên có thể (AVG, MAX, v.v. pp).

Tình hình hiện tại

Hiện tại, một cấu trúc được chuẩn hóa cao được sử dụng để lưu trữ dữ liệu trong cơ sở dữ liệu PostgreQuery, hiện đã tăng lên khoảng 6TB với một bảng cho mỗi biến. Mỗi trong số khoảng 1500 bảng dữ liệu có dạng

(timestamp, station_id, value)

với các chỉ mục trên (station_id), (station_id, timestamp), (timestamp)và một ràng buộc duy nhất trên (station_id, timestamp, value).

Cấu trúc này đòi hỏi sự kết nối bên ngoài nặng nề (lên đến 300 kết nối bên ngoài) khiến cho việc truy xuất dữ liệu trở nên cồng kềnh và tốn kém về mặt tính toán.

Nghiên cứu

Cho đến nay các cân nhắc sau đây đã được thực hiện:

Công nghệ DB

1. Mặc dù NoQuery sẽ cung cấp tính linh hoạt của lược đồ cần thiết, các công cụ để đảm bảo tính toàn vẹn dữ liệu, kiểm soát truy cập và quản lý dữ liệu meta dường như là thách thức và không có trải nghiệm NoQuery nào tồn tại trong nhà. Hơn nữa, đọc các bình luận và câu trả lời dọc theo dòng này dường như có lợi cho một giải pháp SQL cho usecase của chúng tôi.
2. Khác nhau thời gian căn cứ cơ sở dữ liệu được tối ưu hóa được coi là (chủ yếu là CrateDB và TimescaleDB ). Cả hai đều có vẻ hứa hẹn liên quan đến phân vùng và bảo vệ "tự động" của họ, nơi TimescaldeDB sẽ được ưa chuộng một chút vì nó dựa trên PostgreQuery.

Mô hình dữ liệu / Lược đồ

Cho đến nay, hai lược đồ khác nhau đã được tìm ra nguyên tắc hoạt động. Tuy nhiên, cả hai đều có nhược điểm đáng kể mà tôi cần tìm cách khắc phục.

1. Mẫu EAV (chống) với một bảng dữ liệu dọc khổng lồ có bật station_idvà phân vùng hàng tháng timestamp. Mặc dù tính linh hoạt của lược đồ được yêu cầu sẽ được đưa ra, mẫu này sẽ không tuân thủ tính dễ truy cập cần thiết vì nó vẫn phụ thuộc rất nhiều vào các phép nối bên trong. Hơn nữa, an toàn kiểu cho các kiểu dữ liệu khác nhau không được đảm bảo ở phía db và điều khiển truy cập là không thể.
2. Một bảng cho mỗi station_idlược đồ thay đổi theo chiều ngang khi thêm cảm biến vào một trạm cụ thể. Cấu trúc không chuẩn hóa này là từ cái nhìn đầu tiên hấp dẫn từ quan điểm ứng dụng (chèn nhanh, yêu cầu lập chỉ mục ít, truy vấn đơn giản trên một trạm). Tuy nhiên, truy vấn sẽ yêu cầu SQL động do trình kết thúc có thể không biết tên bảng cho trạm cụ thể và so sánh trạm chéo chỉ có thể với các truy vấn SQL mở rộng hoặc mã phía máy khách.

Xem xét chung

Mặc dù dung lượng lưu trữ không phải là vấn đề đáng lo ngại, nhưng độ tin cậy, thời gian hoạt động và tốc độ truy xuất dữ liệu là.

Câu hỏi

Mô hình dữ liệu được đề xuất nào sẽ được ưu tiên để đáp ứng các yêu cầu trong khi duy trì khả năng mở rộng? Đề xuất cho bất kỳ lược đồ bổ sung phù hợp với các yêu cầu rất được hoan nghênh.

Cảm ơn bạn.

Tôi đã có tình huống khá giống với dữ liệu của mình, ngoại trừ sự thay đổi số lượng biến, nhưng như TmTron nói JSON có thể phù hợp với bạn. Đây là lược đồ tôi đã có (thích ứng với dữ liệu của bạn):

Cảm biến bảng ": chứa bất kỳ siêu dữ liệu nào bạn muốn khoảng 1k + hàng thường xuyên trong một số trường hợp 7k + không có sự khác biệt thực tế.

Bảng "sensor_data":

• dấu thời gian,
• cảm biến_id int, - FK đến cảm biến
• đo lường_id int (tôi đã có 14),
• var1, var2, var3, var4, var5 - thông báo cho tôi nó là một bộ 5 int8, trong trường hợp của bạn đó là dữ liệu không thể cột, hãy nói JSON
• Lập chỉ mục theo (sensor_id, đo_id, dấu thời gian) (khoảng 1/3 kích thước bảng)

Hàng tấn truy vấn như

{select timestamp, var1,var2,var3,var4,var5 from sensor_data where sensor_id = xx and timestamp between xxxx and xxxx}

Bảng trở nên lớn hơn, truy vấn chậm hơn, khách hàng tức giận và như vậy.

Nỗ lực tối ưu hóa đầu tiên là phân vùng theo phạm vi của cảm biến - 20 mỗi phân vùng, mức tiêu thụ không gian vẫn giữ nguyên, lược đồ trở nên phức tạp hơn, các truy vấn trở nên nhanh hơn nhưng không quá nhiều.

Vì vậy, đây vẫn là lược đồ làm việc:

loại dữ liệu tùy chỉnh "số liệu" (dấu thời gian, var1, var2, var3, var4, var5)

bảng cảm biến_data:

• ngày
• cảm biến
• đo lường
• tập dữ liệu - đó là một cột kiểu "số liệu []" - mảng chứa tất cả dữ liệu cho một chỉ mục duy nhất theo ngày, sensor_id, đo_id

chọn truy vấn đã được thay thế bằng hàm get_data (sensor_id, đo_id, from_time, to_time) chọn (không nhất định (tập dữ liệu)).

chèn trở nên phức tạp hơn:

insert into sensor_data value (to_date(timestamp), sensor, measurement, [(timestamp, var1,var2,var3,var4,var5)])
on conflict (date, sensor_id, measurement_id) do update
set dataset=dataset||excluded.dataset

Tiêu thụ không gian ít hơn ~ 10 lần, truy vấn phức tạp hơn nhưng nhanh hơn đáng kể.

Nếu bạn không yêu cầu dữ liệu bằng phép đo_id, chỉ cần xóa nó khỏi chỉ mục và truy vấn. Nếu bạn có nhiều dữ liệu hơn mỗi ngày, bạn có thể lưu trữ dữ liệu mỗi giờ thay thế cột "ngày" bằng "giờ" date_trunc('hour',timestamp)và bảng phân vùng mỗi tháng, do đó bạn sẽ có tối đa 744 (31 * 24) hàng cho mỗi cảm biến, mỗi lần đo bàn. Đó là số lượng hàng khá hợp lý và sẽ hoạt động đủ nhanh.

Rõ ràng là bạn phải soạn kiểu dữ liệu của riêng bạn (đối với hầu hết các trường hợp loại (dấu thời gian, JSON) sẽ hoạt động)

Ý tưởng chính là postgres lưu trữ các mảng dữ liệu bên ngoài bảng và chỉ đọc chúng khi chúng cần (hơn nữa nó được nén). Vì vậy, bảng trở thành "chỉ mục kinda" cho dữ liệu được lưu trữ ở một nơi khác, nhưng vẫn là một bảng mà bạn có thể lập chỉ mục và phân vùng.

Hạn chế là bạn không thể kiểm soát nội dung mảng dữ liệu với các ràng buộc và tổng hợp dữ liệu trực tiếp. Nhưng đối với các tập hợp đơn giản (như max, min, avg), bạn có thể tổng hợp dữ liệu trước và vẫn lưu trữ nó ở cấp hàng.