किसी भी उत्तर की अनुपस्थिति में मैंने इस मुद्दे को स्वयं आगे बढ़ाया है।
ऐसा लगता है कि उपयोगकर्ता द्वारा परिभाषित फ़ंक्शन सभी आधार प्रकारों को शामिल कर सकते हैं, जिनमें शामिल हैंbytea और smallint[]इसलिए, यह प्रतिनिधित्व के विकल्प को बहुत प्रभावित नहीं करता है।
मैं एक PostgreSQL 9.4 सर्वर पर कई अलग-अलग अभ्यावेदन करने की कोशिश की, जो कि वेनिला कॉन्फ़िगरेशन के साथ विंडोज 7 लैपटॉप पर स्थानीय रूप से चल रहा है। वास्तविक सिग्नल डेटा को स्टोर करने के संबंध इस प्रकार थे।
पूरी फाइल के लिए बड़ी वस्तु
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)
);
स्मालकैप 2 डी सरणी प्रति युग
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)
);
मैंने तब जावा JDBC के माध्यम से इन संबंधों में से प्रत्येक में EDF फ़ाइलों का चयन आयात किया और प्रत्येक अपलोड के बाद डेटाबेस आकार में वृद्धि की तुलना की।
फाइलें थीं:
- फ़ाइल ए: 166 चैनलों के 2706 युग, प्रत्येक चैनल 1024 नमूने (16385 नमूने प्रति युग), 85 एमबी
- फ़ाइल बी: 11897 18 चैनलों के युग, प्रत्येक चैनल 1024 नमूने (प्रति युग 18432 नमूने), 418 एमबी
- फ़ाइल सी: 2046 चैनलों के 11746 युग, प्रत्येक चैनल 64 से 1024 नमूने (प्रति युग 17088 नमूने), 382 एमबी
भंडारण लागत के संदर्भ में, यहां एमबी का आकार प्रत्येक मामले के लिए है:
मूल फ़ाइल आकार के सापेक्ष, बड़े ऑब्जेक्ट लगभग 30-35% बड़े थे। इसके विपरीत, प्रत्येक युग को BYTEA या SMALLINT [] [] के रूप में संग्रहीत करना 10% से कम बड़ा था। प्रत्येक चैनल को अलग-अलग ट्यूपल के रूप में संग्रहीत करने से 40% की वृद्धि होती है, या तो BYTEA या SMALLINT [], इसलिए एक बड़ी वस्तु के रूप में संग्रहीत करने की तुलना में बहुत बुरा नहीं है।
एक चीज जिसकी मैंने शुरुआत में सराहना नहीं की थी, वह यह है कि " पोस्टग्रेज SQL में बहुआयामी सरणियों का प्रत्येक आयाम के लिए मिलान विस्तार होना चाहिए" । इसका मतलब यह है कि SMALLINT[][]प्रतिनिधित्व केवल तब काम करता है जब एक युग में सभी चैनलों में समान संख्या में नमूने होते हैं। इसलिए फ़ाइल C EpochArrayरिलेशन के साथ काम करने में विफल रहता है ।
एक्सेस कॉस्ट के रूप में, मैंने इसके साथ नहीं खेला है, लेकिन कम से कम डेटा डालने के मामले में शुरू में सबसे तेज़ प्रतिनिधित्व था EpochByteaऔर BlobFile, EpochChannelArrayसबसे धीमे के साथ , पहले दो के रूप में लगभग 3 बार ले रहा था।