2011-10-28 13 views
7

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

जबकि मैं एक आर्किटेक्चर करना चाहता हूं जो उच्च मात्रा डेटा के लिए अच्छी तरह से स्केल करता है, मैं वर्तमान में अत्यधिक उच्च (फेसबुक-, Google-पैमाने) वॉल्यूम्स के बारे में चिंता नहीं कर रहा हूं।

मैं

/files/{username}/ 

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

प्रत्येक उपयोगकर्ता को अपनी तालिका देने पर विचार करने के पीछे मेरा तर्क यह था कि यह टेबल पर डेटा को दाढ़ी देने और उपयोगकर्ता को दी गई फ़ाइल की तलाश करते समय खोज समय को कम करने का एक साफ और अलग तरीका है।

उत्तर

3

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

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

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

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

3

यह आपके ऐप और डेटाबेस की प्रकृति और संरचना पर निर्भर करता है। मैंने फ़ोल्डर-आधारित, डेटाबेस ब्लॉब में संग्रहीत चित्रों, प्रमाणीकरण गेटवे के माध्यम से ऑफ़-वेब फ़ाइल फ़ोल्डरों तक संग्रहीत चित्रों सहित कई तकनीकों का उपयोग किया है ...

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

मैं प्रति उपयोगकर्ता एक टेबल का उपयोग नहीं करता, केवल आईडी, उपयोगकर्ता आईडी, चित्र ब्लॉब के तत्वों के साथ चित्रों की एक तालिका का उपयोग नहीं करता।

क्या इससे मदद मिलती है?

+0

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

+1

एक सूचकांक का आकार SQL निष्पादन को प्रभावित करता है, लेकिन अनगिनत ब्लॉब्स का एक बड़ा सेट ध्यान देने योग्य नहीं होगा। लेकिन अगर आपके पास जगह नहीं है तो यह एक महत्वपूर्ण मुद्दा है। उस स्थिति में, आपको उन्हें फाइल सिस्टम में स्टोर करने की आवश्यकता होगी। एक उपयोगकर्ता आईडी/फोटो फ़ोल्डर संरचना ठीक है यदि आपके पास उनमें से बहुत कम होगा, क्योंकि एक फ़ोल्डर में एक बड़ी फ़ाइल गणना से बचने के लिए एक अच्छा अभ्यास है। मैं प्रत्यक्ष पहुंच से बचने के लिए एक .htaccess रखूंगा (माना जाता है कि आपको उन्हें एक्सेस करने के लिए लेख की आवश्यकता है), और एक फोटो का उपयोग करें? Id = जो भी हेडर को छवि/जेपीईजी या जो कुछ भी बदलता है, और रीडफाइल की छवि को गूंजता है। –

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

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