छवि स्टोर के रूप में SQL सर्वर का उपयोग

Question

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

Answer 1

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

The FILESTREAM Attribute

एसक्यूएल सर्वर 2008 में, आप एक varbinary स्तंभ के लिए FILESTREAM विशेषता लागू कर सकते हैं और एसक्यूएल सर्वर:

सौभाग्य से, Sql सर्वर 2008 के साथ, आप अपने केक है और यह भी खाने के लिए अनुमति देता है फिर स्थानीय एनटीएफएस फाइल सिस्टम पर उस कॉलम के लिए डेटा स्टोर करता है। फ़ाइल सिस्टम पर डेटा संग्रहीत करने से दो प्रमुख लाभ मिलते हैं:

• प्रदर्शन फ़ाइल सिस्टम के स्ट्रीमिंग प्रदर्शन से मेल खाता है।
• बीएलओबी आकार केवल फ़ाइल सिस्टम वॉल्यूम आकार से ही सीमित है।

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

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

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

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

Answer 2

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

Answer 3

यदि छवियों को अनुक्रमित किया गया है तो लुकअप एक बड़ी समस्या नहीं होगी। मुझे यकीन नहीं है, लेकिन मुझे नहीं लगता कि फाइल सिस्टम के लिए लुकअप ओ (1) है, ओ (एन) की तरह अधिक (मुझे नहीं लगता कि फाइलें फाइल सिस्टम द्वारा अनुक्रमित हैं)।

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

Answer 4

आम तौर पर एक अच्छा समाधान फाइल सिस्टम पर छवियों को संग्रहीत करना है, और मेटाडेटा (फ़ाइल नाम, आयाम, अंतिम अद्यतन समय, आपको और कुछ भी चाहिए) डेटाबेस में।

यह कहकर कि, इसका कोई "सही" समाधान नहीं है।

Answer 5

एमएस रिसर्च से इस श्वेत पत्र (http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45)

वे विस्तार आप के लिए क्या चाहिए, तो चेक बाहर। लघु संस्करण यह है कि फ़ाइल सिस्टम पर डेटा को सहेजने के बजाय 1 एमबी से अधिक का कोई भी फ़ाइल आकार प्रदर्शन को कम करना शुरू कर देता है।

Answer 6

मुझे संदेह है कि O(log n) लुकअप के लिए एक समस्या होगी। आप कहते हैं कि आपके पास 10 जीबी छवियां हैं। 50 केबी का औसत छवि आकार मानते हुए, यह 200,000 छवियां हैं। 200K पंक्तियों के लिए तालिका में अनुक्रमित लुकअप करना कोई समस्या नहीं है। डिस्क से छवि को वास्तव में पढ़ने और इसे अपने ऐप और क्लाइंट के माध्यम से स्थानांतरित करने के लिए आवश्यक समय की तुलना में यह छोटा होगा।

फाइल सिस्टम पर फ़ाइलों को डेटाबेस में पथ संग्रहीत करने के बनाम डेटाबेस में छवियों को संग्रहीत करने के सामान्य पेशेवरों और विपक्षों पर विचार करने के लायक है। उदाहरण के लिए:

डेटाबेस का पालन लेनदेन अलगाव में

• छवियाँ, स्वचालित रूप से पंक्ति हटा दी जाती है, आदि को हटाने के चित्रों के 10GB के साथ
• डाटाबेस के पाठ्यक्रम एक डेटाबेस छवि फ़ाइलों को केवल pathnames भंडारण से बड़ा है। बैकअप गति और अन्य कारक प्रासंगिक हैं।
• जब आप किसी एप्लिकेशन से किसी डेटाबेस से किसी छवि को सेवा देते हैं तो आपको प्रतिक्रिया पर MIME शीर्षलेख सेट करने की आवश्यकता होती है।
• फाइल सिस्टम पर छवियों को वेब सर्वर (जैसे अपाचे mod_mmap) द्वारा आसानी से कैश किया जाता है, या lighttpd जैसे दुबला वेब सर्वर द्वारा परोसा जा सकता है। यह वास्तव में एक बहुत बड़ा लाभ है।