डेटाबेस संग्रह समाधान

Question

मेरे द्वारा पोस्ट किए गए एक प्रश्न के सिलसिले में क्या उच्च डेटाबेस में उच्च-वॉल्यूम और अत्यधिक-एक्सेस टेबल को स्थानांतरित करना एक अच्छा विचार है? , मैं PostgreSQL में डेटाबेस संग्रह के लिए उपलब्ध विभिन्न तकनीकों / समाधानों की तलाश कर रहा हूं।

कुछ उपाय मैं सोच सकता हूँ:

1. तालिका विभाजन
2. अलग टेबलस्पेस और / या स्कीमा
3. संग्रहित अभिलेखों / तालिकाओं को एक अलग हार्डडिस्क पर ले जाना

किसी भी अन्य सुझाव / संकेत / समाधान वास्तव में स्वागत है और सराहना की है।

नोट: हम CentOS5.2 पर PostgreSQL v9.1.3 चला रहे हैं

Answer 1

संग्रह के बारे में मेरा सुझाव:

1. बनाएं archive_tablespace(यदि आप चाहते हैं कि आप संग्रह पर हार्डवेयर को अलग कर सकते हैं)

2. टेबल बनाएं। उदाहरण के लिए हम टेबल पोस्ट संग्रह करना चाहते हैं।

   create table  posts_all ( LIKE public.posts)  ;
   create table  posts_archive () inherits  ( public.posts_all)  ;
   alter table  public.posts  inherits ( public.posts_all ) ;

   उसके बाद हमारे पास 2 नए टेबल होंगे: public.posts_all (पोस्ट में समान कॉलम के साथ) सभी पोस्ट (संग्रह और उत्पादन) और public.posts_archive को सभी संग्रह पोस्ट को क्वेरी करने के लिए। Public.posts को पोस्ट_ल से विरासत में मिलेंगे।
   जब तक आप पोस्ट टेबल पर रीडायरेक्ट आवेषणों पर ट्रिगर नहीं लिखेंगे, तब तक सम्मिलित रूप से पुराने तरीके से (सार्वजनिक रूप से तालिकाएँ सार्वजनिक करना) जाना चाहिए। यदि आपके पास विभाजन है तो यह अधिक जटिल होगा। काम के आवेदन के साथ और पुराने डेटा माइग्रेशन से पहले आपको इस दृष्टिकोण के साथ काम करने के लिए एप्लिकेशन कोड में कुछ भी नहीं बदलना होगा।

3. तार्किक पृथक्करण के लिए स्कीमा संग्रह बनाएँ। मेरा सुझाव कुछ समय अवधि (वर्ष या महीने) तक संग्रह डेटा को अलग करना होगा यदि संभव हो तो (संग्रह_2005)।

4. आर्काइव_ आर्क स्कीमा में आर्काइव टेबल बनाएं

   create table archive_2005.posts (
     check(record_date >= '2005-01-01 00:00:00'::timestamp 
       and record_date <  '2006-01-01 00:00:00'::timestamp)
   ) inherits (posts_archive) tablespace archive_tablesapce;

   उसके बाद आपके पास स्कीमा आर्काइव_2005 में नए टेबल पोस्ट होंगे और पोस्टग्रैसेक प्लानर को पता चल जाएगा कि वहां डेटा केवल डिज़ाइन किए गए समयावधि में है। यदि आप किसी अन्य समयावधि से क्वेरी करते हैं, तो postgresql इस तालिका में खोज नहीं करेगा।

5. डेटा को संग्रह तालिका में स्थानांतरित करने के लिए कार्य / प्रक्रिया / ट्रिगर बनाएँ।

6. एक बार समयावधि (वर्ष यहां) और वैक्यूम पुरानी तालिका के लिए एक बार संग्रह करें या इसे स्वचालित रूप से ट्रिगर (ऑटोवेक्यूम पर भारी) द्वारा करें। दोनों तकनीकों में कई फायदे और नुकसान हैं।

यदि लागू किया गया है:

1. क्वेरी को संग्रहीत कर सकते हैं (पोस्ट_आर्काइव से * का चयन करें), सभी (पोस्ट_ से * का चयन करें) और उत्पादन (चयन करें * public.posts से) अलग से डेटा
2. संग्रह स्कीमा को अलग से डंप कर सकते हैं और उन पर आसान तरीके से कैस्केड छोड़ सकते हैं। pg_dump -s संग्रह_2005 datase_name ड्रॉप स्कीमा संग्रह_2005 झरना; - सावधान रहें क्योंकि यह सभी संबंधित तालिकाओं को हटा देता है
3. पुराने डेटा को टेबलस्पेस और तार्किक रूप से स्कीमा द्वारा शारीरिक रूप से अलग किया गया।
4. संग्रह प्रक्रिया को प्रबंधित करने के लिए काफी जटिल संरचना
5. दोनों (छोटे और विशेष अनुक्रमणिका = तेज़ क्वेरी और आवश्यक कम स्थान) के लिए क्वेरीज़ को अनुकूलित करने के लिए उत्पादन और संग्रह तालिकाओं पर अलग-अलग इंडेक्स बना सकते हैं)
6. यदि आपने टेबल (वर्ष या महीने के archive_tablespaceहिसाब से ) का विभाजन किया है, तो संग्रह प्रक्रिया पूरी तालिका को स्थानांतरित करने के लिए होगी या इसे पोस्ट_आर्काइव से विरासत में बदलने के लिए होगा (मैंने यह परीक्षण नहीं किया है)
7. यदि आप पुराने (संग्रहीत) डेटा का उपयोग नहीं करना चाहते हैं तो आपको आवेदन में कुछ भी नहीं बदलना होगा।

यह सामान्य तकनीक है और आपको इसे अपनी आवश्यकताओं के अनुकूल बनाना चाहिए। इसे बेहतर बनाने के लिए कोई सुझाव?

आगे पढ़ने: PostgreSQL विरासत , विभाजन

Comments

मैं दूसरा चरण स्पष्ट रूप से समझ नहीं पा रहा था Create tables (table posts example):। क्या आप इस बात की व्याख्या कर सकते हैं कि कुल कितने टेबल हैं और टेबल के बीच की विरासत एक दूसरे से किस प्रकार संबंधित है?

— ज्ञानम

संपादित उत्तर। मुझे उम्मीद है कि यह संग्रह को समझने और लागू करने के लिए पर्याप्त है।

— sufleR

वास्तविक समय के आवेदन में, माता-पिता / मास्टर टेबल के साथ एक से अधिक आश्रित / बच्चे टेबल जुड़े / संबंधित होंगे। तो यहां बताए गए चरण अपने सभी आश्रित / बच्चे के टेबल पर भी लागू होते हैं? क्या मेरी समझ सही है?

— ज्ञानम

हाँ। यह केवल एक तालिका उदाहरण है। मैंने इसे 100GB डेटाबेस में लागू किया है लेकिन केवल कुछ सबसे बड़ी तालिकाओं के लिए।

— sufleR

तो इस मामले में, जो तालिका सामान्य रूप से खाली हो जाएगा ( posts, posts-allया posts-archive), बस पूरे डेटा सेट का प्रतिनिधित्व करने के मौजूद है?

— ज्ञानम