একটি ডাটাবেসে সমস্ত টেবিলের সঙ্কুচিত আকার সন্ধান করুন

Question

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

টেবিলের আকারটি এই সীমা ছাড়িয়ে গেছে কিনা তা দেখতে এই সেটিং থাকা সারণীর আকার যাচাই করতে আমরা সম্প্রতি পর্যন্ত কিছু স্ক্রিপ্টগুলির উপর নির্ভর করেছি।

এখন যাইহোক, সংকোচনের সূচনা হয় এবং sp_spaceused বা sys.allocation_units এর মতো জিনিসগুলি আসলে সংকোচিত ডেটা দ্বারা ব্যবহৃত স্থানটি রিপোর্ট করে বলে মনে হয়।

স্পষ্টতই, অ্যাপ্লিকেশন সার্ভারটি সঙ্কুচিত ডেটার সাথে কাজ করছে তাই এসকিউএল সার্ভারে ডিস্কের ডেটার আকার অপ্রাসঙ্গিক। সঙ্কুচিত তথ্যগুলির আসল আকারটি আমার দরকার।

আমি sp_estimate_data_compression_savings সম্পর্কে জানি কিন্তু নাম যেমন বলেছে, এটি কেবল একটি অনুমান।
আমি যতটা সম্ভব আকারের পছন্দ করতে পছন্দ করব।

কেবলমাত্র আমি ভাবতে পারি যে কয়েকটি সংশ্লেষিত গতিশীল এসকিউএল ছিল সংকোচিত টেবিলগুলির মতো একই কাঠামোর সাথে সংকোচিত টেবিলগুলি তৈরি করা, সেই ছায়ার সারণীতে সংকুচিত ডেটা tingোকানো এবং তারপরে সেই ছায়ার টেবিলের আকার পরীক্ষা করুন।
বলা বাহুল্য, এটি কিছুটা ক্লান্তিকর এবং কয়েক শ 'জিবি ডাটাবেসে চালিত হতে কিছুটা সময় নেয়।

পাওয়ারশেল একটি বিকল্প হতে পারে, তবে আমি select *স্ক্রিপ্টের আকার পরীক্ষা করার জন্য সমস্ত টেবিলের উপর দিয়ে একটি সম্পাদন করতে পুনরাবৃত্তি করতে চাই না কারণ এটি কেবল ক্যাশে বন্যা করবে এবং সম্ভবত খুব বেশি সময় নিতে পারে।

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

ধরে নিন অ্যাপ্লিকেশনটির বাফারটি হ'ল ডেটার আকার। একটি বিগিন্ট সর্বদা একটি বিগিন্টের আকার হয় এবং একটি চরিত্রের ডেটা টাইপ প্রতি অক্ষর (ইউনিকোড) 2 বাইট হয়। বিএলওবি ডেটা ডেটার আকারও গ্রহণ করে, একটি এনাম মূলত একটি অন্তর্নিহিত এবং সংখ্যাসূচক তথ্য সংখ্যা (38,12) হয়, ডেটটাইম একটি ডেটটাইমের আকার হয়। এছাড়াও, কোনও NULLমান নেই, সেগুলি হয় ফাঁকা স্ট্রিং 1900-01-01বা শূন্য হিসাবে সংরক্ষণ করা হয় ।

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

বড় টেবিলের জন্য এনরিটেটেবল ক্যাশেগুলি এড়িয়ে চলুন (AX 2009 এ 128 কেবি বা 16 পৃষ্ঠাগুলিতে, AX 2012 এ 'পুরো টেবিল ক্যাশে আকারের' অ্যাপ্লিকেশন সেটিং [ডিফল্ট: 32 কেবি, বা 4 পৃষ্ঠাগুলি]) এর পরিবর্তে ক্যাচিং রেকর্ড করুন।

Comments

এটি হ্যাকি, তবে সম্ভবত সংকোচনের সাথে পুনরুদ্ধার করা অনুলিপিটি সুনির্দিষ্ট হবে। তারপরে আপনি পুনরুদ্ধারও পরীক্ষা করছেন, যা আপনাকে প্রথম 1 ডিবিএর মতো দেখায়।

— এরিক ডার্লিং

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

— মাইক ওয়ালশ

সমস্ত কলামের জন্য সুম (ডেটালেথেন্থ ()) ডেটা আকারে সঙ্কুচিত হবে?

— তাপাকাহ উআ

@sp_BlitzErik এটি কোনও মন্তব্যের পরিবর্তে উত্তর হতে পারে।

— টম ভি - টপান্সওয়ার্স.অক্সিজ

Answer 1

সঙ্কুচিত তথ্যগুলির আসল আকারটি আমার দরকার।
...
আমি যথাসম্ভব সঠিক আকার পছন্দ করতে চাই

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

1. করছেন সব টেবিল সারি ক্যাশে হচ্ছে? বা শুধু একটি পরিসীমা মধ্যে? এখানে অনুমানটি হ'ল এটি সবই, এবং এটি সঠিক হতে পারে তবে আমি অনুভব করেছি যে এটি অন্তত উল্লেখ করা উচিত যে এটি ঘটতে পারে না (যদি না ডকুমেন্টেশন অন্যথায় উল্লেখ না করে তবে এটি যাইহোক ছোটখাটো বিন্দু মাত্র, চান না এটি উল্লেখ করা হবে না)।

   প্রশ্নটি আপডেট করতে আপডেট করা হয়েছিল: হ্যাঁ, সমস্ত সারি ক্যাশে হচ্ছে।

2. কাঠামো ওভারহেড

   1. ডিবি সাইডে:
      পৃষ্ঠা এবং ডিবি পাশের সারি-ওভারহেড: কোনও পৃষ্ঠায় কত সারি ফিট হয় তা অনেকগুলি কারণ দ্বারা অনুমান করা যায় যেগুলি নির্ধারণ করে determined এমনকি FILLFACTOR100 (বা 0) এর সাথেও , পুরো সারিটির পক্ষে পর্যাপ্ত পরিমাণ না থাকার কারণে এখনও পৃষ্ঠাটিতে কিছু অব্যবহৃত স্থান বাকি রয়েছে। এবং এটি পৃষ্ঠা শিরোনাম ছাড়াও। এছাড়াও, যদি কোনও স্ন্যাপশট আইসোলেশন কার্যকারিতা সক্ষম করা থাকে তবে আমি বিশ্বাস করি যে সংস্করণ নম্বর দ্বারা সারি প্রতি 13 বাইট অতিরিক্ত নেওয়া হবে এবং এটি অনুমানগুলি ফেলে দেবে। সারিটির আসল আকারের সাথে সম্পর্কিত অন্যান্য মিন্টোটিয়া রয়েছে (NULL বিটম্যাপ, ভেরিয়েবল দৈর্ঘ্যের কলামগুলি ইত্যাদি) তবে এ পর্যন্ত উল্লেখ করা আইটেমগুলি একাই পয়েন্টটি তৈরি করা উচিত।
   2. অ্যাপ্লিকেশন সার্ভারের দিকে:
      ক্যাশেড ফলাফলগুলি সঞ্চয় করতে কোন ধরণের সংগ্রহ ব্যবহার করা হচ্ছে? আমি ধরে নিলাম এটি একটি নেট অ্যাপ, তাই এটি DataTableকি? একটি জেনেরিক তালিকা? একটি সাজানো অভিধান? প্রতিটি ধরণের সংগ্রহের আলাদা আলাদা পরিমাণের শোনা রয়েছে। আমি অবশ্যই ডিবি পাশের পৃষ্ঠ এবং সারি ওভারহেডগুলি অবশ্যই মিরর করার বিকল্পগুলির কোনটি আশা করব না, বিশেষত স্কেল (আমি নিশ্চিত যে খুব কম সারিটির পক্ষে যথেষ্ট পরিমাণে আলাদা নাও হতে পারে তবে আপনি পার্থক্যের সন্ধান করছেন না কয়েকশো বাইটে বা কয়েক কেবিতে)
3. তথ্যের ধরণ
   1. ডিবি দিকে:
      CHAR/ VARCHARডেটা অক্ষর প্রতি 1 বাইটে সংরক্ষণ করা হয় (মুহুর্তের জন্য ডাবল-বাইট অক্ষর উপেক্ষা করে)। XMLপাঠ্য উপস্থাপনাকে বোঝায় যে পরিমাণটি প্রায় স্থান গ্রহণ না করা আশাবাদী। এই ডেটাটাইপটি উপাদান এবং বৈশিষ্ট্যগুলির নামের একটি অভিধান তৈরি করে এবং ডকুমেন্টে তাদের কাছে প্রকৃত উল্লেখগুলি তাদের নিজ নিজ আইডির সাথে প্রতিস্থাপন করে (দারুণ সুন্দর, আসলে)। অন্যথায়, স্ট্রিং মানগুলি সমস্ত UTF-16 ("অক্ষর" প্রতি 2 বা 4 বাইট) হয় ঠিক NCHAR/ / এর মতো NVARCHAR। DATETIME26 এবং 8 বাইট মধ্যে হয়। DECIMAL5 এবং 17 বাইটের মধ্যে (যথাযথতার উপর নির্ভর করে)।
   2. অ্যাপ্লিকেশন সার্ভারের দিকে:
      স্ট্রিংস (আবার, ধরে নেওয়া। নেট) সর্বদা UTF-16 থাকে। 8-বিট স্ট্রিং যেমন কোনটি VARCHARধারণ করে তেমন কোনও অপ্টিমাইজেশন নেই । কিন্তু, স্ট্রিংগুলি "ইন্টার্নড" হতে পারে যা একটি ভাগ করা অনুলিপি যা বহুবার উল্লেখ করা যেতে পারে (তবে আমি জানি না যে এটি সংগ্রহে স্ট্রিংয়ের জন্য কাজ করে কিনা, বা যদি তা সব ধরণের সংগ্রহের জন্য কাজ করে)। XMLস্মৃতিতে একইভাবে সঞ্চয় করা যেতে পারে বা নাও থাকতে পারে (আমাকে এটি সন্ধান করতে হবে)। DateTimeসবসময় 8 বাইট (টি-এসকিউএল মত হল DATETIME, কিন্তু না মত DATE, TIMEঅথবা DATETIME2)। Decimalহয় সবসময় 16 বাইট ।

এগুলি বলতে গেলে: অ্যাপ্লিকেশন সার্ভারের দিকে মোটামুটি সঠিক মেমরির পদচিহ্ন আকার পেতে ডিবি সাইডে আপনি করতে পারেন এমন অনেক কিছুই নেই । অ্যাপ্লিকেশন সার্ভারটি নিজেই কোনও বিশেষ টেবিলের সাথে বোঝার পরে নিজেকে জিজ্ঞাসাবাদ করার একটি উপায় খুঁজে বের করতে হবে, সুতরাং এটি কতটা বড় তা জেনে নিন। এবং আমি নিশ্চিত নই যে কোনও ডিবাগার আপনাকে কোনও ভরাট সংগ্রহের রানটাইম আকার দেখতে দেয় কিনা। যদি তা না হয়, তবে কাছে যাওয়ার একমাত্র উপায় হ'ল একটি সারণির সমস্ত সারি পেরিয়ে প্রতিটি কলামকে উপযুক্ত .NET আকার (যেমন INT= * 4, VARCHAR= DATALENGTH() * 2, NVARCHAR= DATALENGTH(), XML= 🙃, ইত্যাদি) দ্বারা গুণিত করা, তবে এটি এখনও প্রশ্নটি ছেড়ে দেয় সংগ্রহের ওভারহেড প্লাস সংগ্রহের প্রতিটি উপাদান।

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

SELECT
   SUM( DATALENGTH([NVarcharColumn_1]) + DATALENGTH([NVarcharColumn_N]) ) + 
   SUM( (DATALENGTH([VarcharColumn_1]) + DATALENGTH([VarcharColumn_N])) * 2 ) + 
   SUM(4 * [number_of_INT_columns]) +
   SUM(8 * [number_of_BIGINT_and_DATETIME_columns]) +
   SUM(16 * [number_of_DECIMAL/NUMERIC_and_UNIQUEIDENTIFIER_columns]) +
   etc..
FROM [SchemaName].[TableName] WITH (NOLOCK) -- assuming no Snapshot Isolation

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

Comments

অ্যাপ্লিকেশনটিতে উপস্থাপিত হওয়ার সাথে সাথে আমরা বাফারের আকারের বিষয়ে নিশ্চিত হয়ে কোডে চেকগুলি প্রয়োগ করে শেষ করেছি।

— টম ভি - টপ্যানসওয়ার্স.অক্সিজ

Answer 2

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

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

আপনার যদি ক্যাশের আকারে ডেটা ধরণের ম্যাপিং থাকে তবে আপনি কিছু টেবিলের মধ্যে ডেটা না দেখেও মূল্যায়ন করতে সক্ষম হবেন:

1. যদি কোনও টেবিলটিতে কেবল স্থিতিশীল ডেটা থাকে (কোনও স্ট্রিং বা ব্লব থাকে না) তবে আপনি sys.partitionsকলাম সংজ্ঞা ব্যবহার করে সারণির আকারটি দেখে এবং সারণির আকারটি নির্ধারণ করে আনতে পারেন।
2. যদি প্রচুর সারি সহ একটি টেবিলের পর্যাপ্ত স্ট্যাটিক ডেটা টাইপ কলাম থাকে তবে আপনি এটির ডেটা না দেখে এটিকে খুব বড় হিসাবে মুছে ফেলতে সক্ষম হতে পারেন। উদাহরণস্বরূপ, 10 মিলিয়ন সারি এবং 5 BIGINTটি কলামযুক্ত একটি টেবিলটিতে সেই ডেটার আকার 10000000 * (8 + 8 + 8 + 8 + 8) = 400 এম বাইট হতে পারে যা আপনার ক্যাশে আকারের সীমা চেয়ে বড় হতে পারে S। এতে স্ট্রিং কলামগুলিরও একটি গুচ্ছ রয়েছে কিনা তা বিবেচ্য নয়।
3. কয়েকটি সারিযুক্ত একটি টেবিল যদি যথেষ্ট ছোট হয় তবে আপনি প্রতিটি গতিশীল ডেটা টাইপের সর্বাধিক সম্ভাব্য আকার রয়েছে তা ধরে নিয়েই আপনি এটি সীমাবদ্ধতার নীচে নিশ্চিত করতে সক্ষম হতে পারেন। উদাহরণস্বরূপ, একটি BIGINTকলাম এবং একটি NVARCHAR(20)কলাম সহ 100 টি সারি টেবিল 100 * (8 + 2 * 20) = 4800 বাইটের বেশি হবে না।
4. এটি সত্য হতে পারে যে কোনও টেবিলের যদি এসকিউএল সার্ভারে একটি সংকুচিত আকার থাকে তবে এটির কোনও কারণের চেয়ে বড় Sএটি ক্যাশে ফিট করার সম্ভাবনা খুব কম। এই জাতীয় মান বিদ্যমান কিনা তা খুঁজে বের করার জন্য আপনাকে পরীক্ষা করতে হবে।
5. আপনি ভাগ্যবান পেতে পারেন যে সমস্ত গতিশীল কলামগুলিতে তাদের পরিসংখ্যান থাকে have পরিসংখ্যানগুলিতে গড় দৈর্ঘ্য সম্পর্কে তথ্য থাকে এবং এটি আপনার উদ্দেশ্যগুলির জন্য যথেষ্ট সঠিক হতে পারে।

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

টেবিলের ডেটা দ্রুত দেখায় এমন প্রশ্নগুলি তৈরি করার জন্য এখানে কিছু ধারণা রয়েছে:

1. বড় টেবিলগুলির জন্য আপনি TABLESAMPLEযতক্ষণ না আপনার নমুনার আকার পর্যাপ্ত পরিমাণে ব্যবহার করতে সক্ষম হবেন ।
2. একটি ক্লাস্টারযুক্ত কী সহ বড় টেবিলগুলির জন্য এটি ক্লাস্টারযুক্ত কীতে ব্যাচগুলিতে প্রক্রিয়া করা দরকারী be দুর্ভাগ্যক্রমে আমি SUM()সেই সংখ্যার মানের উপর ভিত্তি করে যে প্রারম্ভিক প্রস্থানটি ছেড়ে দেয় তা গণনা করার কোনও উপায় জানি না । আমি কেবল কখনও সেই কাজটি দেখেছি ROW_NUMBER()। তবে আপনি টেবিলের প্রথম 10% স্ক্যান করতে পারেন, গণনা করা ডেটার আকারটি সঞ্চয় করতে পারেন, পরবর্তী 10% স্ক্যান করতে পারেন। ক্যাশেগুলির জন্য খুব বড় টেবিলগুলির জন্য আপনি এই পদ্ধতির সাহায্যে খুব তাড়াতাড়ি কাজ বন্ধ করতে পারবেন।
3. কিছু টেবিলের জন্য আপনি গতিশীল সমস্ত কলামগুলিতে আচ্ছাদন সূচিপত্রের জন্য যথেষ্ট ভাগ্যবান হতে পারেন। সারির আকার বা অন্যান্য কারণের উপর নির্ভর করে প্রতিটি সূচক একবারে স্ক্যান করা কোনও টেবিল স্ক্যান করার চেয়ে দ্রুততর হতে পারে। যদি কোনও একক কলামে সূচি পড়ার পরে টেবিলের আকারটি খুব বড় হয় তবে আপনি এই প্রক্রিয়াটি প্রারম্ভিকও ছাড়তে পারেন।
4. আপনার গতিশীল কলামগুলির গড় দৈর্ঘ্য সময়ের সাথে খুব বেশি পরিবর্তন হতে পারে না। আপনার গণনা করা গড় দৈর্ঘ্যটি সংরক্ষণ এবং আপনার গণনায় সেই মানগুলি কিছু সময়ের জন্য ব্যবহার করা ব্যবহারিক হতে পারে। আপনি টেবিলগুলিতে ডিএমএল ক্রিয়াকলাপের ভিত্তিতে বা অন্য কোনও মেট্রিকের ভিত্তিতে এই মানগুলি পুনরায় সেট করতে পারেন।
5. অ্যালগরিদম বিকাশের জন্য যদি সমস্ত টেবিলের উপর পরীক্ষা চালানো সম্ভব হয় তবে আপনি ডেটাগুলিতে নিদর্শনগুলির সুবিধা নিতে সক্ষম হতে পারেন। উদাহরণস্বরূপ, আপনি যদি ক্ষুদ্রতম থেকে শুরু করে টেবিলগুলি প্রক্রিয়া করেন তবে আপনি দেখতে পাচ্ছেন যে আপনি একবারে 10 টি (আমি এই সংখ্যাটি তৈরি করেছি) টেবিলগুলি একক সারিতে প্রক্রিয়াকৃত করে যা ক্যাশের জন্য খুব বড় then ক্যাশে। এটি ক্যাশে উপযুক্তভাবে ফিট করতে পারে এমন কয়েকটি সারণী বাদ দেওয়া ঠিক থাকলে এটি গ্রহণযোগ্য হতে পারে।

আমি বুঝতে পারি যে আমি এই উত্তরে কোনও এসকিউএল কোড অন্তর্ভুক্ত করি নি। আমি এখানে আলোচনা করেছি যে কোনও ধারণার জন্য ডেমো কোড লিখতে সহায়ক হবে কিনা তা আমাকে জানান।

Comments

আমার এমন কিছু বাদে টেবিল পদ্ধতির ভাবেননি, আমি পদ্ধতির মত

— টম ভী - topanswers.xyz চেষ্টা