PostgreSQL-এ ডাটাবেসের আকার হ্রাসের কৌশল: একটি ব্যবহার-ভিত্তিক পদ্ধতি

ডেটাবেস মূল্যের মডেলগুলি কঠিন। একজন বিকাশকারী হিসাবে একটি পরিচালিত ডাটাবেস খুঁজছেন, অনুসন্ধান প্রক্রিয়ার সবচেয়ে বিরক্তিকর (এবং এখনও গুরুত্বপূর্ণ) দিকগুলির মধ্যে একটি হল আপনার ডাটাবেসের আকারের জন্য সমাধানের অগ্রিম মূল্যই নয় বরং মূল্য কীভাবে কাজ করে এবং এটি কতটা ভালভাবে পরিমাপ করবে তাও মূল্যায়ন করা জড়িত। .

ডাটাবেসের মূল্য মূল্যায়ন করার সময় সূক্ষ্ম বিষয়গুলির উপরে (যেমন, "আমার ডেটা বাড়লে বিল কত বাড়বে?", "আমার প্রতি লেখা বা পড়ার জন্য কি চার্জ নেওয়া হচ্ছে?", এবং "আমাকে কি প্রতি ব্যাকআপের জন্য আরও বেশি অর্থ দিতে হবে?" ), ডেভেলপাররা একটি দিককে উপেক্ষা করার প্রবণতা রাখে: একটি ডাটাবেসের মূল্যের মডেল যেভাবে গঠন করা হয় তা প্রভাবিত করবে কিভাবে আপনি আপনার ডেটা পরিচালনা করবেন এবং আপনার পোস্টগ্রেস ডাটাবেসের আকার মূল্যায়ন করবেন।

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

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

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

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

PostgreSQL স্টোরেজ মডেলের উপর দ্রুত রিক্যাপ

একটি ব্যবহার-ভিত্তিক মডেলে আপনার ডাটাবেসের আকার পরিচালনার বিষয়ে আমাদের আলোচনার জন্য একটি সাধারণ ভিত্তি তৈরি করতে, আসুন আমাদের PostgreSQL প্ল্যাটফর্মে মূল্য কীভাবে কাজ করে তা দ্রুত কভার করে শুরু করি ( টাইমস্কেল ) এবং কীভাবে এটি অন্যান্য পরিচালিত PostgreSQL পণ্যের সাথে তুলনা করে, যেমন PostgreSQL এর জন্য Amazon RDS এবং Amazon Aurora।

গতকাল থেকে (💥), আমরা টাইমস্কেল প্ল্যাটফর্মে দুই ধরনের ডাটাবেস পরিষেবা অফার করছি:

• ডায়নামিক PostgreSQL পরিষেবা , যেখানে ডেভেলপাররা কর্মক্ষমতা ত্যাগ না করেই অর্থ সাশ্রয়ের জন্য গতিশীল গণনা সহ PostgreSQL ডাটাবেস তৈরি করতে পারে।

  
  

• টাইম সিরিজ পরিষেবা, যেখানে বিকাশকারীরা হাইপারটেবল, কলামার কম্প্রেশন, এর মাধ্যমে অতিরিক্ত কর্মক্ষমতা এবং স্কেলেবিলিটির সাহায্যে পোস্টগ্রেএসকিউএল ডেটাবেস তৈরি করতে পারে। ক্রমাগত সমষ্টি , এবং টায়ার্ড স্টোরেজ।

  
  

আসুন আমরা আমাদের প্ল্যাটফর্মে স্টোরেজের মূল্য কীভাবে নির্ধারণ করি তার উপর ফোকাস করি। এই উভয় পরিষেবাই স্টোরেজের জন্য ব্যবহার-ভিত্তিক মডেলের সাথে আসে, যার অর্থ নিম্নলিখিত:

• ডেভেলপাররা যে ভলিউম ব্যবহার করে তার জন্য চার্জ করা হয়, ছোট মুদ্রণ ছাড়াই—কোন ন্যূনতম ডাটাবেসের আকার নেই, ন্যূনতম স্কেলিং পদক্ষেপ নেই৷ যদি, মাসের শেষ নাগাদ, আপনি 128 GB ব্যবহার করে থাকেন, তাহলে এর জন্য আপনাকে বিল করা হবে। আপনি 1 GB থেকে শুরু করতে পারেন এবং TB-তে বৃদ্ধি পেতে পারেন।

• ডেটা লিখিত, ডেটা স্থানান্তর বা অনুসন্ধান চালানোর উপর ভিত্তি করে কোনও চার্জ নেই।

• ডাটাবেস বা স্কেলিং তৈরি করার সময় স্টোরেজ বরাদ্দ করার দরকার নেই।

• ম্যানুয়ালি ডিস্কের আকার কমানোর দরকার নেই।

  
  

এই বাড়িতে আনার জন্য, আসুন এই মডেল, Amazon RDS PostgreSQL এবং Amazon Aurora-এর মধ্যে পার্থক্যগুলি তুলে ধরা যাক:

সংক্ষেপে, এখানে আমাদের তুলনা থেকে তিনটি প্রধান টেকওয়ে রয়েছে:

• টাইমস্কেল এবং অরোরা উভয়ই আপনার প্রকৃত ডাটাবেসের আকারের জন্য চার্জ করে। বিপরীতে, RDS PostgreSQL প্রভিশনেড স্টোরেজের জন্য চার্জ। আপনি আরডিএস-এ ভলিউম কমাতে পারবেন না।

  
  

• টাইমস্কেল ডেটা লিখিত, ডেটা স্থানান্তর বা কোয়েরি অপারেশনের জন্য চার্জ করে না। RDS এবং Aurora উভয়ই ডেটা স্থানান্তর প্রতি চার্জ, অতিরিক্ত ব্যাকআপ সঞ্চয়স্থান, এবং আপনি কোন ধরণের স্টোরেজ বেছে নিচ্ছেন তার উপর নির্ভর করে আপনাকে কিছু অতিরিক্ত I/O চার্জ দিতে হতে পারে।

  
  

• টাইমস্কেলের কোনো ন্যূনতম স্কেলিং পদক্ষেপ নেই, যেখানে অরোরা 10 জিবি দিয়ে শুরু করার পরে 10 জিবি বৃদ্ধিতে স্কেল করে।

  
  

আপনি দেখতে পাচ্ছেন, টাইমস্কেল এর মডেলের কাছাকাছি অরোরা I/O-অপ্টিমাইজড , পার্থক্যের সাথে যে টাইমস্কেলে ডেটা স্থানান্তরের মতো জিনিসগুলির জন্য স্কেলিং পদক্ষেপ এবং অতিরিক্ত চার্জের অভাব রয়েছে। বিপরীতে, RDS বরাদ্দ-ভিত্তিক মডেলের একটি ভাল উপস্থাপনা, এমনকি যদি RDS এর "স্টোরেজ টিয়ার" এর অভাব রয়েছে ঐতিহ্যগতভাবে এই মডেলে কাজ করা ডাটাবেস বিক্রেতাদের মধ্যে পাওয়া যায়।

কিভাবে ব্যবহার-ভিত্তিক মূল্য পোস্টগ্রেএসকিউএল স্টোরেজ ম্যানেজমেন্টকে উন্নত করে

আমরা পূর্বে প্রবর্তিত হিসাবে, বিভিন্ন মূল্যের মডেল বিভিন্ন ডাটাবেস অভিজ্ঞতা বোঝায়। যখন আমরা একটি বরাদ্দ-ভিত্তিক থেকে ব্যবহার-ভিত্তিক মডেলে রূপান্তরিত হই, তখন আমাদের গ্রাহকরা আমাদের বলেছিলেন যে তারা তিনটি কার্যক্ষম ক্ষেত্রে অবিলম্বে উন্নতি দেখেছেন:

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

ব্যবহার-ভিত্তিক মডেলগুলি স্টোরেজ অতিরিক্ত ব্যবস্থার সমস্যা দূর করে

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

স্কেল আপ করার সময় আপনার স্টোরেজ সম্পর্কে চিন্তা করার দরকার নেই

“টাইমসকেলের ব্যবহার-ভিত্তিক স্টোরেজ মানে আমাকে আর ডিস্কের আকার নিয়ে ভাবতে হবে না। আমাদের স্টোরেজ খরচ 30% কম, এবং আমাকে কিছুই করতে হবে না!"

অ্যাডাম ম্যাকক্রিয়া, জুডোস্কেল (টাইমস্কেল গ্রাহক)

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

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

আপনি ডাউনস্কেল করতে পারেন (আপনার মুছে ফেলা ডেটার জন্য অর্থ প্রদান বন্ধ করুন)

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

কীভাবে কার্যকরভাবে একটি ব্যবহার-ভিত্তিক মডেল নেভিগেট করবেন: আপনার পোস্টগ্রেস ডেটাবেসের আকার হ্রাস করার টিপস

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

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

একটি উপায়ে, এটি ব্যবহার-ভিত্তিক মডেলগুলির একটি "খারাপ" হিসাবে বিবেচিত হতে পারে, এবং এটির জন্য কিছু কাজের প্রয়োজন - কিন্তু এটি আসলে ছদ্মবেশে একটি আশীর্বাদ। প্রথাগত বরাদ্দ-ভিত্তিক মডেলগুলিতে, ডেটা স্বাস্থ্যবিধি কিছুটা উপেক্ষা করা যেতে পারে কারণ খরচগুলি স্থির করা হয়েছে: আপনি যদি RDS-এ একটি 500 GB ডিস্কে লক হয়ে থাকেন এবং আপনার ডাটাবেস 200 GB হয়, তাহলে আপনার কাছে একটি বড় প্রণোদনা আছে বলে মনে হয় না স্টোরেজ ব্যবহার দক্ষ করুন।

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

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

আপনার PostgreSQL ডাটাবেসে ফোলা কমিয়ে দিন

একটি ব্যবহার-ভিত্তিক মডেলের প্রথম কাজটি হল PostgreSQL স্টোরেজ কীভাবে কাজ করে তার সুনির্দিষ্ট বিষয়ে মনোযোগ দেওয়া, অর্থাৎ, আপনাকে অবশ্যই নিয়মিতভাবে ব্লাট কমাতে হবে। এটি আপনাকে শুধুমাত্র আপনার ডাটাবেসের আকারেই নয় আপনার I/O প্রয়োজনীয়তাগুলির সাথেও সাহায্য করবে৷ আমরা এই বিভাগে কিছু মৌলিক বিষয়ের দিকে আপনাকে নির্দেশ করব, কিন্তু এই HN থ্রেড কিছু মহান পরামর্শ আছে , এবং আমরাও লিখেছি পোস্টগ্রেএসকিউএল-এ টেবিল ব্লোটে একটি ব্লগ পোস্ট .

• মৃত tuples নিরীক্ষণ. PostgreSQL স্টোরেজ অপ্টিমাইজ করার জন্য একটি সক্রিয় পদ্ধতির শুরু হয় মৃত টিপলগুলির উপর ঘনিষ্ঠ নজর রাখার মাধ্যমে। মৃত টিপল, যদি চেক না করা হয়, তাহলে তা জমা হতে পারে এবং অপ্রয়োজনীয় স্টোরেজ ওভারহেডের দিকে নিয়ে যেতে পারে। pgstattuple() এক্সটেনশনটি টেবিলগুলি কীভাবে এই টিপলগুলি পরিচালনা করে তা বোঝার জন্য একটি দুর্দান্ত সহযোগী হতে পারে।

  
  

• ঘন ঘন ভ্যাকুয়াম। টেবিল ব্লোটকে কার্যকরভাবে মোকাবেলা করতে, আপনি আরও ঘন ঘন চালানোর জন্য অটোভ্যাকুয়াম কনফিগার করতে চাইতে পারেন। postgresql.conf-এ বিশ্বব্যাপী অটোভ্যাকুয়াম সেটিংস সামঞ্জস্য করার পরিবর্তে, প্রতি টেবিলের ভিত্তিতে এই সেটিংসগুলিকে সূক্ষ্ম-টিউন করা আরও সুনির্দিষ্ট। এটি এই সত্যটি পূরণ করে যে বিভিন্ন টেবিলে মৃত টিপল জমা করার জন্য বিভিন্ন প্রবণতা থাকতে পারে। অটোভ্যাকুয়াম ক্রিয়াকলাপগুলিকে বাধাগ্রস্ত করতে পারে এমন দীর্ঘ-চলমান লেনদেনগুলি নিরীক্ষণ করাও গুরুত্বপূর্ণ।

  
  

• অব্যবহৃত পৃষ্ঠাগুলি পুনরুদ্ধার করুন। যদিও অটোভ্যাকুয়াম এবং ভ্যাকুয়াম মৃত টিপলগুলিকে সম্বোধন করে, অব্যবহৃত পৃষ্ঠাগুলি পুনরুদ্ধার করা একটি ভিন্ন পদ্ধতির দাবি করে। যদিও VACUUM FULL এই উদ্দেশ্যে ব্যবহার করা যেতে পারে, তবে পুরো টেবিলটি লক করার অন্তর্নিহিত সীমাবদ্ধতা রয়েছে। Pg_repack এটি আপনাকে সাহায্য করতে পারেন।

কিছু PostgreSQL ফাইন-টিউনিং করুন

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

• shared_buffers : PostgreSQL এর পৃষ্ঠা ক্যাশের জন্য ব্যবহৃত মেমরি নিয়ন্ত্রণ করে এবং এটি সাধারণত সিস্টেমের মোট RAM এর 25% এ সেট করা থাকে।

  
  

• work_mem : এটি একটি প্রশ্নের মধ্যে অপারেশন প্রতি বরাদ্দ করা মেমরি সেট করে। টাইমস্কেলে, প্রস্তাবিত সেটিং হল (25 % of RAM) / max_connections ।

  
  

• max_connections : এটি ডাটাবেসে অনুমোদিত সমসাময়িক সংযোগের সর্বাধিক সংখ্যা সেট করে। সংযোগ পুলার অনেক স্বল্পস্থায়ী সংযোগ পরিচালনা করতে সাহায্য করতে পারে।

  
  

• max_worker_processes : এটি PostgreSQL শুরু করতে পারে এমন কর্মী প্রক্রিয়ার সর্বাধিক সংখ্যা নির্ধারণ করে। টাইমস্কেল ব্যবহার করলে, এই প্যারামিটার সেট করার সূত্র হল: max_worker_processes = 3 + timescaledb.max_background_workers + max_parallel_workers ।

  
  

• max_parallel_workers : এটি সমান্তরাল প্রশ্ন সমর্থনকারী কর্মীদের সর্বাধিক সংখ্যা নির্দিষ্ট করে। ডিফল্ট হল উপলব্ধ সিপিইউ সংখ্যার সমান সেট করা।

  
  

• autovacuum_max_workers : এটি সমসাময়িক অটোভ্যাকুয়াম প্রক্রিয়ার সর্বাধিক সংখ্যা নির্ধারণ করে। টাইমস্কেলে, এটি ডিফল্টরূপে 10 এ সেট করা আছে।

ইনডেক্সিং স্বাস্থ্যবিধি অনুশীলন করুন

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

অত্যধিক সূচীকরণের সবচেয়ে সুস্পষ্ট পরিণতি হল স্টোরেজ খরচ বৃদ্ধি, কারণ প্রতিটি সূচকের জন্য আলাদা স্টোরেজ প্রয়োজন, যা টেবিলের আকারের সাথে আনুপাতিকভাবে বৃদ্ধি পায়। এই ওভারহেড আরও তাৎপর্যপূর্ণ হয়ে উঠতে পারে যখন টেবিলগুলিকে বিভাজন করা হয়, যেমন Timescale-এর হাইপারটেবিলগুলিতে।

অপ্রয়োজনীয় সূচীগুলি আপনার লেখার ক্রিয়াকলাপগুলিকে উন্নত করতেও বিপরীতমুখী হতে পারে, কারণ প্রতিটি নতুন ডেটা এন্ট্রি বা পরিবর্তন সমসাময়িক সূচক আপডেটগুলিকে বোঝায়, যার ফলে আরও I/O ক্রিয়াকলাপ এবং সম্ভাব্য টেবিল ব্লোট হয়৷ আপনার সূচীগুলি নিরীক্ষণ আপনাকে শনাক্ত করতে সাহায্য করবে যে কোনটি আর ব্যবহার করা হচ্ছে না, জিনিসগুলিকে ক্ষীণ রেখে৷

এটি করার একটি উপায় হল pg_stat_user_indexes ব্যবহার করে :

 -- Retrieve indexes that might not be used or are infrequently used SELECT schemaname, relname AS table_name, indexrelname AS index_name, idx_scan AS times_used FROM pg_stat_user_indexes WHERE idx_scan = 0 OR idx_scan < some_low_threshold -- replace 'some_low_threshold' with a value that makes sense for your context ORDER BY idx_scan ASC, schemaname, relname;

যদি idx_scan কলামে একটি সূচকের মান 0 থাকে, তাহলে এর মানে হল যে শেষবার পরিসংখ্যান রিসেট করার পর থেকে এটি ব্যবহার করা হয়নি, মানে এটি অপ্টিমাইজেশনের জন্য প্রার্থী হতে পারে। idx_scan এর জন্য একটি কম থ্রেশহোল্ড সেট করে, আপনি কদাচিৎ ব্যবহৃত সূচকগুলিও সনাক্ত করতে পারেন।

টাইমস্কেল কম্প্রেশনের মাধ্যমে আপনার বড় টেবিলগুলি সঙ্কুচিত করুন

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

টাইমস্কেলের কম্প্রেশন নিয়মিত সারি-ভিত্তিক ডেটাকে আরও কমপ্যাক্ট কলামার ফর্ম্যাটে রূপান্তর করে কাজ করে। এই প্রক্রিয়াটি সময়-সিরিজ ডেটার জন্য বিশেষভাবে কার্যকর, যেখানে অনেক কলামে পুনরাবৃত্তিমূলক মান থাকতে পারে; আমরা প্রতিটি ডেটা প্রকারের উপর নির্ভর করে বিভিন্ন কম্প্রেশন অ্যালগরিদম প্রয়োগ করে চিত্তাকর্ষক কম্প্রেশন হার (+90%) অর্জন করতে পারি। এর মানে হল যে আপনার বড় টেবিল 10x পর্যন্ত সঙ্কুচিত হতে পারে।

টাইমস্কেলে, কম্প্রেশন একটি সময়-ভিত্তিক কম্প্রেশন নীতির মাধ্যমে টেবিল-বাই-টেবিল ভিত্তিতে সক্রিয় করা হয়। উদাহরণস্বরূপ, এই কোডটি একটি নির্দিষ্ট হাইপারটেবলে কম্প্রেশন সক্ষম করে এবং স্বয়ংক্রিয়ভাবে দুই সপ্তাহের বেশি পুরানো ডেটা সংকুচিত করে:

 -- Enable compression on the hypertable ALTER TABLE your_hypertable SET ( timescaledb.compress, timescaledb.compress_segmentby = 'some_column' ); -- Set a compression policy to compress data older than two weeks SELECT add_compression_policy('your_hypertable', INTERVAL '2 weeks');

কম্প্রেশন সম্পর্কে আরও জানতে, আমাদের ডকুমেন্টেশন চেক আউট .

একটি ডেটা পরিচালনার কৌশল সেট আপ করুন: পুরানো ডেটা সস্তা সঞ্চয়স্থানে সরান, আপনার আর প্রয়োজন নেই এমন ডেটা মুছুন৷

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

একটি সাধারণ টিয়ারিং নীতি তৈরি করে, আপনি পুরানো, কম-অ্যাক্সেস করা ডেটা একটি তলাবিহীন অবজেক্ট স্টোরেজ স্তরে স্থানান্তর করতে পারেন:

 -- This policy moves all data older than one month to object storage SELECT add_tiering_policy('example', INTERVAL '1 month);

এই বস্তুর দোকান নিম্নলিখিত বৈশিষ্ট্য আছে:

• এটি আমাদের উচ্চ-পারফরম্যান্স স্টোরেজের তুলনায় কম মূল্যের পয়েন্ট সহ আসে, যা আপনাকে অনেক কম খরচে অনেক TB ডেটা সঞ্চয় করতে দেয়।
• এটি অসীম, যার অর্থ আপনি যত খুশি তত ডেটা সঞ্চয় করতে পারেন।
  

এই টায়ার্ড স্টোরেজ আর্কিটেকচারটি টাইমস্কেলের ব্যাকএন্ডে নিহিত রয়েছে। অবজেক্ট স্টোরেজ আপনার ডাটাবেস থেকে বিচ্ছিন্ন একটি "বালতি" নয় - পরিবর্তে, এটি এটির একটি অবিচ্ছেদ্য অংশ। ক্যোয়ারীগুলি আপনার কাছ থেকে কোনও পদক্ষেপের প্রয়োজন ছাড়াই স্বচ্ছভাবে উভয় স্টোরেজ স্তরে অ্যাক্সেস করবে—আপনি একই স্কিমাতে স্ট্যান্ডার্ড SQL ব্যবহার চালিয়ে যেতে পারেন। একবার আপনার টায়ারিং নীতি সেট হয়ে গেলে, বিবেচনা করার আর কিছুই নেই!

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

এই কম খরচের স্টোরেজ লেয়ারটি অফার করার উপরে, টাইমস্কেল আপনার আর প্রয়োজন নেই এমন ডেটা মুছে ফেলার জন্য ডেটা ধারণ নীতি সেট আপ করা সহজ করে তোলে:

 -- Set a data retention policy to drop data older than 10 months SELECT add_retention_policy('your_hypertable', INTERVAL '10 months');

আপনার ডেটাসেটকে কার্যকরভাবে ডাউনস্যাম্পল করতে আপনি উপরেরটির মতো ডেটা ধারণ নীতিগুলিকে অবিচ্ছিন্ন সমষ্টিগুলির সাথে একত্রিত করতে পারেন—যেমন, এক সেকেন্ড থেকে এক মিনিটে গ্রানুলারিটি হ্রাস করা, এক-সেকেন্ডের মানগুলি মুছে ফেলা কিন্তু এক-মিনিটের সমষ্টি বজায় রাখা৷ কীভাবে এটি করতে হয় এবং সক্রিয়ভাবে দীর্ঘমেয়াদী ডেটা পরিচালনা করতে হয় তার একটি উদাহরণ দেখতে এই ব্লগ পোস্টটি পড়ুন .

ব্যবহার-ভিত্তিক মডেল এবং ডেটা ম্যানেজমেন্ট প্যারাডাইম

যদিও ব্যবহার-ভিত্তিক মডেলগুলি পৃষ্ঠে মূল্য পরিবর্তন ছাড়া কিছুই মনে হতে পারে না, তারা কীভাবে ডেভেলপাররা তাদের ডাটাবেসের আকার সম্পর্কে চিন্তা করে এবং কীভাবে তারা ডেটা উপলব্ধি করে এবং পরিচালনা করে তার একটি দৃষ্টান্ত পরিবর্তন করে।

ব্যবহার-ভিত্তিক মডেলগুলি ক্রমাগত উন্নতির সংস্কৃতিকে উন্নীত করে, যেখানে ফোকাস শুধুমাত্র স্টোরেজ ম্যানেজমেন্ট থেকে ডাটাবেস স্বাস্থ্য এবং দক্ষতার দিকে চলে যায়। এর জন্য প্রথমে কিছু নিয়মানুবর্তিতা প্রয়োজন, কিন্তু একবার আপনার মানসিকতা পরিবর্তন হয়ে গেলে এবং আপনি কিছু কৌশল শিখলে, আপনি আপনার PostgreSQL ডাটাবেসকে দক্ষতার সাথে এবং কার্যকরভাবে স্কেল করার জন্য সর্বোত্তম স্থানে থাকবেন।

আপনার PostgreSQL ডাটাবেসের আকার কমপ্রেশন, টায়ার্ড স্টোরেজ এবং ডেটা ধারণ নীতির মতো পদ্ধতিগতভাবে কমাতে সাহায্য করার জন্য Timescale-এর মূল্যবান টুল রয়েছে। এটি আপনাকে একটি ব্যবহার-ভিত্তিক মডেলে আপনার PostgreSQL ডাটাবেসগুলিকে কার্যকরভাবে স্কেল করতে দেয়। এটি নিজে অনুভব করতে, টাইমস্কেল-এর জন্য সাইন আপ করুন—আপনি এটি প্রথম 30 দিনের জন্য বিনামূল্যে ব্যবহার করতে পারেন৷ .

- কার্লোটা সোটা লিখেছেন।