এই উদ্ধৃতিটি এক্সএমএলটিকে সাধারণভাবে স্টোরেজ ফর্ম্যাট হিসাবে ব্যবহার করার বিষয়ে নয় (যার জন্য এটি প্রয়োজনীয়, তার উপর নির্ভর করে ভাল) তবে ডাটাবেস- টাইপ স্টোরেজগুলির ক্ষেত্রে।
লোকেরা যখন ডেটাবেস সম্পর্কে কথা বলে, তাদের সাধারণত স্টোরেজ সিস্টেমগুলি বোঝায় যেগুলি প্রচুর পরিমাণে ডেটা সঞ্চয় করে, প্রায়শই গিগাবাাইট বা টেরাবাইট সীমার মধ্যে। একটি সার্ভারে যে পরিমাণ র্যাম রয়েছে তা এটি সঞ্চয় করে তার চেয়ে একটি ডেটাবেস সম্ভাব্য পরিমাণে অনেক বড়। যেহেতু কারও কাছে একবারে একটি ডেটাবেজে সমস্ত ডেটা প্রয়োজন হয় না, তাই ডাটাবেসগুলি তাদের ডেটাগুলির নির্বাচনী সাবসেটগুলি দ্রুত পুনরুদ্ধারের জন্য অনুকূলিত করা উচিত: SELECTবিবৃতিটি এটিই, এবং সম্পর্কিত ডেটাবেসগুলির পাশাপাশি নোএসকিউএল সমাধানগুলি তাদের অভ্যন্তরীণ স্টোরেজ ফর্ম্যাটটিকে দ্রুত জন্য অনুকূল করে তোলে এই ধরণের সাবলেট পুনরুদ্ধার।
এক্সএমএল, তবে, এই প্রয়োজনীয়তাগুলি সত্যিই ফিট করে না। নেস্টেড ট্যাগ কাঠামোর কারণে, ফাইলটিতে একটি নির্দিষ্ট মান সঞ্চিত আছে তা নির্ধারণ করা অসম্ভব (কোনও ফাইলকে একটি বাইট অফসেটের শর্তে) পুরো ডকুমেন্ট ট্রি না রেখে ম্যাচ পর্যন্ত অন্তত ম্যাচ পর্যন্ত। একটি রিলেশনাল ডাটাবেস সূচী রয়েছে, এবং একটি সূচীতে একটি মান সন্ধান করে, এমনকি একটি আদিম বাইনারি-অনুসন্ধান প্রয়োগকরণ সহ, একটি একক ও (লগ এন) অনুসন্ধান এবং তারপরে প্রকৃত মানগুলি পাওয়া ফাইল-সন্ধান ছাড়া কিছুই নয় (উদাঃ fseek(data_file_handle, row_index * row_size)), যা ও (1)। একটি এক্সএমএল ফাইলে, সর্বাধিক দক্ষ উপায় হ'ল আপনার ডকুমেন্টের উপর স্যাক্স পার্সার চালানো, আপনার আসল ডেটাতে পৌঁছানোর আগে ভয়ঙ্কর প্রচুর পড়া এবং সন্ধান করা; আপনি সূচকগুলি ব্যবহার না করে আপনি ও (এন) এর চেয়ে কমই এর চেয়ে ভাল আর কিছু পেতে পারেন, তবে তারপরে আপনাকে প্রতিটি সন্নিবেশের জন্য পুরো সূচকটি পুনর্নির্মাণ করতে হবে (নীচে দেখুন)।
Serোকানো আরও খারাপ। সম্পর্কিত ডেটাবেসগুলি সারি ক্রমের গ্যারান্টি দেয় না, যার অর্থ তারা কেবল নতুন সারি যুক্ত করতে পারে বা 'মোছা' হিসাবে চিহ্নিত যে কোনও সারি ওভাররাইট করতে পারে। এটি অত্যন্ত দ্রুত: ডিবি চারপাশে লিখিত স্থানগুলির একটি পুল রাখতে পারে; পুলটি থেকে এন্ট্রি নেওয়া হ'ল (1) যদি পুলটি খালি না থাকে; সবচেয়ে খারাপ ক্ষেত্রে, পুলটি খালি এবং একটি নতুন পৃষ্ঠা তৈরি করতে হবে, তবে এটিও ও (1)। বিপরীতে, একটি এক্সএমএল-ভিত্তিক ডাটাবেসকে জায়গা তৈরির জন্য সন্নিবেশ পয়েন্টের পরে সবকিছু সরিয়ে ফেলতে হবে; এটি ও (এন)। সূচকগুলি যখন খেলতে আসে তখন জিনিসগুলি আরও আকর্ষণীয় হয়ে ওঠে: তুলনামূলকভাবে কম জটিলতার সাথে সাধারণত সম্পর্কিত সম্পর্কিত-ডাটাবেস সূচীগুলি আপডেট করা যায়, ও (লগ এন) বলুন; তবে আপনি যদি আপনার এক্সএমএল ফাইলগুলি সূচী করতে চান, তবে প্রতিটি সন্নিবেশ ডকুমেন্টের প্রতিটি মানের অন-ডিস্কের অবস্থানের সম্ভাব্য পরিবর্তন করে, তাই আপনাকে অবশ্যইসম্পূর্ণ সূচকটি পুনর্নির্মাণ করুন । এটি আপডেটের ক্ষেত্রেও যায়, কারণ কোনও উপাদানের পাঠ্য সামগ্রী আপডেট করে বলা, এটির আকার পরিবর্তন করতে পারে, যার অর্থ ক্রমাগত এক্সএমএলকে স্থানান্তরিত করতে হবে। কোনও আপেক্ষিক ডাটাবেসটিকে সূচি স্পর্শ করতে হবে না যদি আপনি একটি অন-সূচকযুক্ত কলাম আপডেট করেন; একটি এক্সএমএল ডাটাবেসকে প্রতিটি আপডেটের জন্য পুরো সূচকটি পুনর্নির্মাণ করতে হবে যা আপডেট হওয়া এক্সএমএল নোডের আকার পরিবর্তন করে।
এগুলি সবচেয়ে গুরুত্বপূর্ণ ডাউনসাইড, তবে আরও রয়েছে। এক্সএমএল খুব ভার্বোজ, যা সার্ভার-থেকে-সার্ভার যোগাযোগের জন্য ভাল, কারণ এটি সুরক্ষা যোগ করে (গ্রহণকারী সার্ভারটি এক্সএমএলে সমস্ত ধরণের সততা পরীক্ষা করতে পারে, এবং যদি স্থানান্তরে কোনও ভুল হয় তবে ডকুমেন্টটি বৈধ হওয়ার সম্ভাবনা নেই) )। সাধারণ সঞ্চয়স্থানের জন্য, তবে এটি হত্যাকারী: এক্সএমএল ডেটার জন্য 100% বা তার বেশি ওভারহেড থাকা অস্বাভাবিক কিছু নয় (এসওএপি বার্তাগুলির মতো জিনিসের জন্য 1000% রেঞ্জের মধ্যে ওভারহেড অনুপাতগুলি দেখা অস্বাভাবিক কিছু নয়), তবে সাধারণ সম্পর্কিত ডিবি স্টোরেজ স্কিমগুলির টেবিল মেটাডেটার জন্য কেবল একটি ধ্রুবক ওভারহেড থাকে, এবং প্রতিটি সারি প্রতি সামান্য বিট; রিলেশনাল ডাটাবেসে বেশিরভাগ ওভারহেড স্থির কলাম প্রস্থ থেকে আসে। আপনার কাছে যদি একটি টেরাবাইট ডেটা থাকে তবে বিভিন্ন কারণে 500% ওভারহেড কেবল অগ্রহণযোগ্য।