অডিট লোগিং-এ ইভেন্ট টেবিলের জন্য PostgreSQL পার্টিশনিং

কেন ইভেন্ট এবং অডিট টেবিল সমস্যা হয়ে ওঠে

ইভেন্ট টেবিল এবং অডিট টেবিল দেখতে একরকম লাগলেও এদের থাকার কারণ আলাদা।

ইভেন্ট টেবিল এমন জিনিসগুলো রেকর্ড করে যা ঘটে: পেজ ভিউ, পাঠানো ইমেইল, webhook কল, জব রান। অডিট টেবিল রেকর্ড করে কে কখন 무엇 পরিবর্তন করেছে: একটি স্ট্যাটাস পরিবর্তন, পারমিশন আপডেট, পেআউট অনুমোদন—প্রায়ই “আগে” এবং “পরে” এর বিস্তারিতসহ।

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

ব্যথাটা দৈনন্দিন কাজে প্রকাশ পায়। অ্যাডমিন প্যানেলে দ্রুত ফিল্টারের প্রয়োজন পড়ে—যেমন “গতকালের ত্রুটি” বা “এই ব্যবহারকারীর ক্রিয়াকলাপ”। টেবিল বড় হলে এই সাধারণ স্ক্রীনগুলো ধীরে কাজ করে।

আপনি সাধারণত প্রথমেই কয়েকটি লক্ষণ লক্ষ্য করবেন:

• সীমিত তারিখ সীমা থাকলেও ফিল্টার সেকেন্ড নেয় (বা টাইমআউট করে)।
• ইনডেক্স এত বড় হয় যে ইনসার্ট ধীর হয় এবং স্টোরেজ খরচ বাড়ে।
• VACUUM ও autovacuum বেশি সময় নেয়, এবং রক্ষণাবেক্ষণ চোখে পড়ে।
• রিটেনশন ঝুঁকিপূর্ণ হয়: পুরনো সারি ডিলিট ধীর এবং বloat সৃষ্টি করে।

পার্টিশনিং একটি উপায় এই সমস্যার মোকাবিলার। সহজভাবে বললে, এটি এক বড় টেবিলকে অনেক ছোট টেবিলে ভাগ করে—যেগুলো একই যৌক্তিক নাম ভাগ করে নেয়। PostgreSQL প্রতিটি নতুন সারিকে একটি নিয়ম অনুযায়ী সঠিক পার্টিশনে রুট করে, সাধারণত সময়ের উপর ভিত্তি করে।

এই কারণেই টিমগুলো ইভেন্ট টেবিলের জন্য PostgreSQL পার্টিশনিং দেখতে চায়: এটি সাম্প্রতিক ডেটাকে ছোট টুকরোয় রাখে, তাই যখন কুয়েরি কেবল একটি সময় উইন্ডোই চায় তখন PostgreSQL পুরো পার্টিশনগুলো স্কিপ করতে পারে।

পার্টিশনিং কোনো জাদুকরী গতি সুইচ নয়। এটি "গত ৭ দিন" ধরনের কুয়েরির ক্ষেত্রে অনেক সহায়ক হতে পারে এবং রিটেনশনকে সহজ করে (পুরনো পার্টিশন ড্রপ করা দ্রুত)। কিন্তু এটি নতুন সমস্যাও তৈরি করতে পারে:

• পার্টিশন কী ব্যবহার না করলে কুয়েরিকে অনেক পার্টিশন চেক করতে হতে পারে।
• বেশি পার্টিশন মানে বেশি অবজেক্ট ম্যানেজ করতে হবে এবং বেশি ভুল কনফিগারেশনের পথ থাকবে।
• কিছু ইউনিক কনস্ট্রেইন্ট এবং ইনডেক্স সকল ডেটায় প্রয়োগ করা কঠিন হতে পারে।

যদি আপনার অ্যাডমিন প্যানেল প্রচুর সময়-ফিল্টার ও পূর্বনির্ধারিত রিটেনশনের ওপর নির্ভরশীল হয়, পার্টিশনিং সত্যিই ফলপ্রসূ হতে পারে। যদি বেশি কুয়েরি হয় "ব্যবহারকারী X-এর সমস্ত ইতিহাস খুঁজুন", তাহলে যত্নসহ UI এবং ইনডেক্স ডিজাইন না করলে এটা মাথাব্যথা বাড়াতে পারে।

লগ ও অডিটের সাধারণ অ্যাক্সেস প্যাটার্ন

ইভেন্ট ও অডিট টেবিল একদিকে বাড়ে: উপরের দিকে। এগুলোতে ধারাবাহিক ইনসার্ট হয়ে এবং আপডেট খুবই কম। বেশিরভাগ সারি একবার লেখা হয়, পরে সাপোর্ট কাজ, ইনসিডেন্ট রিভিউ বা কমপ্লায়েন্স চেকের সময় পড়া হয়।

এই "অ্যাপেন্ড-অনলি" আকৃতি গুরুত্বপূর্ণ। লেখার কার্যক্ষমতা সবসময় চিন্তার বিষয় কারণ ইনসার্ট সারাদিন চলতে থাকে, আর রিড পারফরম্যান্স বিরতির মতো সময়ে জরুরি হয় (যখন সাপোর্ট বা অপস দ্রুত উত্তর চাই)।

অधिकাংশ রিড ফিল্টারভিত্তিক, র‍্যাণ্ডম লুকআপ নয়। একটি অ্যাডমিন প্যানেলে কেউ সাধারণত বিস্তৃতভাবে শুরু করে (গত ২৪ ঘণ্টা) তারপর একটি ব্যবহারকারী, একটি এন্টিটি বা একটি অ্যাকশন-এ সংকীর্ণ হয়।

সাধারণ ফিল্টারগুলো:

• একটি সময় পরিসীমা
• একটি অভিনেতা (user ID, সার্ভিস একাউন্ট, IP ঠিকানা)
• একটি লক্ষ্য (এন্টিটি টাইপ + এন্টিটি ID, যেমন Order #1234)
• একটি অ্যাকশন টাইপ (created, updated, deleted, login failed)
• একটি স্টেটাস বা সেভারিটি (success/error)

টাইম রেঞ্জ প্রাকৃতিক "প্রথম ছাঁকনি" কারণ এটি প্রায়ই উপস্থিত থাকে। এইটিই PostgreSQL পার্টিশনিং-এর মূল অন্তর্দৃষ্টি: অনেক কুয়েরি একটি সময় স্লাইস চায়, এবং বাকি সবকিছু সেই স্লাইসের ভিতরেই দ্বিতীয়ত ফিল্টার করা হয়।

রিটেনশন আরেকটি অপরিবর্তনীয় বিষয়। লগগুলো সচরাচর সারাজীবন থাকে না। টিমগুলো প্রায়শই উচ্চ-ডিটেইল ইভেন্ট ৩০ বা ৯০ দিনের জন্য রাখে, তারপর মুছে বা আর্কাইভ করে। অডিট লগের ক্ষেত্রে মেয়াদকাল বড় থাকতে পারে (৩৬৫ দিন বা তার বেশি), কিন্তু তা হলেও সাধারণত আপনি এমন একটা পাবেন যেখানে পুরনো ডেটা ব্লক না করে সহজে সরানো যায়।

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

এই প্যাটার্নগুলো সরাসরি UI ডিজাইনে দেখা যায়। ডিফল্টভাবে মানুষের প্রত্যাশিত ফিল্টার—তারিখ পিকার, ব্যবহারকারী সিলেক্টর, এন্টিটি সার্চ, অ্যাকশন ড্রপডাউন—এগুলি আপনার টেবিল ও ইনডেক্সকেও সমর্থন করতে হবে যদি আপনি চাইতে দ্রুত অ্যাডমিন অভিজ্ঞতা বজায় থাকুক ভলিউম বাড়লেও।

কিভাবে বুঝবেন পার্টিশনিং উপকারী হবে কিনা

পার্টিশনিং অডিট লগের জন্য স্বয়ংক্রিয় সেরা অনুশীলন নয়। এটি লভ্য হয় যখন একটি টেবিল এত বড় হয়ে যায় যে দৈনন্দিন কুয়েরি ও রুটিন রক্ষণাবেক্ষণ একে অপরের বিরুদ্ধে কাজ করা শুরু করে।

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

সুস্পষ্ট কুয়েরি সংকেত হলো যখন নিয়মিতভাবে আপনি একটি ছোট সময় স্লাইস চান (গত দিন, গত সপ্তাহ), কিন্তু PostgreSQL এখনও টেবিলের বড় অংশ স্পর্শ করে। এটি দেখতে পাবেন ধীর "সাম্প্রতিক কার্যকলাপ" স্ক্রীন বা তারিখ+ব্যবহারকারী, অ্যাকশন টাইপ বা এন্টিটি ID দ্বারা ফিল্টার করা অডিট হিসেবে। যদি কুয়েরি প্ল্যান বড় স্ক্যান দেখায় বা বাফার রিড ধারাবাহিকভাবে বেশি থাকে, তাহলে আপনি এমন ডেটা পড়ছেন যার দরকার ছিল না।

রক্ষণাবেক্ষণ সংকেতও সমানভাবে গুরুত্বপূর্ন:

• VACUUM এবং autovacuum আগের তুলনায় অনেক বেশি সময় নেয়।
• Autovacuum পিছিয়ে পড়ে এবং ডেড টাপলস (বloat) জমা হয়।
• ইনডেক্সগুলো প্রত্যাশার চেয়ে দ্রুত বাড়ে, বিশেষত মাল্টি-কোলাম ইনডেক্স।
• রক্ষণাবেক্ষণ চলাকালীন লক কনটেনশন বেশি লক্ষণীয় হয়।

অপারেশনাল খরচই ধীরে ধীরে টিমকে পার্টিশনিংয়ে ঠেলে দেয়। ব্যাকআপ এবং রিস্টোর ধীরে যায়, স্টোরেজ বাড়ে, এবং রিটেনশন জবগুলো ব্যয়বহুল হয় কারণ বড় DELETE গুলো বLOAT এবং অতিরিক্ত ভ্যাকুয়াম সৃষ্টি করে।

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

ইভেন্ট ও অডিট টেবিলের জন্য মিলানো পার্টিশনিং অপশন

অধিকাংশ অডিট ও ইভেন্ট ডেটার জন্য সহজতম নির্বাচন হলো সময়ভিত্তিক রেঞ্জ পার্টিশনিং। লগগুলো সময়ানুক্রমে আসে, কুয়েরিগুলো প্রায়ই "গত ২৪ ঘণ্টা" বা "গত ৩০ দিন"-এ মনোযোগ দেয়, এবং রিটেনশন সাধারণত সময়ভিত্তিক। সময়ভিত্তিক পার্টিশনে পুরনো ডেটা ড্রপ করা একটি বড় DELETE চালানোর চেয়ে সহজ হতে পারে।

টাইম রেঞ্জ পার্টিশনিং ইনডেক্সগুলোকে ছোট এবং বেশি ফোকাসড রাখে। প্রতিটি পার্টিশনে তার নিজস্ব ইনডেক্স থাকে, তাই গত সপ্তাহের জন্য কুয়েরি একটি বিশাল ইনডেক্স পায়ে হাঁটতে হবে না যেটি বছরের ইতিহাস কভার করে।

অন্যান্য স্টাইল আছে, কিন্তু সেগুলো কম ক্ষেত্রে ফিট হয়:

• List (টেন্যান্ট বা কাস্টমার) কাজ করতে পারে যদি আপনার কয়েকটি খুব বড় টেন্যান্ট থাকে এবং কুয়েরিগুলো সাধারণত একটি টেন্যান্টের ভেতরেই থাকে। কিন্তু শত বা হাজার টেন্যান্ট এলে তা কষ্টদায়ক হয়।
• Hash (লিখনের ভারসাম্য) সাহায্য করতে পারে যখন আপনার সময়-উইন্ডো কুয়েরি নেই এবং আপনি লেখাগুলো সমভাবে বিতরণ করতে চান। অডিট লগের ক্ষেত্রে কম প্রচলিত কারণ এটি রিটেনশন ও সময়ভিত্তিক ব্রাউজিংকে কঠিন করে।
• Subpartitioning (সময় + টেন্যান্ট) শক্তিশালী হতে পারে, কিন্তু জটিলতা দ্রুত বেড়ে যায়। এটি মূলত খুব উচ্চ ভলিউম সিস্টেমের জন্য যেখানে টেন্যান্ট বিচ্ছিন্নতার কড়া চাহিদা থাকে।

যদি আপনি সময়-রেঞ্জ বেছে নেন, একটি পার্টিশন সাইজ নির্বাচন করুন যা ব্রাউজিং ও রিটেনশনের সঙ্গে মেলে। দৈনিক পার্টিশন খুব উচ্চ ভলিউম বা কঠোর রিটেনশনের জন্য মানে দেয়। মাঝারি ভলিউমে মাসিক পার্টিশন পরিচালনা সহজ।

একটি ব্যবহারিক উদাহরণ: যদি একটি অ্যাডমিন দল প্রতিদিন সকালে ব্যর্থ লগইন চেক করে এবং শেষ ৭ দিন ফিল্টার করে, তাহলে দৈনিক বা সাপ্তাহিক পার্টিশন কুয়েরি কেবল সাম্প্রতিক পার্টিশনগুলোই টাচ করবে। PostgreSQL বাকি পার্টিশনগুলো উপেক্ষা করতে পারবে।

যে কোনো পদ্ধতি নিলেও, সাধারণ কাজগুলো পরিকল্পনা করুন: ভবিষ্যৎ পার্টিশন তৈরি করা, দেরিতে আসা ইভেন্ট হ্যান্ডল করা, এবং প্রতিটি বাউন্ডারিতে (দিন শেষ, মাস শেষ) কি হবে নির্ধারণ করা। পার্টিশনিং তখনই লাভজনক হবে যখন এই রুটিনগুলো সহজ থাকে।

সঠিক পার্টিশন কী কিভাবে বেছে নেবেন

ভাল পার্টিশন কী হল সেটি কিভাবে টেবিল পড়া হয় তার সাথে মেলে, ডাটার ডায়াগ্রাম দেখে নয়।

ইভেন্ট ও অডিট লগের জন্য, আপনার অ্যাডমিন প্যানেল থেকে শুরু করুন: মানুষ সাধারণত প্রথমে কোন ফিল্টার ব্যবহার করে, প্রায় সব সময়? বেশিরভাগ টিমের জন্য এটা একটি সময় রেঞ্জ (শেষ ২৪ ঘন্টা, শেষ ৭ দিন, কাস্টম তারিখ)। যদি আপনার ক্ষেত্রেও তাই হয়, সময়ভিত্তিক পার্টিশনিং সাধারণত সবচেয়ে বড় ও পূর্বানুমানযোগ্য লাভ দেয় কারণ PostgreSQL বেছে নেয়া রেঞ্জের বাইরে থাকা সম্পূর্ণ পার্টিশনগুলো স্কিপ করতে পারে।

কী-টিকে একটি দীর্ঘমেয়াদি প্রতিশ্রুতি হিসেবে বিবেচনা করুন। আপনি সেই কুয়েরিগুলোর জন্য অপ্টিমাইজ করছেন যেগুলো আপনে বছর ধরে চালাবেন।

মানুষ যে "প্রথম ফিল্টার" ব্যবহার করে সেটি থেকে শুরু করুন

অধিকাংশ অ্যাডমিন স্ক্রীন একটি প্যাটার্ন অনুসরণ করে: সময় রেঞ্জ এবং তারপর ঐচ্ছিকভাবে ব্যবহারকারী, অ্যাকশন, স্ট্যাটাস বা রিসোর্স। যেটা ফলপ্রসূভাবে ফলানো ফলাফলকে প্রথমে সংকীর্ণ করে—ওটাই পার্টিশন দিয়ে করুন।

দ্রুত বাস্তবতা যাচাই:

• ডিফল্ট ভিউ যদি "সাম্প্রতিক ইভেন্ট" হয়, তাহলে timestamp দিয়ে পার্টিশন করুন।
• ডিফল্ট ভিউ যদি "একটি টেন্যান্ট/অ্যাকাউন্টের ইভেন্ট" হয়, তাহলে tenant_id অর্থবহ হতে পারে, কিন্তু কেবল যদি টেন্যান্টগুলো পর্যাপ্ত বড় হয়।
• যদি প্রথম ধাপ সবসময় "একটি ব্যবহারকারী বেছে নেওয়া" হয়, user_id লোভনীয় মনে হতে পারে, কিন্তু এটি সাধারণত অনেক পার্টিশন তৈরি করে যা পরিচালনা কঠিন করে তোলে।

উচ্চ-কার্ডিনালিটি কী এড়িয়ে চলুন

পার্টিশনিং তখনই ভাল কাজ করে যখন প্রতিটি পার্টিশন ডেটার একটি অর্থবহ টুকরা। user_id, session_id, request_id, device_id-এর মতো কী হাজার বা মিলিয়ন পার্টিশন তৈরি করতে পারে। এটি মেটাডেটা ওভারহেড বাড়ায়, রক্ষণাবেক্ষণ জটিল করে এবং প্রায়ই প্ল্যানিং ধীর করে।

টাইম-ভিত্তিক পার্টিশনগুলো পার্টিশন গণনা পূর্বানুমানযোগ্য রাখে। আপনি দৈনিক, সাপ্তাহিক বা মাসিক বেছে নেবেন ভলিউম অনুযায়ী। খুব কম পার্টিশন (বছরে এক) তেমন সাহায্য করে না। খুব বেশি (প্রতি ঘণ্টা) দ্রুত ওভারহেড বাড়ায়।

সঠিক টাইমস্ট্যাম্প নির্বাচন: created_at বনাম occurred_at

সময় বলতে কি বোঝায় এটি স্পষ্ট করুন:

• occurred_at: যখন ইভেন্টটি প্রোডাক্টে ঘটেছিল।
• created_at: যখন ডাটাবেস এটিকে রেকর্ড করেছে।

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

টাইম কিভাবে সংরক্ষণ করবেন তাও ঠিক করুন। একটি সঙ্গত টাইপ (প্রায়ই timestamptz) ব্যবহার করুন এবং UTC কে সোর্স অব ট্রুথ হিসেবে দেখুন। ভিউয়ারের টাইমজোন UI-এ দেখান। এটি পার্টিশন বাউন্ডারি স্থির রাখে এবং ডে-লাইট সেভিং সমস্যা এড়ায়।

ধাপে ধাপে: পার্টিশনিং পরিকল্পনা ও রোল আউট

পার্টিশনিংকে একটি ছোট মাইগ্রেশন প্রকল্প হিসেবে আচরণ করলে কাজ সহজ হয়, একটি তাড়াহুড়া সামান্য পরিবর্তন হিসেবে নয়। লক্ষ্য হলো সরল লেখা, পূর্বানুমানযোগ্য পড়া, এবং রিটেনশন যা রুটিন অপারেশন হয়।

বাস্তব_rollout পরিকল্পনা

1. আপনার ভলিউমের সাথে মিল রেখে পার্টিশন সাইজ বাছাই করুন। মাসিক পার্টিশন সাধারণত প্রতি মাসে কয়েক লাখ রো থাকলে ঠিকঠাক। যদি প্রতি মাসে কয়েক কোটির রো ইনসার্ট হয়, তখন সাপ্তাহিক বা দৈনিক পার্টিশন ইনডেক্স ছোট রেখে ভ্যাকুয়াম কাজকে সিমিত রাখে।

2. পার্টিশন টেবিলের জন্য কী ও কনস্ট্রেইন্ট ডিজাইন করুন। PostgreSQL-এ একটি ইউনিক কনস্ট্রেইন্টকে পার্টিশন কী অন্তর্ভুক্ত করতে হয় (অথবা অন্যভাবে প্রয়োগ করতে হবে)। একটি সাধারণ প্যাটার্ন হলো (created_at, id), যেখানে id জেনারেট করা হয় এবং created_at পার্টিশন কী। এটা পরে এমন বিস্ময় এড়ায় যে আপনি যে কনস্ট্রেইন্ট আশা করছিলেন তা অনুমোদিত নয়।

3. আগেই ভবিষ্যৎ পার্টিশন তৈরি করুন। পার্টিশন না থাকায় ইনসার্ট ব্যর্থ না করে দেওয়ার জন্য অপেক্ষা করবেন না। কতটা আগেভাগে তৈরি করবেন সিদ্ধান্ত নিন (উদাহরণ: ২–৩ মাস) এবং এটিকে একটি নিয়মিত জব বানান।

4. প্রতি-পার্টিশন ইনডেক্স ছোট ও উদ্দেশ্যমুখী রাখুন। পার্টিশনিং ইনডেক্সকে ফ্রি করে না করে। বেশিরভাগ ইভেন্ট টেবিলে পার্টিশন কী প্লাস এক বা দুইটি ইনডেক্স লাগে যা বাস্তব অ্যাডমিন ফিল্টার মেলে, যেমন actor_id, entity_id, বা event_type। "প্রয়োজনে নয়" ইনডেক্স এড়িয়ে চলুন। নতুন পার্টিশনে সেগুলো যোগ করুন এবং প্রয়োজনে পুরনো পার্টিশন ব্যাকফিল করুন।

5. রিটেনশন ড্রপিং পার্টিশন ঘিরে পরিকল্পনা করুন, না যে সারি ডিলিট করে। যদি আপনি ১৮০ দিনের লগ রাখেন, তাহলে পুরনো পার্টিশন ড্রপ করা দ্রুত এবং বড় DELETE-র তুলনায় বloat কমায়। রিটেনশন নিয়ম, কে চালায়, এবং কিভাবে ভেরিফাই করবেন তা লিখে রাখুন।

ছোট উদাহরণ

যদি আপনার অডিট টেবিলে প্রতি সপ্তাহে ৫ মিলিয়ন রো আসে, তাহলে created_at-এ সাপ্তাহিক পার্টিশন একটি যুক্তিসঙ্গত শুরু। প্রতিটি পার্টিশনে ২টি ইনডেক্স রাখুন: সাধারণত actor_id দ্বারা সার্চের জন্য এক এবং entity_id দ্বারা আরেকটি। রিটেনশন উইন্ডো পেরোলেই সবচেয়ে পুরানো সাপ্তাহিক পার্টিশন ড্রপ করুন বরং মিলিয়নগুলো সারি মুছুন না।

আপনি যদি AppMaster-এ অভ্যন্তরীণ টুল বানান, তাহলে পার্টিশন কী ও কনস্ট্রেইন্টগুলো আগেভাগেই ঠিক করা ভালো যাতে ডেটা মডেল ও জেনারেট করা কোড একই অনুমান অনুসরণ করে শুরু থেকেই।

পার্টিশনিং অ্যাডমিন প্যানেল ফিল্টারগুলোকে কীভাবে বদলে দেয়

একবার আপনি একটি লগ টেবিল পার্টিশন করলে, অ্যাডমিন প্যানেল ফিল্টারগুলো আর "শুধু UI" থাকে না। এগুলো মূলত ঠিক করে দেয় যে একটি কুয়েরি কয়টি পার্টিশন টাচ করবে বা পুরো যাবতীয় ইতিহাস স্ক্যান করবে।

সবচেয়ে বড় বাস্তবিক পরিবর্তন হলো: সময় আর অপশনাল থাকলে ঠিক হবে না। যদি ব্যবহারকারীরা একটি অপরিবর্তিত সার্চ চালাতে পারে (কোনো তারিখ সীমা নেই, শুধু "ব্যবহারকারী X-এর সব দেখাও"), PostgreSQL প্রতিটি পার্টিশন চেক করতে পারে। প্রতিটি চেক দ্রুত হলেও অনেক পার্টিশন খোলা গেলে পেজ ধীর হবে।

একটি ভাল নিয়ম: লগ এবং অডিট সার্চের জন্য একটি সময় রেঞ্জ দাবি করুন এবং ডিফল্ট সেট করুন কিছু যুক্তিযুক্ত (যেমন শেষ ২৪ ঘণ্টা)। কেউ যদি সত্যিই "সমস্ত সময়" চান, সেটি স্পষ্টভাবে একটি জবাবদিহি অপশন বানান এবং জানিয়ে দিন যে ফলাফল ধীর হতে পারে।

ফিল্টারগুলোকে পার্টিশন প্রুনিংয়ের সাথে মেলান

পার্টিশন প্রুনিং তখনই সহায়ক যখন WHERE ক্লজে পার্টিশন কী এমনভাবে থাকে যা PostgreSQL ব্যবহার করতে পারে। created_at BETWEEN X AND Y-এর মতো ফিল্টারগুলো পরিষ্কারভাবে প্রুন করে। প্রুন ভেঙে দেওয়া প্যাটার্নগুলোর মধ্যে রয়েছে টাইমস্ট্যাম্পকে ডেটে কাস্ট করা, কলামকে কোনো ফাংশনে মোড়া, বা পার্টিশন কীয়ের বদলে অন্য সময় কলামে ফিল্টার করা।

প্রতিটি পার্টিশনের ভেতরে ইনডেক্সগুলো মানুষের আসল ফিল্টার মেলানো উচিত। প্রায়ই গুরুত্বপূর্ণ কম্বিনেশনগুলো হলো সময় প্লাস আরেকটি শর্ত: টেন্যান্ট/ওয়ার্কস্পেস, ব্যবহারকারী, অ্যাকশন/টাইপ, এন্টিটি ID, বা স্ট্যাটাস।

সর্টিং ও পেজিনেশন: পাতলা রাখুন

পার্টিশনিং নিজে ধীর পেজিনেশন ঠিক করে না। যদি অ্যাডমিন প্যানেল সবচেয়ে নতুন অনুযায়ী সাজায় এবং ব্যবহারকারী পেজ ৫০০০-এ ঝাঁপায়, গভীর OFFSET পেজিনেশন তখনও PostgreSQL কে অনেক সারি পাড় করে দিতে বাধ্য করে।

কার্সার-স্টাইল পেজিনেশন লজগুলোর জন্য ভাল কাজ করে: "এই টাইমস্ট্যাম্প/ID-এর আগে ইভেন্টগুলো লোড করুন"। এটি ইনডেক্স ব্যবহার রাখে এবং গভীর অফসেট স্ক্যান এড়ায়।

প্রিসেটগুলোও সাহায্য করে। কয়েকটি বিকল্পই সাধারণত যথেষ্ট: শেষ ২৪ ঘণ্টা, শেষ ৭ দিন, আজ, গতকাল, কাস্টম রেঞ্জ। প্রিসেটগুলি আকস্মিকভাবে "সব কিছু স্ক্যান করা" সার্চ কমায় এবং অ্যাডমিন অভিজ্ঞতাকে পূর্বানুমানযোগ্য রাখে।

সাধারণ ভুল ও ফাঁদ

বেশিরভাগ পার্টিশনিং প্রকল্প সহজ কারণগুলোতে ব্যর্থ হয়: পার্টিশন ঠিক আছে, কিন্তু কুয়েরি ও অ্যাডমিন UI তা মেলে না। যদি আপনি চান পার্টিশনিং কার্যকর হোক, বাস্তব ফিল্টার ও বাস্তব রিটেনশনকে কেন্দ্র করে ডিজাইন করুন।

1) ভুল সময় কলামে পার্টিশন করা

পার্টিশন প্রুনিং তখনই হয় যখন WHERE ক্লজ পার্টিশন কীয়ের সাথে মিলে। একটি সাধারণ ভুল হলো created_at দিয়ে পার্টিশন করা আর অ্যাডমিন প্যানেল event_time দ্বারা ফিল্টার করা। যদি আপনার সাপোর্ট দল সবসময় বলে—"10:00 থেকে 10:15-এর মধ্যে কী ঘটেছিল?" কিন্তু টেবিল ইনজেশন সময় দিয়ে পার্টিশন করা, তাহলে আপনি এখনও প্রত্যাশার চেয়ে বেশি ডেটা টাচ করতে পারেন।

2) অনেক ছোট পার্টিশন তৈরি করা

ঘণ্টাভিত্তিক (বা ছোট) পার্টিশন টidy লাগতে পারে, কিন্তু এগুলো ওভারহেড বাড়ায়: ম্যানেজ করতে বেশি অবজেক্ট, কুয়েরি প্ল্যানারের জন্য বেশি কাজ, এবং বেশি সম্ভাবনা মিসিং ইনডেক্স বা পারমিশন।

চরম না হলে দৈনিক বা মাসিক পার্টিশন পরিচালনা সহজ।

3) ধরে নেওয়া যে "গ্লোবাল ইউনিকনেস" এখনও কাজ করবে

পার্টিশনড টেবিলে কিছু ইউনিক কনস্ট্রেইন্ট সীমাবদ্ধ: কিছু ইউনিক ইনডেক্স পার্টিশন কী অন্তর্ভুক্ত না হলে PostgreSQL সব পার্টিশনে জোর করে প্রয়োগ করতে পারে না।

এটি টিমগুলোকে চমক দেয় যখন তারা ভাবছিল event_id চিরদিন ইউনিক থাকবে। যদি গ্লোবালি ইউনিক আইডি দরকার হয়, UUID ব্যবহার করুন এবং ইউনিকনেস সাবধানতার সাথে হ্যান্ডেল করুন—প্রয়োজনে অ্যাপ-স্তরে প্রয়োগ করুন।

4) অ্যাডমিন UI-কে খোলা সার্চ চালাতে দেওয়া

অ্যাডমিন প্যানেল প্রায়ই এমন সার্চ বক্স দিয়ে আসে যা কোন ফিল্টার ছাড়াই চলে। একটি পার্টিশনড লগ টেবিলে, এটা সব পার্টিশন স্ক্যান করার কারণ হতে পারে।

মেসেজ পেলোড জুড়ে ফ্রি-টেক্সট সার্চ বিশেষভাবে ঝুঁকিপূর্ণ। গার্ডরেইল যোগ করুন: সময় রেঞ্জ বাধ্যতামূলক করুন, ডিফল্ট রেঞ্জ কেপ করুন, এবং "সমস্ত সময়" একটি স্পষ্ট সিদ্ধান্ত বানান।

5) রিটেনশন প্ল্যান না থাকা

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

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

ক_commit করার আগে দ্রুত চেকলিস্ট

পার্টিশনিং অডিট লগের জন্য বড় জিত হতে পারে, কিন্তু এটি নিয়মিত কাজ বাড়ায়। স্কিমা বদলানোর আগে মানুষের টেবিলটি বাস্তবে কীভাবে ব্যবহার করে তা সত्यान্বেষণ করুন।

যদি আপনার প্রধান সমস্যা হয় যে অ্যাডমিন পেজগুলো টাইমআউট করে যখন কেউ "গত ২৪ ঘণ্টা" বা "এই সপ্তাহ" খুলে, তাহলে আপনি পার্টিশনিং-এর জন্য উপযুক্ত প্রায়। যদি অধিকাংশ কুয়েরি হয় "user ID সব সময়ে", পার্টিশনিং কম সাহায্য করবে যদি না UI-তে সার্চ গাইড করে এবং প্রতিটি পার্টিশনে সঠিক ইনডেক্স যোগ করা হয়।

একটি সংক্ষিপ্ত চেকলিস্ট:

• টাইম রেঞ্জ ডিফল্ট ফিল্টার। বেশিরভাগ অ্যাডমিন কুয়েরিতেই একটি স্পষ্ট উইন্ডো থাকে (from/to)। যদি খোলা-সীমা সার্চ প্রচলিত হয়, প্রুনিং কম কাজ করে।
• রিটেনশন পার্টিশন ড্রপের মাধ্যমে নির্ধারিত। আপনি পুরোনো পার্টিশন ড্রপ করতে স্বাচ্ছন্দ্যবোধ করেন এবং ডেটা কতদিন রাখা হবে তা স্পষ্ট।
• পার্টিশন সংখ্যা যুক্তিসঙ্গত। বছরে আনুমানিক পার্টিশন (দৈনিক, সাপ্তাহিক, মাসিক) হিসাব করুন। খুব ছোট পার্টিশনগুলো ওভারহেড বাড়ায়; খুব বড় পার্টিশনগুলো লাভ কমায়।
• ইনডেক্সগুলো লোকেরা আসলেই যে ফিল্টার ব্যবহার করে সেই অনুযায়ী। পার্টিশন কী বাদে, সাধারণ ফিল্টার ও সাজানোর ক্রম মেলানো ইনডেক্স প্রয়োজন।
• পার্টিশনগুলি স্বয়ংক্রিয় তৈরি ও মনিটর করা হয়। একটি রুটিন জব ভবিষ্যৎ পার্টিশন বানায়, এবং আপনি জানেন কখন তা ব্যর্থ হয়।

একটি বাস্তবিক পরীক্ষা: আপনার সাপোর্ট বা অপস দলের তিনটি সবচেয়ে বেশি ব্যবহৃত ফিল্টার দেখুন। যদি তার মাঝ থেকে দুটোই সাধারণত "সময় রেঞ্জ + আরেকটি শর্ত" দিয়ে মেটানো হয়, তাহলে ইভেন্ট টেবিলের জন্য PostgreSQL পার্টিশনিং গুরুত্ব সহকারে বিবেচনা করার মতো।

বাস্তব উদাহরণ ও পরবর্তী ব্যবহারিক ধাপ

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

পার্টিশন করার আগে সব কিছু একটি বড় events টেবিলে থাকে। এটি দ্রুত বাড়ে, এবং সাধারণ সার্চও ধীর হয়ে যায় কারণ ডাটাবেস অনেক পুরানো সারি পড়ে। রিটেনশনও কষ্টদায়ক: একটি রাতের কাজ পুরনো সারি ডিলিট করে, কিন্তু বড় DELETE ধীর, বloat সৃষ্টি করে, এবং সাধারণ ট্রাফিকের সঙ্গে টক্কর খায়।

সময়ভিত্তিক মাসিক পার্টিশন করার পরে (ইভেন্ট টাইমস্ট্যাম্প ব্যবহার করে) কার্যপ্রবাহ উন্নত হয়। অ্যাডমিন প্যানেল সময় ফিল্টার বাধ্য করে, তাই বেশিরভাগ কুয়েরি কেবল এক বা দুটি পার্টিশন টাচ করে। পেজ লোড দ্রুত হয় কারণ PostgreSQL নির্বাচিত রেঞ্জের বাইরে থাকা পার্টিশনগুলো উপেক্ষা করে। রিটেনশন নিয়ম রুটিন হয়: মিলিয়নগুলো সারি ডিলিটের বদলে পুরনো পার্টিশন ড্রপ করা হয়।

একটি কঠিন বিষয় থাকে: "সমস্ত সময়" জুড়ে ফ্রি-টেক্সট সার্চ। কেউ যদি একটি IP ঠিকানা বা অস্পষ্ট বাক্যাংশ তারিখ সীমা ছাড়া সার্চ করে, পার্টিশনিং তা সস্তা করতে পারে না। সমাধান সাধারণত প্রোডাক্ট আচরণে থাকে: ডিফল্ট সার্চ টাইম উইন্ডো দিন এবং "শেষ ২৪ ঘণ্টা / ৭ দিন / ৩০ দিন" স্পষ্টভাবে দেখান।

কার্যকর পরবর্তী ধাপগুলো যা সাধারণত কাজ করে:

• প্রথমে আপনার অ্যাডমিন প্যানেলের ফিল্টারগুলো মানচিত্র করুন। কোন ফিল্ডগুলো মানুষ ব্যবহার করে এবং কোনগুলো বাধ্যতামূলক সেটা লিখে রাখুন।
• ব্রাউজিং কিভাবে হয় সেটা মেলে এমন পার্টিশন বেছে নিন। মাসিক পার্টিশন প্রায়ই ভাল শুরু; ভলিউম বেড়ে গেলে সাপ্তাহিক করুন।
• সময় রেঞ্জকে প্রথম-শ্রেণির ফিল্টার বানান। UI যদি "কোনো দিন নেই" অনুমতি দেয়, ধীর পেজ আশা করুন।
• বাস্তব ফিল্টারগুলোর সাথে ইনডেক্সগুলো সমন্বয় করুন। সময় প্রায়ই সর্বদা উপস্থিত হলে, সময়-প্রথম ইনডেক্স কৌশল একটি ভালো বেসলাইন।
• পার্টিশন বাউন্ডারির সাথে মেলানো রিটেনশন নিয়ম নির্ধারণ করুন (উদাহরণ: ১৩ মাস রাখুন এবং তার চেয়ে পুরোনো ড্রপ করুন)।

আপনি যদি AppMaster (appmaster.io) ব্যবহার করে অভ্যন্তরীণ অ্যাডমিন প্যানেল তৈরী করেন, তাহলে এগুলি আগেভাগেই মডেল করা মূল্যবান: সময়-সীমাবদ্ধ ফিল্টারগুলো ডেটা মডেলের অংশ হিসেবে বিবেচনা করুন, কেবল UI-অপশন হিসেবে নয়। সেই ছোট সিদ্ধান্ত ডেটা ভলিউম বাড়লেও কুয়েরি পারফরম্যান্সকে রক্ষা করে।