বড় ফাইল (10 এমবি) একটি ডাটাবেসে সংরক্ষণ করা কি খারাপ অভ্যাস?

Question

আমি বর্তমানে একটি ওয়েব অ্যাপ্লিকেশন তৈরি করছি যা ব্যবহারকারীদের ফাইল সংরক্ষণ এবং ভাগ করার মঞ্জুরি দেয়, 1 এমবি - 10 এমবি আকারের।

এটি আমার কাছে মনে হয় যে একটি ডাটাবেসে ফাইলগুলি সঞ্চয় করা ডেটাবেস অ্যাক্সেসকে উল্লেখযোগ্যভাবে কমিয়ে দেবে।

এই একটি বৈধ উদ্বেগ? ফাইল সিস্টেমে ফাইলগুলি সংরক্ষণ করা এবং ডাটাবেসে ফাইলের নাম এবং পথ সংরক্ষণ করা কি ভাল? ডাটাবেসের সাথে কাজ করার সময় ফাইলগুলি সংরক্ষণের সাথে সম্পর্কিত কোনও সেরা অনুশীলন রয়েছে কি?

আমি এই প্রকল্পের জন্য পিএইচপি এবং মাইএসকিউএল মধ্যে কাজ করছি, কিন্তু বিষয়টি সবচেয়ে পরিবেশের জন্য একই (হয় পাগল নেভিগেশন রুবি , পিএইচপি , .NET ) এবং ডাটাবেস (মাইএসকিউএল, পোস্টগ্রি )।

Comments

ডিবিএ.এসই সম্পর্কিত সম্পর্কিত প্রশ্ন: ফাইলস - ডাটাবেসে বা না?

— নিক চ্যামাস

অবাক হ'ল কেউ এই ইস্যুতে এমএস গবেষণা করেন নি (এসকিউএল সার্ভার ২০০৮ এর জন্য): ব্লগ করতে বা ব্লগ করতে নয়: একটি ডাটাবেস বা একটি ফাইল সিস্টেমে বড় অবজেক্ট স্টোরেজ

— ওডেড

বৃহত্তর একটি আপেক্ষিক পরিমাণ, আমি (এবং সম্ভবত আরও অনেক) 10MBআধুনিক সিস্টেমে এত বড় দেখতে পাচ্ছি না ।

এটি এফএকিউ অনুসারে বিষয়বস্তু - এটি বুলেটগুলির "ডিজাইনের ধরণগুলি" (স্ল্যাশ অ্যান্টিপ্যাটার্নস) এবং "সফ্টওয়্যার আর্কিটেকচার" এর অধীনে ফিট করে। কেন এটি বন্ধ ছিল?

— ইজকাটা

আমি এখনকার মতো প্রশ্নটিতে কোনও অস্পষ্টতা দেখছি না। কেন এটি বন্ধ ছিল আমার কোনও ধারণা নেই।

— রিনিয়ারপোস্ট

Answer 1

ডাটাবেসে ফাইল সংরক্ষণের পক্ষে:

1. ফাইলগুলির ডাটাবেসের বাইরে সংরক্ষণ করা হলে জটিল একটি আপডেটের রোলব্যাক সহ এসিডি ধারাবাহিকতা। এটিকে হালকাভাবে দেখানো হবে না। ফাইল এবং ডাটাবেস সিঙ্কে থাকা এবং লেনদেনে অংশ নিতে সক্ষম হওয়া খুব দরকারী।
2. ফাইলগুলি ডাটাবেসের সাথে চলে এবং এখান থেকে এতিম হতে পারে না।
3. ব্যাকআপগুলি স্বয়ংক্রিয়ভাবে ফাইল বাইনারি অন্তর্ভুক্ত করে।

ডাটাবেসে ফাইল সংরক্ষণের কারণ:

1. বাইনারি ফাইলের আকার ডাটাবেসের মধ্যে পৃথক হয়। এসকিউএল সার্ভারে, যখন ফাইলস্ট্রেম বস্তুটি ব্যবহার না করা হয়, উদাহরণস্বরূপ, এটি 2 জিবি। যদি ব্যবহারকারীদের ফাইলগুলি বৃহত্তর সঞ্চয় করতে হয় (যেমন একটি সিনেমা বলুন), তবে সেই যাদুটি ঘটানোর জন্য আপনাকে হুপসের মধ্য দিয়ে ঝাঁপিয়ে পড়তে হবে।
2. ডাটাবেসের আকার বাড়ায়। আপনার একটি সাধারণ ধারণাটি আপনার মনে রাখা উচিত: একটি ডাটাবেস বজায় রাখতে প্রয়োজনীয় জ্ঞানের স্তরটি ডাটাবেসের আকারের অনুপাতে চলে যায়।উদাহরণস্বরূপ, ছোট ডাটাবেসের চেয়ে বড় ডাটাবেসগুলি বজায় রাখা আরও জটিল। ডাটাবেসে ফাইল সংরক্ষণ করে ডাটাবেস অনেক বড় করতে পারে। এমনকি যদি বলি যে একটি বৃহত ডাটাবেস আকারের সাথে একটি দৈনিক পূর্ণ ব্যাকআপ যথেষ্ট হয়ে যায় তবে আপনি এটি আর সক্ষম করতে পারবেন না। আপনাকে ফাইলগুলি অন্য কোনও ফাইল গ্রুপে রাখার বিষয়টি বিবেচনা করতে হবে (যদি ডাটাবেস এটি সমর্থন করে), ব্যাকআপগুলিকে ফাইলগুলির ব্যাকআপ থেকে ডেটা ব্যাকআপ পৃথক করতে পারে ইত্যাদি। এই বিষয়গুলির কিছুই শেখা অসম্ভব নয়, তবে করুন রক্ষণাবেক্ষণে জটিলতা যুক্ত করুন যার অর্থ ব্যবসায়ের জন্য ব্যয়। যতটা সম্ভব মেমোরিতে যত বেশি ডেটা স্টাফ করার চেষ্টা করা হয় তত বড় ডাটাবেসগুলি আরও মেমরি ব্যবহার করে।
3. আপনি যদি এসকিউএল সার্ভারের FILESTREAMঅবজেক্টের মতো সিস্টেমের নির্দিষ্ট বৈশিষ্ট্যগুলি ব্যবহার করেন এবং অন্য একটি ডাটাবেস সিস্টেমে স্থানান্তরিত করতে চান তবে বহনযোগ্যতা উদ্বেগের কারণ হতে পারে ।
4. ডাটাবেজে ফাইল লেখার কোডটি সমস্যা হতে পারে। এমন একটি সংস্থা যার জন্য আমি এত বেশি চাঁদ না নিয়ে আগে পরামর্শ পেয়েছিলাম যে কোনও সময় কোনও মাইক্রোসফ্ট অ্যাক্সেসকে তাদের ডাটাবেস সার্ভারের সাথে সংযুক্ত করে অলে অ্যাক্সেসের ওল অবজেক্ট নিয়ন্ত্রণ ব্যবহার করে "কিছু" আপলোড করার ক্ষমতা ব্যবহার করা হয়েছিল। পরে তারা একটি আলাদা নিয়ন্ত্রণ ব্যবহার করতে পরিবর্তিত হয়েছিল যা এখনও ওলে নির্ভর করে। অনেক পরে কাঁচা বাইনারি সঞ্চয় করার জন্য কেউ ইন্টারফেস পরিবর্তন করে। এই ওলে অবজেক্টগুলি এক্সট্র্যাক্ট করা ছিল নরকের একটি নতুন স্তরের। আপনি যখন ফাইল সিস্টেমে ফাইলগুলি সঞ্চয় করেন, উত্স ফাইলটি মোড়ানো / টুইটক / পরিবর্তন করতে কোনও অতিরিক্ত স্তর জড়িত থাকে না।
5. কোনও ওয়েবসাইটে ফাইলগুলি পরিবেশন করা আরও জটিল। বাইনারি কলামগুলির সাথে এটি করতে, আপনাকে ডাটাবেস থেকে বাইনারি ফাইলটি স্ট্রিম করতে একটি হ্যান্ডলার লিখতে হবে। আপনি ফাইল পাথ সংরক্ষণ করলেও আপনি এটি করতে পারেন তবে আপনাকে এটি করতে হবে না । আবার হ্যান্ডলার যুক্ত করা অসম্ভব নয় তবে জটিলতা যুক্ত করে এবং ব্যর্থতার অন্য একটি বিষয়।
6. আপনি মেঘ সঞ্চয় করার সুবিধা নিতে পারবেন না। মনে করুন একদিন আপনি আপনার ফাইলগুলি একটি অ্যামাজন এস 3 বালতিতে সঞ্চয় করতে চান। ডাটাবেসে আপনি যা সঞ্চয় করেন তা যদি ফাইল পাথ হয়, তবে আপনাকে এস 3-তে পাথগুলিতে পরিবর্তন করার ক্ষমতা দেওয়া হবে। আমি যতদূর সচেতন, কোনও ডিবিএমএসের সাথে কোনও দৃশ্যে এটি সম্ভব নয়।

আইএমও, ডাটাবেসে ফাইল স্টোরেজ হিসাবে বিবেচনা করা বা "খারাপ" না হিসাবে পরিস্থিতি এবং প্রয়োজনীয়তা সম্পর্কে আরও তথ্যের প্রয়োজন। ফাইলের আকার এবং / অথবা সংখ্যা কি সর্বদা ছোট হতে চলেছে? ক্লাউড স্টোরেজ ব্যবহার করার কোনও পরিকল্পনা নেই? ফাইলগুলি কোনও ওয়েবসাইটে বা উইন্ডোজ অ্যাপ্লিকেশনটির মতো বাইনারি কার্যকর হতে পারে?

সাধারণভাবে, আমার অভিজ্ঞতাতে দেখা গেছে যে এসিআইডি অভাব এবং অনাথের সম্ভাবনার জন্য অ্যাকাউন্টিংয়ের জন্য ব্যবসায়ের পক্ষে স্টোর পাথগুলি কম ব্যয়বহুল। যাইহোক, এর অর্থ এই নয় যে ইন্টারনেট ফাইল স্টোরেজটিতে এসিডি নিয়ন্ত্রণের অভাবের গল্প নিয়ে লিজন নয়, তবে এর অর্থ এই যে সাধারণভাবে সমাধানটি তৈরি করা, বোঝার এবং বজায় রাখা সহজ।

Comments

আপনি সিডিএন ব্যবহার করতে পারবেন না কেন? এটি আমি সমর্থিত প্রতিটি সিডিএন সহ একটি সমর্থিত দৃশ্য।

— বিলি ওনিল

@ বিলিওনিল - আপনি একটি সিডিএন ব্যবহার করতে পারবেন না এবং ডাটাবেসে ফাইলটি সঞ্চয় করতে পারবেন না । আপনি সদৃশ দিয়ে ঠিক না থাকলে আপনার উভয়ই থাকতে পারে না।

— থমাস

তবে, একটি সিডিএন এর পুরো পয়েন্ট হ'ল সদৃশ। সিডিএনগুলি কেবল একটি ওয়েব ঠিকানার লক্ষ্যকেই ক্যাশে করে - একমাত্র প্রয়োজন হ'ল কোনও এইচটিটিপি হোস্ট কনটেন্টটি পরিবেশন করে এবং সামগ্রীটি খুব কমই পরিবর্তিত হয়। (কিভাবে সিডিএন আপনাকে পৃথিবী থেকে বলবে যে আপনি যেভাবেই ছবিটি

— টানলেন

@ বিলিওনিল - তবে, আমি মনে করি এটি আমার পক্ষে শব্দের পছন্দ করা পছন্দ নয় এবং আমি আমার উত্তরটি সামঞ্জস্য করেছি। বিশেষত, আপনি যদি ক্লাউড স্টোরেজটি ব্যবহার করতে চান (এবং তারপরে সম্ভবত আপনার ক্লাউড স্টোরেজ সহ কোনও সিডিএন ব্যবহার করুন), আপনি এটি ডাটাবেস স্টোরেজ সমাধানের সাথে স্থানীয়ভাবে করতে পারবেন না। ডাটাবেস থেকে ফাইলগুলি টানতে এবং আপনার ক্লাউড স্টোরেজ সরবরাহকারীর কাছে পাঠাতে আপনাকে একটি সিঙ্ক্রোনাইজেশন রুটিন লিখতে হবে।

— থমাস

@ বিলিওনিয়েল - একরকম, আপনার মন্তব্যটি সেরা উত্তর ছিল। আপনার কাছে ডিবি স্টোরেজের সমস্ত সুবিধা থাকতে পারে, তবে কোনও সমস্যা নেই।

— বি সেভেন

Answer 2

অনেক ক্ষেত্রে, এটি একটি খারাপ ধারণা। এটি ডাটাবেস ফাইলগুলি ফুটিয়ে তুলবে এবং বেশ কয়েকটি কার্য সম্পাদনের সমস্যা তৈরি করবে। যদি আপনি একটি বিশাল সংখ্যক কলাম সহ টেবিলের মধ্যে ব্লবগুলি আটকে থাকেন তবে এটি আরও খারাপ।

যাহোক! কিছু ডাটাবেস, যেমন এসকিউএল সার্ভারে একটি ফাইলস্ট্রিআম কলামের ধরণ থাকে। এই ক্ষেত্রে, আপনার ডেটাটি ডাটাবেস সার্ভারে একটি পৃথক ফাইলে আসলে সংরক্ষণ করা হয় এবং কেবলমাত্র একটি আইডি ফাইলটিতে সারণীতে সংরক্ষণ করা হয়। এই ক্ষেত্রে আমি এসকিউএল সার্ভারে ডেটা না রাখার অনেক কারণ দেখছি না। ফাইলগুলি স্বয়ংক্রিয়ভাবে সার্ভার ব্যাকআপের অংশ হিসাবে অন্তর্ভুক্ত হয় এবং ডাটাবেস এবং ফাইলগুলি কখনই সিঙ্কের বাইরে থাকে না। টনির ফাইলের নাম সংরক্ষণের পরামর্শের সাথে সমস্যাটি হ'ল ডাটাবেস এবং ফাইল সিস্টেম সিঙ্কের বাইরে চলে যেতে পারে। ডাটাবেস দাবি করবে যে কোনও ফাইল যখন এটি ডিস্কে মুছে ফেলা হয়। যদি কোনও প্রক্রিয়া ডাটাবেস সংশোধন করে এবং তারপরে ক্র্যাশ হয় তবে ফাইল এবং ডাটাবেস মিলবে না (অর্থাত্ কোনও ডাটাবেসের বাইরে ফাইলগুলির সাথে এসিআইডি নেই )।

Comments

আমি এই বক্তব্যটির সাথে একমত নই a যদি কোনও প্রক্রিয়া ডিবি সংশোধন করে এবং ক্রাশ হয় তবে ফাইল এবং ডিবি মিলবে না you আপনি যদি কোনও লেনদেনে পুরো প্রক্রিয়াটি আবদ্ধ করেন (ফাইল তৈরি করুন, ফাইলটি হালনাগাদ করুন, আপডেট ডিবি করুন) এবং ত্রুটি বার্তা নিক্ষেপ করুন যখন কিছু ভুল হয়ে যায় তখন এগুলিকে সিঙ্কে রাখা বেশ সহজ।

— ব্রিডুমস

আমি এতে ব্রিডমদের সাথে রয়েছি: দৃশ্যের বিষয়টি বিবেচনা করুন: ফাইল সিস্টেমে ফাইল সংরক্ষণ করুন (পুরানো ফাইলটি মোছা না করে), ডিবি আপডেট করুন, সাফল্যের সাথে পুরানো ফাইল মুছুন, রোলব্যাকে নতুন ফাইল মুছুন। সবচেয়ে খারাপ ক্ষেত্রে - প্রক্রিয়াটি যদি বাধা পায় তবে আপনার কাছে এতিম ফাইল রয়েছে। তবে আপনার কাছে সবসময়ই ডিবি দ্বারা ফাইলগুলি সঠিক সংস্করণে রেফারেন্স করা থাকে।

— ভের্টেক

ফাইল / ডিবি পদ্ধতিতে অন্যান্য সম্ভাব্য সমস্যা: 1) আপনাকে অনুলিপি অনুলিপি হিসাবে আপডেট করতে হবে। যদি কোনও আপডেটের সময় আপনার প্রক্রিয়া ক্রাশ হয়, তবে ডিবি স্থিতিটি আবার ঘুরিয়ে দেওয়া হবে, ফাইলটি হবে না। 2) এটি করার পরে পুরানো ফাইলের এক ধরণের আবর্জনা সংগ্রহের প্রয়োজন। 3) ডিবিতে সমস্ত কিছু সংরক্ষণ করার অর্থ ব্যাকআপ নেওয়ার পরে ডিবি এবং ফাইলগুলির সংস্করণ সিঙ্কে রয়েছে। 2 সপ্তাহ আগে আপনার ডিবিটিকে তার রাজ্যে পুনরুদ্ধার করুন ... এখন সেই সময়ে ফাইলগুলির বিষয়বস্তু কোথায়?

— তিমিথ বাল্ড্রিজ

@ ব্রিডিয়ামস - না, যেহেতু এসকিউএল সার্ভার সরাসরি ফাইল সিস্টেমে সংহত করে এবং ওএসের পক্ষে এই ফাইলগুলি পরিচালনা করে। আমি সেগুলি নিজেই ব্যবহার করি নি, তবে ডকুমেন্টেশনগুলি এটিকে ফাইলস্ট্রেমের মতো দেখায় এবং এর বংশধর ফাইল টেবিলগুলি আপনাকে উভয় বিশ্বের সেরা উপহার দেয়: ফাইলগুলি ফুলে না গিয়ে ফাইলগুলি ডাটাবেস এবং সম্পর্কিত ডেটা (আপনাকে কেন্দ্রীয়ভাবে আপনার ডেটা পরিচালনা করার অনুমতি দেয়) এর সাথে দৃ bound়ভাবে আবদ্ধ হয় তথ্যশালা.

— নিক চামাস

আমি নিকের সাথে একমত আমরা আমাদের ডিস্ক + ডিবি সিস্টেমটিকে FILESTREAM কলামগুলির সাথে প্রতিস্থাপন করেছি এবং আর কখনও পিছন ফিরে দেখিনি। এফকে দিয়ে অন্য টেবিলের সাথে ফাইল বেঁধে রাখতে পেরে সত্যিই খুব ভাল লাগছে। সুতরাং আপনি বলতে পারেন যে "প্রতিটি ব্যক্তির অবশ্যই তাদের সাথে এক বা একাধিক এইচআর ডক্স যুক্ত থাকতে হবে", বা এর মতো অন্য কিছু।

— টিমোথি বাল্ড্রিজ

Answer 3

হ্যাঁ, এটি একটি খারাপ অভ্যাস।

ডিবিতে পারফরম্যান্স প্রভাব:

• আপনি যদি SELECTকোনও বিএলওবি কলামের সাহায্যে একটি করেন, আপনি সর্বদা ডিস্ক অ্যাক্সেস করবেন, যখন বিএলওবি ব্যতীত আপনার সরাসরি র‌্যাম থেকে ডেটা পাওয়ার সুযোগ থাকবে (হাই থ্রুপুট ডিবি র‌্যামের টেবিলগুলি ফিট করার জন্য অনুকূলিত হবে);
• প্রতিলিপি ধীর হবে, প্রতিরূপে বিলম্ব বেশি হবে, কারণ এটি বিএলএবকে ক্রীতদাসদের দিকে ঠেলে দিতে হবে। উচ্চ প্রতিলিপি বিলম্ব সমস্ত ধরণের জাতি শর্ত এবং অন্যান্য সিঙ্ক্রোনাইজেশন সমস্যা সৃষ্টি করবে, আপনি যদি তা স্পষ্টভাবে বিবেচনা না করেন;
• ডিবি ব্যাকআপ / পুনরুদ্ধার করতে অনেক বেশি সময় লাগবে;

গতির সুবিধা - কেউই না ! কিছু পুরানো ফাইল সিস্টেমগুলি কয়েক মিলিয়ন ফাইলের সাথে ভাল ডিরেক্টরি পরিচালনা করতে পারে না, তবে বেশিরভাগ আধুনিকের কোনও সমস্যা নেই এবং বাস্তবে বিডি (সাধারণত বি-ট্রি) হিসাবে একই ধরণের ডেটা স্ট্রাকচার ব্যবহার করা হয়। উদাহরণস্বরূপ ext4 (ডিফল্ট লিনাক্স ফাইল সিস্টেম) Htree ব্যবহার করে ।

উপসংহার: এটি আপনার ডিবি কর্মক্ষমতা বাধাগ্রস্থ করবে এবং ফাইল পুনরুদ্ধার কর্মক্ষমতা উন্নত করবে না।

এছাড়াও, যেহেতু আপনি ওয়েব অ্যাপ্লিকেশন সম্পর্কে কথা বলছেন - আধুনিক ওয়েবসার্ভার ব্যবহার করে সরাসরি ফাইল সিস্টেম থেকে স্ট্যাটিক ফাইলগুলি সরবরাহ করা, যা sendfile()সিস্কেল করতে পারে অসাধারণ কর্মক্ষমতা উন্নতি is আপনি যদি ডিবি থেকে ফাইল আনছেন তবে এটি অবশ্যই সম্ভব নয়। উদাহরণস্বরূপ এই বেঞ্চমার্কটি বিবেচনা করুন , নিম্ন প্রান্তের ল্যাপটপে 1000 সমবর্তী সংযোগের সাথে এনগনিক্স 25 কে রেক / এস করছেন দেখায় । এই ধরনের লোড যে কোনও ধরণের ডিবি ভাজবে।

Comments

+1 টি। আপনার ওয়েব সার্ভারটিকে এটি সর্বোত্তমভাবে করতে দেয়, ডিস্ক থেকে ফাইলগুলি সরবরাহ করে। পিএইচপি জিজ্ঞাসা করবেন না, যেমন

— পিএইচপিকে

প্রোগ্রামাররা কখন শিখবে যে পারফরম্যান্স এগুলি গুরুত্বপূর্ণ নয়?

— রিইনারপোস্ট

পুনঃটুইট সম্ভবত যখন আমরা উদার শিল্পকলা মেজরগুলি

— পেলাম

@ বিলিওনিল: আপনি কেন ধরে নিলেন যে স্থির এবং গতিশীল সামগ্রীর জন্য আপনার একই সার্ভার থাকতে হবে? সার্ভারগুলিতে ফাইলগুলি সিঙ্ক্রোনাইজ করার জন্য, এর জন্য বিশেষভাবে ডিজাইন করা সরঞ্জাম রয়েছে যা ডাটাবেসের চেয়ে অনেক বেশি দক্ষ। ফাইলসভার হিসাবে ডাটাবেস ব্যবহার করা স্ক্রু ড্রাইভারের সাথে পেরেকটি হাতুড়ি দেওয়ার চেষ্টা করার মতো।

— ভের্টেক করুন

@ বিলিওনিল: আমি সম্মত হই যে সেখানে কিছু "সমাধান" রয়েছে যেখানে এটি কার্যকর হবে, আমি মাইএসকিউএল এর চিত্রগুলি সহ বেশিরভাগ অপেশাদার পিএইচপি সেটআপ দেখেছি। যাইহোক, এই জাতীয় সেটআপে কোনও ডিবি কখনই বিএলওবি সরবরাহকারী উচ্চ ট্র্যাফিককে সমর্থন করবে না।

— ভের্টেক

Answer 4

আমি এটি সম্পর্কে বাস্তববাদী হতে হবে, এবং "এখনও অনুকূলিতকরণ না" নীতি অনুসরণ করুন। এই মুহুর্তে সমাধানটি কার্যকর হয়ে উঠুন এবং সঠিকভাবে প্রয়োগের জন্য আপনার কাছে বিকাশ সংস্থান রয়েছে Make সম্ভাব্য সমস্যা প্রচুর আছে । তবে এগুলি অগত্যা আসল সমস্যা হয়ে ওঠে না। যেমন আপনার যদি 100 জন ব্যবহারকারী থাকে তবে এটি সম্ভবত সমস্যা হবেনা। আপনার যদি 100,000 বা 10,000,000 ব্যবহারকারী থাকে তবে এটি সমস্যা হতে পারে। তবে পরবর্তী ক্ষেত্রে, সমস্ত সমস্যা মোকাবিলার জন্য আরও বিকাশের সংস্থানগুলির একটি ভিত্তি থাকা উচিত।

তবে ডাটাবেসে ডেটা সংরক্ষণ করা আপনাকে অন্যান্য সমস্যার মোকাবেলা থেকে মুক্তি দেয়, যেমন ফাইলগুলি কোথায় সংরক্ষণ করা উচিত, সেগুলি কীভাবে ব্যাক আপ করা উচিত ইত্যাদি Since যেহেতু আপনি ওয়েব অ্যাপ্লিকেশন লিখছেন তা সুরক্ষার কারণে এটি খুব ভাল ধারণা হবে অ্যাপ্লিকেশনটির হোস্টিং প্রক্রিয়াটি ফাইল সিস্টেমে লেখার অ্যাক্সেস না পেয়েছে তা নিশ্চিত করার জন্য আপনাকে সার্ভারটি কনফিগার করতে হবে যাতে সেই প্রক্রিয়াটি ফোল্ডারে যেখানে ডেটা সঞ্চিত থাকে সেখানে সেগুলি পড়তে / লেখার অ্যাক্সেস রাখে।

আমি ব্যক্তিগতভাবে ডেটাবেজে ডেটা সঞ্চয় করতে বেছে নেব, তবে নিশ্চিত হয়ে নিন যে ব্লুব্লবগুলি সত্যই প্রয়োজন হয় না হওয়া পর্যন্ত না পঠিত, অর্থাৎ ব্লগযুক্ত সেই টেবিলগুলিতে কোনও "নির্বাচন করুন ..." কার্যকর করা হবে না। এবং আমি নিশ্চিত করবো যে আপনি যদি পারফরম্যান্সের সমস্যা পান তবে ডিজাইনটি ডেটাবেস থেকে ডেটা ফাইলফাইলে সরিয়ে আনা সহজ করে তোলে। উদাহরণস্বরূপ, ফাইলের তথ্য একটি পৃথক ফাইল টেবিলের মধ্যে সঞ্চয় করুন , এইভাবে ফাইলের তথ্যটি অন্যান্য ব্যবসায়িক সংস্থা থেকে দূরে রাখুন।

ধরে নিই যে ডাটাবেসে পড়া কোনও ফাইল উপস্থাপনের জন্য আপনার কাছে ফাইল ক্লাস রয়েছে, তবে পরে এটিকে সরিয়ে নিয়ে যাওয়ার কোডিং প্রভাবটি ন্যূনতম হবে।

Comments

এটি একটি দুর্দান্ত পরামর্শ। আপনার যে সমস্যা নেই সেগুলি সমাধান শুরু করবেন না।

— ভার্জিনিউজ

Answer 5

মাইক্রোসফ্ট কয়েক বছর আগে এ সম্পর্কে একটি সাদা কাগজ প্রকাশ করেছিল। এটি স্কেল সার্ভারে মনোনিবেশ করে তবে আপনি সেখানে কিছু আকর্ষণীয় তথ্য পেতে পারেন:

BLOB করতে নাকি BLOB- এ না? একটি ডাটাবেস বা একটি ফাইল সিস্টেমে বড় অবজেক্ট স্টোরেজ?

তাদের উপসংহারের একটি খুব সংক্ষিপ্ত সংস্করণ হ'ল:

এনটিএফএস ফাইল সিস্টেম এবং এসকিউএল সার্ভার 2005 এর সাথে তুলনা করার সময়, 256KB এর চেয়ে ছোট BLOBS এসকিউএল সার্ভার দ্বারা আরও দক্ষতার সাথে পরিচালিত হয়, অন্যদিকে এনটিএফএস 1MB এর চেয়ে বড় BLOBS এর জন্য আরও দক্ষ।

আমি আপনাকে সুপারিশ করব যে আপনি আপনার নির্দিষ্ট ব্যবহারের ক্ষেত্রে কিছু ছোট পরীক্ষা লিখুন। মনে রাখবেন যে আপনাকে ক্যাচিংয়ের প্রভাবগুলি থেকে সাবধান থাকতে হবে। (আমি প্রথমবারের মতো সেভ-টু ডিস্ক গতি পেয়েছি যা শারীরিকভাবে সম্ভব হওয়ার চেয়ে বেশি থ্রুপুট পেয়েছিল বলে আমি অবাক হয়েছি!)

Comments

আপনার জানা উচিত যে এনটিএফএস যখন খুব বেশি ~ 100K ফাইলগুলিকে একটি ডিরেক্টরিতে রাখে তখন খুব ত্রুটিযুক্ত আচরণ শুরু করে। ফাইল অ্যাক্সেসটি বেশ খানিকটা ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে পড়ে যায়। আমি উইন্ডোজ 2008 এবং উইন্ডোজ 7 সিস্টেমে এই প্রভাবটি অনুভব করেছি। আমি যখন একাধিক ডিরেক্টরিতে ফাইলগুলি পুনরায় বিতরণ করি তখন সমস্ত কিছু স্বাভাবিক হয়ে যায়। আমি জানি না এর পর থেকে পরিস্থিতির উন্নতি হয়েছে কিনা।

— ফেররুচিয়াও

Answer 6

ডাটাবেসের বাইরে ফাইল সংরক্ষণের পুরানো প্রচলিত প্রজ্ঞা আর না ধরে থাকতে পারে। নীতিগত বিষয় হিসাবে, আমি গতির চেয়ে অখণ্ডতার পক্ষে এবং একটি আধুনিক ডিবিএমএস সহ আপনি উভয়ই রাখতে পারেন।

টম কিট রাজি বলে মনে হচ্ছে :

আমি ডেটাবেসের বাইরে দীর্ঘ সময় ধরে রাখতে চাইলে ডেটা সংরক্ষণ করার কোনও সুবিধা নেই।

এটি ডাটাবেসে থাকলে আমি পারি

এটি পেশাদারভাবে পরিচালিত হয়েছে তা নিশ্চিত হন

ব্যাক আপ

পুনরুদ্ধারযোগ্য (বাকী ডেটা সহ)

সুরক্ষিত

স্কেলেবল (এখনই একটি একক ডিরেক্টরিতে 100,000 নথি রাখার চেষ্টা করুন, এখন সেগুলি টেবিলের মধ্যে রাখুন - কোনটি 'স্কেল' - এটি ডিরেক্টরি নয়)

আমি সহজেই (ফ্ল্যাশব্যাক) মুছে ফেলতে পারি

আমার লকিং আছে

আমি ধারাবাহিকতা পড়েছি ...

Answer 7

হ্যাঁ.

আপনি যদি আপনার ফাইল সিস্টেম থেকে কোনও ফাইল পরিবেশন করেন তবে আপনার ওয়েব সার্ভার বিএসডি বা লিনাক্সে প্রেরণ ফাইলের মতো কার্নেল কোডটি সরাসরি সকেটে ফাইলটি অনুলিপি করতে ব্যবহার করতে পারে। এটি খুব দ্রুত এবং খুব দক্ষ।

ডাটাবেসের বাইরে ফাইল পরিবেশন করার অর্থ আপনাকে ডাটাবেস সার্ভারের ডিস্ক থেকে ডেটাবেস সার্ভারের মেমোরিতে ডাটা কপি করতে হবে, তারপরে ডিবি সার্ভারের মেমরি থেকে ডিবি সার্ভারের নেটওয়ার্ক পোর্টে, তারপরে নেটওয়ার্ক থেকে আপনার ওয়েব সার্ভার প্রক্রিয়াতে, তারপরে আবার আউট করতে হবে বহির্গামী নেটওয়ার্ক সংযোগ।

যদি না আসার সত্যিই ভাল কারণ না থাকে তবে ফাইল সিস্টেম থেকে স্থির ফাইলগুলি পরিবেশন করা সর্বদা ভাল।

Comments

এটি সত্য, তবে আমি দেখতে ব্যর্থ হয়েছি যেখানে ব্যবহারকারী এই প্রশ্নে বলেছেন যে তিনি ডাটাবেস থেকে স্থির ফাইলগুলি পরিবেশন করবেন। এটি খুব ভালভাবে ডায়নামিক ফাইল বা ব্যবহারকারী আপলোড করা ফাইল হতে পারে যা ডাটাবেস থেকে পৃথক ফাইল সিস্টেমে সংরক্ষণ করা থাকলে এখনই সিঙ্ক করতে হবে এবং একটি পৃথক ব্যাকআপ / পুনরুদ্ধার প্রক্রিয়া থাকতে হবে।

— maple_shaft

আমার বোঝার প্রশ্নটি হল ব্যবহারকারী-আপলোড করা ফাইলগুলি পরিবেশন করা about "আমি বর্তমানে একটি ওয়েব অ্যাপ্লিকেশন তৈরি করছি যা ব্যবহারকারীদের ফাইল সংরক্ষণ এবং ভাগ করে নেওয়ার সুযোগ দেয় [...] আমার কাছে মনে হয় ফাইলগুলি একটি ডাটাবেসে সংরক্ষণ করা [...]"। আমি মনে করি না যে ডাটাবেসে প্রচুর মাল্টি-মেগাবাইট ব্লব সহ ডিবি ডাম্প করা সত্যিই সুবিধাজনক। এছাড়াও: হ্যাঁ, ফাইলগুলি মোকাবেলা করা কঠিন; সিঙ্ক করা, সংরক্ষণাগারভুক্ত করা সব আরও কঠিন। তবে এটি খুব বেশি কঠিন নয় এবং আপনার রাতের ব্যাকআপ স্ক্রিপ্টে কয়েকটি লাইন সংরক্ষণ করতে অনলাইন পারফরম্যান্স ত্যাগ করা একটি বড় ভুল।

— ইভান পি।

Answer 8

বিখ্যাত টম কিট লিখেছেন যে তারা (ওরাকল) ওরাকল ডাটাবেসটিকে ফাইল সার্ভার হিসাবে ব্যবহার করছে এবং এটি পুরোপুরি সূক্ষ্মভাবে কাজ করছে, সম্পূর্ণ লেনদেনের সাথে, কোনও পারফরম্যান্স ক্ষতির সাথে এবং একক ব্যাকআপ সহ সাধারণ ফাইল সিস্টেম আরও দ্রুত কাজ করছে working

হ্যাঁ, তবে নোট করুন, তারা ওরাকল ডিবি প্রযোজক এবং অন্য কোনও ব্যবহারকারীর জন্য ব্যয় সংক্রান্ত সমস্যা রয়েছে। ফাইল স্টোরেজ করার জন্য ওরাকল এর মতো বাণিজ্যিক ডিবি ব্যবহার করা ব্যয়বহুল।

তবে পোস্টগ্র্রেএসকিউএল সহ উদাহরণস্বরূপ, আপনি কেবল ব্লব স্টোরেজের জন্য অন্য একটি ডিবি ইনস্ট্যান্স চালাতে পারবেন। তারপরে আপনার পুরো ট্রানজেকশনাল সহায়তা রয়েছে। তবে লেনদেনের জন্য ডিবি জায়গার ব্যয় হয়। একাধিক সমবর্তী লেনদেনের জন্য একাধিক ব্লব দৃষ্টান্ত সংরক্ষণের জন্য ডাটাবেসের প্রয়োজন। পোস্টগ্র্রেএসকিউএল-এ এটি সবচেয়ে বেদনাদায়ক, যেহেতু এই ডাটাবেসটি লেনদেনের জন্য তৈরি ব্লবগুলির নকল সংরক্ষণ করে থাকে, এমনকি ভ্যাকুয়াম প্রক্রিয়া না হওয়া পর্যন্ত তাদের আর প্রয়োজন হয় না।

অন্যদিকে ফাইল সিস্টেম স্টোরেজ সহ, কেউ অবশ্যই ফাইলটি সংশোধন করার সময় আপনাকে অবশ্যই খুব যত্নবান হতে হবে, কারণ লেনদেনটি ফিরিয়ে আনা যেতে পারে এবং পুরানো সংস্করণটি আর না দেখা পর্যন্ত ফাইলের অনুলিপি অবশ্যই রাখতে হবে।

যে সিস্টেমে ফাইল কেবল যুক্ত এবং মুছে ফেলা হয় এবং ফাইলগুলিতে লেনদেনের অ্যাক্সেস কোনও সমস্যা নয়, ফাইল সিস্টেম স্টোরেজই আইএমএইচও সেরা পছন্দ।

Comments

হাই, যখন আপনি বলেছেন "ফাইল স্টোরেজ করার জন্য ওরাকলটি কেবল ব্যয়হীন," যদি আমরা ইতিমধ্যে অন্য ফাইল-ফাইলের ডেটা সঞ্চয় করার জন্য ওরাকল ব্যবহার করি? এখনও কি ব্যয় অকার্যকর হবে?

— জিয়াও পেং - ZenUML.com

আর: "কেউ অবশ্যই ফাইলটি সংশোধন করার সময় আপনাকে অবশ্যই খুব যত্নবান হতে হবে" ... প্রাক্তন ওরাকল ডিবিএ হিসাবে আমার পরামর্শ দিতে হবে যে বড় ফাইলগুলি ডাটাবেস থেকে দূরে রাখা উচিত এবং আপনি কখনই ফাইলগুলি সংশোধন করার অনুমতি দেবেন না। মানুষ ভুল করে. এই ফাইলগুলির রোলব্যাক (পূর্বাবস্থান) পরিচালনা করার একমাত্র ব্যবহারিক উপায় হ'ল তাদের জন্য একটি অনুলিপি অনুলিপি সিস্টেম প্রয়োগ করা। সমস্ত সংস্করণ এভাবে রক্ষণাবেক্ষণ এবং সংরক্ষণাগারভুক্ত হয়। প্রাচীনতমটি রিমোট স্টোরেজে চলে যেতে পারে, এক আর্কাইভ ইত্যাদিতে ছোট ছোট পরিবর্তনগুলি একত্রিত করার জন্য পোস্ট করা হয়

— ডকসালভেজার

Answer 9

সাধারণত একটি পৃথক টেবিলের বড় বিএলএবগুলি সংরক্ষণ করা এবং আপনার প্রধান সারণীতে কেবলমাত্র বিএলওবি-র একটি বিদেশী কী উল্লেখ রাখা ভাল। এইভাবে, আপনি এখনও ডাটাবেস থেকে ফাইলটি পুনরুদ্ধার করতে পারেন (সুতরাং আপনার কোনও বিশেষ কোডের দরকার নেই) এবং আপনি বাহ্যিক ডিবি নির্ভরতা (ডিবি এবং ফাইল সিস্টেমকে সিঙ্কে রাখছেন ইত্যাদি) এড়াতে সমস্যাগুলি এড়াতে পারেন, তবে আপনাকে কেবল ওভারহেডই দিতে হবে যদি আপনি স্পষ্টভাবে সেই টেবিলটিতে যোগদান করেন (বা আলাদা কল করুন) make 10 এমবি ভয়ঙ্করভাবে বড় নয়, বেশিরভাগ আধুনিক বাণিজ্যিক ডাটাবেসে কোনও সমস্যা হবে না। আমি ফাইল সিস্টেমে একটি ফাইল সঞ্চয় করার একমাত্র কারণ হ'ল ডাটাবেস ব্যান্ডউইদথকে কেটে ফেলা। যদি আপনার ডাটাবেসগুলি এই ফাইলগুলির প্রচুর পরিমাণে পরিবর্তন ঘটাতে চলেছে তবে আপনাকে কাজের চাপ বিভক্ত করতে হবে এবং কেবল কোনও ধরণের ফাইল ডেস্ক্রিপ্টর সংরক্ষণ করতে হবে। তারপরে অন্য সার্ভার থেকে ফাইলটি লোড করার জন্য আপনার আলাদা কল থাকতে পারে,

Answer 10

আপনি এই সমস্যার মধ্যে কিছু চালাতে পারেন:

• SELECT *বড় অঙ্কুরের সাথে সারি জড়িত এমনটি করতে খুব দীর্ঘ সময় লাগে, এমনকি আপনার যদি বোঁটের প্রয়োজন না হয় (অবশ্যই আপনার নির্দিষ্ট নির্বাচন করা উচিত, তবে কখনও কখনও অ্যাপ্লিকেশনগুলি এভাবে লেখা হয়)
• ব্যাকআপ করতে অনেক বেশি সময় নিতে পারে। আপনার প্রয়োজনের উপর নির্ভর করে ব্যাকআপের সময় আপনার টেবিলগুলি লক করতে হতে পারে, তাই আপনি আপনার ব্যাকআপের সময় কম রাখতে চাইতে পারেন
• পুনরুদ্ধার করতে আরও অনেক বেশি সময় লাগবে।
• যদি আপনার জায়গার বাইরে চলে যায় তবে এই সমস্যাটি সমাধান করার জন্য আপনাকে কিছু উপায় (সম্ভবত পুরো ডাটাবেসটিকে একটি নতুন সার্ভারে সরিয়ে নিয়ে যেতে হবে) ভাবতে হবে। ফাইল সিস্টেমে ফাইলগুলি সংরক্ষণ করে আপনি সর্বদা অন্য হার্ড ড্রাইভটি মাউন্ট করতে পারেন এবং সফট লিঙ্কগুলি সেট করতে পারেন।
• ডিবাগিং বা অন্যান্য তথ্যের জন্য কেবল কোনও ফাইল অনুসন্ধান করা তত সহজ নয়। এর মধ্যে এমন স্ক্রিপ্টগুলি অন্তর্ভুক্ত রয়েছে যার মধ্যে ডাটাবেস অ্যাক্সেস নাও থাকতে পারে তবে বিভিন্ন ফাইল থেকে কিছু তথ্য প্রয়োজন।

অবশ্যই আপনি কিছু সুবিধা পান:

• তারা সিঙ্কে থাকা ডেটা এবং ফাইল মেনু ব্যাক আপ করছে
• ডাটাবেস না জেনে ফাইল সরিয়ে ফেলা সম্ভব নয়
• আপনাকে ডিস্ক থেকে ফাইলটি পড়তে হবে না তবে এটি একটি স্কয়ার স্টেটমেন্টে করতে পারে
• আপনি ডেটাবেস ডাউনলোড করতে পারেন, আপনার বিকাশের পরিবেশের মধ্যে ডাম্প অন্তর্ভুক্ত করতে পারেন এবং সেখানে সমস্ত নির্ভরতা থাকতে পারে

আমি মতামতগুলি তুলনায় অনেক বেশি ভারী দেখায় ব্যক্তিগতভাবে আমি এটি করি না। তবে উপরে বর্ণিত হিসাবে এটি সম্পূর্ণরূপে আপনার ব্যবহারের ক্ষেত্রে এবং এর উপর নির্ভর করে।

Answer 11

সাইটকোরের মতো কিছু এন্টারপিরস কন্টেন্ট ম্যানেজমেন্ট সিস্টেমগুলি পৃষ্ঠার ডেটা সঞ্চয় করার জন্য একটি ডাটাবেস এবং ফাইল সঞ্চয় করার জন্য অন্য একটি ডাটাবেস ব্যবহার করছে। তারা এমএস এসকিউএল সার্ভার ব্যবহার করছে।

Comments

এই প্রশ্ন জিজ্ঞাসা উত্তর কিভাবে?

— মশা

আপনি যদি কিছুটা গবেষণা করেন, তবে আপনি খুঁজে পাবেন যে সাইটকোর একটি অন্যতম জনপ্রিয় এন্টারপ্রাইজ কন্টেন্ট ম্যানেজমেন্ট সিস্টেম। সাইটকোর প্রচুর সংখ্যক যুগ্ম ব্যবহারকারীকে সমর্থন করে এবং খুব ভালভাবে স্কেল করে, তাই হ্যাঁ, আপনি যদি এটি সঠিকভাবে করেন তবে পৃথক ডাটাবেসের মধ্যে ফাইলগুলি সংরক্ষণ করা কোনও খারাপ অভ্যাস নয়।

— jলজেকার

Answer 12

ব্যবহারিক বাস্তবায়নের জন্য, আপনি যে বিষয়টিকে উদ্বেগ করতে পারেন তা এখানে:

Benifits:

1. সমস্ত ফাইলের সামগ্রী অবশ্যই আপনার টেবিলের সাথে সিঙ্ক্রোনাইজ হয়েছে। উপরের মতামত অনুসারে, ডেটা ব্যাক আপ করা পুরোপুরি সুবিধাজনক কারণ আপনার ফাইল সিস্টেমের সাথে ডেটা সিঙ্ক্রোনাইজ করার দরকার নেই।
2. কোডিং থেকে আপনি সরাসরি এসকিউএল নির্বাচন থেকে ফাইল সামগ্রী পেতে পারেন।
3. কোনও প্রশ্ন থেকে, আপনি এসকিউএল স্টেটমেন্ট থেকে স্পষ্টভাবে ফাইল সামগ্রী বা এর আকারও ফিল্টার করতে পারেন।

downsides:

1. কোন কাঠামো অর্থহীনভাবে একই কাঠামোর সাথে তুলনা করে তবে ফাইলের বিষয়বস্তু সংরক্ষণ করে না এমন তুলনামূলক তুলনায় আপনার ডাটাবেসটি কোয়েরি করার সময় মূলত আরও মেমরি গ্রাস করতে থাকে।
2. অটো ব্যাকআপ কার্যকারিতা সমস্যা তৈরি করতে পারে তবে বেশি নয় but আসুন কল্পনা করুন যে আপনার ডাটাবেস সার্ভার প্রতি 6 ঘন্টা অন্তর জিনিসগুলি ব্যাক আপ করছে এবং সেই ডেটাবেসগুলি আপনার কাছে রেকর্ডে 10-এমবি ফাইল সঞ্চয় করছে। সেই দৃশ্যটি আপনি চান তা নয়।