यह संख्या उतनी नहीं है जितनी आप सोचते हैं। वर्तमान कार्य में हम वेबसाइटों के लिए मीट्रिक डेटा संग्रहीत करते हैं और हमारे पास कुल पंक्तियों की मात्रा बहुत अधिक है। और पिछली नौकरी में मैंने पीजी डेटाबेस के साथ काम किया जो मोबाइल नेटवर्क से मेट्रिक्स एकत्र करता था और यह प्रति दिन ~ 2 बिलियन रिकॉर्ड एकत्र करता था। तो रिकॉर्ड की संख्या में अरबों से डरो मत।
आपको निश्चित रूप से डेटा को विभाजित करने की आवश्यकता होगी - शायद दिन के हिसाब से। इस मात्रा में डेटा के साथ आप इंडेक्स को काफी बेकार पा सकते हैं। उन विमानों पर निर्भर करता है जिन्हें आप EXPLAIN . में देखेंगे कमांड आउटपुट। उदाहरण के लिए, टेल्को ऐप ने किसी भी इंडेक्स का उपयोग बिल्कुल नहीं किया क्योंकि वे पूरे इंजन को धीमा कर देंगे।
एक अन्य प्रश्न यह है कि प्रश्नों के लिए आपको कितनी त्वरित प्रतिक्रिया की आवश्यकता होगी। और प्रश्नों के लिए ग्रैन्युलैरिटी (घंटों/दिनों/सप्ताह आदि से अधिक) में कौन से चरण आप उपयोगकर्ताओं के लिए अनुमति देंगे। आपको सप्ताह या महीने या तिमाही जैसी ग्रैन्युलैरिटी के लिए कुछ एकत्रीकरण करने की भी आवश्यकता हो सकती है।
अतिरिक्त:
उस टेल्को ऐप में प्रति दिन ~ 2 बिलियन रिकॉर्ड प्रति दिन ~ 290GB लेते थे। और इसका मतलब था COPY कमांड के साथ बल्क इंसर्ट का उपयोग करके प्रति सेकंड ~ 23000 रिकॉर्ड का इंसर्ट। प्रत्येक थोक कई हजारों रिकॉर्ड था। कच्चे डेटा को मिनटों में विभाजित किया गया था। डिस्क प्रतीक्षा से बचने के लिए डीबी के पास 4 अलग-अलग डिस्क/सरणी पर 4 टेबल स्पेस थे और उन पर विभाजन वितरित किए गए थे। PostreSQL बिना किसी समस्या के यह सब संभालने में सक्षम था। तो आपको उचित HW कॉन्फ़िगरेशन के बारे में भी सोचना चाहिए।
अच्छा विचार यह भी है कि pg_xlog निर्देशिका को डिस्क या सरणी को अलग करने के लिए स्थानांतरित किया जाए। नहीं बस अलग फाइल सिस्टम। यह सब अलग एचडब्ल्यू होना चाहिए। SSDs मैं केवल उचित त्रुटि जाँच के साथ सरणियों में अनुशंसा कर सकता हूँ। हाल ही में हमें सिंगल एसएसडी पर दूषित डेटाबेस की समस्या थी।
