एक नए डेटाबेस डिज़ाइन के साथ काम करते समय चुनौतियों में से एक यह है कि आप चीजों को नहीं जानते हैं कि टेबल कितनी बड़ी हो जाएगी जब तक कि वे वास्तव में उचित मात्रा में डेटा के साथ पॉप्युलेट नहीं हो जाते। लेकिन अगर डिज़ाइन को अंतिम मापनीयता संबंधी चिंताओं को ध्यान में रखना है, तो आप अनुमान लगाने तक उस डेटा को प्राप्त करने के लिए इसे तैनात नहीं कर सकते। इसका एक तरीका आक्रामक तरीके से चीजों को प्रोटोटाइप करना है। इस उद्देश्य के लिए स्टेजिंग हार्डवेयर का उपयोग करें कि नए एप्लिकेशन इस तरह के विवरणों को छांटते समय अस्थायी रूप से जीवित रह सकें। आप बस इस बात पर ध्यान दे सकते हैं कि आपको ऐप को स्थानांतरित करने की आवश्यकता होगी और संभवत:कुछ महीनों के बाद इसे फिर से डिज़ाइन करना होगा, जब आपके पास एक बेहतर विचार हो कि इसमें कौन सा डेटा दिखाई देने वाला है।
इस चिकन/अंडे की समस्या को हल करने का दूसरा तरीका डेटा जनरेटर लिखना है। यह देखने के लिए कि यह कैसा दिखता है, कितना सघन है, और इसके मूल्यों को कैसे वितरित किया जाता है, यह देखने के लिए हाथ से पर्याप्त नमूना डेटा तैयार करें। फिर कुछ ऐसा लिखें जो उन आँकड़ों को लेता है और उसके समान एक बड़ा डेटा सेट तैयार करता है। आप इसे कभी भी पूर्ण नहीं पाएंगे, लेकिन यह होना जरूरी नहीं है। कुछ कमियों के साथ भी विशाल डेटा सेट बनाना, अभी भी डेटाबेस आकार का अनुमान लगाने का सबसे अच्छा तरीका है। ओवरहेड के इतने सारे स्रोत हैं कि इसका हिसाब देना मुश्किल है कि आपके डेटा जैसी किसी चीज़ के आधार पर कोई भी मापी गई तालिका और सूचकांक आकार, किसी भी अन्य दृष्टिकोण की तुलना में अधिक सटीक होने जा रहा है। एक कारण है कि मैं पहले उपयुक्त आकार का डेटाबेस बनाने के लिए pgbench का उपयोग करके प्रदर्शन संबंधी चिंताओं के बारे में कई सवालों के जवाब देता हूं।
हालांकि डेटा जनरेशन आसान नहीं है। विशेष रूप से यथार्थवादी टाइमस्टैम्प उत्पन्न करना हमेशा कष्टप्रद होता है। और इससे कोई फर्क नहीं पड़ता कि आपने उन्हें कितनी कुशलता से लिखा है, वे आमतौर पर आपके चलने की अपेक्षा से अधिक समय लेते हैं-और परिणामी डेटा को डेटाबेस में लाने और ठीक से अनुक्रमित करने में भी अधिक समय लेते हैं।
और यह अभी भी जारी है, चाहे आपने इसे कितनी भी बार किया हो, क्योंकि भले ही आप सब कुछ सही करते हैं, मर्फी का नियम काम को दर्दनाक बनाने के लिए दखल देगा। मेरे घर पर सभी कंप्यूटर अपेक्षाकृत सस्ते पीसी हार्डवेयर से बनाए गए हैं। सबसे सस्ता सामान उपलब्ध नहीं है - मेरे पास मानक हैं - लेकिन निश्चित रूप से उसी गुणवत्ता का उपयोग नहीं कर रहे हैं जो मैं लोगों को सर्वर में देखने की सलाह दूंगा। इस सप्ताह की डेटा पीढ़ी की समस्या ने याद दिलाया कि बेहतर हार्डवेयर का मूल्य व्यवसाय के महत्वपूर्ण कार्य के लिए कितना खर्च होता है।
डेटा की कुछ अरब पंक्तियाँ बनाने और उस आयात को 10 घंटे तक देखने के बाद, मैं इस तरह पूरी नौकरी को रद्द करने से खुश नहीं था:
psql:load.sql:10: ERROR: invalid input syntax for type timestamp: "201^Q-04-14 12:17:55"
CONTEXT: COPY testdata, line 181782001, column some_timestamp: "201^Q-04-14 12:17:55"
पता चला, मेरे द्वारा जेनरेट किए गए 250GB परीक्षण डेटा को लिखने के बीच में, लाइनों में से एक आउटपुट दूषित हो गया था। दो बिट फ़्लिप हो गए, और लिखा गया डेटा गलत था। मुझे नहीं पता कि यह कहां हुआ था।
स्मृति सबसे अधिक संदिग्ध है। वास्तविक सर्वर ईसीसी रैम का उपयोग करते हैं, और अच्छे कारण के लिए। यदि आप बहुत अधिक RAM वाले सिस्टम की निगरानी करते हैं, तो ECC द्वारा चुपचाप ठीक की गई त्रुटियों की संख्या चौंकाने वाली हो सकती है। मैं घर पर जिस रैम का उपयोग करता हूं वह अच्छी है, लेकिन त्रुटि का पता लगाने / सुधार क्षमताओं के बिना किसी भी मेमोरी पर त्रुटि दर आपकी पसंद से अधिक होने वाली है - और जब तक वे कोड में नहीं होते हैं जो सिस्टम क्रैश की ओर जाता है, तब तक इसका पता नहीं चलता। डेटा जनरेशन का काम इन समस्याओं को उजागर करने में अच्छा है, क्योंकि यह आम तौर पर आपके सर्वर पर कम से कम एक सीपीयू को संभावित दिनों के लिए भारी लोड के तहत रखता है। यदि आपके सिस्टम में कोई अस्थिरता है, तो सिस्टम को गर्म करना और इसे लंबे समय तक चलने देना इसे और बढ़ा देगा।
इस तरह के भ्रष्टाचार के खिलाफ सुरक्षा की दूसरी परत डिस्क पर लिखे जा रहे डेटा पर चेकसम लगाना, त्रुटियों को लिखने और फिर डेटा को फिर से पढ़ने से बचाने के लिए है। ZFS फाइल सिस्टम द्वारा किया गया ब्लॉक चेकसमिंग उसी के बेहतर कार्यान्वयन में से एक है। मेरे मामले में, मैंने ZFS का उपयोग किया है या नहीं, इससे कोई फर्क नहीं पड़ता। यदि ब्लॉक चेकसम होने से पहले बिट्स फ़्लिप हो गए, तो मैंने जंक डेटा को बाहर लिखा होगा-इससे मेल खाने के लिए जंक चेकसम के साथ-चाहे।
मेरा अगला कदम विभाजन . का उपयोग करना था मेरी विशाल फ़ाइल को लेने और इसे और अधिक काटने के आकार के टुकड़ों में तोड़ने के लिए उपयोगिता - इसके समाप्त होने की प्रतीक्षा करने के लिए कुछ और घंटे। तब मैं खराब फ़ाइलों को ठीक करते हुए अच्छी फ़ाइलों को लोड करना शुरू कर सकता था।
यह देखते हुए कि परिणामी फाइलें 13GB थीं और मेरे एक सर्वर में 16GB RAM है, हालाँकि मैं vi का उपयोग करके इस एक वर्ण टाइपो को ठीक कर सकता था। सैद्धांतिक रूप से ऐसा होना चाहिए, लेकिन मुझे अपने संदेह होने लगे हैं कि मैं कितने समय से फाइल के बाद में फिर से लिखने का इंतजार कर रहा हूं:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21495 gsmith 20 0 8542m 8.3g 1544 R 98 53.0 419:56.70 vi datafile-ag
यह एक ठोस 7 घंटे है जिसका मैं बस इस एक वर्ण टाइपो के ठीक होने की प्रतीक्षा कर रहा था, इसलिए मैं परीक्षण डेटा लोड करना समाप्त कर सकता हूं। जैसा मैं कह रहा था, गंभीर डेटा जनरेशन कभी आसान नहीं होता।
