বাইনারি ফাইলগুলি ডাটাবেসে সংরক্ষণ করা উচিত?

Question

আপনার ডাটাবেসের ডেটার সাথে সম্পর্কিত বাইনারি ফাইলগুলি সংরক্ষণ করার জন্য সেরা জায়গাটি কী? আপনার উচিত:

1. একটি ব্লাব সঙ্গে ডাটাবেস সংরক্ষণ করুন
2. ডাটাবেসে একটি লিঙ্ক সহ ফাইল সিস্টেমে সঞ্চয় করুন
3. ফাইল সিস্টেমে সংরক্ষণ করুন তবে বিষয়বস্তুর একটি হ্যাশটির নতুন নাম দিন এবং হ্যাশটি ডাটাবেসে সংরক্ষণ করুন
4. এমন কিছু যা আমি ভেবে দেখিনি

(1) এর সুবিধা (অন্যদের মধ্যে) হ'ল লেনদেনের পারমাণবিকতা সংরক্ষণ করা হয়। ব্যয়টি হ'ল আপনি নাটকীয়ভাবে স্টোরেজ (এবং সম্পর্কিত স্ট্রিমিং / ব্যাকআপ) প্রয়োজনীয়তা বাড়িয়ে তুলতে পারেন

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

সম্পাদনা করুন:

দেখে মনে হচ্ছে কিছু আরডিবিএমএস তাদের স্বতন্ত্র উপায়ে coveredেকে রেখেছে - আমি কীভাবে অন্যেরা এটি করি তা জানতে আগ্রহী হব - এবং বিশেষত পোস্টগ্রিজের সমাধানে

Comments

এই প্রশ্নের এখানে একটি সদৃশ রয়েছে: একটি ব্লব বা কেবল url এ চিত্রগুলি সংরক্ষণ করা ভাল? এটি এইটির পক্ষে বন্ধ ছিল, কারণ এটি আরও অসামান্য। আরও অন্তর্দৃষ্টি জন্য উভয় প্রশ্ন পড়তে ভুলবেন না!

— মারিয়ান

Answer 1

1. একটি ব্লাব সঙ্গে ডাটাবেস সংরক্ষণ করুন

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

2. ডাটাবেসে একটি লিঙ্ক সহ ফাইল সিস্টেমে সঞ্চয় করুন

   আমি এইরকম ভয়াবহ বিপর্যয় পেরিয়ে এসেছি এবং এটি আমাকে ভয় দেখায় যে লোকেরা এটিকে পরামর্শ দিয়ে চলেছে। কয়েকটি বিপর্যয়ের অন্তর্ভুক্ত:

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

3. ফাইল সিস্টেমে সংরক্ষণ করুন তবে বিষয়বস্তুর একটি হ্যাশটির নতুন নাম দিন এবং হ্যাশটি ডাটাবেসে সংরক্ষণ করুন

   উপরের পরিস্থিতিতে আমার ব্যাখ্যার উপর ভিত্তি করে আমি সর্বশেষে এটি কাজ করেছি this তারা ভেবেছিল যে এটি বৃহত ডাটাবেসগুলির সাথে অভিজ্ঞতা অর্জনে সংস্থার অক্ষমতা (প্রায় 40 জি এর চেয়ে বড় কিছু "খুব বড়" হিসাবে নির্ধারিত হয়েছিল), বৃহত্তর হার্ড ড্রাইভগুলি কেনার কর্পোরেট অক্ষমতা এবং আরও আধুনিক পিছনে কেনার অক্ষমতার মধ্যে একটি আপস was আপ সমাধান, এবং আমি উপরে চিহ্নিত করা ঝুঁকি # 1 & # 3 থেকে দূরে সরে যাওয়ার প্রয়োজনীয়তা।

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

Comments

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

— ফিল লেলো

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

— আলী রাজেঝি

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

— টেক

Answer 2

সম্পূর্ণ ডেটা অখণ্ডতার জন্য নম্বর 1। আপনি যদি ডেটার কোয়ালিটির বিষয়ে চিন্তা না করেন তবে অন্যান্য বিকল্পগুলি ব্যবহার করুন। এটা খুব সহজ।

বেশিরভাগ আরডিবিএমএসের যে কোনও উপায়ে BLOBs (যেমন এসকিউএল সার্ভার ফাইল স্ট্রিম) সংরক্ষণ করার জন্য অনুকূলিতকরণ রয়েছে

Comments

এটি কী সম্পর্কে (3) বিশেষত যা ডেটা অখণ্ডতার ঝুঁকিতে ফেলেছে? (আপনি অধিকার আপনার লেনদেনের এপিআই পেতে অভিমানী)

— জ্যাক ডগলাস

@ জ্যাকপিডগলাস: আপনার কাছে হ্যাশ রয়েছে যা সঠিক তথ্য নয় এবং এখনও

— ডেটস

@ জ্যাকপিডুগলাস এও সম্ভাবনা রয়েছে যে সার্ভারের অ্যাডমিন এবং ডিবিএর সাথে সম্পর্কিত বিভিন্ন ঝুঁকি রয়েছে যে ফাইলগুলি ভুলভাবে মুছে ফেলা হবে, বা অস্থায়ী ফাইল হিসাবে বিবেচিত হওয়ায় ব্যাক-আপ হবে না।

— ফিল লেলো

Answer 3

যদি ওরাকলটির জন্য যাচ্ছেন তবে dbfs এবং সুরক্ষিত ফাইলগুলি দেখুন।

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

dbfs ডাটাবেসের একটি ফাইল সিস্টেম। আপনি এটি একটি লিনাক্স হোস্টে নেটওয়ার্ক ফাইল সিস্টেমের মতো মাউন্ট করতে পারেন। এটি সত্যই শক্তিশালী। ব্লগ দেখুন এটিতে আপনার সুনির্দিষ্ট প্রয়োজন অনুসারে প্রচুর বিকল্প রয়েছে। একটি ডিবিএ হওয়া, একটি ফাইল সিস্টেম দেওয়া (লিনাক্সে মাউন্ট করা ডাটাবেসের ভিত্তিতে), আমি কোনও সমস্যা ছাড়াই এটিতে একটি ওরাকল ডাটাবেস তৈরি করেছি। (একটি ডাটাবেস, একটি ... ডাটাবেসে সঞ্চিত)। এটি খুব কার্যকর হবে না তবে এটি শক্তিটি দেখায়।

আরও সুবিধা রয়েছে: প্রাপ্যতা, ব্যাকআপ, পুনরুদ্ধার, সমস্ত অন্যান্য সম্পর্কিত সম্পর্কিত ডেটার সাথে সামঞ্জস্যপূর্ণ consistent

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

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

একটি শেষ, বড় আশ্চর্য, একটি নিয়মিত ফাইল সিস্টেমের চেয়ে প্রায়শই একটি ডিবিএফএস ফাইল সিস্টেমের কর্মক্ষমতা আরও ভাল। এটি বিশেষত সত্য যদি ফাইলগুলি কয়েকটি ব্লকের চেয়ে বড় হয়।

Answer 4

আমি মনে করি যে এখানে সঠিক উত্তরটি আপনার প্রয়োগের উপর এবং এই নথিগুলি কতটা গুরুত্বপূর্ণ তা নির্ভর করে depends

একটি নথির ব্যবস্থাপনার ব্যবস্থা, বা এমন একটি ব্যবস্থার জন্য যেখানে সঞ্চিত নথিগুলির পুনরুদ্ধার সমালোচনা হয় (তাই বেশিরভাগ বিষয়গুলি আর্থিক, এইচআর বা সিআরএম সম্পর্কিত), দস্তাবেজগুলিকে ইনলাইনে সংরক্ষণ করে বা আপনার প্রিয় ডিবি বিক্রেতার মালিকানা সংক্রান্ত নথি প্রযুক্তিটি ডান থিংয়ের মতো মনে হয় Do

তবে, এমন অনেকগুলি অ্যাপ্লিকেশন রয়েছে যেখানে আমি বিশ্বাস করি যে বিপরীত সিদ্ধান্তটি উপযুক্ত।

হেল্পডেস্ক সিস্টেম এবং উইকি-টাইপ সিস্টেমগুলি এমন যেখানে আমার মনে হয় ডেটাবেস থেকে ডেটা রাখার জন্য এটি অনেক অর্থবোধ করে। আমি বিশ্বাস করি যে জিরার মতো কিছু আপনি প্রকৃতপক্ষে ডকুমেন্টগুলি ইনলাইনে সঞ্চয় করতে চান কিনা তা চয়ন করার জন্য একটি বিকল্প সরবরাহ করে।

মাঝারি আকারের ব্যবসায়ের জন্য, টিকিটিং সিস্টেমের ইনলাইনে নথি সংরক্ষণের অর্থ মেগাবাইটে পরিমাপ করা একটি সংকোচিত ব্যাকআপ এবং গিগাবাইটে পরিমাপ করা একটির মধ্যে পার্থক্য হতে পারে।

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

দলিলগুলি আলাদা রাখার অন্যান্য সুবিধা রয়েছে।

• আপনি সহজেই পৃথক প্রক্রিয়াগুলি চালাতে পারেন যা মেটাডেটা নথিটি ক্যাটালগ করে, ভাইরাস স্ক্যানিং করে, কীওয়ার্ড ইনডেক্সিং সম্পাদন করে etc.
• ব্যাকআপ বা পুনরুদ্ধার - RSSync, স্টোরেজ স্ন্যাপশট ইত্যাদিতে সহায়তা করার জন্য আপনি সরঞ্জামগুলির সুবিধা নিতে পারেন - যা নিজেকে ডাটাবেসের চেয়ে ফাইলগুলিতে আরও ভাল ধার দেয়
• আপনি আসলে এমন স্টোরেজ ব্যবহার করতে পারেন যা সংক্ষেপণ বা ডুপ্লিকেশনকে সমর্থন করে (আপনার সান প্রশাসকরা যে জিনিসগুলি বছরের পর বছর ধরে ব্লুবার্ড করে চলেছেন, বিশ্বব্যাপী ডাটাবেস প্রশাসকদের নিষেধাজ্ঞা)
• একাধিক সাইট জুড়ে একটি ইনস্টলেশনের জন্য, আপনি একটি বিতরণ ফাইল সিস্টেমের সাথে একটি কেন্দ্রিয়ায়িত ডাটাবেস পরিপূরক করতে পারেন

আমি মনে করি যে # 2 এবং # 3 এর একটি সংকর সংমিশ্রণ চালাক হতে পারে। আসল ফাইলের নাম রাখুন, তবে নথির একটি হ্যাশ / চেকসাম গণনা করুন এবং সংরক্ষণ করুন, যাতে আপনার কিছু রেফারেন্স পয়েন্ট থাকে যে কেউ যদি ফাইলটি সরিয়ে নিয়ে যায় বা পুনরায় নামকরণ করে তবে পুনরুদ্ধারে সহায়তা করবে।

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

Answer 5

এটা করবেন না।

ডাটাবেসে ফাইল সঞ্চার করার পক্ষে আসলে কোনও উল্টোটি নেই।

আপনি নিজেকে যখন ভাবেন তখন কি এটিকে ইতিমধ্যে অদ্ভুত এবং মজাদার মনে হয় না:

আমি কি একটি ডাটাবেস বা একটি ফাইল সিস্টেমে ফাইলগুলি সঞ্চয় করব ?

আরও ভাল, জোরে বলে।

তথ্যে:

ডাটাবেস ব্যবহার করে

" পিআরএস " ... তবে বেশ নয় :

• "পারমাণবিকতা" যা সঠিক তবে এটি দ্বিগুণ তরোয়াল। কারণ এটি এর সাথে বরাবর টেনে নিয়ে যায়।
• অখণ্ডতা. উপরের মতই.

আমি সত্যিই পক্ষপাতদুষ্ট হতে চাই না তবে যুক্ত করার মতো আরও কিছু আছে বলে আমি মনে করি না। যদি আপনি এটির বিষয়ে চিন্তা করেন তবে পেশাদাররা আসলে এত দুর্দান্ত নয়।

আমি নীচে কিছু মন্তব্য ভুলে গেলে, ইতিমধ্যে নীচে পড়তে থাকুন।

কনস:

• কাজের জন্য ভুল সরঞ্জাম
• কঠিন বজায় রাখা
• ধীরে
• শত শত এমবি / গিগাবাইট ডেটা পেরের ব্যবহারকারীকে সঞ্চয় করার বিষয়ে ভুলে যান ।
• দ্রুত বর্ধমান সাইটগুলির ব্যাক আপ করা দুঃস্বপ্ন হবে।
• পুনরুদ্ধার / চলন্ত এছাড়াও স্তন্যপান হবে।

ফাইল সিস্টেম ব্যবহার করে

পেশাদাররা:

• বজায় রাখা সহজ উপায়
• দ্রুত
• এটির সাথে ডেটাবেস ব্যাক আপগুলির কোনও সম্পর্ক নেই
• যুক্তিযুক্তভাবে আরও বহনযোগ্যতা *

কনস :

• কোনটি *

*সূক্ষ্ম মুদ্রণ

এই মুহূর্তে আপনি নিজেকে জিজ্ঞাসা করছেন, ধরে রাখছেন মানে কোন বিপর্যয় নেই ?! কিভাবে?

এখানে সবচেয়ে বড় ভুল হ'ল লোকে হাতুড়ি দিয়ে স্ক্রু আঁকতে চেষ্টা করছে।

প্রধান কারণ এবং আমি যতদূর যেতে চাই বলতে শুধুমাত্র কারণ এই বলা হচ্ছে কারণ হল ফাইল লিঙ্ক ।

এটি এমন একটি সমস্যা যা ডাটাবেস সমাধান করার জন্য নয়। এমনকি যদি আপনি এটি সম্পর্কে চিন্তা করেন তবে এটি নির্বোধ শোনায়।

"ডাটাবেসটি আমার ফাইল লিঙ্কিংয়ের সমস্যার সমাধান করবে।"

বাস্তবে যখন, যৌক্তিকভাবে অ্যাপ্লিকেশনটি লিঙ্কগুলি পরিচালনা ও পরিবেশনার দায়িত্বে থাকা উচিত ।

একটি সমাধান:

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

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

কীভাবে এটি প্রয়োগ করা যায় তা এই উত্তরের বাইরে নয় তবে আপনি সাধারণভাবে সর্বাধিক ব্যবহৃত ওয়েব ল্যাঙ্গুয়েজে (পিএইচপি) উদাহরণটি দেখতে পারেন:

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

এই দুটোই একসাথে সত্যই শক্তিশালী।

Comments

আপনি এতে আগ্রহী হতে পারেন: গবেষণা. microsoft.com/apps/pubs/default.aspx?id=64525 মাইক্রোসফ্টের একটি গবেষণা যা দেখায় যে ডাটাবেসে ব্লবগুলি সঞ্চয় করা ফাইল সিস্টেমের তুলনায় দ্রুততর (কিছু আকারের ব্লবগুলির জন্য) অন্তত). এটি আমার পরীক্ষার সাথে সামঞ্জস্যপূর্ণ যা দেখায় যে মাঝারি আকারের ব্লবগুলির জন্য (<~ 1MB) উদাহরণস্বরূপ পোস্টগ্রিস ফাইল সিস্টেমের চেয়েও দ্রুত। ওরাকলের ক্ষেত্রে এটি একই পারফরম্যান্সের বিষয়ে তবে আমি নতুন সুরক্ষিত স্টোরেজ ফর্ম্যাটটি এখনও পরীক্ষা করিনি (তবে তারা দাবি করে এটি এটি পুরাতন স্টোরেজ ফর্ম্যাটের চেয়ে দ্রুত)

— a_horse_with_no_name

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

— টেক

Answer 6

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

বড় সুবিধাটি হ'ল পারমাণবিকতা এবং ব্যাকআপ উদ্দেশ্যে সমস্ত সম্পর্কিত ডেটা এক জায়গায় রাখার ক্ষমতা। এটি কিছু ভুল হওয়ার সম্ভাবনা হ্রাস করে।

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

দণ্ড: যদি ফাইলগুলি মাঝে মধ্যে অ্যাক্সেস করা হয় তবে আমি ডিবিতে সংরক্ষণ করব। যদি সেগুলি ঘন ঘন এবং বারবার অ্যাক্সেস করা হয় তবে কমপক্ষে পোস্টগ্র্যাসএসকিউএল সহ, আমি মনে করি ব্যয়গুলি সুবিধাগুলির চেয়ে বেশি।

Answer 7

আগের দিন, মাইক্রোসফ্ট ডেটাবেসে ছবি (এবং একই রকমের ব্লব ডেটা ধরণের) সঞ্চয় করার দক্ষতা বাড়িয়ে তোলে। এটি এসকিউএল সার্ভার 2000 এর একটি দুর্দান্ত বৈশিষ্ট্য ছিল (আমি দৃ sure়ভাবে নিশ্চিত যে এটি 2000 ছিল, 7.0 নয়) এবং অনেক লোক ব্যান্ডওয়্যাগনে ঝাঁপিয়ে পড়েছিল।

ডাটাবেসে ব্লগগুলি সংরক্ষণ করার সুবিধা এবং অসুবিধা রয়েছে:

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

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

এসকিউএল সার্ভার ২০০৮ ফাইল স্ট্রিমিং চালু করেছে। ডাটাবেসটিতে ফাইলগুলিতে পয়েন্টার রয়েছে, ফাইলগুলি ডাটাবেসে নেই সার্ভারে থাকে তবে আপনি ডাটাবেসটি ব্যাকআপ করার সময় ফাইলগুলিও ব্যাক আপ হয়।

আপনার ব্যাকআপগুলি বেশ বড় আকার ধারণ করতে পারে তবে আপনি অনাথ ফাইল / নথি / ব্লব / চিত্রগুলি দিয়ে শেষ করবেন না।

আমার ব্যক্তিগত পছন্দটি হ'ল ডেটাবেস স্টোর পয়েন্টার / নেটওয়ার্ক লোকেশন এবং একটি ফাইল সার্ভারকে ফাইলগুলি পরিচালনা করতে দেওয়া। ফাইল সার্ভারগুলি যাইহোক এই জাতীয় কাজের জন্য আরও ভাল।

Comments

কিছু মনে করবেন না যে আপনি যদি সার্ভারটির মালিক না হন তবে আপনি ডাটাবেস স্পেস বনাম ফাইল স্পেসের জন্য এমবি প্রতি আরও অনেক বেশি হেক দিতে চলেছেন। ডিস্কে ফাইল থাকা সমস্যা সমাধান করা আরও সহজ করে তোলে - আপনি কীভাবে SELECT image FROM tableএসএসএমএসে থাকবেন এবং সঠিক চিত্রটি আছে তা যাচাই করবেন?

— হারুন বারট্রান্ড

Answer 8

একটি ডাটাবেসে ফাইল সংরক্ষণ করবেন না।

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

• ডাটাবেসে ফাইলগুলিতে কোনও ফাইলহ্যান্ড নেই । এটার মানে কি?

  • প্রোগ্রামার-টক: আপনি চাইছেন না ( fseek), অ্যাসিনক্রোনাস অ্যাক্সেস ( asyncioবা epoll) দিয়ে রিসোর্স পরিচালনা করার কোনও ক্ষমতা নেই , নেই sendfile(কার্নেল স্পেস থেকে অনুলিপিটি সংরক্ষণ করা)।

  • ব্যবহারিক প্রয়োগ: এইচটিটিপি 2/3 এর মাধ্যমে কোনও ক্লায়েন্টের কাছে কোনও ভিডিও বা ছবি পাঠাতে চান? এটি যদি ডাটাবেসে থাকে তবে আপনাকে প্রথমে এটি জিজ্ঞাসা করতে হবে। যেই প্রশ্নের জন্য ফাইলটি ফিরে আসে, সেই ফাইলটি পরবর্তী ধাপে যাওয়ার আগে আপনাকে পুরো ক্যোয়ারির সমাপ্তির জন্য অপেক্ষা করতে হবে। ওয়েব সার্ভারের চেয়ে আলাদা সার্ভারে একটি rdbms সহ একটি প্রোডাকশন ইনস্টল করার সময় আপনাকে প্রথমে ফাইলটি স্ট্রিমিংয়ের পরিবর্তে আরডিবিএমএস থেকে ওয়েবসার্ভারে পুরোপুরি স্থানান্তর করতে হবে । তবে, যদি পরিবহন স্তরটি ফাইল-সিস্টেম বিমূর্ততা সরবরাহ করে (যা এনএফএসও সমর্থন করে) আপনি ফাইলটির অর্ধেক পথ সন্ধান করতে এবং তত্ক্ষণাত প্রয়োজনের চেয়ে ফাইলটির আর কোনও বাফারিং ছাড়াই ক্লায়েন্টের কাছে ফিরে স্ট্রিমিং শুরু করতে পারেন। এটি নিয়মিত ওয়েব সার্ভার দ্বারা করা হয়nginx , অ্যাপাচি , PureFTP এবং ProFTP।

• আরডিবিএমএসে ডাবল কপি। এটি ডাটাবেসের মধ্যে খুব সম্ভবত, আপনি সম্ভবত এটি দু'বার লিখে যাবেন। একবার একটি লিখন-এগিয়ে লগ (ওয়াল), এবং তারপরে আবার টেবিল স্পেসে

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

• কোয়েরিটি ধীর করার জন্য ফাইল-পঠন এবং হস্তান্তর স্থানটি যদি আপনার নিজের জিজ্ঞাসার প্রয়োজন হয় তবে ফাইলটি নিজেই একটি সারিটিতে সংরক্ষণ করা হয়, পুরো সারিটি হয় হয় ফাইলটি স্থানান্তরিত হওয়ার জন্য অপেক্ষা করতে হবে, অথবা আপনাকে দুটি পৃথক প্রশ্ন জারি করতে হবে ।

• ডিবি-ক্লায়েন্টে মেমোরি ব্যবহার । ডিবি-ক্লায়েন্ট (libpq, jdbc, odbc, freetds, ইত্যাদি) বা এর মত সম্ভবত মেমরিটিতে ক্যোয়ারীটি বাফার করবে। যখন মেমোরি বাফারটি ক্লান্ত হয়ে যায় তখন এটি একটি ডিস্ক-বাফার শুরু করতে পারে বা আরও খারাপ হতে পারে এটি ডিস্কে পেজ করার জন্য কার্নেলের কাছে ফিরে যেতে পারে।

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

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

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

• ক্লাউড মাইগ্রেশন আপনি যদি কখনও কোনও সান বা ক্লাউডে ফাইলগুলি সঞ্চয় করতে চান তবে আপনার আরও বেশি অসুবিধা হবে কারণ এখন স্টোরেজ-মাইগ্রেশন একটি ডাটাবেস-স্থানান্তর। যদি আপনার ফাইলগুলি উদাহরণস্বরূপ ফাইল সিস্টেমে সঞ্চিত থাকে তবে আপনি মোটামুটি সহজেই তাদের এস 3 এ সরিয়ে নিতে পারেন (এবং এর মতো কিছু দিয়ে s3fsএটি স্বচ্ছ হতে পারে)।

ব্যতিক্রমসমূহ

ডাটাবেসে ফাইল সংরক্ষণের কয়েকটি কার্যকর ব্যবহার রয়েছে,

• আপনি যখন প্রয়োজন transitionally ফাইল সম্পাদনা করার। এর অর্থ ফাইলটি সম্পাদনা করা এটি আক্ষরিক অর্থে আপনার লেনদেনের অংশ। অথবা যদি লেনদেনের সম্পর্কগুলিতে ডেটা-অখণ্ডতা সম্পর্কিত সমস্যাগুলি (টেবিলগুলি) ব্যর্থ হয় তবে আপনাকে ফাইলটিতে রোল-ব্যাক সম্পাদনা করার সক্ষমতা প্রয়োজন ।
• যখন আপনি প্রয়োজন ফাইল সিস্টেম নিশ্চিত করার অবিকল ডেটার সাথে versioned হয় এবং আপনি তাদের সুসংগত পালন যে কোন ঝুঁকি সাধ্যের বাইরে।
• যখন আপনি ডাটাবেস আসলে ফাইলটি বিশ্লেষণ করতে পারেন এবং আপনি এটি অনুসন্ধান করতে পারেন। উদাহরণস্বরূপ PostgreSQL এ, টপোলজগুলি পোস্টজিআইএসের সাহায্যে অনুসন্ধান হতে পারে। এই মুহুর্তে, এটি ফাইল হওয়ার সময় এটি কোয়েরির জন্য ডেটা এবং স্টোরেজ ডাম্পেরও নয়।

Mitigations

• কিছু ডাটাবেসের একটি "বাহ্যিকভাবে পরিচালিত সংস্থান" সম্পর্কে ধারণা থাকে যেখানে ডেটাবেস হয় ডিস্কে ব্যক্তিগতভাবে ফাইল পরিচালনা করে যেমন

  • লার্জ অবজেক্ট অবকাঠামোর মাধ্যমে পোস্টগ্রিএসকিউএল লেনদেনের সময়কালের জন্য কোনও সংস্থায় একটি ফাইলহ্যান্ডেল সরবরাহ করে।

  • এসকিউএল সার্ভার 2017 এর ফাইল স্ট্রিম অবকাঠামো একটি অস্থায়ী অ্যাক্সেস সরবরাহ করে যা লেনদেনের সময়কালের জন্য স্থায়ী হয় যা আপনি ফাইল পাথ পেতে এবং ফাইল হ্যান্ডেল এতে খুলতে ব্যবহার করতে পারেন।

  • ওরাকল সরবরাহ করে BFILE(যা তাদের অভ্যন্তরীণ এলওবি স্টাফ বলে যার সাথে এটির কোনও সম্পর্ক নেইSecureFile

• কিছু ডেটাবেস বড় বাইনারি অবজেক্টগুলি লাইন-অফ-লাইন বা ক্যান, যেমন ওরাকল সিকিওরফাইলে সঞ্চয় করে। এটি আপনাকে পুনরায় লিখন না দিয়ে সারিটি আপডেট করার অনুমতি দেয়।

• ওরাকল এর মতো কিছু ডাটাবেস ওয়াল লগ ছাড়াই তাদের এমভিসি করে এবং ফাইলটি ডাবল-লিখিত করতে হয় না।

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

• ওরাকল অভ্যন্তরীণ- LOB স্টোরেজ (সিকিউরফায়ালের মাধ্যমে) এর মাধ্যমে alচ্ছিক প্রতিলিপি, সংক্ষেপণ এবং এনক্রিপশন সরবরাহ করে।

উপসংহার

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

এটি সহজ রাখুন, এবং সাধারণ নিয়মটি ফাইলগুলিকে ডিবি থেকে দূরে রাখে ।

সমাধান

একাধিক ভাড়াটে এবং ব্যবহারকারীদের কার্যকরভাবে কাজ করতে আপনার কীভাবে ফাইল সংরক্ষণ করতে হবে বা এ জাতীয় ফ্যাশনে একটি ফাইল সিস্টেমকে বিমূর্ত করা উচিত? আমি ফাইলের বিষয়বস্তুগুলি হ্যাশ করার জন্য আংশিক। আজকাল এটি বেশ সাধারণ এবং ভালভাবে কাজ করে।

Answer 9

যদিও এটি আংশিকভাবে অ্যাপ্লিকেশন / পরিবেশের উপর নির্ভর করে (লোকেরা অন্তর্ভুক্ত), আমি ব্লবটির জন্য যাব।

ডাটাবেসে সমস্ত কিছু রাখার অর্থ প্রতিলিপি ফাইল ডেটার জন্য কাজ করে। আপনার এফএস ফাইলগুলি সিঙ্ক্রোনাইজ করার জন্য একটি পৃথক প্রক্রিয়া দরকার।

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

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

আমি বিএলওবি স্টোরেজটিতে যে পরিমার্জনটি বিবেচনা করব তা হ'ল ডেটা ছড়িয়ে দেওয়া যদি এর অর্থ হয়; যদি আপনার কেবলমাত্র 20 এমবি বিএলএব থেকে 512 বাইটের প্রয়োজন হয় তবে এই সেক্টরের মতো অ্যাক্সেসটি সত্যিকারের উত্সাহ, বিশেষত যদি আপনি দূরবর্তী ক্লায়েন্টদের সাথে কাজ করছেন (এবং আবারও, একটি আংশিক আপডেটের ফলে খুব কম প্রতিরূপ ট্র্যাফিক তৈরি হয়)।

Answer 10

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

এইভাবে আপনি দৈত্য আকারের ডাটাবেসগুলি মোকাবেলা না করে ডেটা সর্বদা অ্যাক্সেসযোগ্য হওয়ার নির্ভরযোগ্যতা পান।

Answer 11

পোস্টগ্রিজের জন্য:

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

Answer 12

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