বৃহত্তর অ্যাপ্লিকেশনটিতে সামগ্রিক ডেটা অ্যাক্সেস কৌশল এবং পারফরম্যান্স অপ্টিমাইজেশনের ক্ষেত্রে যখন প্রশ্নটি "কোন ওআরএম ব্যবহার করা উচিত" সত্যই একটি বিশাল আইসবার্গের ডগাটিকে লক্ষ্য করে।
ডাটাবেস ডিজাইন এবং রক্ষণাবেক্ষণ
এটি একটি বিস্তৃত মার্জিন দ্বারা, ডেটা-চালিত অ্যাপ্লিকেশন বা ওয়েব সাইটের থ্রুপুটগুলির একক গুরুত্বপূর্ণ নির্ধারক এবং প্রায়শই প্রোগ্রামাররা একেবারে উপেক্ষা করে।
আপনি যদি যথাযথ স্বাভাবিককরণের কৌশল ব্যবহার না করেন তবে আপনার সাইটটি বিনষ্ট হবে ome আপনার যদি প্রাথমিক কী না থাকে তবে প্রায় প্রতিটি ক্যোয়ারী কুকুর-ধীর হবে। যদি আপনি কোনও অকারণে কী-মান জুড়ি (একে একে সত্তা-গুণমান-মান) এর জন্য সারণীগুলি ব্যবহার করার মতো সুপরিচিত অ্যান্টি-প্যাটার্নগুলি ব্যবহার করেন তবে আপনি শারীরিক পাঠ এবং লেখার সংখ্যাটি বিস্ফোরিত করবেন।
আপনি যদি ডেটাবেস আপনাকে প্রদত্ত বৈশিষ্ট্যগুলির সদ্ব্যবহার না করেন যেমন পৃষ্ঠা সংক্ষেপণ, FILESTREAMস্টোরেজ (বাইনারি ডেটার জন্য), SPARSEকলামগুলি, hierarchyidশ্রেণিবিন্যাসের জন্য, এবং আরও (সমস্ত এসকিউএল সার্ভারের উদাহরণ), তবে আপনি আর কোথাও দেখতে পাবেন না কর্মক্ষমতা আপনি পারে এইজন্য হও।
আপনি আপনার ডাটাবেসটি ডিজাইন করার পরে এবং নিজেকে নিশ্চিত করে নিন যে এটি সম্ভবত যতটা সম্ভব, কমপক্ষে আপাতত উপযুক্ত after
আগ্রহী বনাম অলস লোড হচ্ছে
বেশিরভাগ ওআরএম সম্পর্কের জন্য অলস লোডিং নামে একটি কৌশল ব্যবহার করে , যার অর্থ ডিফল্টরূপে এটি একবারে একটি সত্তা (টেবিলের সারি) লোড করবে এবং প্রতিবার এক বা একাধিক সম্পর্কিত (বিদেশী) লোড করার সময় ডাটাবেসে গোল-ভ্রমণ করবে foreign কী) সারি।
এটি কোনও ভাল বা খারাপ জিনিস নয়, বরং এটি ডেটা দিয়ে আসলে কী করা হবে এবং আপনি কীভাবে সম্মুখভাগে জানেন তা নির্ভর করে। কখনও কখনও অলস-লোডিং করা একেবারে সঠিক জিনিস। উদাহরণস্বরূপ, এনহাইবারনেট কোনও কিছুর জন্য জিজ্ঞাসা না করার সিদ্ধান্ত নিতে পারে এবং নির্দিষ্ট আইডির জন্য কেবল একটি প্রক্সি তৈরি করতে পারে । আপনার যদি কখনও প্রয়োজন সমস্ত আইডি নিজেই হয় তবে কেন এটি আরও বেশি চাওয়া উচিত? অন্যদিকে, আপনি যদি 3-স্তরের শ্রেণিবিন্যাসে প্রতিটি একক উপাদানের একটি গাছ মুদ্রণের চেষ্টা করছেন, অলস-লোডিং একটি ও (N²) ক্রিয়ায় পরিণত হয়, যা কার্য সম্পাদনের জন্য অত্যন্ত খারাপ।
"খাঁটি এসকিউএল" (যেমন কাঁচা ADO.NET কোয়েরি / সঞ্চিত পদ্ধতি) ব্যবহার করার একটি আকর্ষণীয় সুবিধা হ'ল এটি আপনাকে মূলত কোনও প্রদত্ত স্ক্রিন বা পৃষ্ঠা প্রদর্শন করার জন্য ঠিক কী ডেটা প্রয়োজন তা নিয়ে ভাবতে বাধ্য করে। ORMs এবং অলস লোড হচ্ছে বৈশিষ্ট্য না প্রতিরোধ এই কাজ থেকে, কিন্তু তারা না আপনি হতে ... ভাল, সুযোগ দিতে অলস , এবং ঘটনাক্রমে প্রশ্নের আপনি চালানো সংখ্যা বিস্ফোরিত করা। সুতরাং আপনাকে আপনার ওআরএম আগ্রহী-লোডিং বৈশিষ্ট্যগুলি বুঝতে হবে এবং যে কোনও প্রদত্ত পৃষ্ঠার অনুরোধের জন্য আপনি সার্ভারে যে কোয়েরি পাঠাচ্ছেন তার সংখ্যা সম্পর্কে সর্বদা সচেতন হন।
ক্যাশিং
সমস্ত বড় ওআরএম প্রথম স্তরের ক্যাশে বজায় রাখে, এ কেএ "আইডেন্টিটি ক্যাশে", যার অর্থ আপনি যদি একই আইডিটির আইডি দিয়ে দু'বার অনুরোধ করেন তবে এটির জন্য দ্বিতীয় রাউন্ড-ট্রিপের প্রয়োজন হবে না, এবং (যদি আপনি নিজের ডাটাবেসটি সঠিকভাবে ডিজাইন করেছেন) ) আপনাকে আশাবাদী সম্মতি ব্যবহার করার ক্ষমতা দেয়।
এল 2 ক্যাশে এল 2 এস এবং ইএফ-তে বেশ অস্বচ্ছ, আপনার ধরণের বিশ্বাস রাখতে হবে যে এটি কাজ করছে। এনহাইবারনেট এটি সম্পর্কে ( Get/ Loadবনাম Query/ QueryOver) আরও সুস্পষ্ট । তবুও, যতক্ষণ সম্ভব আপনি আইডি দিয়ে যতটা সম্ভব ক্যোয়ারী করার চেষ্টা করবেন, আপনার এখানে ভাল হওয়া উচিত। অনেক লোক এল 1 ক্যাশে সম্পর্কে ভুলে যায় এবং বার বার একই সত্তাকে বার বার তার আইডি (অর্থাত্ একটি দেখার ক্ষেত্র) ব্যতীত অন্য কোনও কিছু দ্বারা সন্ধান করে। আপনার যদি এটি করতে হয় তবে ভবিষ্যত অনুসন্ধানের জন্য আপনার আইডি বা এমনকি পুরো সত্ত্বাটি সংরক্ষণ করা উচিত।
এছাড়াও একটি স্তর 2 ক্যাশে ("ক্যোয়ারী ক্যাশে") রয়েছে। এনহাইবারনেটের এই বিল্ট-ইন রয়েছে। লিনক থেকে এসকিউএল এবং সত্তা ফ্রেমওয়ার্কে কোয়েরিগুলি সংকলিত হয়েছে , যা কোয়েরি এক্সপ্রেশন নিজেই সংকলন করে অ্যাপ্লিকেশন সার্ভারের লোডগুলি বেশ খানিকটা কমাতে সহায়তা করতে পারে তবে এটি ডেটা ক্যাশে করে না। মাইক্রোসফ্ট ডেটা-অ্যাক্সেস উদ্বেগের পরিবর্তে এটিকে একটি অ্যাপ্লিকেশন উদ্বেগ হিসাবে বিবেচনা করবে বলে মনে হয় এবং এটি এল 2 এস এবং ইএফ উভয়েরই একটি প্রধান দুর্বল বিষয়। এটি "কাঁচা" এসকিউএল এর একটি দুর্বল পয়েন্টও বলা বাহুল্য। মূলত এনএইচবারনেট ব্যতীত অন্য যে কোনও ওআরএমের সাথে সত্যিই ভাল পারফরম্যান্স পেতে আপনার নিজের ক্যাশিং ফ্যাক্যাড বাস্তবায়ন করতে হবে।
EF4 এর জন্য একটি এল 2 ক্যাশে "এক্সটেনশন" রয়েছে যা ঠিক আছে তবে অ্যাপ্লিকেশন-স্তরের ক্যাশের জন্য কোনও পাইকারি প্রতিস্থাপন নয়।
প্রশ্নের সংখ্যা
সম্পর্কিত ডেটাবেসগুলি ডেটা সেটগুলির উপর ভিত্তি করে । অল্প সময়ের মধ্যে তারা প্রচুর পরিমাণে ডেটা তৈরি করতে সত্যিই ভাল , তবে কোয়েরি বিলম্বের দিক থেকে তারা কোথাও খুব ভাল নেই কারণ প্রতিটি কমান্ডের সাথে একটি নির্দিষ্ট পরিমাণের ওভারহেড জড়িত রয়েছে। একটি সু-নকশাযুক্ত অ্যাপ্লিকেশনটিকে এই ডিবিএমএসের শক্তিতে খেলতে হবে এবং কোয়েরির সংখ্যা হ্রাস করার চেষ্টা করা উচিত এবং প্রতিটিটিতে ডেটা পরিমাণ বাড়িয়ে তোলার চেষ্টা করা উচিত।
আপনি কেবল একটি সারি প্রয়োজন হলে এখন আমি পুরো ডাটাবেসটি জিজ্ঞাসা করতে বলছি না। যদি আপনি প্রয়োজন, আমি কি বলছি হয় Customer, Address, Phone, CreditCard, এবং Orderএকটি পৃষ্ঠার পরিবেশন করার জন্য একই সময়ে সব সারি, তাহলে আপনি উচিত জিজ্ঞাসা , একই সময়ে তাদের সবার নির্ধারিত আলাদাভাবে প্রতিটি প্রশ্নের সাথে নির্বাহ না। কখনও কখনও এটি এর থেকেও খারাপ, আপনি এমন কোডটি দেখতে পাবেন যা একই Customerরেকর্ডটিতে পরপর 5 বার অনুসন্ধান করে, প্রথমে প্রথমে Id, তারপরে Name, তারপরে EmailAddress, তারপরে ... এটি হাস্যকরভাবে অক্ষম fficient
এমনকি আপনার যদি এমন বেশ কয়েকটি ক্যুরিয়াস চালানোর প্রয়োজন হয় যা সমস্ত সম্পূর্ণ ডেটার সম্পূর্ণ সেটগুলিতে পরিচালিত হয় তবে এটি সাধারণত একক "স্ক্রিপ্ট" হিসাবে ডেটাবেজে প্রেরণ করা এবং এটি একাধিক ফলাফল সেটগুলি ফেরত দিতে আরও দক্ষ efficient এটি ওভারহেড যা আপনার সাথে উদ্বিগ্ন, ডেটার মোট পরিমাণ নয়।
এটি সাধারণ জ্ঞানের মতো শোনাতে পারে তবে অ্যাপ্লিকেশনটির বিভিন্ন অংশে কার্যকর হওয়া সমস্ত প্রশ্নের ট্র্যাক হারানো প্রায়শই সহজ; আপনার সদস্যতা সরবরাহকারী ব্যবহারকারী / ভূমিকা সারণী, আপনার শিরোনাম ক্রিয়া শপিং কার্টের অনুসন্ধান করে, আপনার মেনু ক্রিয়াটি সাইটের মানচিত্রের টেবিলটি অনুসন্ধান করে, আপনার সাইডবার অ্যাকশন বৈশিষ্ট্যযুক্ত পণ্যের তালিকাকে জিজ্ঞাসাবাদ করে এবং তারপরে সম্ভবত আপনার পৃষ্ঠাটি কয়েকটি পৃথক স্বায়ত্তশাসিত অঞ্চলে বিভক্ত হয়ে গেছে অর্ডার ইতিহাস, সম্প্রতি দেখা, বিভাগ, এবং তালিকা সারণীগুলি আলাদাভাবে জিজ্ঞাসা করুন এবং আপনি এটি জানার আগে আপনি পৃষ্ঠাটি পরিবেশন করা শুরু করার আগে 20 টি ক্যুরিয়ার চালাচ্ছেন। এটি পুরোপুরি কর্মক্ষমতা ধ্বংস করে।
কিছু ফ্রেমওয়ার্ক - এবং আমি এখানে মূলত এনহাইবারনেটের কথা ভাবছি - এটি সম্পর্কে অবিশ্বাস্যভাবে চালাক এবং আপনাকে শেষ ভবিষ্যতের সম্ভাব্য মুহুর্তে ফিউচার নামক কিছু ব্যবহার করার অনুমতি দেয় যা পুরো প্রশ্নের সন্ধান করে এবং এগুলি একবারে কার্যকর করার চেষ্টা করে। আফাইক, আপনি নিজেরাই মাইক্রোসফ্ট প্রযুক্তিগুলির সাথে এটি করতে চাইলে; আপনার এটিকে আপনার অ্যাপ্লিকেশন যুক্তিতে তৈরি করতে হবে।
সূচী, পূর্বাভাস এবং অনুমানগুলি
কমপক্ষে 50% দেবের সাথে আমি কথা বলি এবং এমনকী কিছু ডিবিএর সূচকগুলি কভার করার ধারণাটিতেও সমস্যা রয়েছে বলে মনে হয়। তারা মনে করে, "ভাল, Customer.Nameকলামটি সূচিযুক্ত, তাই আমি নামটিতে যা করি প্রতিটি তাত্পর্য দ্রুত হওয়া উচিত" " আপনি যদি সন্ধান করছেন এমন নির্দিষ্ট কলামটি Nameসূচকটি কভার না করে এটি সেভাবে কাজ করে না । এসকিউএল সার্ভারে, INCLUDEএটি CREATE INDEXবিবৃতিতে সম্পন্ন হয়েছে।
যদি আপনি নির্লিপ্তভাবে SELECT *সর্বত্র ব্যবহার করেন - এবং আপনি যদি অন্য কোনও প্রজেকশন ব্যবহার করে স্পষ্টভাবে নির্দিষ্ট না করেন তবে প্রতিটি ওআরএম আরও কম কি করবে - তবে ডিবিএমএস আপনার সূচিগুলি সম্পূর্ণ উপেক্ষা করা পছন্দ করতে পারে কারণ সেগুলিতে অন-আচ্ছাদিত কলাম রয়েছে। একটি অভিক্ষেপের অর্থ হ'ল উদাহরণস্বরূপ, এটি করার পরিবর্তে:
from c in db.Customers where c.Name == "John Doe" select c
পরিবর্তে আপনি এটি করুন:
from c in db.Customers where c.Name == "John Doe"
select new { c.Id, c.Name }
আর এই ইচ্ছা অধিকাংশ আধুনিক ORMs জন্য, নির্দেশ এটি শুধুমাত্র যান এবং ক্যোয়ারীতে Idএবং Nameকলাম যা সম্ভবতঃ সূচক দ্বারা আচ্ছাদিত করা হয় (কিন্তু Email, LastActivityDateঅথবা যাই হোক না কেন অন্য কলাম তুমি সেখানে বিদ্ধ ঘটেছে)।
অনুপযুক্ত ভবিষ্যদ্বাণীগুলি ব্যবহার করে কোনও সূচক সুবিধা পুরোপুরি উড়িয়ে দেওয়া খুব সহজ। উদাহরণ স্বরূপ:
from c in db.Customers where c.Name.Contains("Doe")
... আমাদের আগের ক্যোয়ারীর সাথে প্রায় একইরকম দেখাচ্ছে তবে বাস্তবে একটি পূর্ণ টেবিল বা সূচি স্ক্যান হবে কারণ এটি অনুবাদ করে LIKE '%Doe%'। একইভাবে, সন্দেহজনকভাবে সহজ দেখাচ্ছে এমন আরও একটি ক্যোয়ারী হ'ল:
from c in db.Customers where (maxDate == null) || (c.BirthDate >= maxDate)
ধরে নিই যে আপনার একটি সূচক রয়েছে BirthDate, এই শিকারীর কাছে এটি সম্পূর্ণরূপে অকেজো রেন্ডার করার ভাল সুযোগ রয়েছে। এখানে আমাদের অনুমান প্রোগ্রামার স্পষ্টতই এক ধরণের গতিশীল ক্যোয়ারী তৈরি করার চেষ্টা করেছে ("শুধুমাত্র সেই জন্মের তারিখ ফিল্টার করে যদি সেই প্যারামিটারটি নির্দিষ্ট করা থাকে"), তবে এটি করার সঠিক উপায় এটি নয়। পরিবর্তে এইভাবে লেখা:
from c in db.Customers where c.BirthDate >= (maxDate ?? DateTime.MinValue)
... এখন ডিবি ইঞ্জিন কীভাবে এটি প্যারামিটারাইজ করতে পারে এবং একটি সূচী অনুসন্ধান করতে পারে তা জানে। একটি নাবালিক্য, ক্যোয়ারী এক্সপ্রেশনটিতে আপাতদৃষ্টিতে তুচ্ছ পরিবর্তন পারফরম্যান্সকে মারাত্মকভাবে প্রভাবিত করতে পারে।
দুর্ভাগ্যক্রমে লিনকুই এ জাতীয় খারাপ কোয়েরি লিখতে খুব সহজ করে তোলে কারণ কখনও কখনও সরবরাহকারীরা আপনি কী করার চেষ্টা করেছিলেন এবং ক্যোয়ারীটি অনুকূল করে তুলেছিলেন তা অনুমান করতে সক্ষম হন এবং কখনও কখনও তারা তা করেন না। সুতরাং আপনি হতাশাজনকভাবে বেমানান ফলাফলগুলি শেষ করেছেন যা অন্ধভাবে স্পষ্ট হয়ে উঠত (অভিজ্ঞ ডিবিএর কাছে) যাইহোক আপনি কেবল সাদামাটা পুরানো এসকিউএল লিখেছিলেন।
মূলত এগুলি এই বিষয়টিতে নেমে আসে যে আপনাকে উত্পন্ন এসকিউএল এবং কার্যকর করার পরিকল্পনাগুলির উভয় দিকেই আপনাকে সত্যই নজর রাখতে হবে এবং যদি আপনি প্রত্যাশিত ফলাফল না পান তবে বাইপাস করতে ভয় পাবেন না ORM স্তরটি একবারে এসকিউএল হ্যান্ড-কোড করে। এটি কেবল EF নয়, কোনও ওআরএমের জন্য F
লেনদেন এবং লকিং
আপনি কি মিলিসেকেন্ড অবধি বর্তমান তথ্য প্রদর্শন করতে হবে? হতে পারে - এটি নির্ভর করে - তবে সম্ভবত না। দুঃখিতভাবে, সত্তা ফ্রেমওয়ার্ক আপনি দেয় নাnolock , আপনি শুধুমাত্র ব্যবহার করতে পারেন READ UNCOMMITTEDএ লেনদেন স্তর (না টেবিল স্তর)। বাস্তবে কোনও ওআরএমই বিশেষভাবে নির্ভরযোগ্য নয়; যদি আপনি নোংরা পাঠ করতে চান, আপনাকে এসকিউএল স্তরে নেমে অ্যাড-হক প্রশ্নগুলি বা সঞ্চিত পদ্ধতি লিখতে হবে। সুতরাং এটি আবার কীভাবে ফুটে ওঠে তা ফ্রেমওয়ার্কের মধ্যে এটি করা আপনার পক্ষে কত সহজ।
সত্তা ফ্রেমওয়ার্ক এ বিষয়ে দীর্ঘ পথ পাড়ি দিয়েছে - EF এর 1 সংস্করণ (। নেট 3.5 এ) god শ্বর -ভয়ঙ্কর ছিল, "সত্তা" বিমূর্ততাটি ভেঙে ফেলতে অবিশ্বাস্যরকম কঠিন করে তুলেছিল , তবে এখন আপনি এক্সিকিউটিস্টোরকিউরি এবং অনুবাদ করেছেন , সুতরাং এটি সত্যই সত্য এতোটা খারাপ না. এই ছেলের সাথে বন্ধুত্ব করুন কারণ আপনি তাদের প্রচুর ব্যবহার করবেন।
রাইটিং লকিং এবং ডেডলকগুলি এবং যতটা সম্ভব অল্প সময়ের জন্য ডাটাবেসে লক ধরে রাখার সাধারণ অনুশীলনের বিষয়টি রয়েছে। এই ক্ষেত্রে, বেশিরভাগ ওআরএম (এজেন্টি ফ্রেমওয়ার্ক সহ) আসলে কাঁচা এসকিউএল এর চেয়ে ভাল থাকে কারণ তারা কাজের প্যাটার্নের ইউনিটকে encapsulate করে , যা EF- এ সেভচেনজেস । অন্য কথায়, আপনি যখনই চাইবেন আপনার হার্টের বিষয়বস্তুগুলিতে "সন্নিবেশ" বা "আপডেট" বা "মুছুন" করতে পারেন, এই জ্ঞানটি সুরক্ষিত করুন যে আপনি কাজের এককটি প্রতিশ্রুতি না দেওয়া পর্যন্ত কোনও পরিবর্তন আসলেই ডাটাবেজে সঞ্চারিত হবে না।
মনে রাখবেন যে একটি UW দীর্ঘমেয়াদি লেনদেনের সাথে সমান নয় । ইউউউউ এখনও ওআরএম এর আশাবাদী সম্মতিযুক্ত বৈশিষ্ট্যগুলি ব্যবহার করে এবং মেমরিতে সমস্ত পরিবর্তনগুলি ট্র্যাক করে । চূড়ান্ত প্রতিশ্রুতি না হওয়া পর্যন্ত একটিও ডিএমএল বিবৃতি বের হয় না। এটি লেনদেনের সময়গুলিকে যথাসম্ভব কম রাখে। যদি আপনি কাঁচা এসকিউএল ব্যবহার করে আপনার অ্যাপ্লিকেশনটি তৈরি করেন তবে এই স্থগিত আচরণ অর্জন করা বেশ কঠিন।
EF- এর বিশেষত এর অর্থ কী: আপনার ইউনিটগুলিকে যতটা সম্ভব মোটা করে তুলুন এবং আপনার একেবারে প্রয়োজন না হওয়া পর্যন্ত এগুলি প্রতিশ্রুতিবদ্ধ করবেন না। এটি করুন এবং আপনি এলোমেলো সময়ে পৃথক ADO.NET কমান্ড ব্যবহার করার চেয়ে অনেক কম লক যুক্তি দিয়ে শেষ করবেন।
উচ্চ ট্র্যাফিক / উচ্চ-পারফরম্যান্স অ্যাপ্লিকেশনগুলির জন্য EF সম্পূর্ণ জরিমানা, ঠিক যেমন উচ্চ ট্র্যাফিক / উচ্চ-কার্যকারিতা অ্যাপ্লিকেশনগুলির জন্য অন্যান্য প্রতিটি কাঠামো সূক্ষ্ম। আপনি কীভাবে এটি ব্যবহার করেন তা গুরুত্বপূর্ণ। এখানে সর্বাধিক জনপ্রিয় ফ্রেমওয়ার্কগুলির একটি দ্রুত তুলনা এবং পারফরম্যান্সের ক্ষেত্রে তারা কী বৈশিষ্ট্যগুলি উপস্থাপন করে (কিংবদন্তি: এন = সমর্থিত নয়, পি = আংশিক, ওয়াই = হ্যাঁ / সমর্থিত):
আপনি দেখতে পাচ্ছেন, EF4 (বর্তমান সংস্করণ) খুব খারাপভাবে ভাড়া দেয় না, তবে পারফরম্যান্স যদি আপনার প্রাথমিক উদ্বেগ হয় তবে এটি সম্ভবত সেরা নয়। এনএইচবারনেট এই অঞ্চলে অনেক বেশি পরিপক্ক এবং এমনকি লিনক থেকে এসকিউএল এমন কিছু কর্মক্ষমতা-বাড়ানো বৈশিষ্ট্য সরবরাহ করে যা EF এখনও দেয় না। কাঁচা ADO.NET প্রায়শই খুব নির্দিষ্ট ডেটা অ্যাক্সেসের দৃশ্যের জন্য দ্রুত হতে চলেছে , তবে, আপনি যখন সমস্ত টুকরা একসাথে রাখেন তখন এটি বিভিন্ন কাঠামোগত দিক থেকে প্রাপ্ত অনেকগুলি গুরুত্বপূর্ণ বেনিফিট দেয় না।