ডাটাবেস পরিবর্তন করার আগে ব্যয়বহুল অনুরোধটি খুঁজে নিন
একটি ব্যবহারকারীর ক্রিয়াকলাপ থেকে শুরু করুন: ক্যাটাগরি লোড, আর্টিকেল সার্চ, কার্টে যোগ করা, বা অর্ডার সাবমিশন। তার রুট, কুয়েরি গণনা, ডাটাবেস সময়, ফেরত দেওয়া রো, এবং অনুরোধের সময় ধরুন। একটি ধীর পেজ অ্যাপ্লিকেশন কোড বা অন্য কোন নির্ভরশীলতার উপরও অপেক্ষা করতে পারে, তাই শুধুমাত্র পেজ-লোড টাইম থেকে নির্ণয় করবেন না।
একটি কুয়েরি প্ল্যান হল টেবিল, ইনডেক্স, জয়েন, সর্ট এবং অগ্রিগেটগুলোর মধ্যে ডাটাবেসের রুট। PostgreSQL-এ EXPLAIN সেই রুট দেখায়। EXPLAIN ANALYZE স্টেটমেন্টটি চালায় এবং প্রকৃত রো ও টাইমিং রিপোর্ট করে, তাই একটি নিরাপদ প্রতিনিধিত্বকারী কুয়েরি ব্যবহার করুন। বড় এস্তিমেট-বনাম-প্রকৃত রো পার্থক্য পরিসংখ্যান বা শর্তাদি তদন্তের কারণ, স্বয়ংক্রিয়ভাবে ইনডেক্স আবেদনের অজুহাত নয়।
একটি প্রার্থী কুয়েরিকে একটি রুট এবং আউটকামের সঙ্গে বেঁধে দিন, যাতে কেবল ড্যাশবোর্ড-রিপোর্ট ধীর চেকআউটকে প্রতিপক্ষ না করে।
পরিবর্তনের আগে টাইমিং এবং তুলনীয় ট্রাফিক রেকর্ড করুন, গ্রাহক শনাক্তকারী, টোকেন বা কার্ড-সম্পর্কিত মান লগ ছাড়া।
আপনি আসলে যে অ্যাক্সেস পাথ ব্যবহার করেন সেটার জন্য ইনডেক্স ডিজাইন করুন
একটি ইনডেক্স হল একটি রক্ষণাবেক্ষিত স্ট্রাকচার যা রো খুঁজে পেতে বা সেগুলো অর্ডারে ফেরত দিতে সাহায্য করে; এটি সার্বজনীন গতি সুইচ নয়। একটি গুরুত্বপূর্ণ কুয়েরির ফিল্টার, জয়েন কী এবং সর্ট অর্ডার থেকে শুরু করুন, তারপর প্ল্যানে প্রস্তাবিত ইনডেক্স নিশ্চিত করুন। PostgreSQL ডকুমেন্ট করে যে একটি মিলে যাওয়া B-tree ইনডেক্স আলাদা সর্ট ছাড়াই ORDER BY মেটাতে পারে, বিশেষত ছোট LIMIT-এ।
ইনডেক্সগুলি স্টোরেজ ও লিখনের কাজ যোগ করে কারণ insert, update, delete এগুলো রক্ষণাবেক্ষণ করে। এমন একটি কুয়েরির জন্য যা টেবিলের বড় অংশই চায়, একটি সিকুয়েনশিয়াল স্ক্যান এবং স্পষ্ট সর্ট দ্রুত হতে পারে। প্রোডাকশন-এর মতো ডেটায় পরীক্ষা করুন এবং কেবল তখনই একটি ইনডেক্স রাখুন যখন সুবিধা তার খরচকে ন্যায্য করে।
কুয়েরির প্রকৃত ফিল্টার এবং ORDER BY ব্যবহার করুন, যেখানে ইন্টারফেস স্থায়ী অর্ডারের জন্য একটি নির্ধারিত টাই-ব্রেকার চায়।
পুনরায় পর্যালোচনা করুন কোন ইনডেক্স ব্যবহার হচ্ছে এবং রাইট-ওয়ার্কে তার খরচ কী; ডেটা ও ট্রাফিক বদলালে পুনরায় যাচাই করুন।
পেজিনেশনকে স্থিতিশীল এবং সাশ্রয়ী করুন
পেজ-নাম্বর পেজিনেশন সাধারণত LIMIT ও OFFSET ব্যবহার করে। সর্বদা একটি পূর্বানুমেয় অর্ডার আরোপ করুন। PostgreSQL সতর্ক করে যে ORDER BY ছাড়া LIMIT অনিশ্চিত সাবসেট ফেরত দিতে পারে; ভিন্ন LIMIT বা OFFSET মানে অপ্টিমাইজার ভিন্ন প্ল্যান বেছে নিতে পারে।
বড় OFFSETগুলো যাচাইয়ের দাবি রাখে কারণ স্কিপ করা সারিগুলোও এখনও গণনা করতে হয়। গভীর ক্যাটালগ, অর্ডার-ইতিহাস, বা আর্কাইভ ব্রাউজিং-এর জন্য কার্সর বা কাইজেট (keyset) পেজিনেশন বিবেচনা করুন: শেষ দেখা স্থায়ী সর্ট মান এবং ইউনিক টাই-ব্রেকারের পরে রো অনুরোধ করুন। নতুন বা মুছে ফেলা রেকর্ড কীভাবে প্রদর্শিত হবে তা ইন্টারফেস বদলানোর আগে সংজ্ঞায়িত করুন।
অসীম ফলাফলের চেয়ে সবচেয়ে ছোট দরকারী পেজটি ফেরত দিন।
প্রতিটি অনুরোধে ইন্টারফেস কি সত্যিকারের সঠিক মোট সংখ্যা চায় তা সিদ্ধান্ত নিন।
ভুল রেসপন্স না দিয়ে রিড কাজ কেশ করুন
ক্যাশিং পূর্বের একটি রেজাল্ট পুনরায় ব্যবহার করে ডাটাবেস থেকে পুনর্নির্মাণের পরিবর্তে। পাবলিক, পুনরাবৃত্ত পেজ এবং ভার্সনকৃত অ্যাসেটগুলির জন্য HTTP স্তর থেকে শুরু করুন, কারণ একটি ক্যাশ হিট অ্যাপ্লিকেশন ও ডাটাবেস উভয় কাজ এড়াতে পারে। web.dev ভার্সনকৃত URL-এর জন্য দীর্ঘমেয়াদি কেশিং সুপারিশ করে; URL বদলানোই বাস্তবিক ইনভ্যালিডেশনের উপায়।
ক্যাশ পলিসি একটি সঠিকতার সিদ্ধান্ত। একটি শেয়ার করা ক্যাশ একটি রেসপন্স একাধিক ব্যবহারকারীর মধ্যে পুনরায় ব্যবহার করতে পারে, তাই অ্যাকাউন্ট, কার্ট, মূল্য, বা অনুমোদন-নির্দিষ্ট আউটপুট শেয়ার করবেন না যদি না সেটা সেই স্কোপের জন্য ডিজাইন ও পরীক্ষিত হয়ে থাকে। Cache-Control-এর private ব্রাউজার ক্যাশ অবস্থা পর্যন্ত পুনরায় ব্যবহার সীমাবদ্ধ করে, আর no-store নির্দেশ করে যে ক্যাশগুলো এটি রাখবে না।
পাবলিক ক্যাটালগ বা আর্টিকেল আউটপুটকে সেশন-নির্দিষ্ট, লোকেশন-নির্দিষ্ট এবং অনুমতি-সংবেদনশীল আউটপুট থেকে আলাদা করুন।
কে একটি স্টেল মান দেখতে পারে, কতক্ষণ, এবং ইনভ্যালিডেশন বা রিভ্যালিডেশন পথ কী তা সংজ্ঞায়িত করুন।
শুধু সিলিং বাড়ানোর বদলে সংযোগ ধারণক্ষমতা রক্ষা করুন
একটি সংযোগ হল ডাটাবেসের সঙ্গে একটি লাইভ ক্লায়েন্ট সেশন। ওয়ার্কার, ক্রন জব, প্রিভিউ, বা রিট্রাইগুলো স্লট শেষ করে দিতে পারে এমনকি যখন পৃথক কুয়েরিগুলি গ্রহণযোগ্য দেখায়। PostgreSQL-এর max_connections সমমান concurrent connections নিয়ন্ত্রণ করে, সার্ভার স্টার্টে সেট করা হয়, এবং উচ্চ মান নির্দিষ্ট করে আরো রিসোর্স বরাদ্দ করে যার মধ্যে শেয়ারড মেমরি অন্তর্ভুক্ত। একটি কাজের মডেল ছাড়া এটিকে বাড়ালে ব্যর্থতা স্থানে সরতে পারে।
ওয়েব ওয়ার্কার, ব্যাকগ্রাউন্ড জব, অ্যাডমিনিস্ট্রেশন এবং রিপ্লিকাসহ এক বাজেট নির্ধারণ করুন। যেখানে মানায় সেখানে bounded pooling ব্যবহার করুন, পুনরুদ্ধারের জন্য হেডরুম রাখুন, এবং টাইমআউট প্রয়োগ করুন যাতে বিচ্ছিন্ন কাজ অনির্দিষ্টকাল অপেক্ষা না করে। নিরাপদ সংখ্যা ইঞ্জিন, মেমরি, কুয়েরি মিশ্রণ এবং প্রোভাইডার সীমার উপর নির্ভর করে; অপারেটরের সাথে এগুলো নিশ্চিত করুন।
ওয়েব প্রসেস, কিউ, নির্ধারিত টাস্ক, মাইগ্রেশন, রিপোর্টিং টুল এবং ডেপ্লয়মেন্ট জবগুলো অন্তর্ভুক্ত করুন।
একই সময়েরConcurrency সীমা দিন এবং ব্যাকফফ ব্যবহার করুন যাতে একটি ত্রুটি সংযোগ চাহিদা বহুগুণ না বাড়ায়।
প্রসঙ্গ ও গোপনীয়তা নিয়ন্ত্রণসহ কুয়েরি খরচ পর্যবেক্ষণ করুন
একটি ধীর নমুনার চেয়ে মোট প্রভাব দিয়ে ডাটাবেস কাজকে র্যাঙ্ক করুন। হাজারবার কল হওয়া মাঝারি ধীর কুয়েরি একটি বিরল রিপোর্টের চেয়ে বেশি প্রভাব ফেলতে পারে। PostgreSQL-এর pg_stat_statements পরিকল্পনা ও এক্সিকিউশনের ডেটা সমষ্টি করে, কল সংখ্যা, মোট ও গড় এক্সিকিউশন টাইম, রো, এবং বাফার কার্যক্রমসহ। এটি সার্ভার কনফিগারেশন এবং রিস্টার্ট চায়; পরিকল্পনা ট্র্যাকিং ওভারহেড বাড়াতে পারে।
কুয়েরি গ্রুপগুলোকে রুট, রিলিজ সংস্করণ, ও সময় উইন্ডোর সাথে যুক্ত করুন। OpenTelemetry পরামর্শ দেয় কুয়েরি টেক্সট সংগ্রহের আগে স্বয়ংক্রিয়ভাবে লিটারালগুলো সংবেদনশীলতা অপসারণ করে এবং গ্রুপিংয়ের জন্য নিম্ন-কার্ডিনালিটি কুয়েরি সারসংক্ষেপ ব্যবহার করার। এটি মালিকদের ট্রেন্ড দেখা সহজ করে তোলে, গ্রাহক ডেটা রপ্তানি না করে বা প্রতিটি মানের জন্য একটি লেবেল তৈরি না করে।
দায়িত্ব, মোট সময়, কল, ত্রুটি, সংযোগ এবং রো দেখুন; প্রত্যেকটি বিভিন্ন ব্যর্থতার মোড উন্মোচন করে।
প্যারামিটারাইজড কুয়েরি ব্যবহার করুন এবং ট্রেস বা লগ অ্যাপ থেকে বের হওয়ার আগে লিটারালগুলো অপসারণ করা হয়েছে কি না যাচাই করুন।
রিভার্সিবল রিলায়েবিলিটি কাজ হিসেবে ডাটাবেস বদল শিপ করুন
একটি ইনডেক্স, রিরাইট, ক্যাশ পলিসি, পুল সেটিং, বা স্কিমা পরিবর্তনকে প্রোডাকশন পরিবর্তন হিসেবে আচরণ করুন—একটি মালিক, সফলতার মাপকাঠি, এবং রোলব্যাক সিদ্ধান্ত সহ। প্রতিনিধিত্বকারী পরিবেশে ভ্যালিডেট করুন, সীমিত স্লাইসে রিলিজ করুন, এবং প্রভাবিত যাত্রাটি পর্যবেক্ষণ করুন। দ্রুত হওয়া সফলতা নয় যদি পরিবর্তন ভুল, অনুপস্থিত, পুনরাবৃত্তি বা স্টেল ডেটা ফেরত দেয়।
স্কিমা পরিবর্তন যত্ন দাবি করে কারণ অ্যাপ্লিকেশন সংস্করণ কভারল্যাপ করতে পারে। Google Cloud নির্দেশনা একটি সামঞ্জস্য-প্রথম ক্রম বর্ণনা করে: পুরানো ও নতুন স্কিমা হ্যান্ডেল করে এমন অ্যাপ্লিকেশন রিলিজ করুন, স্কিমা পরিবর্তন করুন, তারপর যে ফিচারটি এটি ব্যবহার করে তা রিলিজ করুন। এটি একটি অ্যাপ্লিকেশন রোলব্যাক পথ বজায় রাখে। লকিং এবং অনলাইন-চেঞ্জ আচরণ ইঞ্জিন ও ম্যানেজড সার্ভিস অনুযায়ী ভিন্ন; উচ্চ-ভলিউম বা পেমেন্ট-সংক্রান্ত সিস্টেমের জন্য যোগ্যতার পর্যালোচনা নিন।
রুট, পারফরম্যান্স ও সঠিকতার সিগন্যাল, এবং rollout থামানোর থ্রেশহোল্ড নামক করুন।
নিয়ন্ত্রিত স্লাইসে পারফরম্যান্স ও সঠিকতা যাচাই করুন পূর্বে প্রসারিত করার আগে; ইনসিডেন্টের বাইরেও ফিরবার পথ অভ্যাস করুন।