क्या मुझे CHAR (36) से UUID तक कॉलम प्रकार बदलने के लिए समय का निवेश करना चाहिए?


14

मेरे डेटाबेस में कुछ मिलियन पंक्तियाँ पहले से हैं। जब मैंने अपना स्कीमा डिज़ाइन किया तो मुझे पोस्टग्रेसीक्यूएल यूआईडी डेटा प्रकार के बारे में पता नहीं था।

तालिकाओं में से एक में 16M पंक्तियाँ (लगभग 3.5M से 4 M रिकॉर्ड प्रति शार्द) हैं, जो प्रति दिन लगभग 500K रिकॉर्ड बढ़ रही हैं। आवश्यकता होने पर भी कुछ घंटों के लिए उत्पादन प्रणाली को नीचे ले जाने का मेरा सौभाग्य अभी भी है। मेरे पास एक या दो सप्ताह में यह विलासिता नहीं होगी।

मेरा प्रश्न यह है कि क्या ऐसा करना सार्थक होगा? मैं जोइन प्रदर्शन, डिस्क स्थान उपयोग (पूर्ण gzip'd डंप 1.25 GiB है) के बारे में सोच रहा हूँ, उस प्रकृति की चीजें।

तालिका स्कीमा है:

# \d twitter_interactions
                Table "public.twitter_interactions"
         Column          |            Type             | Modifiers 
-------------------------+-----------------------------+-----------
 interaction_id          | character(36)               | not null
 status_text             | character varying(1024)     | not null
 screen_name             | character varying(40)       | not null
 twitter_user_id         | bigint                      | 
 replying_to_screen_name | character varying(40)       | 
 source                  | character varying(240)      | not null
 tweet_id                | bigint                      | not null
 created_at              | timestamp without time zone | not null
Indexes:
    "twitter_interactions_pkey" PRIMARY KEY, btree (interaction_id)
    "twitter_interactions_tweet_id_key" UNIQUE, btree (tweet_id)
    "index_twitter_interactions_on_created_at" btree (created_at)
    "index_twitter_interactions_on_screen_name" btree (screen_name)
Triggers:
    insert_twitter_interactions_trigger BEFORE INSERT ON twitter_interactions FOR EACH ROW EXECUTE PROCEDURE twitter_interactions_insert_trigger()
Number of child tables: 9 (Use \d+ to list them.)

जवाबों:


13

मैं यूयूआईडी प्रकार में बदलाव पर विचार करूंगा। char(36)40 बाइट्स uuidलेता है , 16 लेता है, इसलिए आप प्रति पंक्ति 24 बाइट बचाएंगे, जो आपके लिए एक दिन के बाद 12 एमबी, 4 जीबी के बराबर होगा। प्लस इंडेक्स। आपके पास जो हार्डवेयर है, उसके आधार पर, यह बहुत अधिक नहीं है, लेकिन यह हो सकता है। और यह आगे बढ़ता है अगर आपके पास इस तरह के अधिक सुधार के अवसर हैं।

इसके अलावा, मुझे आपके द्वारा स्कीमा में कोई बाधा नहीं दिखाई देती है जो यह सुनिश्चित करती interaction_idहै कि वास्तव में सही प्रारूप में है। सही प्रकार का उपयोग करने से आपको वह भी मिल जाएगा।

यदि आप इसे पसंद करते हैं, हालांकि, उपयोग करने से bigintभी अधिक बचत होगी और बेहतर प्रदर्शन भी होगा। यह बहुत संभावना नहीं है कि आपका आवेदन इतना बड़ा है कि एक bigintआईडी कॉलम के लिए काम नहीं करेगा।


मेरे पास एक वितरित प्रणाली है: डेटा के कई स्रोत इंटरैक्शन के लिए आईडी जनरेट करते हैं, इस प्रकार मैं एक सादे BIGINT का उपयोग नहीं कर सकता जब तक कि मैं नोड आईडी के लिए N बिट्स आरक्षित नहीं करता।
फ्रांस्वा ब्यूसोइल

3
@ फ्रांस्वा बेयूसोइल, नोड आईडी के लिए एन बिट्स को जमा करना एक क्रम में प्रत्येक Nth संख्या का उपयोग करने के लिए बराबर है (और इसलिए लागू करना आसान है)। इसके अलावा, आप समग्र कुंजियों का उपयोग करने पर विचार कर सकते हैं।
१३:११

1
कई अनुक्रमों (नोड आईडी के साथ) का समन्वय करना व्यवहार में एक प्रशासनिक परेशानी है और मानव त्रुटि के लिए प्रवण है। मुझे इस परिदृश्य में UUIDs का उपयोग न करने का कोई कारण नहीं दिखता, खासकर बिट्स आजकल सस्ते हैं (मेमोरी और स्टोरेज दोनों)। वास्तव में, यह परिदृश्य बहुत कारण है कि UUIDs का आविष्कार दशकों पहले किया गया था: केंद्रीकृत समन्वय के बिना वितरित सिस्टम के बीच डेटा साझा करने के लिए
तुलसी बॉर्क

6

मैं कल्पना के किसी भी खंड द्वारा एक व्यक्ति को पोस्टग्रेज नहीं कर रहा हूं, लेकिन मैं SQL सर्वर से जो कुछ भी जानता हूं, उसके आधार पर आप डेटा पेज पर जितनी अधिक पंक्तियां फिट कर सकते हैं, आपके पास बेहतर प्रदर्शन होने वाला है (डिस्क से डेटा पढ़ना आम तौर पर है) सबसे महंगा ऑपरेशन)। इस प्रकार, एक 36 से जा रहा ish 1 16 बाइट के लिए बाइट व्यापक क्षेत्र GUID एक सीधे आगे लागत बचत लगता है। जितना कम आप पढ़ सकते हैं उतनी ही तेजी से आप परिणाम लौटा सकते हैं। यह सब निश्चित रूप से मानता है कि एक GUID / UUID तालिका की व्यावसायिक आवश्यकताओं को पूरा करता है। यदि कोई UUID इसे संतुष्ट करता है, तो क्या कोई बिगिन होगा ? यह आपके संग्रहण को प्रति पंक्ति 8 बाइट की लागत को आगे बढ़ाएगा।

संपादित करें 1

Postgres में चरित्र डेटा के लिए , उनके लिए एक अतिरिक्त भंडारण लागत है। 127 बाइट्स के अंतर्गत आने वाले छोटे तारों में 1 बाइट ओवरहेड होता है, जबकि कुछ में 4 बाइट्स होते हैं, जो कि दूसरे प्रतिवादी को 36 बाइट फ़ील्ड के लिए 40 बाइट की लागत के साथ आता है। लेकिन स्ट्रिंग संपीड़न के लिए एक विकल्प भी है, इसलिए शायद इसे पूरे 40 खर्च नहीं होंगे। मैं यह नहीं बता सकता कि अंतिम लागत क्या होगी, लेकिन मूल बातें बनी रहेंगी: 16 बाइट्स में कुछ भी भंडारण लागत में वृद्धि करेगा, इससे पढ़ने के लिए अधिक समय लगेगा। और अधिक मेमोरी का उपभोग करें।

एक छोटी स्ट्रिंग (126 बाइट तक) के लिए भंडारण की आवश्यकता 1 बाइट से अधिक वास्तविक स्ट्रिंग है, जिसमें चरित्र के मामले में स्पेस पेडिंग शामिल है। लंबे समय तक तार के बजाय ओवरहेड के 4 बाइट्स होते हैं। 1. लंबे तार स्वचालित रूप से सिस्टम द्वारा संपीड़ित होते हैं, इसलिए डिस्क पर भौतिक आवश्यकता कम हो सकती है।


3

अंतरिक्ष समस्या के अलावा ध्यान रखें कि आपको सही डेटा प्रकार का उपयोग करने के लिए प्रत्येक तालिका को बदलना होगा या आपका सम्मिलित प्रदर्शन टैंक, बुरी तरह से होगा।


यह एक दिया गया था, लेकिन मुझे याद दिलाने के लिए धन्यवाद।
फ्रांस्वा ब्यूसोइल

3
इस तरह के बड़े बदलाव करते समय मुझे पता चलता है कि सबकुछ लिख देना (कोई बात नहीं याद रखना कितना सरल है) आमतौर पर भुगतान करता है।
mrdenny

3

डेटा और इंडेक्स के आकार में बचत के अलावा (जैसा कि अन्य लोगों द्वारा कहा गया है), जो I / O बचत में अनुवाद करता है, जिस चीज पर आपको विचार करने की आवश्यकता है वह यह है कि आप नए मूल्यों को कैसे उत्पन्न interaction_idकरेंगे और इसका क्या प्रभाव पड़ेगा अनुक्रमित और क्वेरी की स्थिति (मिलती है)।

इंडेक्स के लिए - यह छोटा होगा, हालांकि यदि आपके बहुत से प्रश्न यूयूआईडी को स्विच करने वाले इंडेक्स स्कैन का उपयोग करते हैं तो इंडेक्स स्कैन को असंभव सौंप सकते हैं (यह निर्भर करता है कि आप यूयूआईडी कैसे उत्पन्न करेंगे) और bigintबहुत बेहतर विकल्प हो सकता है।

अंत में, जैसा कि वास्तविक प्रदर्शन प्रभाव आपके उपयोग पैटर्न और डेटा वितरण पर भी निर्भर करता है, आपको परीक्षण चलाने चाहिए और एक विकास और परीक्षण वातावरण होना चाहिए जिसमें आप अपने परिवर्तनों का परीक्षण कर सकते हैं।

यह आपको प्रदर्शन पर प्रभाव के बारे में अधिक सटीक उत्तर देगा।


उपयोगी योगदान के लिए धन्यवाद और साइट पर आपका स्वागत है :)
जैक का कहना है कि topanswers.xyz

मेरी पहुंच पैटर्न डेट रेंज के माध्यम से हैं, स्क्रीन_नाम का उपयोग करके, या UUID द्वारा। यूनिक आईडी पर कोई रेंज स्कैन अनुमानित नहीं है। आपके उत्तर के लिए धन्यवाद, बहुत जानकारीपूर्ण।
फ्रांस्वा ब्यूसोलिल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.