ডাটাবেসের বৃদ্ধি নিয়ন্ত্রণ করুন:টেবিলের আকার ছোট রাখা এবং ডেটা ব্লাট এড়ানোর কৌশল

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

যদিও এটি একটি নির্দিষ্ট বিন্দুতে ঠিকঠাক কাজ করে, এটি কিছু ডেটা ব্লোট রোধ করার জন্য খুব দরকারী — অথবা, যদি আপনি এটি প্রতিরোধ করতে না পারেন, পর্যাপ্তভাবে বৃদ্ধি পরিচালনা করার জন্য আপনার পরিকাঠামোর জন্য আগে থেকেই পরিকল্পনা করা।

আমরা ডুব দেওয়ার আগে, আসুন দেখি কীভাবে আমরা ফুলে যাওয়া অ্যাপ্লিকেশনগুলির সাথে শেষ হতে পারি৷

আরো ডেটা সবসময় দুর্দান্ত হয় না

আমরা যে অ্যাপ্লিকেশনগুলিতে কাজ করি তার বেশিরভাগই সময়ের সাথে বড় হতে থাকে।

আপনি যদি আপনার ডাটাবেসের জন্য একটি ক্লাউড প্রদানকারী ব্যবহার করেন, তাহলে আপনি আপনার বরাদ্দকৃত সঞ্চয়স্থানের সীমাতে আঘাত করতে পারেন। একবার এটি ঘটলে, আপনাকে একটি ভিন্ন উদাহরণ টাইপে আপগ্রেড করতে হবে। Heroku PostgreSQL ডাটাবেসের একটি সীমা রয়েছে, উদাহরণস্বরূপ, একটি "শখ" স্তরের উদাহরণ 1GB ডেটার মধ্যে সীমাবদ্ধ৷

আরও ডেটা থাকার ফলে কোয়েরির গতির জন্যও প্রভাব রয়েছে। একটি সূচক ছাড়া যা সম্ভব হত তা বড় টেবিলের সাথে অসম্ভব হয়ে যায়। কিছু সারি পরিসীমা স্ক্যান ধীর হয়ে যাবে। ডাটাবেস UPDATE করতে আরও লক অর্জিত হবে এবং DELETE অপারেশন।

ডাটাবেস টেবিল কিভাবে বৃদ্ধি পায়

ধীরে ধীরে ডেটা জমা হয়। আজ যা সমস্যা নয় তা এক মাস বা ছয় মাসে সহজেই সমস্যায় পরিণত হতে পারে। ডেটা হোর্ডিং সম্পর্কে সবচেয়ে বিশ্বাসঘাতকতা হল যে এটি মিস করা এত সহজ। কয়েকটি খুব ক্লাসিক পরিস্থিতি বিবেচনা করুন:

• সম্মতিজনিত কারণে, আপনি paper_trail এর মত একটি রত্ন গ্রহণ করেন এবং একটি audit_log_entries পান টেবিল আপনার অ্যাপ্লিকেশনে তাৎপর্যের মোড সহ প্রতিটি অপারেশন audit_log_entries-এ একটি সারি তৈরি করে টেবিল সেই অডিট লগ এন্ট্রিগুলি কখনই সংরক্ষণাগারভুক্ত হয় না৷
৷
• আপনি আপলোড গ্রহণ করেন এবং ActiveStorage ব্যবহার করছেন। আপনি কখনই আপলোডগুলি মুছবেন না, তাই আপনার activestorage_blobs৷ টেবিল বড় এবং বড় হতে থাকে।
• আপনি ওয়েবে প্রকাশের জন্য একটি ভাগ করা CMS চালান, এবং আপনি নিবন্ধের অংশগুলিকে আপনার ডাটাবেসে সংরক্ষণ করার অনুমতি দেন৷ আপনার প্ল্যাটফর্ম সফল হয়, কিন্তু আপনার লেখকদের অধিকাংশই বই আকারের নিবন্ধ লেখেন। pages টেবিলটি খুব বড় আকারের হয়ে ওঠে যদিও এতে মাত্র কয়েক হাজার পৃষ্ঠা থাকে।
• আপনি ব্যবহারকারীর আপলোড করা সামগ্রীর অনুমতি দেন, কিন্তু সম্মতির কারণে আপনি ডেটা মুছবেন না এবং পরিবর্তে paranoia এর মতো কিছু ব্যবহার করুন একটি পতাকা মাধ্যমে মুছে ফেলার জন্য. আপনার user_items টেবিল অনির্দিষ্টকালের জন্য বৃদ্ধি পায়, এবং আপনার অজান্তেই, 10M সারি অতিক্রম করে৷

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

অনুমান করাও অনেক সহজ হয়ে যায়। যেমন:

• আজ আমাদের events টেবিল মেমরি ফিট. বর্তমান বৃদ্ধির হারে, এটি সাত মাসে মেমরিতে ফিট হবে না৷
• আমাদের RDS ইন্সট্যান্স টাইপের জন্য আমরা 30% স্টোরেজ ব্যবহার করছি। আমরা আগামী বছরের জানুয়ারিতে 90% হিট করব৷
• আমাদের কাছে payments-এ একটি সম্পূর্ণ টেবিল স্ক্যান কোয়েরি রয়েছে প্রতিটি সারিতে একটি ফাংশন গণনা করতে যেখানে ইনপুট প্রশ্নের উপর নির্ভর করে। আমরা জানি যে payments টেবিলটি তিন সপ্তাহে দুই মিলিয়ন সারি অতিক্রম করবে এবং আগামী বছরের জানুয়ারির মধ্যে 20 মিলিয়ন ছাড়িয়ে যাবে।

এই সব একটি ঘটনা বা একটি বিভ্রাট হিসাবে উপস্থাপন করার সম্ভাবনা আছে. তবে আপনি যদি যথেষ্ট তাড়াতাড়ি আক্রমণ করেন তবে আপনি এটি মোটামুটি সহজেই প্রশমিত করতে পারেন। যেমন:

• events-এ 30 দিনের বেশি পুরানো সমস্ত ডেটার জন্য সংরক্ষণাগার সেট আপ করুন টেবিল।
• চার মাসে আপনার RDS ইনস্ট্যান্স আপগ্রেড করুন।
• সম্পূর্ণ টেবিল স্ক্যান সীমিত করতে, একটি অতিরিক্ত WHERE যোগ করুন পরিবর্তে সারিগুলির একটি অনেক ছোট উপসেটে ফাংশন গণনা করার জন্য আমাদের ক্যোয়ারীতে শর্ত।

আপনার ডাটাবেস বৃদ্ধির মাধ্যমে দৃশ্যমানতা অর্জন করুন

আপনার ডাটাবেস বৃদ্ধির উপর নজর রাখতে, আপনার দুটি সম্ভাবনা রয়েছে:

• বিশেষ টুলিং ইনস্টল করুন (যেমন MySQL-এর জন্য পরিসংখ্যান) এবং প্রমিথিউস, টেলিগ্রাফ বা অন্যান্য সরঞ্জামের মাধ্যমে এটিকে আপনার মেট্রিক্স সংগ্রহ ইঞ্জিনের সাথে সংযুক্ত করুন।
• অ্যাপসিগন্যাল ব্যবহার করুন, বিশেষ করে যদি আপনি ইতিমধ্যেই আপনার অ্যাপ্লিকেশনের জন্য এটি ব্যবহার করছেন।

AppSignal বিভিন্ন ধরনের মেট্রিক সঞ্চয় করতে পারে এবং এটি সমর্থন করে এমন একটি মেট্রিক প্রকারকে বলা হয় gauge . একটি gauge পরিবেশ প্রতি একক সময়ের সিরিজ (যেমন production , staging , অথবা development ) যা আপনি সময়ে সময়ে আপডেট করতে পারেন। AppSignal মেট্রিক্স ট্যাগগুলিকেও অনুমতি দেয়, তাই আমরা স্বয়ংক্রিয়ভাবে কিছু ট্যাগ করা gauge তৈরি করতে পারি আমাদের ডাটাবেস টেবিলের জন্য মেট্রিক্স। আসুন এটি করি:

• db.row_count আমাদের টেবিলে সারিগুলির আনুমানিক সংখ্যার জন্য, প্রতি টেবিলে (আমরা আনুমানিক পরে পাব)
• db.data_size_bytes বাইটের সংখ্যার জন্য একটি টেবিল ব্যবহার করছে
• db.index_size_bytes বাইটের সংখ্যার জন্য একটি টেবিলের সূচক ব্যবহার করছে

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

ডাটাবেস টেবিলের সারিগুলি দ্রুত গণনা করা হচ্ছে

সারির সংখ্যার "আনুমানিক" অংশ অপরিহার্য। সাধারনত, আপনি যদি টেবিলে একটি সুনির্দিষ্ট সংখ্যক সারি চান, আপনি SELECT COUNT(1) FROM my_table এর মত একটি প্রশ্ন করতে পারেন . যাইহোক, এটি আমাদের পছন্দের চেয়ে ধীর হতে পারে৷

যখন আপনি COUNT , ডাটাবেস নিশ্চিত করে যে ক্যোয়ারী চলাকালীন সারণির সারির সংখ্যা পরিবর্তিত হবে না — এবং তাই ক্যোয়ারী চলাকালীন টেবিল লক করবে বা একটি ভিন্ন লেনদেন তৈরি করবে। টেবিল যত বড় হবে, কোয়েরি তত ধীর হবে — আরও সারি স্ক্যান করা হবে এবং আরও লক জমা হবে।

তাই, যখন আমরা চাই সারির সংখ্যার "যথেষ্ট কাছাকাছি" আনুমানিকতা (কর্মক্ষমতা অনুমানের জন্য, 10-30 হাজার সারির নির্ভুলতা কম বা বেশি যথেষ্ট), আমরা এই ধরনের ডেটার জন্য অনুসন্ধান করতে অভ্যন্তরীণ ডাটাবেস ইঞ্জিন পরিসংখ্যান ব্যবহার করতে পারি।

বেশিরভাগ ডাটাবেস টেবিলের ডেটাতে অপ্টিমাইজড অ্যাক্সেস করেছে যেহেতু সারিগুলি "পৃষ্ঠাগুলিতে" লেখা আছে। ডাটাবেস ইঞ্জিন ট্র্যাক রাখে কোন সারি কোন পৃষ্ঠাগুলিতে বরাদ্দ করা হয়েছে, মোটামুটিভাবে সন্নিবেশ ক্রমে:

• সারি 1-100 পৃষ্ঠা 1 এ রয়েছে
• সারি 101-200 পৃষ্ঠা 2 এ রয়েছে
• সারি 201-300 পৃষ্ঠা 3 এ রয়েছে

ইত্যাদি।

যেহেতু ইঞ্জিন জানে তার প্রতি টেবিলে কতটি পৃষ্ঠা রয়েছে এবং এটি ব্যবহার করে প্রতি পৃষ্ঠায় মোটামুটি সারি গণনা করে, তাই এটি বরাদ্দ করা পৃষ্ঠাগুলি গণনা করতে পারে এবং তারপরে আপনাকে সেই অনুমানটি দিতে পৃষ্ঠার আকার (প্রতি পৃষ্ঠার সারি) দ্বারা এটিকে গুণ করতে পারে৷ এর কিছু সুবিধা রয়েছে:গণনা খুব দ্রুত, এবং ক্যোয়ারী চলাকালীন টেবিলটি লক করার প্রয়োজন নেই।

MySQL এর জন্য টেবিলের আকার রেকর্ড করুন

তারপরে আমাদের যা করতে হবে তা ডাটাবেসের প্রতি আলাদা কারণ আমাদের টেবিলের পরিসংখ্যানের জন্য ডাটাবেস ইঞ্জিনকে জিজ্ঞাসা করতে হবে। আসুন MySQL দিয়ে শুরু করি। এখানে আমাদের চালানোর জন্য যে ক্যোয়ারী দরকার:

তারপর, এর আউটপুট থেকে কয়েকটি কলাম ধরুন। আমরা যেগুলির প্রতি আগ্রহী তা হল Data_length৷ , Index_length , এবং Rows . একটি টেবিলের আকার Data_length + Index_length এর যোগফল হিসাবে সংজ্ঞায়িত করা হয় , এবং পৃষ্ঠার উপর ভিত্তি করে আনুমানিক সারি গণনা Rows এ রয়েছে .

আসুন এটিকে একটি কোড ব্লকে প্যাকেজ করি যা আপনার সম্পূর্ণ ডাটাবেসের জন্য এই ডেটা সংগ্রহ করে। যেহেতু আমরা কোনো ActiveModel এর সাথে কাজ করছি না ক্লাস, আমরা সরাসরি ActiveRecord দ্বারা প্রদত্ত ক্যোয়ারী পদ্ধতি ব্যবহার করতে যাচ্ছি:

PostgreSQL-এর জন্য টেবিলের আকার রেকর্ড করুন

PostgreSQL এর জন্য আমাদের আরও বিস্তৃত ক্যোয়ারী দরকার কারণ আমাদের কাছে SHOW TABLE STATUS এর মত শর্টকাট কোয়েরি নেই . আমাদের অভ্যন্তরীণ PostgreSQL টেবিলগুলি জিজ্ঞাসা করতে হবে:

মনে রাখবেন যে এটি শুধুমাত্র public এর জন্য দায়ী স্কিমা (আপনি সম্ভবত ব্যবহার করছেন ডিফল্ট)। আপনি যদি অন্যান্য স্কিমা অন্তর্ভুক্ত করতে চান, তাহলে আপনাকে WHERE t.table_schema = 'public' সরাতে হবে শর্ত এবং প্রতিস্থাপন করুন table_info.fetch('name') table_info.fetch('full_table_name') সহ .

নিয়মিত মেট্রিক্স আপডেট করুন

এই ব্লকটি নিয়মিত বিরতিতে চলতে হয়, তাই এটিকে সিডেকিক শিডিউলার বা ক্রোন থেকে চালানো একটি রেক টাস্কে রাখা ভাল। উদাহরণস্বরূপ, আপনি যদি good_job ব্যবহার করেন, তাহলে আপনি এটিকে আপনার "cron" বিভাগে যোগ করতে পারেন:

একটি ড্যাশবোর্ড তৈরি করুন

একবার আপনার কাছে ডেটা আসছে, একটি ড্যাশবোর্ড তৈরি করুন। আপনি আপনার প্রয়োজনের জন্য নিম্নলিখিত ড্যাশবোর্ড অনুলিপি করতে পারেন:

Add dashboard এ ক্লিক করুন এবং তারপর Import dashboard প্রদর্শিত মডেল ডায়ালগে। ড্যাশবোর্ড আপনাকে এইরকম গ্রাফ দেবে:

এবং এই টেবিলের আকার গ্রাফ:

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

ডেটা ব্যাখ্যা করা

আপনার ডেটা দেখার সময়, সারি গণনা বা আকারে সূচকীয় বা রৈখিক বৃদ্ধির দিকে নজর দিন — অন্য কথায়, একটি টেবিল বড় থেকে বড় হচ্ছে।

আপনি যদি এটি দেখতে পান তবে আপনার কাছে কয়েকটি বিকল্প রয়েছে। একটি হল এই সীমাহীন বৃদ্ধির জন্য আর্কিটেক্ট করা — কখন আপগ্রেড করতে হবে এবং আপনি পরবর্তী সেরা আকারে আপগ্রেড করতে পারবেন কিনা তা জানুন। আরেকটি হল একটি নিয়মিত মুছে ফেলার কাজ সেট করা — আমার প্রাক্তন সহকর্মী ওয়ান্ডার হিলেন এই বিষয়ে একটি দুর্দান্ত নিবন্ধ লিখেছেন৷

উদাহরণস্বরূপ, উপরের স্ক্রিনশটে, কিছু টেবিল নিয়মিত সঙ্কুচিত হয় — এটি যখন নিয়মিত পরিষ্কারের কাজগুলি চলে। আপনি দেখতে পাচ্ছেন যে ডেটা একটি নির্দিষ্ট বিন্দু পর্যন্ত জমা হয়, কিন্তু যখন সারিগুলির প্রবেশ মোটামুটি ধ্রুবক থাকে, তখন আকার এবং সারির সংখ্যা কমে যায়৷

যতক্ষণ না এই ড্রপগুলি থাকে এবং আপনার টেবিলে ডেটার পরিমাণ স্থির হারে বৃদ্ধি পায়, আপনার ডাটাবেস হঠাৎ করে সীমাবদ্ধতা নিয়ে আপনাকে অবাক করবে না৷

সারাংশ:ডেটাবেস টেবিল থেকে ডেটা ব্লোট এড়িয়ে চলুন

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

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

আপনার ডাটাবেস আপনাকে অবাক করতে দেবেন না!

জুলিক তারখানভ

অতিথি লেখক জুলিক তারখানভ চেডার পেমেন্টের একজন স্টাফ সফ্টওয়্যার ইঞ্জিনিয়ার এবং একাধিক রুবি ওপেন সোর্স লাইব্রেরির লেখক৷

জুলিক তারখানভের সমস্ত নিবন্ধ