Insights

rewrite-এর আগে database tuning: প্রথমে কী ঠিক করবেন

যখন database দৃশ্যমান bottleneck হয়ে ওঠে, টিমগুলো প্রায়ই সরাসরি migration বা rewrite-এর দিকে যায়। কখনও সেটা দরকার হয়, কিন্তু অনেক সময় প্রথম দরকার database tuning ও structure review। প্রথম প্রশ্ন হলো performance কোথায় হারাচ্ছে, এবং কী নিরাপদে উন্নত করা যায়।

সবচেয়ে উপযুক্ত

  • যে application-এ slow query বাস্তব user behavior-এ প্রভাব ফেলছে
  • যে টিমগুলো delivery অস্থির না করে performance উন্নত করার চাপের মধ্যে আছে
  • যে system-এ প্রতিটি release-এর সাথে data model আরও জটিল হয়েছে

query path দিয়ে শুরু করুন

সময় আসলে কোথায় খরচ হচ্ছে তা দিয়ে শুরু করুন। heavy query path, indexing, join pattern, reporting load, এবং application code যেখানে দুর্বল data access পুষিয়ে নিচ্ছে, সেগুলো দেখুন।

  • সবচেয়ে ধীর এবং ব্যয়বহুল recurring query path চিহ্নিত করুন
  • application inefficiency আর সত্যিকারের database bottleneck আলাদা করুন
  • indexing, cardinality assumption, এবং স্পষ্ট structural mismatch পর্যালোচনা করুন

tuning যা ঢাকতে পারে না, সেই structure problem খুঁজুন

কিছু performance problem আসলে schema problem। overloaded table, inconsistent key, historical shortcut, এবং data ownership-এর অস্পষ্টতা এমন drag তৈরি করে যা query tweak দিয়ে একা ঠিক হবে না।

  • যে table বা relation খুব বেশি কাজ করছে তা খুঁজে বের করুন
  • schema choice কীভাবে reporting বা integration path জটিল করছে তা শনাক্ত করুন
  • tactical tuning আর structural redesign need আলাদা করুন

কেন tuning আগে করা অনেক সময় নিরাপদ পদক্ষেপ

একটি পরিমিত tuning-first pass বর্তমান performance উন্নত করে, কোন schema debt গুরুত্বপূর্ণ তা পরিষ্কার করে, এবং ভবিষ্যতের migration বা redesign-এর জন্য cleaner foundation দেয়।

  • পুরো system বদলাতেই হবে এমন ভান না করে তাৎক্ষণিক উন্নতি
  • পরে redesign বা migration সিদ্ধান্তের জন্য ভালো evidence
  • মূল সমস্যা পরিষ্কার করার সময় delivery-তে কম বিঘ্ন

পরবর্তী ধাপ

এটা যদি আপনার সামনে থাকা কাজের সাথে মেলে, তাহলে কথোপকথন শুরু করুন।

system, delivery risk, বা operational problem নিয়ে একটি ছোট নোটই আলোচনা শুরু করার জন্য যথেষ্ট।