PostgreSQL hstore कुंजी/मान बनाम पारंपरिक एसक्यूएल प्रदर्शन

Question

मैं एक कुंजी/मान बैकएंड, कुछ इस तरह विकसित करने की आवश्यकता:

Table T1 id-PK, Key - string, Value - string 
INSERT into T1('String1', 'Value1') 
INSERT INTO T1('String1', 'Value2') 

Table T2 id-PK2, id2->external key to id 
some other data in T2, which references data in T1 (like users which have those K/V etc) 

मैं जिन/GIST साथ PostgreSQL hstore के बारे में सुना। बेहतर क्या है (प्रदर्शन-वार)? ऐसा करने से SQL के साथ पारंपरिक तरीका जुड़ता है और अलग-अलग कॉलम (कुंजी/मान) होते हैं? क्या PostgreSQL hstore इस मामले में बेहतर प्रदर्शन करता है?

डेटा का प्रारूप कोई भी कुंजी => कोई मान होना चाहिए। मैं टेक्स्ट मिलान करना भी चाहता हूं उदा। आंशिक रूप से खोज करें (एसक्यूएल में% पसंद करें या हिस्टोर समकक्ष का उपयोग करें)। मैं इसमें लगभग 1 एम -2 एम प्रविष्टियां रखने की योजना बना रहा हूं और शायद किसी बिंदु पर स्केल कर सकता हूं।

आप क्या सलाह देते हैं? एसक्यूएल पारंपरिक तरीका/PostgreSQL hstore या दृढ़ता के साथ किसी अन्य वितरित कुंजी/मूल्य स्टोर जा रहे हैं?

यदि यह मदद करता है, तो मेरा सर्वर 1-2 जीबी रैम वाला वीपीएस है, इसलिए एक बहुत अच्छा हार्डवेयर नहीं है। मैं इसके ऊपर एक कैश परत भी सोच रहा था, लेकिन मुझे लगता है कि यह समस्या को जटिल बनाता है। मैं सिर्फ 2 एम प्रविष्टियों के लिए अच्छा प्रदर्शन चाहता हूँ। अपडेट अक्सर किया जाएगा लेकिन अधिक बार खोज करता है।

धन्यवाद।

Answer 1

आपका प्रश्न अस्पष्ट है क्योंकि आप अपने उद्देश्य के बारे में स्पष्ट नहीं हैं।

यहां कुंजी इंडेक्स (पन इरादा) है - यदि आप बड़ी मात्रा में चाबियों से निपट रहे हैं तो आप उन्हें कम से कम लुकअप के साथ पुनर्प्राप्त करने और असंबद्ध डेटा खींचने के बिना सक्षम करना चाहते हैं।

लघु जवाब आप शायद hstore का उपयोग नहीं करना चाहते हैं, लेकिन और अधिक विस्तार पर गौर करने देता है ...

• प्रत्येक id कई कुंजी/मान जोड़े है (सैकड़ों +) करता है? hstore का उपयोग न करें।
• क्या आपके किसी भी मूल्य में टेक्स्ट के बड़े ब्लॉक (4kb +) होंगे? hstore का उपयोग न करें।
• क्या आप वाइल्डकार्ड अभिव्यक्तियों में कुंजी द्वारा खोज करने में सक्षम होना चाहते हैं? hstore का उपयोग न करें।
• क्या आप जटिल जॉइन/एकत्रीकरण/रिपोर्ट करना चाहते हैं? hstore का उपयोग न करें।
• क्या आप एक कुंजी के लिए मान अपडेट करेंगे? hstore का उपयोग न करें।
• id के तहत एक ही नाम के साथ एकाधिक कुंजी? hstore का उपयोग नहीं कर सकते।

तो hstore का उपयोग क्या है? खैर, एक अच्छा परिदृश्य होगा यदि आप किसी बाहरी एप्लिकेशन के लिए कुंजी/मूल्य जोड़े रखना चाहते हैं, जहां आप जानते हैं कि आप हमेशा सभी कुंजी/मानों को फिर से प्राप्त करना चाहते हैं और हमेशा डेटा को ब्लॉक के रूप में सहेज लेंगे (यानी, यह कभी संपादित नहीं होता है जगह में)। साथ ही आप इस डेटा को खोजने में सक्षम होने के लिए कुछ लचीलापन चाहते हैं - अल्बियेट बहुत आसानी से - एक्सएमएल या जेएसओएन के ब्लॉक में इसे संग्रहीत करने के बजाय। इस मामले में कुंजी/मूल्य जोड़े की संख्या कम होती है, आप अंतरिक्ष पर सहेजते हैं क्योंकि आप कई tuples को एक hstore में संपीड़ित करते हैं।

अपनी मेज के रूप में इस पर विचार करें:

CREATE TABLE kv (
    id /* SOME TYPE */ PRIMARY KEY, 
    key_name TEXT NOT NULL, 
    key_value TEXT, 
    UNIQUE(id, key_name) 
); 

Answer 2

मुझे लगता है कि डिजाइन खराब सामान्यीकृत है।

CREATE TABLE t1 
(
    t1_id serial PRIMARY KEY, 
    <other data which depends on t1_id and nothing else>, 
    -- possibly an hstore, but maybe better as a separate table 
    t1_props hstore 
); 

-- if properties are done as a separate table: 
CREATE TABLE t1_properties 
(
    t1_id int NOT NULL REFERENCES t1, 
    key_name text NOT NULL, 
    key_value text, 
    PRIMARY KEY (t1_id, key_name) 
); 

गुण छोटे हैं और आप उन्हें मिलती है में या फैंसी चयन मानदंड के साथ भारी उपयोग करने की आवश्यकता नहीं है, और hstore ही पर्याप्त होता है: इस तरह कुछ और प्रयास करें। इलियट ने उस संबंध में विचार करने के लिए कुछ समझदार चीजें रखीं।

उपयोगकर्ताओं का आपका संदर्भ बताता है कि यह अपूर्ण है, लेकिन आपने वास्तव में यह सुझाव देने के लिए पर्याप्त जानकारी नहीं दी है कि वे कहां हैं। आप t1 में एक सरणी के साथ प्राप्त कर सकते हैं, या आप एक अलग तालिका के साथ बेहतर हो सकता है।