क्या SSDs डेटाबेस की उपयोगिता को कम करते हैं


28

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

मैं आज (सॉफ्टवेयर आर्किटेक्चर पर) एक वीडियो देख रहा था , रॉबर्ट सी। मार्टिन की एक बातचीत पर, और वीडियो के उत्तरार्ध में, डेटाबेस का विषय मुख्य फोकस था।

उन्होंने जो कहा, उसकी मेरी समझ से ऐसा लग रहा था कि वह कह रहे हैं कि एसएसडी डेटाबेस की उपयोगिता ( काफी कम ) कर देगा।

यह समझाने के लिए कि मैं इस व्याख्या पर कैसे आया:

उन्होंने चर्चा की कि कैसे HDDs / कताई डिस्क के साथ, डेटा को पुनः प्राप्त करना धीमा है। हालांकि, इन दिनों हम एसएसडी का उपयोग करते हैं, उन्होंने कहा। वह "रैम आ रहा है" से शुरू होता है और फिर रैम डिस्क का उल्लेख करके जारी रहता है, लेकिन फिर वह कहता है कि इसे रैम डिस्क नहीं कहा जा सकता है, इसलिए केवल रैम कहने के लिए रिसॉर्ट्स। इसलिए RAM के साथ, हमें अनुक्रमित की आवश्यकता नहीं है, क्योंकि प्रत्येक बाइट को प्राप्त करने के लिए समान समय लगता है। ( यह पैराग्राफ मेरे द्वारा लिखा गया है )

इसलिए, वह डीबी के लिए एक प्रतिस्थापन के रूप में रैम (कंप्यूटर मेमोरी में) का सुझाव दे रहा है (जैसा कि मैंने उसके बयान की व्याख्या की है) इसका कोई मतलब नहीं है क्योंकि यह कहने जैसा है कि सभी रिकॉर्ड एक एप्लिकेशन के जीवनकाल में संसाधित मेमोरी हैं ( जब तक आप डिमांड पर डिस्क फ़ाइल से नहीं खींचते)

इसलिए, मैंने रैम द्वारा सोच का सहारा लिया, उसका मतलब है एसएसडी। तो, उस स्थिति में, वह कह रहा है कि SSDs डेटाबेस की उपयोगिता को कम करते हैं। वह यहां तक ​​कहते हैं, "अगर मैं ओरेकल था, तो मैं डर गया होगा। मेरे अस्तित्व का बहुत आधार वाष्पीकरण है।"

SSDs की मेरी थोड़ी समझ से, HDDs के विपरीत, जो O(n)समय की तलाश में हैं (मुझे लगता है), SSDs पास हैं O(1), या लगभग यादृच्छिक हैं। इसलिए, उनका सुझाव मेरे लिए दिलचस्प था, क्योंकि मैंने इसके बारे में कभी नहीं सोचा था। पहली बार मुझे कुछ साल पहले डेटाबेस में पेश किया गया था, जब एक प्रोफेसर नियमित फाइलसिस्टम पर लाभों का वर्णन कर रहा था, मैंने निष्कर्ष निकाला कि डेटाबेस की प्राथमिक भूमिका अनिवार्य रूप से एक बहुत अनुक्रमित फाइलसिस्टम (साथ ही अनुकूलन, कैशिंग, समवर्ती पहुंच) की है। आदि), इस प्रकार, यदि SSD में अनुक्रमित की आवश्यकता नहीं है, तो इस तरह के डेटाबेस को कम उपयोगी बनाते हैं।

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

नोट : मैंने यह सुनिश्चित करने के लिए अंत तक देखा कि उसने कुछ अलग नहीं कहा।

संदर्भ के लिए: 42:22 है जब पूरे डेटाबेस विषय आता है, 43:52 है जब वह "हम क्यों डेटाबेस भी करते हैं" के साथ शुरू होता है

यह उत्तर कहता है कि SSDs की DB की गति काफी बढ़ गई है। यह प्रश्न पूछता है कि अनुकूलन कैसे बदला जाता है।

करने के लिए टी एल; डॉ मेरे सवाल, (चाहे वह आगामी है या पहले से ही हुआ है) डेटाबेस की उपयोगिता को कम सर्वर बाजार में बड़े पैमाने पर एसएसडी उपयोग के आगमन करता है?

ऐसा लग रहा था कि प्रस्तुतकर्ता यह बताने की कोशिश कर रहा था कि SSDs के साथ, कोई डिस्क पर डेटा संग्रहीत कर सकता है, और इस बारे में चिंता करने की ज़रूरत नहीं है कि SSD के साथ पुराने HDD के साथ इसे पुनर्प्राप्त करने के लिए कितना धीमा होगा, समय के पास है। O(1)(मुझे लगता है)। तो, यह सच होने की स्थिति में, यह काल्पनिक रूप से अपने फायदे में से एक को खो देगा: अनुक्रमण, क्योंकि तेजी से चाहने वाले समय के लिए अनुक्रमित होने का लाभ चला गया है।

जवाबों:


59

एक डेटाबेस में कुछ चीजें हैं जो SSDs का उपयोग करते समय ट्वीक किया जाना चाहिए । उदाहरण के लिए, PostgreSQL के लिए बोलना आप समायोजित कर सकते हैं effective_io_concurrency, और random_page_cost। हालाँकि, तेजी से पढ़ता है और तेजी से यादृच्छिक पहुँच एक डेटाबेस क्या करता है नहीं है। यह सुनिश्चित करता है

वह केवल अनुक्रमित के बारे में गलत है। यदि पूरी तालिका को राम में पढ़ा जा सकता है, तो एक सूचकांक अभी भी उपयोगी है। मुझे विश्वास नहीं है? आइए एक विचार प्रयोग करें,

  • कल्पना करें कि आपके पास एक अनुक्रमित स्तंभ के साथ एक तालिका है।

    CREATE TABLE foobar ( id text PRIMARY KEY );
  • कल्पना कीजिए कि उस तालिका में 500 मिलियन पंक्तियाँ हैं।

  • कल्पना करें कि सभी 500 मिलियन पंक्तियों को एक फ़ाइल में एक साथ समाहित किया गया है।

क्या तेज है,

  1. grep 'keyword' file
  2. SELECT * FROM foobar WHERE id = 'keyword'

यह सिर्फ यह नहीं है कि डेटा कहां है, यह इस बारे में है कि आप इसे कैसे ऑर्डर करते हैं और आप इसे क्या ऑपरेशन कर सकते हैं। PostgreSQL B-tree, Hash, GiST, SP-GiST, GIN और BRIN इंडेक्स (और ब्लूम एक एक्सटेंशन के माध्यम से) का समर्थन करता है। आपको लगता है कि सभी गणित और कार्यक्षमता दूर चला जाता है क्योंकि आप तेजी से यादृच्छिक पहुँच है सोचने के लिए मूर्खता होगी।


31
बस एक परिशिष्ट - ओपी को "सामग्री-पता योग्य पहुंच" के साथ "यादृच्छिक अभिगम" को भ्रमित न करने के लिए सावधान रहना चाहिए। जैसा कि ओपी ने कहा, "यादृच्छिक अभिगम" का अर्थ है कि स्मृति के प्रत्येक बाइट को प्राप्त करना हे (1) है। हालांकि, उस "रैंडम-एक्सेस मेमोरी" में डेटा को अभी भी क्रमिक रूप से इसके माध्यम से खोज करने की आवश्यकता है; यही है, आप मेमोरी से यह नहीं पूछ सकते हैं "मुझे वह डेटा मिल जाए जो इस तरह दिखता है " और इसे जादुई रूप से आपको सौंप दिया गया है।
बॉब जार्विस -

2
@BusJarvis आप सही हैं। आपकी टिप्पणी और भी स्पष्ट करने में मदद करती है @ EvanCarroll के "क्या तेजी से" उदाहरण है कि क्यों अनुक्रमण और यहां तक ​​कि सबइंडेक्सिंग मामला, और बस हथियाने O(1)के लिए उपयोग के मामलों के लिए पर्याप्त नहीं है जो एक DB प्रदान करता है
अब्दुल

12

आपकी पोस्ट के आधार पर, यह स्पष्ट संदेश दिखाई देता है कि RDBMS लुकअप समय अनुकूलन को हार्डवेयर से बदला जा रहा है जो IO समय को नगण्य बनाता है।

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

सामान्य रूप से RDBMS सिस्टम का मुख्य मूल्य डेटा संगति, डेटा उपलब्धता और डेटा एकत्रीकरण है। एक्सेल स्प्रेडशीट, सीएसवी फ़ाइल, या "डेटा बेस" रखने की अन्य विधि का उपयोग करने से कोई गारंटी नहीं मिलती है।

SSD आपके प्राथमिक सर्वर से किसी भी कारण (नेटवर्क, ओएस भ्रष्टाचार, बिजली हानि) के लिए अनुपलब्ध होने से आपकी रक्षा नहीं करता है। SSD आपको खराब डेटा संशोधन से बचाता नहीं है। SSD "केवल" होने की तुलना में एनालिटिक्स को चलाने के लिए इसे तेज नहीं बनाता है।


हालांकि मैं बेहतर जानकारी प्राप्त की है, मैं एक डीबी डब्ल्यू / HDD पर बनाम डेटा भंडारण कच्चे एसएसडी डेटा भंडारण के संदर्भ में पूछ रहा था, और अपने जवाब (मुझ से गरीब सवाल शब्दों की वजह से) SSD पर डीबी के संदर्भ में है
अब्दुल

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

8

अंकल बॉब शायद इस तरह के रूप में स्मृति डेटाबेस के बारे में बात कर रहा था Redis या Gemfire । इन डेटाबेस में, डेटाबेस में सब कुछ वास्तव में रैम में निहित है। डेटाबेस खाली शुरू हो सकता है और अल्पकालिक डेटा (कैश के रूप में इस्तेमाल किया जा रहा है) के साथ दायर किया जा सकता है या यह डिस्क से सब कुछ लोड करके और समय-समय पर चेकपॉइंट बदलकर डिस्क में शुरू होता है।

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

यह ओरेकल क्यों चिंता करना चाहिए? डेटा बढ़ रहा है और यह संभावना नहीं है कि RDBMSes चले जाएंगे। हालांकि, वर्षों से ओरेकल के इंजीनियरिंग का बहुत समय वास्तव में तेजी से कताई डिस्क पर डेटा पुनर्प्राप्ति करने के तरीकों में चला गया है। ओरेकल को पूरी तरह से अलग स्टोरेज टियर के अनुकूल होना होगा। वे ओरेकल डेटाबेस इन मेमोरी के साथ हैं , लेकिन वे अतीत की तुलना में विभिन्न प्रतियोगिता के संपर्क में हैं। यह सोचें कि क्वेरी ऑप्टिमाइज़र डिस्क पर चीजों के लेआउट के आधार पर सही रणनीतियों का चयन करने में कितना समय लगाता है ...।


आह। मुझे कभी नहीं पता था कि इन-मेमोरी डेटाबेस जैसी चीजें
अब्दुल

1
एक अन्य उदाहरण के रूप में SQLite मेमोरी में चल सकता है इसलिए किसी अलग डेटाबेस का उपयोग करने की आवश्यकता नहीं है
user151019

8

सामुदायिक विकी पोस्ट ने उत्तर एकत्र करना मूल रूप से प्रश्न टिप्पणियों के रूप में छोड़ दिया


मैं इसके ठीक विपरीत कहूंगा। चूंकि पढ़ने / लिखने की गति इतनी तेज़ है, इसलिए अब आप संख्याओं को और भी तेज़ी से क्रंच करने के लिए GPU त्वरित डेटाबेस (जैसे BlazingDB या Alenka ) प्राप्त कर सकते हैं । अब आपके पास और भी जटिल प्रश्न तेजी से चल सकते हैं। अब ऐसे प्रश्न जिन पर लोग विचार नहीं कर रहे हैं उन्हें उचित गति से चलाया जा सकता है। अधिक जटिल, और अधिक डेटा आप बेहतर हैं - साइबरनार्ड

जबकि बॉब मार्टिन लंबे समय से आसपास हैं और उनकी राय आम तौर पर सुनने के लायक है (अगर सहमत नहीं हैं :-), इस मामले में मुझे लगता है कि वह "द डेथ ऑफ रिलेशनल डेटाबेस" ऑन डाइविंग अस "डाइविंग कर रहे हैं (जिनमें से) मैं एक सहयोगी सदस्य हूं :-)। सीमित परिस्थितियों में कुछ चीजों के लिए कुछ हद तक ठोस तर्क दिया जा सकता है कि गैर-संबंधपरक डेटाबेस प्रौद्योगिकियां एक बढ़त प्रदान कर सकती हैं। हालांकि, कहा जा रहा है कि, IMO रिलेशनल मॉडल, विभिन्न और विविध तरीकों से त्रुटिपूर्ण है, यह अभी भी उपलब्ध सबसे अच्छा सामान्य प्रयोजन डेटाबेस मॉडल प्रदान कर सकता है। YMMV। - बॉब जार्विस

डेटाबेस का उपयोग करने का प्राथमिक कारण यह नहीं है क्योंकि डिस्क धीमी हैं (वास्तव में, मूल रूप से, जिसे डेटाबेस का उपयोग करने के कारण के रूप में उद्धृत किया गया था ), बल्कि इसलिए क्योंकि डेटा जटिल है । एक डेटाबेस का प्राथमिक उद्देश्य कई ऐप / उपयोगकर्ताओं को सही डेटा खोजने में सक्षम बनाना और यहां तक ​​कि एक साथ इसे नियंत्रित तरीके से बदलने में सक्षम होना है। ऐसा करना जल्द ही डेटाबेस का एक माध्यमिक लक्ष्य है। - RBarryYoung

RDBMS जल्द ही किसी भी समय दूर नहीं जा रहा है; वे कुछ प्रकार के आवेदन के लिए सबसे अच्छा विकल्प हैं, और NoSQL (मोंगो, आदि) दूसरों के लिए सबसे अच्छा विकल्प है। मैदान के लिए घोड़े। - sh1rts

डेटाबेस डेटा व्यवस्थित करने में मदद करता है। यह वास्तव में वैसे भी पहले स्थान पर डेटा की तेज़ पहुंच के लिए डिज़ाइन नहीं किया गया था। - जी जियांग

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.