शार्पिंग के बिना PostgreSQL पर 100 टेराबाइट्स डेटाबेस

Question

क्या नोड्स की संख्या के बीच डेटा शार्पिंग के बिना PostgreSQL पर 100 टीबी डेटाबेस (लगभग 90 टीबी वास्तव में) सेटअप करना यथार्थवादी है ? क्या समान सेटअपों के बारे में कोई सफलता की कहानियां / उदाहरण हैं?

Comments

मुझे लगता है कि यह आपके कार्यभार पर निर्भर करता है। डेटा कैसे वितरित किया जाता है, और इसे कैसे क्वेर किया जाएगा? आपको किस प्रकार के प्रतिक्रिया समय की आवश्यकता है?

— फ्रैंक किसान

खैर, लोड प्रोफ़ाइल को अक्सर आवेषण (लगभग 50K प्रति सेकंड चरम पर), अपेक्षाकृत शायद ही कभी चयन (उपयोगकर्ता और टाइमस्टैम्प द्वारा पंक्तियों की सीमा) के रूप में वर्णित किया जा सकता है। उपयोगकर्ता और दिनांक / टाइमस्टैम्प द्वारा डेटा को आसानी से विभाजित / विभाजन किया जा सकता है

Answer 1

50K प्रति सेकंड लिखता है जिसे अवशोषित करने की आवश्यकता आमतौर पर एक चुनौती से अधिक होती है। यहां तक ​​कि काफी सरल आवेषण के साथ सिंथेटिक बेंचमार्क में, PostgreSQL की सीमाएं लगभग 10 K / s के आसपास अधिकतम होती हैं - और वहां भी आपके पास डेटाबेस आकार के संदर्भ में इतना बड़ा जानवर नहीं है।

इसके अलावा उस एकल PostgreSQL नोड के लिए I / O सिस्टम भी दिलचस्प होने वाला है RAID 10 के साथ और यह मानते हुए कि 50K आवेषण सिर्फ 50K IOPS के बराबर होने जा रहे हैं (जो कि शायद गलत है, लेकिन यह आपकी डेटाबेस योजना और सूचकांकों पर निर्भर करता है ), आपको एक बहुत अच्छे सरणी के साथ लगभग सौ डिस्क की आवश्यकता होती है जो आपको कई सौ डिस्क खरीदने से बचाता है जो समयबद्ध तरीके से लिखते हैं।

अगर शार्डिंग आसान है और आप इतने बड़े राइट लोड की उम्मीद करते हैं तो शार्डिंग के लिए जाएं। लिखना बहुत कठिन हो सकता है।

Comments

इस बात से सहमत। यह एक ExaData प्रकार प्रणाली का डोमेन है। दुख की बात है, एसएसडी - ओटोह के साथ इन दिनों 50k IOPS प्राप्त करना काफी महंगा है। मैं हार्डवेयर के लिए यहां 7 अंकों के बड़े बजट की उम्मीद करूंगा, जिसमें एक मिड रेंज से लेकर हाई एंड सैन शामिल है।

— टॉमटॉम

हां, ExaData एक विकल्प है यदि आप "लंबवत एकीकृत समाधान स्टैक" पर जाना चाहते हैं, जो संभवतः मांगों को देखते हुए उतना बुरा नहीं है।

— pfo

हाँ। इस तरह के कुछ के लिए गंभीर फायदे हैं, दोनों, 100tb के साथ-साथ 50.000 iops वास्तव में "सस्ते" चिल्लाते नहीं हैं। एक्सडाटा क्या करता है - एसएसडी के साथ पूरी तरह से लोड होने पर 1 मिलियन आईओपीएस?

— टॉमटॉम

इन टिप्पणियों को जोड़ने के लिए मुझे लगता है कि आवेषण की मात्रा के साथ डेटा की उस मात्रा को प्राप्त करने के लिए आवश्यक बजट दिए जाने पर मुझे एक भुगतान-योग्य SQL इंजन का उपयोग करने के लिए लुभाया जाएगा, यह समग्र बजट का एक छोटा प्रतिशत होगा और आप 'बहुत बेहतर समर्थन होगा।

— चॉपर 3

में पूरी तरह से सहमत हूँ। एक पल के लिए आपका बजट SAN कई हजार वैल्यूएशन बदल देता है।

— टॉमटॉम

Answer 2

यह यथार्थवादी है और काम करेगा। प्रदर्शन बड़े पैमाने पर निर्भर करता है कि आपके पास कितनी रैम है। RAM जितनी बड़ी होगी, कैश उतना ही बड़ा होगा और PostgreSQL डिस्क को लोड करने से पहले डेटा को कैश कर सकता है।

PostgreSQL कैश को डेटा लिखेगा, और समय-समय पर कैश को ऑफलोड करेगा। तो प्रति सेकंड 50k INSERT का 50k IOPS में अनुवाद नहीं किया जाएगा। यह कम रास्ता होगा, क्योंकि यह एक साथ रिकॉर्ड को क्लस्टर करेगा और उन सभी को एक ही समय में लिख देगा।

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

मैंने एक बार 16GB सर्वर पर 400TB के साथ Oracle DB (Oracle 10g) पर काम किया था, केवल एक उदाहरण। डेटाबेस कार्यभार प्राथमिक INSERTs भी था, इसलिए प्रति दिन कुछ चयन और हर दिन लाखों INSERTs। प्रदर्शन समस्या बनने से बहुत दूर था।

Answer 3

100TB में आपके पास कुछ महत्वपूर्ण चुनौतियां हैं। यह आपके लिए काम करेगा या नहीं यह इस बात पर निर्भर करता है कि आप इन्हें कैसे संबोधित करना चाहते हैं।

1. लेखन भार को अवशोषित करने के लिए आपको पर्याप्त तरीके चाहिए। यह लिखने के भार पर निर्भर करता है। लेकिन पर्याप्त रूप से भयानक भंडारण के साथ इसे हल किया जा सकता है। वेग यहाँ एक बड़ी समस्या है। इसी तरह रीड एक्सेस को ध्यान से देखना होगा।

2. अधिकांश डेटाबेस में छोटी-छोटी तालिकाओं का एक समूह नहीं होता है, लेकिन अक्सर एक या दो वास्तव में बड़े होते हैं, जो db आकार के आधे तक हो सकते हैं। PostgreSQL में 32TB प्रति टेबल की हार्ड लिमिट है। उसके बाद पृष्ठ प्रकार से बाहर tid टाइप होता है। यह PostgreSQL के एक कस्टम बिल्ड या टेबल पार्टीशन द्वारा नियंत्रित किया जा सकता है, लेकिन यह एक गंभीर चुनौती है जिसे सबसे पहले संबोधित करने की आवश्यकता है।

3. PostgreSQL में वास्तविक सीमा होती है कि यह विभिन्न कार्यों के लिए कितनी रैम का उपयोग कर सकता है। इसलिए अधिक रैम होना एक निश्चित बिंदु से परे आपकी मदद कर सकता है या नहीं कर सकता है।

4. बैकअप .... इस पैमाने पर बैक अप दिलचस्प हैं। 60TB db जो मुझे पता है कि fs स्नैपशॉट बैकअप का उपयोग करना था और फिर संग्रह के लिए बरमान के बैकअप को नकली करना था। ये नकली बैकअप fs स्नैपशॉट बैकअप के लिए समीप थे। जैसा कि मैंने कहा "वे नकली बैकअप नहीं हैं। वे वैकल्पिक बैकअप हैं!"

इस सीमा तक पहुंचने वाले डेटाबेस वाले लोग हैं। मैं कम से कम एक व्यक्ति से मिला हूं, जिसने नीदरलैंड्स में एक बैंक के लिए काम किया था, जिसके पास 60TB पोस्टग्रेक्यूएल डेटाबेस था। हालाँकि यह वास्तव में, वास्तव में आपके कार्यभार और आकार पर निर्भर करता है, समस्या नहीं है।