PostgreSQL bytea 및 smallint []

대규모 (100Mb-1GB) 다중 채널 시계열 데이터를 PostgreSQL 데이터베이스로 가져 오려고합니다. 데이터는 일반적으로 각각 몇 초의 "레코드"또는 "에포크"로 데이터를 청크하는 EDF 형식 파일 에서 가져옵니다 . 각 에포크의 레코드는 각 데이터 채널에 대한 신호를 짧은 정수의 순차적 배열로 보유합니다.

최악의 경우 BLOB로 데이터베이스 내에 파일을 저장해야합니다. 이를 감안할 때 신호 데이터를 기반으로 쿼리를 촉진하는 등 데이터베이스 내의 데이터로 더 많은 작업을 수행 할 수있는 옵션을 조사하고 싶습니다.

나의 초기 계획은 에포크 레코드 당 하나의 행으로 데이터를 저장하는 것입니다. 내가 계량하려고하는 것은 실제 신호 데이터를 bytea 또는 smallint [] (또는 smallint [] []) 유형으로 저장할지 여부입니다. 누구든지 다른 것을 추천 할 수 있습니까? 저장 및 액세스 비용에 관심이 있습니다. 사용법은 한 번만 삽입하고 가끔 읽고 업데이트하지 않을 가능성이 있습니다. 레코드를 비교하는 분석 기능을 추가 할 수 있도록 사용자 정의 유형으로 더 쉽게 정리 된 경우 훨씬 좋습니다.

의심의 여지없이 나는 세부 사항이 낮으므로 명확하게 설명하고 싶은 내용에 대한 의견을 자유롭게 추가하십시오.

답변이 없으면 문제를 직접 탐구했습니다.

사용자 정의 함수 가 and를 포함한 모든 기본 유형을 처리 할 수있는 것처럼 보이 므로 표현 선택에 큰 영향을 미치지 않습니다.byteasmallint[]

바닐라 구성으로 Windows 7 랩톱에서 로컬로 실행되는 PostgreSQL 9.4 서버에서 여러 가지 다른 표현을 시도했습니다. 실제 신호 데이터를 저장하는 관계는 다음과 같습니다.

전체 파일을위한 큰 객체

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

채널당 SMALLINT 어레이

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

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

에포크 당 SMALLINT 2D 어레이

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

에포크 당 BYTEA 어레이

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

그런 다음 Java JDBC를 통해 선택한 EDF 파일을 각 관계로 가져오고 각 업로드 후 데이터베이스 크기의 증가를 비교했습니다.

파일은 다음과 같습니다.

• 파일 A : 16 채널 2706 에포크, 각 채널 1024 샘플 (에포크 당 1,16385 샘플), 85 MB
• 파일 B : 18 채널의 11897 에포크, 각 채널 1024 샘플 (에포크 당 18332 샘플), 418 MB
• 파일 C : 20746 개 채널의 11746 개 에포크, 각 채널 64 ~ 1024 개 샘플 (에포크 당 17088 개 샘플), 382MB

스토리지 비용 측면에서 다음은 각 사례에서 차지하는 크기 (MB)입니다.

원래 파일 크기에 비해 큰 개체는 약 30-35 % 더 큽니다. 반대로, 각 시대를 BYTEA 또는 SMALLINT [] []로 저장하면 10 % 미만이되었습니다. 각 채널을 별도의 튜플로 저장하면 BYTEA 또는 SMALLINT []로 40 % 증가하므로 큰 객체로 저장하는 것보다 나쁘지 않습니다.

내가 처음에 알지 못했던 한 가지는 PostgreSQL에서 "다차원 배열이 각 차원마다 일치하는 범위를 가져야한다"는 것입니다 . 이는 SMALLINT[][]에포크의 모든 채널에 동일한 수의 샘플이있는 경우에만 표현 이 작동 함을 의미합니다 . 따라서 파일 C는 EpochArray관계에 대해 작동하지 않습니다 .

액세스 비용 등의 측면에서,이 주위에 연주하지만, 적어도 초기에 가장 빠르게 표현이었다 데이터를 삽입 측면에서하지 EpochBytea와 BlobFile함께, EpochChannelArray처음 두대로만큼 3 번에 대한 고려, 가장 느린.