সুতরাং আমি এমন একটি অ্যাপ্লিকেশন ব্যবহার করছি যা ডিবিতে চিত্রগুলি প্রচুর পরিমাণে সঞ্চয় করে। এ সম্পর্কে আপনার দৃষ্টিভঙ্গি কী? আমি সরাসরি ডিবিতে সঞ্চয় করার চেয়ে ফাইল সিস্টেমে লোকেশনটি সঞ্চয় করতে আরও বেশি ধরণের আছি।
আপনার কি মতামত / মতামত আছে?
উত্তর:
আমি এমন কিছু অ্যাপ্লিকেশনের দায়িত্বে রয়েছি যা অনেকগুলি টিবি চিত্র পরিচালনা করে। আমরা খুঁজে পেয়েছি যে ডাটাবেসের মধ্যে ফাইল পাথগুলি সংরক্ষণ করা সর্বোত্তম।
কয়েকটি সমস্যা আছে:
বেশিরভাগ ইস্যুগুলির মতো, এটি যতটা সহজ শোনাচ্ছে তেমন সহজ নয়। এমন অনেকগুলি ক্ষেত্রে রয়েছে যেগুলি ডেটাবেজে চিত্রগুলি সংরক্ষণ করার জন্য এটি বোধগম্য হবে।
অন্যদিকে যুক্ত সমস্যা আছে
ফাইলের দোকান। ফেসবুক ইঞ্জিনিয়ারদের এটি নিয়ে দুর্দান্ত কথা হয়েছিল। একবার হ'ল ডিরেক্টরিতে থাকা ফাইলগুলির ব্যবহারিক সীমাটি জানা ছিল।
এটি কিছুটা লম্বা শট হতে পারে তবে আপনি যদি এসকিউএল সার্ভার ২০০ ব্যবহার করে (বা ব্যবহারের পরিকল্পনা করছেন) তবে আমি নতুন ফাইল স্ট্রিমের ডেটা টাইপের দিকে নজর দেওয়ার পরামর্শ দেব ।
ফাইল স্ট্রিম ডিবিতে ফাইলগুলি সংরক্ষণের প্রায় বেশিরভাগ সমস্যার সমাধান করে:
তবে এসকিউএলের "স্বচ্ছ ডেটা এনক্রিপশন" ফাইল স্ট্রিম অবজেক্টগুলিকে এনক্রিপ্ট করে না, তাই যদি এটি বিবেচনা করা হয় তবে আপনি কেবল সেগুলি ভের্নাইনারি হিসাবে সংরক্ষণ করে রাখা ভাল।
এমএসডিএন নিবন্ধ থেকে:
লেনদেন-এসকিউএল স্টেটমেন্টগুলি সন্নিবেশ, আপডেট, ক্যোয়ারী, অনুসন্ধান এবং FILESTREAM ডেটা ব্যাক আপ করতে পারে। উইন 32 ফাইল সিস্টেম ইন্টারফেসগুলি ডেটাতে স্ট্রিমিং অ্যাক্সেস সরবরাহ করে।
FILESTREAM ফাইলের ডেটা ক্যাশে করার জন্য এনটি সিস্টেম ক্যাশে ব্যবহার করে। এটি FILESTREAM ডেটাতে ডেটাবেস ইঞ্জিনের কার্য সম্পাদনে যে প্রভাব থাকতে পারে তা হ্রাস করতে সহায়তা করে। এসকিউএল সার্ভার বাফার পুল ব্যবহৃত হয় না; অতএব, এই মেমরিটি ক্যোয়ারী প্রসেসিংয়ের জন্য উপলব্ধ।
ডিবিতে ফাইলের পাথগুলি অবশ্যই যাওয়ার উপায় - আমি ছবিগুলির টিবি সহ গ্রাহকদের কাছ থেকে গল্প শুনেছি গল্পটি শুনেছি যে এটি কোনও দুঃস্বপ্ন হয়ে যায় যে কোনও ডিবিতে কোনও উল্লেখযোগ্য পরিমাণে চিত্র সঞ্চয় করার চেষ্টা করে - একা অভিনয়টি খুব বেশি হয়।
আমার অভিজ্ঞতাতে, কখনও কখনও সহজ সমাধানটি প্রাথমিক কী অনুসারে চিত্রের নামকরণ হয় । সুতরাং নির্দিষ্ট রেকর্ডের অন্তর্ভুক্ত চিত্রটি পাওয়া সহজ এবং এর বিপরীতে। তবে একই সাথে আপনি ডাটাবেসে চিত্রটি সম্পর্কে কোনও কিছু সঞ্চয় করছেন না ।
এখানে কৌশলটি একজন উদ্যোগী না হওয়া।
এখানে একটি বিষয় লক্ষণীয় যে প্রো ফাইল সিস্টেম ক্যাম্পের মধ্যে কেউই একটি নির্দিষ্ট ফাইল সিস্টেম তালিকাভুক্ত করেনি। এর অর্থ কি এফএটি 16 থেকে জেডএফএস পর্যন্ত প্রত্যেকটি ডাটাবেস হ্যান্ডলি মারে?
না।
সত্যটি হ'ল অনেক ডাটাবেস অনেকগুলি ফাইল সিস্টেমকে পরাজিত করে, এমনকি যখন আমরা কেবল কাঁচা গতির কথা বলি।
কর্মের সঠিক কোর্সটি হল আপনার সুনির্দিষ্ট দৃশ্যের জন্য সঠিক সিদ্ধান্ত নেওয়া এবং এটি করার জন্য আপনার কয়েকটি নম্বর এবং কিছু ব্যবহারের ক্ষেত্রে প্রাক্কলন প্রয়োজন।
যে জায়গাগুলিতে আপনি অবশ্যই রেফারেন্সিয়াল অখণ্ডতা এবং এসিআইডি সম্মতির গ্যারান্টি দিতে হবে সেখানে ডাটাবেসে চিত্র সংরক্ষণের প্রয়োজন।
আপনি লেনদেনের গ্যারান্টি দিতে পারবেন না যে ডাটাবেসে সঞ্চিত সেই চিত্রটি সম্পর্কিত চিত্র এবং মেটা-ডেটা একই ফাইলটিকে বোঝায়। অন্য কথায়, গ্যারান্টি দেওয়া অসম্ভব যে ফাইল সিস্টেমের ফাইলটি কেবল একই সময়ে এবং মেটাডেটার মতো একই লেনদেনে পরিবর্তিত হয়।
অন্যরা যেমন বলেছে যে এসকিউএল ২০০৮ একটি ফাইল স্ট্রিম টাইপ নিয়ে আসে যা আপনাকে একটি ফাইলের নাম বা সনাক্তকারীকে ডিবিতে পয়েন্টার হিসাবে সঞ্চয় করতে দেয় এবং স্বয়ংক্রিয়ভাবে আপনার ফাইল সিস্টেমে চিত্রটি সঞ্চয় করে যা একটি দুর্দান্ত দৃশ্য।
আপনি যদি কোনও পুরানো ডাটাবেসে থাকেন তবে আমি বলব যে আপনি যদি এটি ব্লব ডেটা হিসাবে সংরক্ষণ করেন তবে আপনি বৈশিষ্ট্যগুলি অনুসন্ধানের পথে ডাটাবেস থেকে সত্যিই কিছু পাবেন না, তাই সম্ভবত এটি সবচেয়ে ভাল একটি ফাইল সিস্টেমে একটি ঠিকানা সঞ্চয় করতে, এবং চিত্রটি সেভাবে সঞ্চয় করতে।
আপনি কেবল ফাইল সিস্টেমে স্থান বাঁচাতে পারেন, কারণ আপনি কেবলমাত্র ফাইল সিস্টেমের মধ্যে ঠিক পরিমাণের পরিমাণ বা কমপ্যাক্ট স্পেস সংরক্ষণ করতে যাচ্ছেন।
এছাড়াও, আপনি এমন কোনও কাঠামো বা উপাদানগুলির সাহায্যে সংরক্ষণের সিদ্ধান্ত নিতে পারেন যা আপনাকে কোনও ডিবি হিট ছাড়াই আপনার ফাইল সিস্টেমে কাঁচা চিত্রগুলি ব্রাউজ করার অনুমতি দেয় বা বাল্কে ফাইলগুলি অন্য সিস্টেমে স্থানান্তর করতে পারে, হার্ড ড্রাইভ, এস 3 বা অন্য কোনও দৃশ্যে - অবস্থান আপডেট করে আপনার প্রোগ্রাম, কিন্তু স্টোরেজ বাড়ানোর চেষ্টা করার সময় চিত্রগুলি আপনার ডিবি থেকে বের করে আনার চেষ্টা করেও হিট না করে আবার কাঠামোটি রাখুন।
সম্ভবত, এটি আপনাকে আপনার ওয়েব ইঞ্জিন / প্রোগ্রামে সাধারণত হিট ইমেজ ইউআরএলগুলির উপর ভিত্তি করে কিছু ক্যাচিং উপাদান নিক্ষেপ করার অনুমতি দেয়, সুতরাং আপনি সেখানে নিজেকেও সংরক্ষণ করছেন।
ছোট স্ট্যাটিক চিত্রগুলি (বেশ কয়েকটি মেগের বেশি নয়) যা প্রায়শই সম্পাদিত হয় না, তা ডাটাবেসে সংরক্ষণ করা উচিত। এই পদ্ধতিতে সহজ বহনযোগ্যতা (চিত্রগুলি ডাটাবেসের সাথে স্থানান্তরিত করা হয়), সহজ ব্যাকআপ / পুনরুদ্ধার (চিত্রগুলি ডাটাবেসের সাহায্যে ব্যাক আপ করা হয়) এবং আরও ভাল স্কেলেবিলিটি (হাজার হাজার ছোট থাম্বনেইল ফাইল সহ একটি ফাইল সিস্টেম ফোল্ডার এটিকে স্কেলিবিলিটি দুঃস্বপ্নের মতো মনে হয়) আমাকে).
একটি ডাটাবেস থেকে চিত্রগুলি পরিবেশন করা সহজ, কেবল একটি HTTP হ্যান্ডলার বাস্তবায়ন করুন যা বাইনারি স্ট্রিম হিসাবে ডিবি সার্ভার থেকে ফিরে আসা বাইট অ্যারে পরিবেশন করে।
এখানে বিষয়ের একটি আকর্ষণীয় সাদা কাগজ paper
ব্লগ করতে বা না করতে ব্লগ করতে: একটি ডাটাবেস বা একটি ফাইল সিস্টেমে বড় অবজেক্ট স্টোরেজ
উত্তরটি হল, এটা নির্ভরশীল." অবশ্যই এটি ডাটাবেস সার্ভার এবং ব্লব স্টোরেজ সম্পর্কিত তার পদ্ধতির উপর নির্ভর করবে। এটি ব্লবগুলিতে কীভাবে ডেটা সংরক্ষণ করা হচ্ছে তার পাশাপাশি সেই তথ্য কীভাবে অ্যাক্সেস করা হয় তার উপরও নির্ভর করে।
ছোট আকারের ফাইলগুলি স্টোরেজ প্রক্রিয়া হিসাবে ডেটাবেস ব্যবহার করে দক্ষতার সাথে সঞ্চয় করা এবং বিতরণ করা যেতে পারে। বড় ফাইলগুলি সম্ভবত ফাইল সিস্টেমটি ব্যবহার করে সবচেয়ে ভাল সঞ্চয় করা হবে, বিশেষত যদি সেগুলি প্রায়শই পরিবর্তন / আপডেট করা হয়। (ব্লব টুকরা পারফরম্যান্সের ক্ষেত্রে একটি ইস্যু হয়ে ওঠে।)
মনে রাখার জন্য এখানে একটি অতিরিক্ত বিষয়। ব্লবগুলি সংরক্ষণের জন্য একটি ডাটাবেস ব্যবহারকে সমর্থন করার একটি কারণ হ'ল এসিডি সম্মতি। যাইহোক, পরীক্ষকরা সাদা কাগজে যে পদ্ধতির ব্যবহার করেছিলেন, (এসকিউএল সার্ভারের বাল্ক লগড অপশন), যা এসকিউএল সার্ভারের মধ্য দিয়ে দ্বিগুণ হয়ে গেছে, কার্যকরভাবে এসিআইডি-তে 'ডি' পরিবর্তন করে একটি 'ডি' করেছে, কারণ ব্লব ডেটা লগ করা হয়নি as প্রাথমিক লেনদেনের জন্য লেখেন। সুতরাং, যদি সম্পূর্ণ এসিডি সম্মতি আপনার সিস্টেমের জন্য একটি গুরুত্বপূর্ণ প্রয়োজন হয়, ডাটাবেসের ব্লগ আই / ও ফাইলের সাথে আই / ও ফাইলের তুলনা করার সময় ডাটাবেসের জন্য এসকিউএল সার্ভার থ্রুপুট পরিসংখ্যান অর্ধেক করে দিন।
একটি জিনিস যা আমি এখনও কাউকে উল্লেখ করতে দেখিনি তবে অবশ্যই লক্ষ্য করার মতো এটি হ'ল বেশিরভাগ ফাইল সিস্টেমেও প্রচুর পরিমাণে চিত্র সংরক্ষণ করার সাথে সম্পর্কিত সমস্যা রয়েছে। উদাহরণস্বরূপ, যদি আপনি উপরে বর্ণিত পদ্ধতিটি গ্রহণ করেন এবং প্রতিটি কী ফাইলের নাম প্রাথমিক কী অনুসারে রাখেন, বেশিরভাগ ফাইল সিস্টেমে আপনি সমস্যার সমাধান করতে পারবেন যদি আপনি খুব বড় সংখ্যক চিত্রের কাছে পৌঁছে যান তবে আপনি সমস্ত চিত্রকে একটি বড় ডিরেক্টরিতে রাখার চেষ্টা করেন ( যেমন কয়েক হাজার বা মিলিয়ন) millions
এর সাধারণ সমাধান হ'ল এগুলি হ'ল সাব ডাইরেক্টরিগুলির সুষম গাছগুলিতে নিয়ে যাওয়া।
কেউই কিছু উল্লেখ করেন নি যে ডিবি পারমাণবিক ক্রিয়াকলাপ, লেনদেনের অখণ্ডতা এবং একত্রে চুক্তির নিশ্চয়তা দেয়। এমনকি উল্লেখযোগ্যভাবে অখণ্ডতা একটি ফাইল সিস্টেমের সাথে উইন্ডোটির বাইরে রয়েছে - সুতরাং আপনি কীভাবে জানবেন যে আপনার ফাইলের নামগুলি এখনও সত্য?
যদি আপনার ছবিগুলি কোনও ফাইল-সিস্টেমে থাকে এবং কেউ যদি নতুন সংস্করণ লিখছেন বা এমনকী ফাইলটি মোছার কারণেও ফাইলটি পড়ছেন - তবে কি হবে?
আমরা ব্লবগুলি ব্যবহার করি কারণ এগুলি পরিচালনা করতেও খুব সহজ (ব্যাকআপ, প্রতিলিপি, স্থানান্তর)। তারা আমাদের জন্য ভাল কাজ।
একটি ডাটাবেসে চিত্রগুলিতে কেবল ফাইলপথগুলি সঞ্চয় করার সমস্যাটি হ'ল ডাটাবেসের সততা আর জোর করা যায় না।
যদি ফাইলপথের দ্বারা নির্দেশিত প্রকৃত চিত্রটি অনুপলব্ধ হয়ে যায়, অজান্তেই ডাটাবেসটির অখণ্ডতা ত্রুটি রয়েছে।
চিত্রগুলি হ'ল প্রকৃত ডেটা যাচাই করা হচ্ছে এবং কোনও একধরণের ফাইল সিস্টেমের সাথে ইন্টারফেস করার পরিবর্তে (চিত্রগুলি হ'ল চিত্রগুলি হঠাৎ অদৃশ্য হবে না) সহজেই পরিচালিত হতে পারে (যদি ফাইল সিস্টেমটি স্বাধীনভাবে অ্যাক্সেস করা থাকে, চিত্রগুলি হঠাৎ করেই "অদৃশ্য হয়ে যাবে"), আমি এগুলি সরাসরি একটি ব্লগ বা এ জাতীয় হিসাবে সঞ্চয় করতে যাব।
এমন একটি সংস্থায় যেখানে আমি কাজ করতাম আমরা একটি ওরাকল 8 আই (তখন 9 আই) ডাটাবেসে 155 মিলিয়ন ইমেজ সংরক্ষণ করি stored 7.5TB মূল্য।
সাধারণত, আমি আপনার অবকাঠামো (ডাটাবেস) এর অংশটি স্কেল করতে সবচেয়ে ব্যয়বহুল এবং কঠিনতম গ্রহণ এবং এর মধ্যে সমস্ত বোঝা againstোকানোর বিরুদ্ধে দৃor়ভাবে আছি। অন্যদিকে: এটি ব্যাকআপ কৌশলটি সহজতর করে, বিশেষত যখন আপনার একাধিক ওয়েব সার্ভার থাকে এবং কোনও উপায়ে ডেটা সিঙ্ক্রোনাইজ করা প্রয়োজন need
অন্যান্য জিনিসগুলির মতো এটিও প্রত্যাশিত আকার এবং বাজেটের উপর নির্ভর করে।
আমরা একটি ডকুমেন্ট ইমেজিং সিস্টেম প্রয়োগ করেছি যা এসকিউএল ২০০৫ ব্লাব ক্ষেত্রগুলিতে এর সমস্ত চিত্র সঞ্চয় করে। এই মুহুর্তে বেশ কয়েকশ জিবি রয়েছে এবং আমরা দুর্দান্ত প্রতিক্রিয়ার সময়গুলি দেখছি এবং অল্প বা কোনও কার্যকারিতা হ্রাস পাচ্ছি। এছাড়াও, নিয়ন্ত্রক সম্মতিতে, আমাদের মধ্যে একটি মিডওয়্যার স্তর রয়েছে যা একটি নতুন অপটিক্যাল জুকবক্স সিস্টেমে নতুন পোস্ট করা নথি সংরক্ষণাগারভুক্ত করে যা সেগুলি স্ট্যান্ডার্ড এনটিএফএস ফাইল সিস্টেম হিসাবে প্রকাশ করে।
আমরা ফলাফলগুলি নিয়ে খুব সন্তুষ্ট হয়েছি, বিশেষত:
অনুমান: অ্যাপ্লিকেশনটি ওয়েব সক্ষম / ওয়েব ভিত্তিক
আমি আশ্চর্য হয়েছি কেউই এটির সত্যই উল্লেখ করেনি ... বিশেষজ্ঞরা অন্যদের কাছে এটি অর্পণ করুন -> একটি তৃতীয় পক্ষের চিত্র / ফাইল হোস্টিং সরবরাহকারী ব্যবহার করুন ।
আপনার ফাইলগুলিকে কোনও প্রদত্ত অনলাইন পরিষেবাতে সঞ্চয় করুন
আরেকটি স্ট্যাকওভারফ্লো থ্রেড এখানে এ সম্পর্কে কথা বলছে ।
এই থ্রেডটি ব্যাখ্যা করে যে আপনার তৃতীয় পক্ষের হোস্টিং সরবরাহকারী কেন ব্যবহার করা উচিত।
এটা এত মূল্য। তারা এটি দক্ষতার সাথে সঞ্চয় করে। আপনার সার্ভার থেকে ক্লায়েন্টের অনুরোধ ইত্যাদিতে কোনও ব্যান্ডউইড আপলোড হচ্ছে না etc.
আপনি যদি এসকিউএল সার্ভার ২০০৮ এ না থাকেন এবং ডাটাবেসে নির্দিষ্ট চিত্র ফাইল রাখার কিছু দৃ reasons় কারণ থাকে তবে আপনি "উভয়" পদ্ধতির গ্রহণ করতে পারেন এবং ফাইল সিস্টেমটিকে অস্থায়ী ক্যাশে হিসাবে ব্যবহার করতে পারেন এবং ডাটাবেসটিকে মাস্টার সংগ্রহস্থল হিসাবে ব্যবহার করতে পারেন ।
উদাহরণস্বরূপ, আপনার ব্যবসায়ের যুক্তি পরীক্ষা করতে পারে যে কোনও চিত্র ফাইল সরবরাহ করার আগে ডিস্কে উপস্থিত রয়েছে কিনা, প্রয়োজনে ডাটাবেস থেকে পুনরুদ্ধার করা। এটি আপনাকে একাধিক ওয়েব সার্ভারের ক্ষমতা এবং কম সিঙ্ক সমস্যার সমাধান কিনে।
আমি এটি "সত্যিকারের বিশ্বের" উদাহরণটি কতটা তা নিশ্চিত নই, তবে আমার বর্তমানে একটি অ্যাপ্লিকেশন রয়েছে যা কার্ডের জন্য চিত্রগুলি সহ একটি ট্রেডিং কার্ড গেমের জন্য বিশদ সংরক্ষণ করে। মঞ্জুর করা ডাটাবেসের জন্য রেকর্ড গণনাটি আজ অবধি কেবল 2851 রেকর্ড, তবে নির্দিষ্ট কার্ডগুলি একাধিকবার প্রকাশিত হয়েছে এবং বিকল্প শিল্পকর্ম রয়েছে তা দেখিয়ে শিল্পকর্মের "প্রাথমিক বর্গক্ষেত্র" স্ক্যান করার জন্য এটি আরও কার্যকর আকারের ছিল এবং তারপরে গতিশীলভাবে অনুরোধ করা হলে কার্ডের জন্য সীমানা এবং বিবিধ প্রভাব তৈরি করুন।
এই চিত্র গ্রন্থাগারের মূল স্রষ্টা একটি ডেটা অ্যাক্সেস ক্লাস তৈরি করেছিলেন যা অনুরোধের ভিত্তিতে চিত্রটিকে রেন্ডার করে এবং এটি দেখার এবং স্বতন্ত্র কার্ডের জন্য এটি বেশ দ্রুত করে।
এটি নতুন কার্ডগুলি প্রকাশের সময় স্থাপনা / আপডেটগুলিকে সহজ করে দেয়, চিত্রগুলির পুরো ফোল্ডারটি জিপ করে এবং পাইপগুলির নীচে প্রেরণ না করে এবং সঠিক ফোল্ডার কাঠামোটি তৈরি হয় তা নিশ্চিত করার পরিবর্তে, আমি কেবল ডাটাবেস আপডেট করি এবং ব্যবহারকারীকে আবার ডাউনলোড করতে পারি have বর্তমানে এটি 56MB অবধি মাপসই, যা দুর্দান্ত নয় তবে আমি ভবিষ্যতের প্রকাশের জন্য বর্ধিত আপডেট বৈশিষ্ট্যে কাজ করছি। এছাড়াও, অ্যাপ্লিকেশনটির একটি "কোনও চিত্র নেই" সংস্করণ রয়েছে যা ডায়াল-আপগুলি তাদের ডাউনলোডের বিলম্ব ছাড়াই অ্যাপ্লিকেশন পেতে দেয়।
এই সমাধানটি আজ পর্যন্ত দুর্দান্ত কাজ করেছে যেহেতু অ্যাপ্লিকেশনটি নিজেই ডেস্কটপে একক উদাহরণ হিসাবে লক্ষ্যযুক্ত। একটি ওয়েব সাইট রয়েছে যেখানে এই সমস্ত ডেটা অনলাইন অ্যাক্সেসের জন্য সংরক্ষণাগারযুক্ত, তবে আমি কোনওভাবেই এর জন্য একই সমাধানটি ব্যবহার করতে চাই না। আমি সম্মত হয়েছি যে ফাইলের অ্যাক্সেস পছন্দনীয় হবে কারণ এটি চিত্রগুলির জন্য অনুরোধের ফ্রিকোয়েন্সি এবং ভলিউমের তুলনায় আরও ভাল হবে।
আশা করি এটি খুব বেশি উদ্বেগজনক নয়, তবে আমি বিষয়টি দেখেছি এবং অপেক্ষাকৃত সফল ছোট / মাঝারি স্কেল অ্যাপ্লিকেশন থেকে আমার অন্তর্দৃষ্টি সরবরাহ করতে চেয়েছিলাম।
এসকিউএল সার্ভার ২০০৮ এমন একটি সমাধান দেয় যা উভয় পৃথিবীর মধ্যে সেরা: ফাইল স্ট্রিমের ডেটা টাইপ ।
এটি নিয়মিত টেবিলের মতো পরিচালনা করুন এবং ফাইল সিস্টেমের কর্মক্ষমতা রাখুন।
এটি আপনি যে সমস্ত চিত্র সঞ্চয় করতে যাচ্ছেন তার সংখ্যা এবং তার আকারের উপরও নির্ভর করে। আমি অতীতে চিত্রগুলি সঞ্চয় করতে ডাটাবেস ব্যবহার করেছি এবং আমার অভিজ্ঞতা মোটামুটি ভাল।
আইএমও, চিত্র সংরক্ষণ করার জন্য ডাটাবেস ব্যবহার করার প্রসেস হ'ল
উ: আপনার ছবিগুলি ধরে রাখার জন্য আপনার এফএস কাঠামোর দরকার নেই
খ। বেশি সংখ্যক আইটেম সংরক্ষণ করার সময় ডাটাবেস সূচীগুলি এফএস গাছের চেয়ে আরও
ভাল পারফর্ম করে
D. ব্যাকআপগুলি সহজ। যদি আপনার প্রতিলিপি সেট আপ থাকে এবং ব্যবহারকারীর কাছাকাছি কোনও সার্ভার থেকে সামগ্রী বিতরণ করা হয় তবে এটিও ভাল কাজ করে। এই ধরনের ক্ষেত্রে, সুস্পষ্ট সিঙ্ক্রোনাইজেশন প্রয়োজন হয় না।
যদি আপনার চিত্রগুলি ছোট হতে চলেছে (তবে <<৪ কে বলুন) এবং আপনার ডিবির স্টোরেজ ইঞ্জিনটি ইনলাইন (রেকর্ডে) সমর্থন করে বিএলএলও, কোনও দিকনির্দেশনা প্রয়োজন না হওয়ায় এটি আরও কার্যকারিতা উন্নত করে (স্থানীয়করণের রেফারেন্স অর্জন করা হয়)।
আপনি যখন অল্প সংখ্যক বিশাল আকারের চিত্র নিয়ে কাজ করছেন তখন চিত্র সংরক্ষণ করা খারাপ ধারণা হতে পারে। ডিবিতে চিত্রগুলি সংরক্ষণ করার সাথে আরেকটি সমস্যা হ'ল, তৈরির মতো মেটাডেটা, পরিবর্তনের তারিখগুলি অবশ্যই আপনার অ্যাপ্লিকেশন দ্বারা পরিচালিত হবে।
আমি সম্প্রতি একটি পিএইচপি / মাইএসকিউএল অ্যাপ্লিকেশন তৈরি করেছি যা একটি মাইএসকিউএল টেবিলের মধ্যে পিডিএফ / ওয়ার্ড ফাইল সঞ্চয় করে (এখন পর্যন্ত ফাইলের হিসাবে 40 এমবি হিসাবে বড়)।
পেশাদাররা:
কনস:
আমি আমার বাস্তবায়নটিকে একটি সাফল্য বলব, এটি ব্যাকআপের প্রয়োজনীয়তার যত্ন নেয় এবং প্রকল্পের বিন্যাসকে সহজ করে দেয়। অ্যাপ্লিকেশনটি ব্যবহার করে এমন 20-30 লোকের জন্য পারফরম্যান্সটি দুর্দান্ত।
আমার অভিজ্ঞতা আমি উভয় পরিস্থিতি পরিচালনা করতে হয়েছিল: ডিবিতে সঞ্চিত পথ সহ ফাইল সিস্টেমে ডেটাবেস এবং চিত্রগুলিতে সঞ্চিত চিত্রগুলি।
প্রথম সমাধান, ডাটাবেসে চিত্রগুলি কিছুটা "ক্লিনার" কারণ আপনার ডেটা অ্যাক্সেস লেয়ারটি কেবল ডাটাবেস অবজেক্টের সাথেই মোকাবেলা করতে হবে; তবে এটি তখনই ভাল যখন আপনার কম সংখ্যার সাথে ডিল করতে হবে।
স্পষ্টতই যখন আপনি বাইনারি বড় অবজেক্টগুলির সাথে ডিল করেন তখন ডেটাবেস অ্যাক্সেসের কার্যকারিতা হ্রাস পাচ্ছে এবং ডাটাবেসগুলির মাত্রা অনেক বেড়ে যাবে যার ফলে আবার কার্যকারিতা হ্রাস পাবে ... এবং সাধারণত ফাইল সিস্টেমের জায়গার চেয়ে ডাটাবেসের স্পেস অনেক বেশি ব্যয়বহুল।
অন্যদিকে ফাইল সিস্টেমে বড় বাইনারি অবজেক্টগুলি রাখার ফলে আপনাকে ব্যাকআপ পরিকল্পনা করতে হবে যা ডাটাবেস এবং ফাইল সিস্টেম উভয় বিবেচনা করতে হবে এবং এটি কিছু সিস্টেমের জন্য সমস্যা হতে পারে।
ফাইল সিস্টেমে যাওয়ার আরেকটি কারণ হ'ল যখন আপনার তৃতীয় পক্ষের অ্যাক্সেসের সাথে আপনার চিত্রগুলির ডেটা (বা শব্দ, ভিডিও, যাই হোক না কেন) ভাগ করতে হয়: এই দিনগুলিতে আমি একটি ওয়েব অ্যাপ্লিকেশন বিকাশ করছি যা "বাইরের" থেকে অ্যাক্সেস করতে হবে এমন চিত্রগুলি ব্যবহার করে "আমার ওয়েব ফার্মটি এমনভাবে যাতে বাইনারি ডেটা পুনরুদ্ধার করার জন্য একটি ডাটাবেস অ্যাক্সেস কেবল অসম্ভব। তাই কখনও কখনও ডিজাইনের বিবেচনাগুলিও থাকে যা আপনাকে কোনও পছন্দে চালিত করে।
এই পছন্দটি করার সময়, আপনিও বিবেচনা করুন, বাইনারি বস্তুগুলিতে অ্যাক্সেস করার সময় আপনাকে যদি অনুমতি এবং প্রমাণীকরণের সাথে মোকাবিলা করতে হয়: এই প্রয়োজনীয়তাগুলি সাধারণত ডিবিতে সংরক্ষণ করা হয় তখন একটি সহজ উপায়ে সমাধান করা যেতে পারে।
আমি একবার একটি ইমেজ প্রসেসিং অ্যাপ্লিকেশন উপর কাজ করেছি। আমরা একটি ডিরেক্টরিতে আপলোড করা চিত্রগুলি সঞ্চয় করেছিলাম যা কিছু কিছু ছিল / চিত্র / [আজকের তারিখ] / [আইডি নম্বর]। তবে আমরা চিত্রগুলি থেকে মেটাডেটা (এক্সিফ ডেটা )ও বের করেছি এবং এটি একটি টাইমস্ট্যাম্প এবং এর সাথে ডেটাবেজে সংরক্ষণ করেছি।
পূর্ববর্তী একটি প্রকল্পে আমি ফাইল সিস্টেমে চিত্রগুলি সঞ্চয় করেছিলাম এবং এর ফলে ব্যাকআপ, প্রতিলিপি এবং ফাইল সিস্টেমটি ডাটাবেসের সাথে সিঙ্কের বাইরে চলে যাওয়ার কারণে প্রচুর মাথা ব্যথা করে।
আমার সর্বশেষ প্রকল্পে আমি ডেটাবেজে চিত্রগুলি সঞ্চয় করছি এবং ফাইল সিস্টেমে তাদের ক্যাশে করছি, এবং এটি সত্যই ভাল কাজ করে। আমার এখন পর্যন্ত কোনও সমস্যা হয়নি।
দ্বিতীয় ফাইলের পাথের বিষয়ে সুপারিশ। আমি বেশ কয়েকটি প্রকল্পে কাজ করেছি যেগুলি বড়-ইশ সম্পদ সংগ্রহ পরিচালনা করার জন্য প্রয়োজন, এবং সরাসরি ডিবিতে জিনিস সংরক্ষণের যে কোনও প্রচেষ্টা ব্যর্থতা এবং হতাশার ফলে দীর্ঘমেয়াদী হয়েছিল।
কেবলমাত্র "প্রো" আমি ডিবিতে তাদের সংরক্ষণের বিষয়ে ভাবতে পারি তা হ'ল স্বতন্ত্র চিত্রের সম্পদের সহজ সম্ভাবনা। যদি ব্যবহারের জন্য কোনও ফাইল পাথ না থাকে এবং সমস্ত চিত্র সরাসরি ডিবি থেকে প্রবাহিত হয় তবে কোনও ব্যবহারকারীর এমন ফাইল খুঁজে পাওয়ার কোনও ঝুঁকি নেই যা তাদের অ্যাক্সেস না করে should
এটি দেখে মনে হচ্ছে এটি কোনও ওয়েব-অ্যাক্সেসযোগ্য ফাইল স্টোর থেকে ডেটার টানে মধ্যস্থতাকারী স্ক্রিপ্টের সাথে আরও ভাল সমাধান করা সম্ভব। সুতরাং ডিবি স্টোরেজটি আসলেই প্রয়োজনীয় নয়।
রাস্তার শব্দটি হ'ল আপনি যদি কোনও ডাটাবেস বিক্রেতার প্রমাণ না দিয়ে চেষ্টা করেন যে আপনার ডাটাবেসটি এটি করতে পারে (যেমন ধরুন, মাইক্রোসফ্ট টেরার্সভার এসকিউএল সার্ভারে বাজিলিয়ান চিত্রগুলি সংরক্ষণ করার বিষয়ে মাইক্রোসফ্টের অভিমান করে) এটি খুব ভাল ধারণা নয়। বিকল্প - যখন ডাটাবেসে ফাইল সার্ভার এবং পাথগুলিতে চিত্রগুলি সংরক্ষণ করা এত সহজ হয় তবে কেন বিরক্ত হন? ব্লব ক্ষেত্রগুলি এক প্রকারের এসইউভিগুলির অফ-রোড ক্ষমতার মতো - বেশিরভাগ লোক এগুলি ব্যবহার করে না, যারা সাধারণত সমস্যায় পড়ে, এবং তারপরে এমনগুলি রয়েছে যারা কেবল মজাদার জন্য।
ডাটাবেসে কোনও চিত্র সঞ্চয় করার অর্থ এখনও ইমেজ ডেটা ফাইল সিস্টেমে কোথাও শেষ হয় তবে অস্পষ্ট হয় যাতে আপনি সরাসরি এটি অ্যাক্সেস করতে পারবেন না।
+ + Ves:
-ves:
উভয় পদ্ধতিই সাধারণ এবং অনুশীলনযোগ্য। এর সুবিধা এবং অসুবিধাগুলি একবার দেখুন। যেভাবেই হোক, অসুবিধাগুলি কীভাবে কাটিয়ে উঠতে হবে সে সম্পর্কে আপনাকে ভাবতে হবে। ডাটাবেসে সংরক্ষণ করার অর্থ সাধারণত ডাটাবেস প্যারামিটারগুলি টুইট করা এবং একরকম ক্যাশে প্রয়োগ করা। ফাইল সিস্টেম ব্যবহার করার জন্য আপনার ফাইল সিস্টেম + ডাটাবেস সিঙ্কে রাখার কিছু উপায় খুঁজে পাওয়া দরকার।