रेल: डेटाबेस में बाइनरी फाइलों को संग्रहीत करना

Question

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

Answer 1

यह एक सुंदर मानक डिजाइन प्रश्न है, और वास्तव में वास्तव में "एक सच्चा उत्तर" नहीं है।

अंगूठे का नियम आमतौर पर पालन करता है "डेटा डेटाबेस में जाता है, फाइलें फाइलों में जाती हैं"।

विचार से कुछ को ध्यान में रखना:

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

2. फ़ाइलें आम तौर पर बड़ी होती हैं। बड़े डेटाबेस निश्चित रूप से व्यवहार्य हैं, लेकिन वे धीमे और बैक अप के लिए असुविधाजनक हैं आदि। जब आपको ऐसा करने की आवश्यकता नहीं है तो अपने डेटाबेस को बड़ा क्यों बनाएं?

3. बहुत पसंद है 2., फ़ाइलों को कई मशीनों में कॉपी करना वास्तव में आसान है। मान लें कि आप क्लस्टर चला रहे हैं, आप समय-समय पर अपने मास्टर मशीन से फाइल सिस्टम को अपने दासों में rsync कर सकते हैं और मानक स्थिर http सेवारत का उपयोग कर सकते हैं। स्पष्ट रूप से डेटाबेस को क्लस्टर भी किया जा सकता है, यह केवल सहज ज्ञान युक्त नहीं है।

4. 3 के फ्लिप पक्ष पर, यदि आप पहले से ही अपने डेटाबेस को क्लस्टर कर रहे हैं, तो क्लस्टर फाइलों के साथ निपटने के लिए प्रशासनिक जटिलता है। डीबी में फाइलों को संग्रहीत करने पर विचार करने का यह एक कारण होगा, मैं कहूंगा।

5. डेटाबेस में ब्लॉब डेटा आम तौर पर अपारदर्शी है। आप इसे फ़िल्टर नहीं कर सकते हैं, इसके द्वारा क्रमबद्ध कर सकते हैं, या इसके द्वारा समूह बना सकते हैं। इससे डेटाबेस में इसे संग्रहीत करने के मूल्य कम हो जाते हैं।

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

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

8. अनुमतियां। फाइल सिस्टम में अनुमतियां होती हैं, और वे पीछे की ओर दर्द हो सकती हैं। इसके विपरीत, वे आपके आवेदन के लिए उपयोगी हो सकते हैं। अगर आप 7 का लाभ उठा रहे हैं तो अनुमतियां वास्तव में आपको काट लेंगी, क्योंकि यह लगभग गारंटी है कि आपका वेब सर्वर आपके अनुप्रयोगों की तुलना में अलग-अलग अनुमतियों के साथ चलता है।

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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