একাধিক ডাটাবেস অ্যাক্সেস বা একটি বিশাল অ্যাক্সেস?

Question

শুধুমাত্র এটি প্রয়োজন হয় যখন, অথবা একটি বস্তু সকল তথ্যকেই বোঝাচ্ছি যা ঝুলিতে পুনরুদ্ধার করতে এক এক্সেস করণ প্রয়োজন সঠিক তথ্য পেতে AJAX এর মাধ্যমে একটি ডাটাবেস একাধিক বার অ্যাক্সেস করা যায়নি: কি একটা ভাল পদ্ধতির যখন এটি কর্মক্ষমতা এবং অনুকূল সম্পদ ব্যবহার করতে আসে পারে প্রয়োজন হতে , একটি উচ্চ সম্ভাবনার সাথে যা আসলেই সমস্ত প্রয়োজন হয় না?

আমি জানি কীভাবে আসল প্রশ্নগুলি বেনমার্ক করতে হয়, তবে হাজার হাজার ব্যবহারকারী একসাথে ডাটাবেস অ্যাক্সেস করতে এবং সংযোগ পুলিং কীভাবে কার্যকর হয় সে সম্পর্কে কীভাবে সেরা তা পরীক্ষা করতে জানি না।

Comments

আপনি কি প্ল্যাটফর্ম ব্যবহার করছেন? যদি ল্যাম্প ইউ চুড ম্যাকচ্যাচিং ব্যবহার করে

— ravi404

অন্য কোনও পারফরম্যান্স অপটিমাইজেশনের মতোই, আপনি এটি পরিমাপ করেন।

— টেলাস্টিন

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

— DudeOnRock

@DudeOnRock - নড়া সাধারণভাবে এটি তথ্য পরিবর্তনগুলি আপনার ব্যবহারের নিদর্শন এবং কিভাবে নির্ভর করে। যদি একটি ক্যোয়ারী মানুষের প্রয়োজনের 80% সরবরাহ করে এবং ডেটা প্রায়শই পরিবর্তন হয় না, তবে তার সাথে যান। ক্যাশে সহজ, অনুকূলকরণ সহজ। যদি একটি ক্যোয়ারী ব্যবহারকারীদের সাধারণত যা প্রয়োজন তার 5% এর মতো করে ফিরে আসে তবে সম্ভবত না not আমি কম চেয়ে আরো প্রশ্নের দিকে ঝোঁক হবে। আপনি এটি সর্বদা ডিবিতে পৌঁছানোর আগে সার্ভারে সর্বদা সেগুলি কেটে ফেলতে পারেন। 'সবকিছু একটি জিজ্ঞাসা করে' পূর্বাবস্থায় ফেলা শক্ত Hard

— টেলাস্টিন

@ আরভজ: আকর্ষণীয় মনে হচ্ছে!

— DudeOnRock

Answer 1

এর সঠিক কোনও উত্তর নেই; যে কোনও অপ্টিমাইজেশনের মতো এটি প্রসঙ্গ / ব্যবহারের উপর নির্ভর করে।

তবে, নীচে থাম্বের নিয়ম হিসাবে বিবেচনা করুন:

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

Answer 2

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

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

Comments

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

— স্পেসট্রকার

Answer 3

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

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

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

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

Answer 4

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

Comments

মন্তব্য অনুসারে, এটি একটি স্থানীয় ডাটাবেস ব্যবহার করছে, সুতরাং এখানে "ওভার ওয়্যার" বিলম্ব নেই।

— ম্যাসন হুইলারের

মন্তব্য অনুসারে, তিনি এমন কৌশলগুলির সন্ধান করেছিলেন যা "সবকিছু যখন স্থানীয় ছিল তখন দুর্দান্ত হবে না, তবে সরাসরি গ্রহণের সময় উপ-অনুকূল" হবে।

— টিএমএন

Answer 5

আপনি যদি স্থাপত্য সংক্রান্ত সিদ্ধান্ত নিচ্ছেন, তবে REST হ'ল একটি বিকল্প। REST সহ, আপনি সর্বদা একাধিকবার কোনও সংস্থার জন্য অনুরোধ করেন, অর্থাত আপনি 2 টি অবজেক্ট পাওয়ার অনুরোধ পাঠান না কারণ প্রতিটি বস্তুর নিজস্ব ইউআরএল রয়েছে। এই স্টাইলটি করার সাথে পারফরম্যান্স উদ্বেগ সম্ভবত এইচটিটিপি / ২.০ প্রকাশিত হলে সমাধান হবে। অন্যথায়, আপনি এটি যথাসম্ভব দ্রুততর করার জন্য অনুকূলিত করেছেন। প্রচুর সংস্থাগুলি এভাবেই করছে।