2009-08-05 7 views
14

मैंने इस संबंध में कुछ पोस्ट पढ़ा लेकिन मुझे अभी भी समझ में नहीं आता कि मेरे मामले में सबसे अच्छा समाधान क्या है।

मैं एक नया वेब ऐप लिखना शुरू कर रहा हूं और बैकएंड 1-10 मिलियन छवियों प्रदान करने जा रहा है। (औसत आकार 200-500kB एक ही छवि के लिए)
छवियों को संग्रहित करना: डीबी या फ़ाइल सिस्टम -

मेरी साइट 100-1000 उपयोगकर्ताओं एक ही समय में करने के लिए सामग्री और छवियों को प्रदान करेगा।

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

व्यक्तिगत तौर पर मैं डीबी में अपने सभी छवियों, लेकिन किसी भी सुझाव वास्तव में सराहना की जाएगी :)

क्या आपको लगता है कि मेरे मामले में डीबी दृष्टिकोण सही विकल्प है करने का विचार पसंद है?

+0

की डुप्लीकेट http://stackoverflow.com/questions/1212832/most-efficient-way-to-store-a-20-meg-file-in-a-sql-server- 2005-छवि-कॉलम – andrewWinn

+2

डुप्लिकेट? मैं जावा, mysql, और छवि फ़ाइलों का उपयोग कर रहा हूं जो 1/20 - 1/50 के 1/50 हैं। मेरा प्रश्न किसी विशिष्ट तकनीक से संबंधित नहीं है, लेकिन छवियों के आकार/qty को संग्रहीत करने की आवश्यकता है जिन्हें – mickthompson

उत्तर

22

देखें अपने डेटाबेस यह बहुत, बहुत बड़ी कर देगा में उन छवियों के सभी लाना। इसका मतलब है कि आपका डीबी इंजन उन सभी छवियों को कैशिंग में व्यस्त करेगा (एक ऐसा कार्य जिसे वास्तव में इसके लिए डिज़ाइन नहीं किया गया है) जब यह इसके बजाय हॉट एप्लिकेशन डेटा कैश कर सकता है।

ओएस और/या आपके रिवर्स प्रॉक्सी तक फ़ाइल कैशिंग छोड़ दें - वे इससे बेहतर होंगे।

+0

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

5

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

+1

यह प्रश्न SO पर दैनिक आधार पर पूछता रहता रहता है। –

4

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

0

हम फ़ाइलनेट का उपयोग करते हैं, जो इमेजिंग के लिए अनुकूलित सर्वर है। ये बहुत कीमती है। फ़ाइल सर्वर का उपयोग करना एक सस्ता समाधान है।

कृपया डेटाबेस सर्वर पर बड़ी फ़ाइलों को संग्रहीत करने पर विचार न करें।

जैसा कि अन्य ने उल्लेख किया है, डेटाबेस में बड़ी फ़ाइलों के संदर्भ संग्रहीत करें।

14

कुछ अन्य फाइल सिस्टम पर छवियों को स्टोर करने के कारण हैं:

  • छवि सर्वर भी चला सकते हैं जब डेटाबेस या व्यस्त है नीचे।
  • फ़ाइल सिस्टम स्टोर फ़ाइलों पर बनाए जाते हैं और इसमें काफी कुशल हैं।
  • आपके डेटाबेस में डेटा डंपिंग का मतलब है धीमे बैकअप और अन्य ऑपरेशंस।
  • किसी भी सर्वर-साइड कोडेड को एक छवि की सेवा करने के लिए जरूरी नहीं है, केवल सादा पुराना आईआईएस/अपाचे।
  • आप गंदगी-सस्ते वेब सर्वर, या संभावित रूप से सीडीएन के साथ तेजी से स्केल कर सकते हैं।
  • आप डेटाबेस को शामिल किए बिना संबंधित काम (थंबनेल जेनरेट आदि) कर सकते हैं।
  • आपका डेटाबेस सर्वर स्मृति में "वास्तविक" तालिका डेटा को अधिक रख सकता है, जहां आप क्वेरी के लिए अपनी डेटाबेस गति प्राप्त करते हैं। यदि यह छवि फ़ाइलों को कैश करने के लिए अपनी बहुमूल्य स्मृति का उपयोग करता है, तो यह आपको स्मृति में अधिक से अधिक फोटो इंडेक्स बनाम गतिशील रूप से कुछ भी नहीं खरीदता है।
3

आप किस डेटाबेस का उपयोग कर रहे हैं? एमएस एसक्यूएल सर्वर 2008 FILESTREAM स्टोरेज

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

details

संबंधित मुद्दे