ৰেণ্ডম I/O ৰ প্ৰকৃত খৰচ

আপোনাৰ ব্যৱসায়িক চফ্টৱেৰ হ'ব লাগেতকৈ লেহেমীয়া — আৰু ৰেণ্ডম I/O হৈছে অদৃশ্য অপৰাধী

প্ৰতিবাৰেই কোনো গ্ৰাহকে এটা লেহেমীয়া ডেচব'ৰ্ডৰ বিষয়ে অভিযোগ কৰে, প্ৰতিবাৰ আপোনাৰ দলে এটা প্ৰতিবেদন লোড হ'বলৈ অতিৰিক্ত তিনি ছেকেণ্ড অপেক্ষা কৰে, আৰু প্ৰতিবাৰ যেতিয়া আপোনাৰ চেকআউট পৃষ্ঠাই অধৈৰ্য্যতাৰ বাবে এজন ক্ৰেতাক হেৰুৱায় — ৰেণ্ডম I/O-এ আপোনাৰ ৰাজহ নিৰৱে নিষ্কাশন কৰাৰ সম্ভাৱনা আছে। ডাটাবেছ অভিযন্তাৰ বাবে সংৰক্ষিত বাজৱৰ্ড নহয়। ই প্ৰায় প্ৰতিটো ব্যৱসায়িক এপ্লিকেচনৰ ভিতৰত লুকাই থকা এটা জুখিব পৰা, ব্যয়বহুল বটলনেক, চি আৰ এম লুকআপৰ পৰা আৰম্ভ কৰি চালান উৎপাদনলৈকে। ইয়াৰ প্ৰকৃত খৰচ বুজি পোৱাটো কেৱল কাৰিকৰী কচৰৎ নহয় — ই আৰ্থিক কচৰৎ। ইয়াক আওকাণ কৰা কোম্পানীসমূহে ফুলি উঠা ক্লাউড বিল, হেৰুৱা গ্ৰাহক, আৰু দলসমূহে তৎক্ষণাত লোড হ'বলগীয়া পৰ্দাত অপেক্ষা কৰি আবদ্ধ হৈ থকাত মূল্য দিয়ে।

ৰেণ্ডম I/O ৰ প্ৰকৃত অৰ্থ কি (আৰু ই কিয় ব্যয়বহুল)

ইয়াৰ মূলত, I/O — ইনপুট/আউটপুট — হৈছে সংৰক্ষণলৈ তথ্য পঢ়া আৰু লিখা প্ৰক্ৰিয়া । যেতিয়া আপোনাৰ এপ্লিকেচনে এটা ডাটাবেইচৰ পৰা ৰেকৰ্ডসমূহ আনে, ডিষ্কৰ পৰা নথিপত্ৰসমূহ ল'ড কৰে, বা লেনদেন লগসমূহ লিখে, ই I/O কাৰ্য্যসমূহ কৰে। এই কাৰ্য্যসমূহ দুটা সোৱাদত আহে: ক্ৰমিক আৰু ৰেণ্ডম। ক্ৰমিক I/O এ সংলগ্ন ব্লকসমূহত তথ্য পঢ়ে বা লিখে, যেনে এটা কিতাপ আৰম্ভণিৰ পৰা শেষলৈকে পঢ়া। ৰেণ্ডম I/O এ অভাৱনীয়ভাৱে ইফালে সিফালে জপিয়াই যায়, যেনে 47 পৃষ্ঠালৈ ফ্লিপ কৰা, তাৰ পিছত 3 পৃষ্ঠালৈ, তাৰ পিছত 812 পৃষ্ঠালৈ।

এই দুটা আৰ্হিৰ মাজৰ পৰিৱেশনৰ ব্যৱধান আচৰিত ধৰণৰ। এটা পৰম্পৰাগত হাৰ্ড ড্ৰাইভত, ক্ৰমিক পঢ়াই 150-200 MB/s থ্ৰুপুট লাভ কৰিব পাৰে, আনহাতে ৰেণ্ডম পঢ়াই প্ৰায়ে 0.5-1.5 MB/s ত ক্ৰ'ল কৰে — এটা পাৰ্থক্য 100x বা তাতকৈ অধিক । আনকি আধুনিক NVMe SSD সমূহত, যি যাদৃচ্ছিক I/O পৰিৱেশন নাটকীয়ভাৱে উন্নত কৰে, ব্যৱধান এতিয়াও কাৰ্য্যভাৰৰ ওপৰত নিৰ্ভৰ কৰি 5x ৰ পৰা 20x লৈকে থাকে। যেতিয়া আপোনাৰ ব্যৱসায়িক এপ্লিকেচনে প্ৰতি ছেকেণ্ডত হাজাৰ হাজাৰ সৰু, সিঁচৰতি পঢ়া অনুৰোধ জাৰি কৰে — ইয়ালৈ এটা গ্ৰাহকৰ নাম টানি, এটা চালান লাইন বস্তু, এটা অনুমতি পৰীক্ষা আন ক'ৰবাত — প্ৰতিটো হপে মাইক্ৰ'ছেকেণ্ডত জুখি লেটেন্সি প্ৰৱৰ্তন কৰে যি প্ৰকৃত ব্যৱহাৰকাৰী অপেক্ষাৰ সময়ৰ চেকেণ্ডত যৌগিক কৰে।

পদাৰ্থ বিজ্ঞানৰ কোনো পৰিৱৰ্তন হোৱা নাই: সংৰক্ষণৰ মাজেৰে সিঁচৰতি হৈ থকা তথ্য অভিগম কৰাটো ইয়াক ক্ৰমত প্ৰবাহিত কৰাতকৈ মৌলিকভাৱে লেহেমীয়া। যিটো সলনি হৈছে সেয়া হৈছে আধুনিক এপ্লিকেচনসমূহে যাদৃচ্ছিক I/O সৃষ্টি কৰা স্কেল, যাৰ ফলত ইয়াৰ খৰচ আওকাণ কৰাটো অসম্ভৱ হৈ পৰিছে।

প্ৰতিটো ব্যৱসায়িক কাৰ্য্যকলাপৰ ওপৰত লুকাই থকা কৰ

এজন ব্যৱহাৰকাৰীয়ে এটা CRM ডেচব'ৰ্ড খোলে কি হয় বিবেচনা কৰক। এপ্লিকেচনে এটা গ্ৰাহক টেবুল প্ৰশ্ন কৰে, ইয়াক শেহতীয়া কাৰ্য্যকলাপ লগসমূহৰ সৈতে যোগ কৰে, সংশ্লিষ্ট চুক্তি মানসমূহ টানে, ব্যৱহাৰকাৰীৰ অনুমতিসমূহ পৰীক্ষা কৰে, অধিসূচনা গণনাসমূহ লোড কৰে, আৰু প্ৰদৰ্শন পছন্দসমূহ আনে। এই প্ৰশ্নসমূহৰ প্ৰতিটোৱে ডিষ্কত বিভিন্ন স্থানত সংৰক্ষণ কৰা বিভিন্ন টেবুলসমূহ স্পৰ্শ কৰিব পাৰে। 50 টা গ্ৰাহক ৰেকৰ্ড প্ৰদৰ্শন কৰা এটা ডেচব'ৰ্ডে হুডৰ তলত 300 ৰ পৰা 500 যাদৃচ্ছিক I/O কাৰ্য্যসমূহ সৃষ্টি কৰিব পাৰে। শীৰ্ষ ব্যৱসায়িক সময়ত ইয়াক ২০০ সমকালীন ব্যৱহাৰকাৰীৰে গুণ কৰক, আৰু আপোনাৰ ডাটাবেইচ চাৰ্ভাৰে প্ৰতি ছেকেণ্ডত ১০০,০০০ ৰেণ্ডম পঢ়াৰ ওপৰলৈ প্ৰক্ৰিয়া কৰি আছে।

এয়া কাল্পনিক নহয়। Percona দ্বাৰা ২০২৪ চনৰ এটা অধ্যয়নত দেখা গৈছে যে দুৰ্বলভাৱে অনুকূলিত ডাটাবেইচ ৱৰ্কলোডে তেওঁলোকৰ মুঠ এক্সিকিউচন সময়ৰ ৬৮%লৈকে I/O কাৰ্য্যসমূহত অপেক্ষা কৰি খৰচ কৰে, ৰেণ্ডম অভিগম আৰ্হিসমূহ প্ৰাথমিক অপৰাধী হোৱাৰ সৈতে। হাজাৰ হাজাৰ ব্যৱসায়ক সেৱা আগবঢ়োৱা এটা SaaS কোম্পানীয়ে, ই পোনপটীয়াকৈ অধিক আন্তঃগাঁথনি খৰচলৈ অনুবাদ কৰে। ক্লাউড প্ৰদানকাৰীসকলে IOPS দ্বাৰা চাৰ্জ লয় (প্ৰতি ছেকেণ্ডত I/O কাৰ্য্যসমূহ), আৰু যাদৃচ্ছিক I/O-গধুৰ কাৰ্য্যভাৰে মাহিলী সংৰক্ষণ বিলসমূহ শ শৰ পৰা লাখ লাখ ডলাৰলৈ ঠেলিব পাৰে — তথ্যৰ আয়তনৰ বাবে নহয়, কিন্তু অভিগম আৰ্হিৰ বাবে।

খৰচ আন্তঃগাঁথনিৰ বাহিৰলৈও বিস্তৃত। প্ৰতি ১০০ মিলিছেকেণ্ডৰ অতিৰিক্ত পৃষ্ঠা লোড সময়ৰ মূৰে মূৰে ৰূপান্তৰৰ হাৰ প্ৰায় ৭% হ্ৰাস পায়, আকামাইৰ গৱেষণা অনুসৰি। যেতিয়া ৰেণ্ডম I/O এ আপোনাৰ চালান সৃষ্টি বা প্ৰতিবেদন লোডিংত এটা সম্পূৰ্ণ চেকেণ্ড যোগ কৰে, আপুনি কেৱল গণনা বাৰ্ন কৰা নাই — আপুনি ৰাজহ বাৰ্ন কৰিছে ।

য'ত ব্যৱসায়িক এপ্লিকেচনসমূহে পৰিৱেশন ৰক্তক্ষৰণ কৰে

সকলো বৈশিষ্ট্য সমান সৃষ্টি কৰা নহয় যেতিয়া I/O আৰ্হিৰ কথা আহে । কিছুমান সাধাৰণ ব্যৱসায়িক কাৰ্য্যকলাপও যাদৃচ্ছিক প্ৰৱেশৰ বাবে আটাইতকৈ বেয়া অপৰাধী:

• অন্বেষণ আৰু ফিল্টাৰিং: একাধিক ক্ষেত্ৰসমূহৰ মাজেৰে প্ৰশ্ন কৰিলে (নাম, তাৰিখ, অৱস্থা, টেগসমূহ) ডাটাবেইচক সংৰক্ষণৰ মাজেৰে সিঁচৰতি হৈ থকা সূচীসমূহ স্কেন কৰিবলৈ বাধ্য কৰে, গধুৰ যাদৃচ্ছিক পঢ়া সৃষ্টি কৰে
• ডেচব'ৰ্ড সংগ্ৰহসমূহ: ৰাজহৰ যোগফল, সক্ৰিয় ব্যৱহাৰকাৰী গণনা, বা অতিৰিক্ত চালান গণনা কৰাৰ বাবে বিভিন্ন তথ্য পৃষ্ঠাসমূহত বিয়পি থকা হাজাৰ হাজাৰ শাৰী স্পৰ্শ কৰাৰ প্ৰয়োজন
• অনুমতি পৰীক্ষাসমূহ: বহু-ভাড়াতীয়া প্লেটফৰ্মসমূহত ভূমিকা-ভিত্তিক অভিগম নিয়ন্ত্ৰণৰ বাবে প্ৰায়ে প্ৰতিটো অনুৰোধত একাধিক লুকআপৰ প্ৰয়োজন হয় — ব্যৱহাৰকাৰী → ভূমিকা → অনুমতিসমূহ → সম্পদ — প্ৰত্যেকেই বিভিন্ন টেবুলসমূহ আঘাত কৰা
• ৰিপৰ্ট সৃষ্টি: মাহিলী পে-ৰোল প্ৰতিবেদন, বহৰ ৰক্ষণাবেক্ষণৰ সাৰাংশ, বা এইচ আৰ বিশ্লেষণে একেলগে ডজন ডজন টেবুলৰ পৰা তথ্য টানে
• বাস্তৱ-সময়ৰ জাননীসমূহ: মডিউলসমূহৰ মাজেৰে নতুন বাৰ্তাসমূহ, কাৰ্য্য আপডেইটসমূহ, আৰু চিস্টেম সতৰ্কবাণীসমূহৰ বাবে পৰীক্ষা কৰিলে সৰু, যাদৃচ্ছিক প্ৰশ্নসমূহৰ এটা স্থিৰ প্ৰবাহ সৃষ্টি হয়

আৰ্হি স্পষ্ট: এটা প্লেটফৰ্মে যিমানেই অধিক মডিউল আৰু বৈশিষ্ট্যসমূহ প্ৰদান কৰে, সিমানেই অধিক I/O পথসমূহ বহুগুণিত হয়। এটা সৰল লিংক-ইন-বায়' সঁজুলিয়ে প্ৰতি পৃষ্ঠা লোডত ১০টা প্ৰশ্ন সৃষ্টি কৰিব পাৰে। চি আৰ এম, চালান, এইচ আৰ, পে-ৰোল, বুকিং, আৰু বিশ্লেষণ মডিউলৰ সৈতে এটা সম্পূৰ্ণ ব্যৱসায়িক অপাৰেটিং চিষ্টেমে — যেনেকৈ মেৱেইজে ইয়াৰ ২০৭টা মডিউলত প্ৰদান কৰে — তাত্ত্বিকভাৱে শ শ সৃষ্টি কৰিব পাৰে। তৎক্ষণাত অনুভৱ কৰা প্লেটফৰ্ম আৰু মন্থৰ অনুভৱ কৰা প্লেটফৰ্মৰ মাজৰ পাৰ্থক্য প্ৰায়ে সেই I/O আৰ্হিসমূহ পৰ্দাৰ আঁৰত কিমান বুদ্ধিমানৰূপে পৰিচালিত হয় তাৰ ওপৰত নিৰ্ভৰ কৰে।

সমস্যাত হাৰ্ডৱেৰ পেলোৱাটোৱে কিয় কাম নকৰে

যেতিয়া এপ্লিকেচনসমূহ লেহেমীয়া হয় তেতিয়া প্ৰবৃত্তিটো হৈছে উন্নয়ন কৰা। ডাঙৰ চাৰ্ভাৰ, দ্ৰুত SSD, অধিক RAM। আৰু হাৰ্ডৱেৰ উন্নয়নে সহায় কৰিলেও, ই হ্ৰাস পোৱা ৰিটাৰ্ণৰ এটা বক্ৰ অনুসৰণ কৰে যিয়ে চিএফঅ'সকলক অস্বস্তিকৰ কৰি তোলে। আপোনাৰ ডাটাবেইচ চাৰ্ভাৰৰ RAM 64GB ৰ পৰা 128GB লৈ দুগুণ কৰিলে কেশ্ব হিট হাৰ 92% ৰ পৰা 96% লৈ উন্নত হব পাৰে — এটা অৰ্থপূৰ্ণ লাভ, কিন্তু বাকী 4% কেশ্ব মিছে এতিয়াও ৰেণ্ডম I/O ৰ সৈতে সংৰক্ষণ হিট কৰে । AWS ত আপোনাৰ IOPS আবণ্টন 3,000 ৰ পৰা 10,000 লৈ তিনিগুণ কৰিলে প্ৰতিমাহে প্ৰায় $450 অধিক খৰচ হয় কিন্তু p99 সঁহাৰি সময় 30% উন্নত কৰিব পাৰে।

আচল সমস্যাটো স্থাপত্যৰ। ৰেণ্ডম I/O প্ৰায়ে গভীৰ সমস্যাৰ এটা লক্ষণ: অনুপস্থিত বা বেয়াকৈ ডিজাইন কৰা সূচীসমূহ, N+1 প্ৰশ্ন আৰ্হিসমূহ য'ত এপ্লিকেচনে বেচিঙৰ পৰিবৰ্তে প্ৰতি বস্তুত এটা ডাটাবেইচ কল কৰে, অতি-স্বাভাৱিক আঁচনিসমূহ যি এটা প্ৰদৰ্শন শাৰীৰ বাবে পাঁচটা টেবুল যোগদানৰ প্ৰয়োজন, আৰু পঢ়া প্ৰতিলিপিসমূহ বা কেচিং স্তৰসমূহৰ অভাৱ। হাৰ্ডৱেৰ উন্নয়নে লক্ষণটোৰ চিকিৎসা কৰে। স্থাপত্য অনুকূলনে কাৰণটোৰ চিকিৎসা কৰে।

সৰ্বাধিক ব্যয়বহুল I/O কাৰ্য্য হৈছে যিটো প্ৰথম অৱস্থাত থাকিব নালাগে । দ্ৰুত সংৰক্ষণত ব্যয় কৰা প্ৰতিটো ডলাৰৰ বাবে, প্ৰশ্ন অনুকূলনত ব্যয় কৰা দহ চেণ্টে উন্নত ফলাফল প্ৰদান কৰে। যিবোৰ কোম্পানীয়ে পৰিৱেশনৰ ওপৰত জয়ী হয়, সেইবোৰে নিজৰ প্ৰতিযোগীতকৈ বেছি খৰচ নকৰে — তেওঁলোকে নিজৰ ডাটা অভিগমৰ আৰ্হিক আউট-থিংক কৰে।

ব্যৱহাৰিক কৌশলসমূহ যি প্ৰকৃততে যাদৃচ্ছিক I/O হ্ৰাস কৰে

এৰাব নোৱাৰা I/O হ্ৰাস কৰাৰ বাবে আপোনাৰ এপ্লিকেচনৰ সম্পূৰ্ণ পুনৰ লিখাৰ প্ৰয়োজন নাই । ইয়াৰ বাবে তথ্য কেনেকৈ সংৰক্ষণ কৰা হয়, অভিগম কৰা হয় আৰু কেশ্ব কৰা হয় তাৰ লক্ষ্য, জুখিব পৰা পৰিবৰ্তনৰ প্ৰয়োজন। ইয়াত সৰ্বোচ্চ প্ৰভাৱ পেলোৱা কৌশলসমূহ উল্লেখ কৰা হৈছে:

1. আক্ৰমণাত্মক প্ৰশ্ন বেচিং প্ৰণয়ন কৰক। N+1 প্ৰশ্ন আৰ্হিসমূহ আগ্ৰহী লোডিঙৰ সৈতে সলনি কৰক। যদি আপোনাৰ ডেচব'ৰ্ডে ৫০ জন গ্ৰাহক আৰু তেওঁলোকৰ শেহতীয়া কাৰ্য্যকলাপ লোড কৰে, ৫০ টা ব্যক্তিগত লুকআপৰ পৰিবৰ্তে WHERE customer_id IN (...) ব্যৱহাৰ কৰি এটা প্ৰশ্নত সকলো ৫০ টা কাৰ্য্যকলাপৰ গোট আনিব। ই কেৱল তালিকা দৰ্শনত যাদৃচ্ছিক I/O ৮০% হ্ৰাস কৰিব পাৰে।
2. কম্পোজিট সূচীসমূহ কৌশলগতভাৱে ব্যৱহাৰ কৰক। (tenant_id, status, created_at) ত এটা সংমিশ্ৰিত সূচীয়ে ডাটাবেইচক পৃথক সূচীসমূহৰ মাজেৰে একাধিক যাদৃচ্ছিক লুকআপৰ পৰিবৰ্তে এটা ক্ৰমিক সূচী স্কেনৰ সৈতে সাধাৰণ ফিল্টাৰ কৰা প্ৰশ্নসমূহ সন্তুষ্ট কৰিবলৈ দিয়ে।
3. বুদ্ধিমান অবৈধকৰণৰ সৈতে এটা কেচিং স্তৰ উন্মোচন কৰক। সঘনাই অভিগম কৰা কিন্তু খুব কমেইহে সলনি কৰা তথ্য — ব্যৱহাৰকাৰীৰ অনুমতি, সংস্থাৰ সংহতিসমূহ, মডিউল সংৰূপসমূহ — মেমৰিত কেশ্ব কৰক। Redis বা Memcached এ এইবোৰ মাইক্ৰ'ছেকেণ্ডত সেৱা আগবঢ়াব পাৰে, প্ৰতি মিনিটত হাজাৰ হাজাৰ যাদৃচ্ছিক পঢ়া আঁতৰাই।
4. পূৰ্ব-গণনা সংগ্ৰহসমূহ। প্ৰতিটো ডেচব'ৰ্ড লোডত মাহেকীয়া ৰাজহ বা হেডকাউণ্ট গণনা কৰাৰ পৰিবৰ্তে, সংগ্ৰহ কাৰ্য্যসমূহ এটা সময়সূচীত চলাওক আৰু ফলাফলসমূহ সংৰক্ষণ কৰক। বাস্তৱ-সময়ৰ ৰেণ্ডম I/O ৰ এটা বৃহৎ হ্ৰাসৰ বাবে তথ্য সতেজতাৰ অলপ পৰিমাণৰ ব্যৱসায় কৰক।
5. বৃহৎ টেবুলসমূহ অভিগম আৰ্হি অনুসৰি বিভাজন কৰক। যদি 90% প্ৰশ্নই যোৱা 30 দিনৰ তথ্য স্পৰ্শ কৰে, আপোনাৰ টেবুলসমূহ তাৰিখ পৰিসীমা অনুসৰি বিভাজন কৰক যাতে সক্ৰিয় বিভাজন কেশ্বত গৰম হৈ থাকে যেতিয়া ঐতিহাসিক তথ্য সস্তা সংৰক্ষণত ঠাণ্ডা থাকে।

এইবোৰ বিদেশী কৌশল নহয়। এইবোৰ একেবোৰ আৰ্হি যিয়ে লাখ লাখ ব্যৱহাৰকাৰীক সেৱা আগবঢ়োৱা প্লেটফৰ্মসমূহক জটিল, বহু-মডিউল আন্তঃপৃষ্ঠসমূহত উপ-ছেকেণ্ডৰ সঁহাৰি সময় বজাই ৰাখিবলৈ অনুমতি দিয়ে। যেতিয়া Mewayz এ V2 ৰ বাবে ইয়াৰ স্থাপত্য পুনৰ নিৰ্মাণ কৰিছিল — এটা লিংক-ইন-বায়' সঁজুলিৰ পৰা 138,000 তকৈ অধিক ব্যৱহাৰকাৰীক সেৱা আগবঢ়োৱা এটা 207-মডিউল ব্যৱসায়িক অপাৰেটিং ছিষ্টেমলৈ স্কেলিং — I/O অভিগম আৰ্হিসমূহ অনুকূল কৰাটো আন্তঃগাঁথনি খৰচসমূহ আনুপাতিকভাৱে গুণ নকৰাকৈ সেই সম্প্ৰসাৰণক কাৰ্য্যক্ষম কৰাৰ বাবে মূল আছিল।

ব্যৱহাৰকাৰীৰ অভিজ্ঞতা আৰু ধৰি ৰখাৰ ওপৰত যৌগিক প্ৰভাৱ

কাৰ্য্যক্ষমতা কেৱল এটা বেকএণ্ড চিন্তা নহয় — ই এটা উৎপাদন বৈশিষ্ট্য। গুগলৰ গৱেষণাই ধাৰাবাহিকভাৱে দেখুৱাইছে যে ৫৩% মোবাইল ব্যৱহাৰকাৰীয়ে লোড হ’বলৈ ৩ ছেকেণ্ডতকৈ অধিক সময় লোৱা পৃষ্ঠা এটা পৰিত্যাগ কৰে। ব্যৱসায়িক এপ্লিকেচনসমূহৰ বাবে য'ত ব্যৱহাৰকাৰীয়ে প্ৰতিদিনে ডজন ডজন বাৰ যোগাযোগ কৰে, সহনশীলতা আৰু কম। সাপ্তাহিক প্ৰতিবেদন চলোৱা এজন পে-ৰোল মেনেজাৰ, আবেদনকাৰীক পৰ্যালোচনা কৰা এজন এইচ আৰ লিড, বা পাইপলাইনৰ অৱস্থা পৰীক্ষা কৰা এজন বিক্ৰী প্ৰতিনিধি — এই ব্যৱহাৰকাৰীসকলে গতিৰ এক স্বজ্ঞাত অনুভূতি গঢ়ি তোলে। তেওঁলোকে হয়তো "চালান সংগ্ৰহ প্ৰশ্নত যাদৃচ্ছিক I/O বিলম্ব অতি উচ্চ," কিন্তু তেওঁলোকে ক'ব "এই চফ্টৱেৰটোৱে লেহেমীয়া অনুভৱ কৰে" আৰু বিকল্পসমূহৰ মূল্যায়ন আৰম্ভ কৰিব।

যৌগিক প্ৰভাৱ জুখিব পৰা যায়। 2.4 ছেকেণ্ডৰ পৰিবৰ্তে 800ms ত ডেচব'ৰ্ড লোড কৰা এটা প্লেটফৰ্মে কেৱল 3x দ্ৰুত অনুভৱ নকৰে — ই ব্যৱহাৰৰ আচৰণ সলনি কৰে। ব্যৱহাৰকাৰীসকলে তথ্য অধিক সঘনাই পৰীক্ষা কৰে, অধিক মডিউলসমূহ অন্বেষণ কৰে, আৰু সঁজুলিটোক তেওঁলোকৰ কাৰ্য্যপ্ৰবাহসমূহত অধিক গভীৰভাৱে সংহতি কৰে। উচ্চ এংগেজমেণ্টে অধিক ৰিটেনচনক ড্ৰাইভ কৰে, যিয়ে অধিক জীৱনকালৰ মূল্যক ড্ৰাইভ কৰে। স্লেকে বিখ্যাতভাৱে ইয়াৰ প্ৰাৰম্ভিক বৃদ্ধিৰ এটা উল্লেখযোগ্য অংশক অব্ছেছিভ পাৰফৰমেন্স অপ্টিমাইজেচনৰ বাবে দায়ী কৰিছিল, গতি নিজেই এটা প্ৰতিযোগিতামূলক খাদ বুলি স্বীকাৰ কৰিছিল।

অল-ইন-ৱান ব্যৱসায়িক প্লেটফৰ্মসমূহৰ বাবে, এই প্ৰভাৱ প্ৰতিটো মডিউলত বহুগুণে বৃদ্ধি পায়। যদি চি আৰ এম দ্ৰুত হয় কিন্তু চালান লেহেমীয়া হয়, তেন্তে সমগ্ৰ প্লেটফৰ্মৰ ধাৰণা ক্ষতিগ্ৰস্ত হয়। বৈশিষ্ট্যসমূহৰ মাজেৰে পৰিৱেশনৰ সামঞ্জস্যতা — বুকিং ব্যৱস্থাপনাৰ পৰা বহৰ অনুসৰণলৈকে বিশ্লেষণলৈকে — সকলোতে সামঞ্জস্যপূৰ্ণভাৱে অনুকূলিত I/O আৰ্হিৰ প্ৰয়োজন, কেৱল আটাইতকৈ দৃশ্যমান মডিউলসমূহত নহয়।

কি গুৰুত্বপূৰ্ণ জুখি: যাদৃচ্ছিক I/O দৃশ্যমান কৰা

আপুনি যি দেখা নাপায় ঠিক কৰিব নোৱাৰে। যাদৃচ্ছিক I/O খৰচসমূহ সম্বোধন কৰাৰ প্ৰথম পদক্ষেপ হৈছে আপোনাৰ অভিযান্ত্ৰিক আৰু কাৰ্য্যসমূহ দলসমূহৰ বাবে সিহতক দৃশ্যমান কৰা। Datadog, New Relic, বা আনকি Grafana ৰ সৈতে Prometheus ৰ দৰে মুক্ত-উৎস সমাধানসমূহে IOPS আৰ্হিসমূহ অনুসৰণ কৰিব পাৰে, বিলম্ব বিতৰণসমূহ প্ৰশ্ন কৰিব পাৰে, আৰু বাস্তৱ সময়ত কেশ্ব হিট হাৰসমূহ। আটাইতকৈ গুৰুত্বপূৰ্ণ মেট্ৰিকসমূহ হ’ল:

• p95 আৰু p99 প্ৰশ্ন বিলম্ব: গড় বিলম্বই বিষ লুকুৱাই ৰাখে। ৯৫ আৰু ৯৯ শতাংশই দেখুৱাই যে আপোনাৰ আটাইতকৈ লেহেমীয়া — আৰু আটাইতকৈ হতাশ — ব্যৱহাৰকাৰীসকলে প্ৰকৃততে কি অনুভৱ কৰে
• পঢ়া বনাম লিখা, ক্ৰমিক বনাম যাদৃচ্ছিক দ্বাৰা IOPS বিভাজন: ই আপোনাৰ কাৰ্য্যভাৰ I/O-বাউণ্ড নে নহয় আৰু কি ধৰণৰ I/O প্ৰধান
প্ৰকাশ কৰে
• কেশ্ব হিট অনুপাত: এটা ভালদৰে টিউন কৰা চিস্টেমত 95% ৰ তলৰ অনুপাতে ডাটা অভিগম আৰ্হিৰ পৰামৰ্শ দিয়ে যি মেমৰিৰ পৰা সেৱা আগবঢ়োৱা হোৱা নাই
• প্ৰতি পৃষ্ঠা লোডত প্ৰশ্নৰ সংখ্যা: যদি এটা ব্যৱহাৰকাৰীৰ কাৰ্য্যই ২০-৩০ টাতকৈ অধিক ডাটাবেইচ প্ৰশ্ন ট্ৰিগাৰ কৰে, প্ৰায় নিশ্চিতভাৱে এটা অনুকূলন সুযোগ
আছে

এই তথ্যৰ সৈতে সজ্জিত, দলসমূহে অনুমান কৰাৰ পৰিৱৰ্তে সৰ্বোচ্চ-প্ৰভাৱ অনুকূলনসমূহক অগ্ৰাধিকাৰ দিব পাৰে। I/O পৰিৱেশনক প্ৰথম-শ্ৰেণীৰ মেট্ৰিক হিচাপে গণ্য কৰা ব্যৱসায়সমূহে — আপটাইম, ভুল হাৰ, আৰু ব্যৱহাৰকাৰী সন্তুষ্টিৰ সৈতে — কম খৰচত দ্ৰুত উৎপাদনসমূহ ধাৰাবাহিকভাৱে প্ৰদান কৰে। যিখন বজাৰত ব্যৱহাৰকাৰীয়ে ব্যৱসায়িক সঁজুলিসমূহ গ্ৰাহক এপৰ দৰেই সঁহাৰিজনক হ’ব বুলি আশা কৰে, সেই অনুশাসন ঐচ্ছিক নহয়। ই হৈছে ১৩৮,০০০ ব্যৱহাৰকাৰীলৈ ৰূপৱতীভাৱে স্কেল কৰা প্লেটফৰ্ম আৰু নিজৰ জটিলতাৰ অধীনত বাকল কৰা প্লেটফৰ্মৰ মাজৰ পাৰ্থক্য।

সঘনাই সোধা প্ৰশ্ন

এৰাব নোৱাৰা I/O সঠিকভাৱে কি, আৰু ই ইমান লেহেমীয়া কিয়?

এৰাব নোৱাৰা I/O ঘটে যেতিয়া এটা ব্যৱস্থাপ্ৰণালীয়ে এটা সংৰক্ষণ ড্ৰাইভত বিভিন্ন, অক্ৰমিক অৱস্থানৰ পৰা তথ্যৰ সৰু অংশ পঢ়ে বা লিখে । ক্ৰমিক I/O ৰ দৰে নহয় (এটা নথিপত্ৰ আৰম্ভণিৰ পৰা শেষলৈকে পঢ়া), পঢ়া/লিখা মূৰে অহৰহ ইফালে সিফালে জপিয়াই যাব লাগিব, গুৰুত্বপূৰ্ণ দৈহিক বিলম্ব সৃষ্টি কৰি। এইটোৱেই হৈছে প্ৰধান কাৰণ এটা ডাটাবেইচ প্ৰশ্ন যিয়ে সিঁচৰতি ৰেকৰ্ডসমূহ আনিছে এটা ডাঙৰ ভিডিঅ' ফাইল ষ্ট্ৰীম কৰাতকৈ বহুত লেহেমীয়া, যদিও মুঠ তথ্যৰ পৰিমাণ কম।

এৰাব নোৱাৰা I/O এ মোৰ ব্যৱসায়িক কাৰ্য্যকলাপত প্ৰত্যক্ষভাৱে কেনেকৈ প্ৰভাৱ পেলায়?

ই ব্যৱহাৰকাৰীৰ অভিজ্ঞতা আৰু উৎপাদনশীলতাক প্ৰত্যক্ষভাৱে প্ৰভাৱিত কৰে। লেহেমীয়া এপ্লিকেচনৰ সঁহাৰিয়ে গ্ৰাহকক হতাশ কৰে, যাৰ ফলত কাৰ্ট পৰিত্যাগ আৰু সমৰ্থন টিকট হয়। কৰ্মচাৰীৰ বাবে মন্থৰ চি আৰ এম আৰু প্ৰতিবেদন সঁজুলিয়ে মূল্যৱান সময় নষ্ট কৰে। এই পলমসমূহে স্পষ্ট খৰচলৈ ৰূপান্তৰিত হয়: হেৰুৱা বিক্ৰী, কৰ্মচাৰীৰ দক্ষতা হ্ৰাস, আৰু আপোনাৰ ব্ৰেণ্ডৰ সঁহাৰিৰ বাবে সুনামৰ সম্ভাৱ্য ক্ষতি। বিলম্বৰ প্ৰতিটো চেকেণ্ডৰ এটা আৰ্থিক মূল্য থাকে।

এয়া কেৱল এটা হাৰ্ডৱেৰ সমস্যা নহয়নে? মই কেৱল দ্ৰুত SSD কিনিব নোৱাৰোনে?

যদিও দ্ৰুত SSD সমূহে সহায় কৰে, সিহত এটা ব্যয়বহুল আৰু প্ৰায়ে অসম্পূৰ্ণ সমাধান। মূল কাৰণ সাধাৰণতে অদক্ষ চফ্টৱেৰ যিয়ে বহুতো সৰু, সিঁচৰতি ডাটাবেছ অনুৰোধ কৰে। এপ্লিকেচন ক'ড আৰু ডাটাবেইচ প্ৰশ্নসমূহ অনুকূল কৰি ৰেণ্ডম I/O কম কৰিবলে বহুত বেছি ফলপ্ৰসূ। Mewayzৰ দৰে সমাধানসমূহ, ইয়াৰ ২০৭টা পূৰ্ব-নিৰ্মিত মডিউলৰ সৈতে $19/মাহৰ পৰা আৰম্ভ কৰি, তথ্য অভিগম আৰ্হিসমূহ দক্ষতাৰে ষ্ট্ৰীমলাইন কৰিবলে ডিজাইন কৰা হৈছে।

এৰাব নোৱাৰা I/O মোৰ বটলনেক নেকি চিনাক্ত কৰাৰ প্ৰথম পদক্ষেপ কি?

আপোনাৰ এপ্লিকেচনৰ পৰিৱেশন নিৰীক্ষণ সঁজুলিসমূহৰ সৈতে আৰম্ভ কৰক। ডাটাবেইচ মেট্ৰিক্স বিচাৰক যিয়ে প্ৰতি ছেকেণ্ডত উচ্চ পঢ়া/লিখা কাৰ্য্যসমূহ (IOPS) দেখুৱাই লেহেমীয়া প্ৰশ্ন সময়ৰ সৈতে সংযুক্ত। সঘনাই, সৰু সৰু প্ৰশ্নসমূহ চিনাক্ত কৰিবলৈ আপোনাৰ এপ্লিকেচন প্ৰফাইল কৰক। যদি এটা ব্যৱহাৰকাৰী কাৰ্য্যই কেইটামান দক্ষৰ পৰিবৰ্তে ডজন ডজন ব্যক্তিগত ডাটাবেইচ কল ট্ৰিগাৰ কৰে, আপুনি সম্ভৱতঃ এটা যাদৃচ্ছিক I/O সমস্যা পাইছে যি ঠিকনা দিয়াৰ প্ৰয়োজন।