PostgreSQL bytea vs smallint []

Tôi đang tìm cách nhập dữ liệu chuỗi thời gian đa kênh lớn (100Mb - 1 GB) vào cơ sở dữ liệu PostgreQuery. Dữ liệu đến từ các tệp định dạng EDF chia dữ liệu thành "bản ghi" hoặc "kỷ nguyên" thường là vài giây mỗi lần. Mỗi bản ghi của epoch giữ các tín hiệu cho từng kênh dữ liệu dưới dạng các dãy liên tiếp của các số nguyên ngắn.

Tôi bắt buộc phải lưu trữ các tệp trong cơ sở dữ liệu, trong trường hợp xấu nhất là BLOB. Do đó, tôi muốn điều tra các tùy chọn cho phép tôi làm gì đó nhiều hơn với dữ liệu trong cơ sở dữ liệu, chẳng hạn như tạo điều kiện truy vấn dựa trên dữ liệu tín hiệu.

Kế hoạch ban đầu của tôi là lưu trữ dữ liệu dưới dạng một hàng trên mỗi bản ghi kỷ nguyên. Điều tôi đang cố gắng cân nhắc là lưu trữ dữ liệu tín hiệu thực tế dưới dạng các loại bytea hay smallint [] (hoặc thậm chí smallint [] []). Bất cứ ai có thể đề nghị cái này hơn cái kia? Tôi quan tâm đến chi phí lưu trữ và truy cập. Cách sử dụng có khả năng được chèn một lần, thỉnh thoảng đọc, cập nhật không bao giờ. Nếu một loại được gói dễ dàng hơn như một loại tùy chỉnh để tôi có thể thêm các chức năng để phân tích so sánh các bản ghi thì càng nhiều càng tốt.

Không còn nghi ngờ gì nữa, tôi rất ít chi tiết, vì vậy hãy thoải mái thêm ý kiến ​​về những gì bạn muốn tôi làm rõ.

Trong trường hợp không có bất kỳ câu trả lời nào, tôi đã tự mình khám phá vấn đề này.

Có vẻ như các hàm do người dùng xác định có thể xử lý tất cả các loại cơ sở, bao gồm bytea và smallint[], do đó, điều này không ảnh hưởng nhiều đến sự lựa chọn đại diện.

Tôi đã thử một số cách trình bày khác nhau trên máy chủ PostgreQuery 9.4 chạy cục bộ trên máy tính xách tay Windows 7 có cấu hình vanilla. Các mối quan hệ để lưu trữ dữ liệu tín hiệu thực tế như sau.

Đối tượng lớn cho toàn bộ tệp

CREATE TABLE BlobFile (
    eeg_id INTEGER PRIMARY KEY,
    eeg_oid OID NOT NULL
);

Mảng SMALLINT trên mỗi kênh

CREATE TABLE EpochChannelArray (
    eeg_id INT NOT NULL,
    epoch INT NOT NULL,
    channel INT,
    signal SMALLINT[] NOT NULL,
    PRIMARY KEY (eeg_id, epoch, channel)
);

BYTEA mỗi kênh trong mỗi kỷ nguyên

CREATE TABLE EpochChannelBytea (
    eeg_id INT NOT NULL,
    epoch INT NOT NULL,
    channel INT,
    signal BYTEA NOT NULL,
    PRIMARY KEY (eeg_id, epoch, channel)
);

Mảng 2D SMALLINT mỗi epoch

CREATE TABLE EpochArray (
    eeg_id INT NOT NULL,
    epoch INT NOT NULL,
    signals SMALLINT[][] NOT NULL,
    PRIMARY KEY (eeg_id, epoch)
);

Mảng BYTEA mỗi epoch

CREATE TABLE EpochBytea (
    eeg_id INT NOT NULL,
    epoch INT NOT NULL,
    signals BYTEA NOT NULL,
    PRIMARY KEY (eeg_id, epoch)
);

Sau đó, tôi đã nhập một lựa chọn các tệp EDF vào từng quan hệ này thông qua Java JDBC và so sánh sự tăng trưởng về kích thước cơ sở dữ liệu sau mỗi lần tải lên.

Các tập tin là:

• Tệp A: 2706 epoch của 16 kênh, mỗi kênh 1024 mẫu (16385 mẫu mỗi epoch), 85 MB
• Tệp B: 11897 epoch của 18 kênh, mỗi kênh 1024 mẫu (18432 mẫu mỗi epoch), 418 MB
• Tệp C: 11746 epoch của 20 kênh, mỗi kênh 64 đến 1024 mẫu (17088 mẫu mỗi epoch), 382 MB

Về chi phí lưu trữ, đây là kích thước chiếm MB trong mỗi trường hợp:

Liên quan đến kích thước tệp gốc, Đối tượng lớn lớn hơn khoảng 30 - 35%. Ngược lại, lưu trữ mỗi kỷ nguyên dưới dạng BYTEA hoặc SMALLINT [] [] lớn hơn 10%. Lưu trữ mỗi kênh dưới dạng một bộ riêng biệt giúp tăng 40%, vì BYTEA hoặc SMALLINT [], vì vậy không tệ hơn nhiều so với việc lưu trữ dưới dạng một đối tượng lớn.

Một điều tôi ban đầu không đánh giá cao là "Mảng nhiều chiều phải có phạm vi phù hợp cho từng chiều" trong PostgreQuery . Điều này có nghĩa là SMALLINT[][]đại diện chỉ hoạt động khi tất cả các kênh trong một kỷ nguyên có cùng số lượng mẫu. Do đó File C không hoạt động với EpochArraymối quan hệ.

Trong nhiệm kỳ làm chi phí truy cập, tôi đã không chơi xung quanh với điều này, nhưng ít nhất về cách chèn các dữ liệu ban đầu đại diện nhanh nhất là EpochByteavà BlobFile, với EpochChannelArraysự chậm nhất, lấy khoảng 3 lần miễn là hai người đầu tiên.