SQL सर्वर डेटाबेस में निरर्थक अनुक्रमणिका की पहचान करने की प्रक्रिया में क्रांति लाना

अनावश्यक सूचकांक
सूचकांक जो किसी अन्य सूचकांक या अनुक्रमितों के सेट की उपस्थिति के कारण बेकार और अनावश्यक हो जाता है।

क्या आपने कभी यह कहावत सुनी है कि "बहुत अच्छी चीज भी बुरी हो सकती है"? खैर, यह SQL सर्वर इंडेक्स पर भी लागू होता है। मेरा मतलब है, निश्चित रूप से, आप जितने चाहें उतने गैर-क्लस्टर इंडेक्स बना सकते हैं, लेकिन आप ऐसा क्यों करेंगे? यह कोलोन की दस परतें पहनकर अपने क्रश को प्रभावित करने की कोशिश करने जैसा है - यह काम नहीं करेगा और यह सिर्फ चीजों को बदतर बना देता है।

दोहरी मुसीबत

SQL सर्वर में डुप्लिकेट इंडेक्स के खतरे

SQL सर्वर में, उसी ऑब्जेक्ट पर डुप्लिकेट इंडेक्स बनाना संभव है। जबकि अनुक्रमणिका कुंजियों से गुणों तक सब कुछ समान हो सकता है, यह अभ्यास कई कमियों के साथ आता है।

1. डुप्लिकेट इंडेक्स अतिरिक्त स्टोरेज स्पेस लेते हैं। और कीमती भंडारण स्थान को बर्बाद करना किसे पसंद है? हमें नहीं! एक इंडेक्स रिडंडेंसी एनालिसिस (अनावश्यक इंडेक्स के विश्लेषण के लिए फैंसी शब्द) करके, हम अनावश्यक इंडेक्स की पहचान करने और लगभग 10% स्टोरेज स्पेस को बचाने में सक्षम थे। यह आपके 4TB डेटाबेस में छिपे हुए 400GB खजाने को खोजने जैसा है!
2. अनावश्यक इंडेक्स डीएमएल स्टेटमेंट (डेटा डालने, अपडेट करने, हटाने) को धीमा कर सकते हैं। हर बार बदलाव करने पर एक ही इंडेक्स की कई प्रतियों को अपडेट करने की कल्पना करें। टाइम-वेस्टर के बारे में बात करें! लेकिन डरें नहीं, निरर्थक इंडेक्स को हटाने से प्रदर्शन में सुधार हो सकता है और आपके डेटाबेस को अविश्वसनीय हल्क जैसा महसूस हो सकता है। साथ ही, आप CPU कोर पर पैसा बचा सकते हैं जिसे आप कम कर सकते हैं।
3. इंडेक्स को पुनर्निर्माण या पुनर्गठित करना डुप्लिकेट इंडेक्स के साथ वास्तविक दर्द हो सकता है। निरर्थक अनुक्रमणिका से छुटकारा पाकर, आप इस प्रक्रिया को तेज़ कर सकते हैं और अधिक महत्वपूर्ण चीज़ों पर वापस जा सकते हैं (जैसे अपना पसंदीदा शो द्वि घातुमान देखना)।
4. एक ही वस्तु पर एकाधिक अनुक्रमणिका होने से क्वेरी ऑप्टिमाइज़र के लिए अपना काम करना अधिक कठिन हो सकता है। और कोई भी सनकी अनुकूलक नहीं चाहता है! अपनी अनुक्रमणिका को सरल बनाकर, आप ऑप्टिमाइज़र के जीवन को आसान बना सकते हैं और क्वेरी प्रदर्शन में सुधार कर सकते हैं।

SQL सर्वर में अनुक्रमणिका दुविधा

सूचकांकों को बेमानी माना जा सकता है, भले ही वे समान न हों। इंडेक्स में, कॉलम को दो श्रेणियों में विभाजित किया जाता है: इंडेक्स कॉलम और कॉलम शामिल करें।

अपने इंडेक्स के साथ जेंगा न खेलें: ऑर्डर क्यों मायने रखता है!

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

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

निरर्थक सूचकांकों का वर्गीकरण

निरर्थक सूचकांक तीन प्रकार के होते हैं:

• डुप्लिकेट इंडेक्स: दो इंडेक्स में एक ही क्रम में समान कुंजी कॉलम होते हैं (यानी समान इंडेक्स) जिसमें कॉलम शामिल होते हैं। ऐसा इसलिए है क्योंकि कॉलम शामिल करने का क्रम मायने नहीं रखता।
  उदाहरण: दोनों इंडेक्स में समान कुंजी कॉलम "कॉलमए" और "कॉलमबी" समान क्रम में हैं और समान गैर-कुंजी कॉलम "कॉलमसी" और "कॉलमडी" शामिल हैं, जिससे वे डुप्लिकेट इंडेक्स बनाते हैं।
  CREATE INDEX idx1 ON MyTable (ColumnA, ColumnB) INCLUDE (ColumnC, ColumnD);
CREATE INDEX idx2 ON MyTable (ColumnA, ColumnB) INCLUDE (ColumnD, ColumnC);


• ओवरलैपिंग इंडेक्स: एक इंडेक्स में कुंजी कॉलम होते हैं जो किसी अन्य इंडेक्स के कुंजी कॉलम के बाएं क्रम वाले सबसेट बनाते हैं और अन्य इंडेक्स के गैर-कुंजी कॉलम के गैर-कुंजी कॉलम सबसेट ओवरलैपिंग इंडेक्स होते हैं। ओवरलैपिंग इंडेक्स में प्रमुख कॉलम बाएं क्रम में होने चाहिए, जिसका अर्थ है कि वे घटते महत्व के क्रम में सूचीबद्ध हैं, जिसमें सबसे महत्वपूर्ण कॉलम पहले दिखाई देता है। ऐसा इसलिए है क्योंकि SQL सर्वर किसी श्रेणी स्कैन के लिए अनुक्रमणिका का उपयोग केवल तभी कर सकता है जब सबसे बाएँ स्तंभ निर्दिष्ट किया गया हो, और उसके बाद केवल तभी जब अगला बाएँ स्तंभ निर्दिष्ट किया गया हो, और इसी तरह आगे भी।
  उदाहरण: इस उदाहरण में, इंडेक्स "idx1" में प्रमुख कॉलम "कॉलमए" और "कॉलमबी" हैं, जो इंडेक्स "आईडीएक्स2" में प्रमुख कॉलम "कॉलमए", "कॉलमबी" का बायां सबसेट है। इसलिए, "idx2" "idx1" को ओवरलैप करता है और ये दो इंडेक्स ओवरलैपिंग इंडेक्स हैं।
  CREATE INDEX idx1 ON MyTable (ColumnA, ColumnB) INCLUDE (ColumnX, ColumnY);
CREATE INDEX idx2 ON MyTable (ColumnA, ColumnB, ColumnD) INCLUDE (ColumnX, ColumnY, ColumnZ);


• समान अनुक्रमणिका: अनुक्रमणिका जिसमें एक ही क्रम में समान कुंजी कॉलम होते हैं, लेकिन अलग-अलग कॉलम शामिल होते हैं। समान अनुक्रमणिकाओं को हल करने के लिए, एक अनुक्रमणिका को अद्यतन किया जाना चाहिए ताकि दोनों अनावश्यक अनुक्रमितों के कॉलम शामिल किए जा सकें।
  उदाहरण: सॉल्यूशन इंडेक्स: इस उदाहरण में, इंडेक्स "idx2" में प्रमुख कॉलम "कॉलमए" और "कॉलमबी" हैं, जो "आईडीएक्स1" के समान है। शामिल कॉलम हालांकि अलग हैं, और परिणामी इंडेक्स में कॉलम शामिल होना चाहिए क्योंकि दोनों इंडेक्स के अलग-अलग संघ में कॉलम शामिल हैं।
  CREATE INDEX idx1 ON MyTable (ColumnA, ColumnB) INCLUDE (ColumnX, ColumnY);
CREATE INDEX idx2 ON MyTable (ColumnA, ColumnB) INCLUDE (ColumnP, ColumnQ);

CREATE INDEX idx1 ON MyTable (ColumnA, ColumnB) INCLUDE (ColumnX, ColumnY, ColumnP, ColumnQ);


SQL सर्वर में दक्षता के लिए शिकार

जैसा कि हमने SQL सर्वर डेटाबेस की रहस्यमय दुनिया में गहराई से प्रवेश किया, हमने एक अजीब घटना की खोज की - अप्रयुक्त अनुक्रमणिका! ये इंडेक्स अतीत के डेटाबेस के भूत की तरह थे, जो हमारे स्टोरेज को परेशान कर रहे थे और अनावश्यक इंडेक्स अपडेट के साथ हमारी कीमती कंप्यूटिंग शक्ति को हड़प रहे थे।

हमने अपने बड़े डेटाबेस के साथ कुछ गंभीर मुद्दों पर ध्यान दिया है - हमारे सीपीयू और डेटा आईओ अक्सर बढ़ रहे थे, जो एक स्वस्थ डेटाबेस के लिए अच्छा संकेत नहीं है। अपराधी मुख्य रूप से परेशान करने वाले प्रश्न थे, लेकिन कुछ मामलों में, प्रश्न पूरी तरह से निर्दोष लग रहे थे और अनुक्रमणिका ठीक दिख रही थी। गहराई से गोता लगाने के बाद, हमने पाया कि वास्तविक समस्या प्राथमिक स्तंभों पर कई अप्रयुक्त अनुक्रमणिकाएँ थीं। ये निरर्थक अनुक्रमणिका अत्यधिक मात्रा में अद्यतनों का कारण बन रही थीं और कई क्वेरी योजनाएँ बना रही थीं, इस प्रकार हमारे डेटाबेस के प्रदर्शन पर कहर ढा रही थी।

इसलिए, हमने एक-एक करके इन निरर्थक अनुक्रमणिकाओं को हटाने के लिए अपनी खोज शुरू की। लेकिन अफसोस, निरर्थक इंडेक्स को हटाने की प्रक्रिया एक वास्तविक स्नूज़-फेस्ट बन गई। एक डेटाबेस व्यवस्थापक के रूप में, निरर्थक अनुक्रमितों का शिकार करना वाल्डो कहां है का वास्तविक जीवन का खेल खेलने जैसा है। आपको एसक्यूएल स्क्रिप्ट्स के समुद्र के माध्यम से झारना है, एक स्क्रिप्ट को निष्पादित करना है जो सभी इंडेक्स और उनके अनुक्रमित और शामिल कॉलम सूचीबद्ध करता है, और फिर अनावश्यक इंडेक्स की पहचान करने के लिए प्रत्येक व्यक्तिगत इंडेक्स के माध्यम से कंघी करता है। विडंबना हम पर नहीं पड़ी है - हम अविश्वसनीय रूप से अक्षम कुछ करके डेटाबेस दक्षता को बढ़ावा देने की कोशिश कर रहे हैं। और जब आपको लगता है कि आपने निरर्थक इंडेक्स की पहचान कर ली है, तब भी आपको उन्हें एक-एक करके हटाना होगा, जिससे आप अपने करियर की पसंद का दूसरा अनुमान लगा सकते हैं और अपने लैपटॉप में बीच चेयर और पिना कोलाडा के लिए ट्रेडिंग करने का सपना देख सकते हैं।

और ओह लड़के, हम एक इलाज के लिए थे - पता चला कि हमारी डेटाबेस समस्याएं अभी शुरू हो रही थीं! हमें पता चला कि हमारे प्रिय डीबीए के लिए प्राथमिकताओं की सूची में बेकार इंडेक्स से छुटकारा पाना बहुत कम था। यह उन्हें अपने प्रिय कैफीन फिक्स को छोड़ने की कोशिश करने जैसा था - लगभग असंभव! लेकिन हमें पता था कि अगर हम अपने डेटाबेस की समस्याओं को ठीक करने की कोई उम्मीद रखना चाहते हैं तो हमें प्रक्रिया को और अधिक कुशल बनाना होगा।

लेकिन डरो मत, क्योंकि हमने अपने भरोसेमंद साथी, स्नोर्कल को याद किया! इसकी मदद से, हमने एक सुपरचार्ज्ड ऑप्टिमाइज़ेशन मेट्रिक — इंडेक्स रिडंडेंसी मेट्रिक बनाया। इस आसान उपकरण के लिए धन्यवाद, हम प्रक्रिया को सुव्यवस्थित करने और कुछ ही समय में उन बेकार इंडेक्स से छुटकारा पाने में सक्षम थे। इस बुरे लड़के ने इतनी तेजी से डीबीए बनाया, वे एक चीता को एक सुस्ती की तरह बना सकते थे।

स्नोर्कल क्या है?

बॉस की तरह डेटाबेस का निदान!

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

लेकिन इतना ही नहीं है — Snorql अप्रयुक्त तालिकाओं और अप्रयुक्त अनुक्रमणिकाओं की भी पहचान करता है, जिससे आपको संभावित स्थान बचत के बारे में और भी अधिक जानकारी मिलती है। Snorql के ऑप्टिमाइज़ेशन मेट्रिक्स के साथ, आप आत्मविश्वास से सूचित निर्णय ले सकते हैं कि कौन से इंडेक्स और टेबल को हटाना है, अव्यवस्था को कम करना और अपने डेटाबेस में संगठन में सुधार करना।

स्नोर्कल रिपॉजिटरी:
1. स्नोर्कल (ढांचा): https://github.com/udaan-com/snorql
2. स्नोर्कल-फ्रंटेंड: https://github.com/udaan-com/snorql-frontend

यदि आपको और समझाने की आवश्यकता है, तो शानदार लेख स्नोर्कल को देखना सुनिश्चित करें - एक बॉस की तरह डेटाबेस का निदान

इंडेक्सिंग फोलीज

डेटाबेस दक्षता की खोज में सीखा गया पाठ

निरर्थक इंडेक्स से निपटने के लिए, हम अपने इंडेक्स को वर्गीकृत करने के लिए एक एल्गोरिथम लेकर आए। काफी सरल लगता है, है ना? बस तुलना करें और कंट्रास्ट करें, और वॉइला - अप्रयुक्त, डुप्लिकेट, ओवरलैपिंग और समान इंडेक्स बड़े करीने से सॉर्ट किए जाएंगे। लेकिन अपने घोड़ों को पकड़ो, मेरे दोस्त - यह पार्क में टहलना नहीं था! हमारे मीट्रिक को पूर्ण करने में कई पुनरावृत्तियों का समय लगा, और हमें रास्ते में मूल्यवान अंतर्दृष्टि प्राप्त हुई।

1. पार्टी के लिए रीड-रेप्लिका और जियो-रेप्लिका डेटाबेस को आमंत्रित करना:
   हमने महसूस किया कि सिर्फ इसलिए कि प्राथमिक डेटाबेस में एक इंडेक्स मौजूद है, इसका मतलब यह नहीं है कि इसे रीड-रेप्लिका और जियो-रेप्लिका इंस्टेंसेस में उसी तरह से व्यवहार किया जा रहा है। और चीजों को और भी जटिल बनाने के लिए, रीड-रेप्लिका या जियो-रेप्लिका डेटाबेस में अत्यधिक उपयोग किए जा रहे इंडेक्स को प्राथमिक डेटाबेस में अप्रयुक्त इंडेक्स के रूप में चिह्नित किया जा सकता है। इसलिए, हमारे सूचकांक वर्गीकरण एल्गोरिथम के लिए सटीक आँकड़े प्राप्त करने के लिए, हमें सभी उदाहरणों में सूचकांक उपयोग और सूचकांक अद्यतन दोनों को इकट्ठा और सारांशित करना था।
2. यह सुनिश्चित करना कि अद्वितीय इंडेक्स पार्टी में बने रहें:
   तो, यहाँ सौदा है - अद्वितीय इंडेक्स और UNIQUE बाधाएँ भाई-बहन की तरह हैं जो उसी तरह विशिष्टता को लागू करती हैं। जब आप एक अद्वितीय बाधा बनाते हैं, तो SQL सर्वर एक जादूगर की तरह होता है जो पतली हवा से एक अद्वितीय अनुक्रमणिका बनाता है। और इस टोने-टोटके के कारण, आप सीधे डेटाबेस से अद्वितीय अनुक्रमणिका को नहीं छोड़ सकते। इसलिए, किसी भी दुर्घटना से बचने के लिए, हमें अपने वर्गीकरण एल्गोरिथम से अद्वितीय अनुक्रमणिका को बाहर करना पड़ा।
3. UX कैसे न करें:
   हमारे इंडेक्स रिडंडेंसी एनालिसिस के पहले संस्करण में, हमने इंडेक्स स्तर पर अनावश्यक इंडेक्स को समूहीकृत करने की कोशिश की। इसने संपूर्ण तालिका को देखे बिना पैरेंट और चाइल्ड इंडेक्स के बीच संबंधों को समझना कठिन बना दिया। साथ ही, हमने जो एल्गोरिदम विकसित किया वह 3डी शतरंज के खेल जितना जटिल था, और हमें जल्दी ही एहसास हुआ कि यह जाने का रास्ता नहीं था।

5. समान इंडेक्स को कैसे संभालें
तो, कल्पना करें कि आपके दो दोस्त हैं जो एक जैसे दिखते हैं, लेकिन उनमें से एक के पास एक शानदार टोपी है और दूसरे के पास एक शानदार चश्मा है। वे समान इंडेक्स की तरह हैं - अनुक्रमित कॉलम के लिए डुप्लिकेट या ओवरलैपिंग, लेकिन अलग-अलग कॉलम शामिल हैं। लेकिन यहाँ पकड़ है - आप कुछ गंभीर प्रदर्शन मुद्दों को पैदा किए बिना उन्हें जूतों की एक जोड़ी की तरह स्वैप नहीं कर सकते। उन्हें हटाना भी जवाब नहीं है - यह आपके किसी मित्र के साथ सिर्फ इसलिए संबंध तोड़ने जैसा है क्योंकि उन दोनों का नाम एक ही है! सबसे अच्छा तरीका यह है कि दोनों में से सभी कॉलम शामिल करने के लिए किसी एक इंडेक्स को अपडेट किया जाए, और फिर दूसरे को अलविदा कह दिया जाए। इस तरह, हम समान अनुक्रमणिकाओं पर बचत कर सकते हैं और अपने डेटाबेस मित्रों के बीच शांति बनाए रख सकते हैं।

ठीक है दोस्तों, यह हमारी आस्तीनें चढ़ाने और नीचे उतरने और गंदे होने का समय है! हमने उन परेशान करने वाले एज मामलों की पहचान कर ली है, और अब समय आ गया है कि कार्यान्वयन के चरण में सबसे पहले गोता लगाया जाए।

तो, कौन अपने हाथ गंदे करने के लिए तैयार है? चलो यह काम करते हैं!

इंडेक्स रिडंडेंसी मेट्रिक में गोता लगाना

इसके पीछे जादूगर पर ध्यान केंद्रित करने का समय है, एल्गोरिथम!

नोट: अनुक्रमणिका अतिरेक विश्लेषण वर्तमान में SQL सर्वर डेटाबेस के लिए उपलब्ध है, और कार्यान्वयन इस डेटाबेस सिस्टम के लिए विशिष्ट है।

Github अंक ✅ #79 नई मीट्रिक — अनुक्रमणिका अतिरेक मीट्रिक Github PR ⛓ #84 [नई मीट्रिक] अनुक्रमणिका अतिरेक मीट्रिक

मैंने एल्गोरिदम को चरणों में तोड़ दिया है:

1. नीचे दी गई sql क्वेरी का उपयोग करके डेटाबेस में सभी इंडेक्स का विस्तृत डेटा प्राप्त करें

3. तालिका द्वारा समूह अनुक्रमित करें, और प्रत्येक तालिका पर पुनरावृति करें, उन अनुक्रमणिकाओं को फ़िल्टर करें जिनके name == NULLढेर अनुक्रमणिका को फ़िल्टर करना है, और अनुक्रमित स्तंभों की संख्या के आधार पर अवरोही क्रम में क्रमबद्ध करें।
हम उन अनुक्रमणिकाओं की एक सूची भी बनाए रखते हैं जिन्हें छोड़ा जाना है। इनमें वे इंडेक्स शामिल हैं जो पहले से ही वर्गीकृत या अद्वितीय इंडेक्स हैं।

4. अप्रयुक्त इंडेक्स की पहचान करें। यहां, यदि उपयोग 10 से कम है तो हम इसे अप्रयुक्त इंडेक्स मानते हैं। हमने यह छोटी सीमा इसलिए रखी है क्योंकि यह संभव हो सकता है कि एड-हॉक क्वेरी चलाते समय एक इंडेक्स का उपयोग किया जाए।

5. अद्वितीय अनुक्रमणिका की पहचान करना। विशिष्टता बनाए रखने के लिए जानबूझकर कॉलम पर अद्वितीय इंडेक्स बनाए जाते हैं, इसलिए हम इन्हें विश्लेषण में वर्गीकृत करना छोड़ देते हैं। हम बेहतर विश्लेषण और दृश्यता के लिए तालिका स्तर पर अद्वितीय अनुक्रमणिका दिखाते हैं।

6. इसे पोस्ट करें, हम प्रत्येक इंडेक्स पर पुनरावृति करते हैं, और अनावश्यक इंडेक्स खोजने के लिए इसका विश्लेषण करते हैं

एक। डुप्लीकेट इंडेक्स को वर्गीकृत करें:
डुप्लीकेट इंडेक्स को वर्गीकृत करना सीधा है। अनुक्रमित कॉलम और शामिल कॉलम समान होने चाहिए और अनुक्रमणिका कॉलम समान क्रम में होने चाहिए

बी। ओवरलैपिंग इंडेक्स को वर्गीकृत करें:
चाइल्ड इंडेक्स इंडेक्सेड कॉलम उसी क्रम में पैरेंट इंडेक्स किए गए कॉलम का लेफ्ट आधारित सबसेट होना चाहिए, और शामिल कॉलम समान होना चाहिए।

सी। समान अनुक्रमणिका वर्गीकृत करें:
अनुक्रमित कॉलम समान होने चाहिए, जबकि शामिल कॉलम भिन्न हो सकते हैं

इससे क्या उड़ान मिली?

अधिक बचत, कम तनाव, और खुशहाल DBA!

पता चलता है कि इंडेक्स रिडंडेंसी एनालिसिस सिर्फ डीबीए के लिए ही नहीं, बल्कि पूरे संगठन के लिए एक ट्रीट था। डींग मारने के लिए हमारे पास कुछ रसदार लाभ हैं:

1. चा चिंग! हमने बिना किसी प्रदर्शन बाधा के अपने डेटाबेस का आकार घटाकर कुछ रुपये बचाए। हमारे शीर्ष डेटाबेस की गणना औसतन 8% और भंडारण में 10% की गिरावट आई है। उदाहरण के लिए, हमने 32 vCore डेटाबेस को घटाकर 24 vCore डेटाबेस कर दिया, और बाम, हमने लागत पर 22% की बचत की! वैसे भी उन सभी अतिरिक्त कोर की जरूरत किसे है?

3. डीबीए चांद पर हैं। हमने यह भी सुना है कि वे स्क्रीन पर खुले इंडेक्स रिडंडेंसी मेट्रिक के साथ अपने मॉनिटर को चूम रहे हैं। अरे, हम न्याय नहीं कर रहे हैं - अगर उन्हें खुश करने के लिए यही है, तो ऐसा ही हो!