পোস্টগ্রেস টোস্ট: ডেটা কম্প্রেশন মেকানিজম এবং এর সীমাবদ্ধতা বোঝা

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

PostgreSQL এর কিছুটা কম্প্রেশন মেকানিজম আছে: টোস্ট 🍞 এই পোস্টে, আমরা আপনাকে পোস্টগ্রেস টোস্ট কীভাবে কাজ করে এবং বিভিন্ন টোস্টিং কৌশলগুলি নিয়ে চলে যাব। আমরা যতটা ভালো টোস্ট উপভোগ করি, আমরা আলোচনা করব কেন আধুনিক বৃহৎ ডাটাবেসের স্টোরেজ ফুটপ্রিন্ট কমানোর জন্য এই ধরনের কম্প্রেশন বৈশিষ্ট্য আপনার প্রয়োজন হয় না—এবং কিভাবে, PostgreSQL উত্সাহী হিসাবে আমরা টাইমস্কেলে এখানে এসেছি, আমরা সিদ্ধান্ত নিয়েছি NoSQL ডাটাবেসের কলামার ডিজাইন দ্বারা অনুপ্রাণিত, PostgreSQL-এর জন্য আরও উপযুক্ত কম্প্রেশন মেকানিজম তৈরি করতে।

পোস্টগ্রেস টোস্ট কি?

এমনকি যদি এটি ডেটাসেটের আকার কমাতে পারে, TOAST (The Oversized Attribute Storage Technique) আপনার প্রথাগত ডেটা কম্প্রেশন মেকানিজম নয়। TOAST কী তা বোঝার জন্য, আমাদের কথা বলে শুরু করতে হবে পোস্টগ্রেএসকিউএল-এ কীভাবে ডেটা সংরক্ষণ করা হয় .

পোস্টগ্রেসের স্টোরেজ ইউনিটগুলিকে পেজ বলা হয় এবং এগুলোর একটি নির্দিষ্ট আকার থাকে (ডিফল্টরূপে 8 kB)। একটি নির্দিষ্ট পৃষ্ঠার আকার পোস্টগ্রেসকে অনেক সুবিধা দেয়, যেমন এর ডেটা পরিচালনার সরলতা, দক্ষতা এবং সামঞ্জস্য, তবে এটি একটি খারাপ দিক নিয়ে আসে: কিছু ডেটা মান সেই পৃষ্ঠার মধ্যে মাপসই নাও হতে পারে।

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

টোস্ট-সক্ষম ডেটা প্রকার

TOAST-এর অধীন হতে পারে এমন ডেটা প্রকারগুলি প্রাথমিকভাবে পরিবর্তনশীল-দৈর্ঘ্যের যেগুলির একটি আদর্শ PostgreSQL পৃষ্ঠার আকারের সীমা অতিক্রম করার সম্ভাবনা রয়েছে৷ অন্যদিকে, integer , float বা timestamp মতো নির্দিষ্ট-দৈর্ঘ্যের ডেটা প্রকারগুলি TOAST-এর অধীন হয় না কারণ সেগুলি একটি পৃষ্ঠার মধ্যে আরামদায়কভাবে ফিট করে৷

TOAST-এর অধীন হতে পারে এমন ডেটা প্রকারের কিছু উদাহরণ হল:

• json এবং jsonb

• বড় text স্ট্রিং

• varchar এবং varchar(n) (যদি varchar(n) এ নির্দিষ্ট দৈর্ঘ্য যথেষ্ট ছোট হয়, তাহলে সেই কলামের মান সবসময় TOAST থ্রেশহোল্ডের নিচে থাকতে পারে।)

• bytea বাইনারি ডেটা সংরক্ষণ করে

• জ্যামিতিক ডেটা যেমন path এবং polygon এবং পোস্টজিআইএস ধরনের geometry বা geography

  
  

পোস্টগ্রেস টোস্ট কীভাবে কাজ করে?

TOAST বোঝা শুধুমাত্র পৃষ্ঠার আকারের ধারণার সাথে সম্পর্কিত নয় বরং আরেকটি Postgres স্টোরেজ ধারণার সাথেও সম্পর্কিত: tuples। Tuples হল একটি PostgreSQL টেবিলের সারি। সাধারণত, একটি টিপলের মধ্যে সমস্ত ফিল্ডের মোট আকার প্রায় 2 kB এর বেশি হলে TOAST মেকানিজম শুরু হয়।

আপনি যদি মনোযোগ দিয়ে থাকেন, আপনি হয়তো ভাবছেন, "অপেক্ষা করুন, কিন্তু পৃষ্ঠার আকার প্রায় 8 kB—কেন এই ওভারহেড?" কারণ PostgreSQL এটি নিশ্চিত করতে পছন্দ করে যে এটি একটি একক পৃষ্ঠায় একাধিক টিপল সংরক্ষণ করতে পারে: যদি টিপলগুলি খুব বড় হয় তবে প্রতিটি পৃষ্ঠায় কম টিপল ফিট করে, যার ফলে I/O ক্রিয়াকলাপ বৃদ্ধি পায় এবং কর্মক্ষমতা হ্রাস পায়।

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

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

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

   
   

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

পোস্টগ্রেস কম্প্রেশন অ্যালগরিদম: pglz

আমরা উল্লেখ করেছি যে TOAST পোস্টগ্রেএসকিউএল-এ বড় মান সংকুচিত করতে পারে। কিন্তু কোন কম্প্রেশন অ্যালগরিদম PostgreSQL ব্যবহার করছে এবং এটি কতটা কার্যকর?

pglz (PostgreSQL Lempel-Ziv) হল একটি ডিফল্ট অভ্যন্তরীণ কম্প্রেশন অ্যালগরিদম যা PostgreSQL দ্বারা বিশেষভাবে TOAST-এর জন্য তৈরি।

এটি কীভাবে খুব সহজ শর্তে কাজ করে তা এখানে:

• pglz বারবার ডেটা এড়াতে চেষ্টা করে। যখন এটি পুনরাবৃত্ত ডেটা দেখে, একই জিনিস আবার লেখার পরিবর্তে, এটি আগে যেখানে এটি লিখেছিল সেদিকেই নির্দেশ করে। এই "পুনরাবৃত্তি এড়ানো" স্থান বাঁচাতে সাহায্য করে।

  
  

• pglz ডেটার মাধ্যমে পড়ার সময়, এটি সাম্প্রতিক ডেটা দেখেছে তার কিছুটা মনে রাখে। এই সাম্প্রতিক স্মৃতিকে "স্লাইডিং উইন্ডো" বলা হয়।

  
  

• নতুন ডেটা আসার সাথে সাথে, pglz পরীক্ষা করে যে এটি সম্প্রতি এই ডেটা দেখেছে কিনা (এর স্লাইডিং উইন্ডোর মধ্যে)। যদি হ্যাঁ, এটি ডেটা পুনরাবৃত্তি করার পরিবর্তে একটি সংক্ষিপ্ত রেফারেন্স লেখে।

  
  

• যদি ডেটা নতুন হয় বা প্রকৃত ডেটার চেয়ে ছোট একটি রেফারেন্স তৈরি করার জন্য যথেষ্ট বার পুনরাবৃত্তি না হয়, pglz এটি যেমন আছে তেমনই লিখে দেয়।

  
  

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

  
  

• pglz এর মেমরির জন্য আলাদা স্টোরেজের প্রয়োজন নেই (স্লাইডিং উইন্ডো); এটি কম্প্রেস করার সময় যেতে যেতে এটি তৈরি করে এবং ডিকম্প্রেস করার সময় একই কাজ করে।

  
  

এই বাস্তবায়নটি TOAST প্রক্রিয়ার মধ্যে কম্প্রেশন দক্ষতা এবং গতির মধ্যে ভারসাম্য অফার করার জন্য ডিজাইন করা হয়েছে। কম্প্রেশন হারের ক্ষেত্রে, pglz এর কার্যকারিতা মূলত ডেটার প্রকৃতির উপর নির্ভর করবে।

উদাহরণস্বরূপ, উচ্চ পুনরাবৃত্ত ডেটা উচ্চ এনট্রপি ডেটার (যেমন এলোমেলো ডেটা) থেকে অনেক ভাল সংকুচিত করবে। আপনি 25 থেকে 50 শতাংশের মধ্যে কম্প্রেশন অনুপাত দেখতে পারেন, কিন্তু এটি একটি খুব সাধারণ অনুমান- ফলাফলগুলি ডেটার সঠিক প্রকৃতির উপর ভিত্তি করে ব্যাপকভাবে পরিবর্তিত হবে।

TOAST কনফিগার করা হচ্ছে

টোস্ট কৌশল

ডিফল্টরূপে, PostgreSQL আগে ব্যাখ্যা করা পদ্ধতি অনুসারে TOAST প্রক্রিয়ার মধ্য দিয়ে যাবে (সংকোচন প্রথম এবং লাইনের বাইরের স্টোরেজ পরবর্তী, যদি কম্প্রেশন যথেষ্ট না হয়)। তবুও, এমন পরিস্থিতি থাকতে পারে যেখানে আপনি প্রতি-কলামের ভিত্তিতে এই আচরণটিকে সূক্ষ্ম-টিউন করতে চাইতে পারেন। PostgreSQL আপনাকে TOAST কৌশলগুলি PLAIN , EXTERNAL , EXTENDED , এবং MAIN ব্যবহার করে এটি করতে দেয়৷

• EXTENDED : এটি ডিফল্ট কৌশল। এটি বোঝায় যে ডেটা একটি পৃথক টোস্ট টেবিলে লাইনের বাইরে সংরক্ষণ করা হবে যদি এটি একটি নিয়মিত টেবিল পৃষ্ঠার জন্য খুব বড় হয়। TOAST টেবিলে ডেটা সরানোর আগে, স্থান বাঁচাতে এটি সংকুচিত হবে।

  
  

• EXTERNAL : এই কৌশলটি PostgreSQL কে এই কলামের জন্য ডেটা লাইনের বাইরে সংরক্ষণ করতে বলে যদি ডেটা একটি নিয়মিত টেবিলের পৃষ্ঠায় ফিট করার জন্য খুব বড় হয়, এবং আমরা PostgreSQL কে ডেটা সংকুচিত না করার জন্য বলছি—মানটি কেবলমাত্র এখানে সরানো হবে TOAST টেবিল যেমন আছে।

  
  

• MAIN : এই কৌশল একটি মধ্যম স্থল. এটি সংকোচনের মাধ্যমে মূল টেবিলে ডেটা রাখার চেষ্টা করে; যদি ডেটা অবশ্যই খুব বড় হয়, এটি একটি ত্রুটি এড়াতে ডেটাটিকে TOAST টেবিলে নিয়ে যাবে, কিন্তু PostgreSQL সংকুচিত ডেটা স্থানান্তর করবে না। পরিবর্তে, এটি TOAST টেবিলে মানটিকে তার আসল আকারে সংরক্ষণ করবে।

  
  

• PLAIN : একটি কলামে PLAIN ব্যবহার করা PostgreSQL কে কলামের ডেটা সবসময় প্রধান টেবিলে লাইনে সংরক্ষণ করতে বলে, যাতে এটি একটি লাইনের বাইরের টোস্ট টেবিলে সরানো না হয়। একাউন্টে নিন যে যদি ডেটা পৃষ্ঠার আকারের বাইরে বৃদ্ধি পায়, তাহলে INSERT ব্যর্থ হবে কারণ ডেটা ফিট হবে না।

আপনি যদি একটি নির্দিষ্ট টেবিলের বর্তমান কৌশলগুলি পরিদর্শন করতে চান তবে আপনি নিম্নলিখিতগুলি চালাতে পারেন:

 \d+ your_table_name

আপনি এই মত একটি আউটপুট পাবেন:

 => \d+ example_table                     Table "public.example_table" Column |    Data Type  | Modifiers | Storage | Stats target | Description ---------+------------------+-----------+----------+--------------+-------------  bar  | varchar(100000) |      | extended |       |

আপনি যদি স্টোরেজ সেটিংস পরিবর্তন করতে চান তবে আপনি নিম্নলিখিত কমান্ডটি ব্যবহার করে তা করতে পারেন:

 -- Sets EXTENDED as the TOAST strategy for bar_column ALTER TABLE example_blob ALTER COLUMN bar_column SET STORAGE EXTENDED;

মূল পরামিতি

উপরের কৌশলগুলি ছাড়াও, TOAST আচরণ নিয়ন্ত্রণ করতে এই দুটি পরামিতিও গুরুত্বপূর্ণ:

TOAST_TUPLE_THRESHOLD

এটি সেই পরামিতি যা বড় আকারের টিপলের জন্য টোস্টিং অপারেশন (সংকোচন এবং লাইনের বাইরের স্টোরেজ) বিবেচনা করা হলে আকারের থ্রেশহোল্ড সেট করে।

আমরা পূর্বে উল্লেখ করেছি, ডিফল্টরূপে, TOAST_TUPLE_THRESHOLD আনুমানিক 2 kB এ সেট করা আছে।

TOAST_COMPRESSION_THRESHOLD

এটি সেই প্যারামিটার যা পোস্টগ্রেস টোস্টিং প্রক্রিয়া চলাকালীন এটিকে সংকুচিত করার কথা বিবেচনা করার আগে একটি মানের সর্বনিম্ন আকার নির্দিষ্ট করে।

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

এটা সব একসাথে আনা

TOAST_TUPLE_THRESHOLD হল ট্রিগার পয়েন্ট। যখন একটি টিপলের ডেটা ফিল্ডের আকার এই থ্রেশহোল্ডকে অতিক্রম করে, তখন PostgreSQL তার কলামগুলির জন্য সেট করা TOAST কৌশলের উপর ভিত্তি করে কম্প্রেশন এবং লাইনের বাইরের স্টোরেজ বিবেচনা করে কীভাবে এটি পরিচালনা করা যায় তা মূল্যায়ন করবে। গৃহীত সঠিক পদক্ষেপগুলিও কলাম ডেটা TOAST_COMPRESSION_THRESHOLD অতিক্রম করে কিনা তার উপর নির্ভর করবে:

• EXTENDED (ডিফল্ট কৌশল): যদি একটি টিপলের আকার TOAST_TUPLE_THRESHOLD অতিক্রম করে, PostgreSQL প্রথমে বড় আকারের কলামগুলিকে সংকুচিত করার চেষ্টা করবে যদি সেগুলি TOAST_COMPRESSION_THRESHOLD এর বেশি হয়। যদি কম্প্রেশন টিপলের আকারকে থ্রেশহোল্ডের নিচে নিয়ে আসে, তাহলে এটি মূল টেবিলে থাকবে। যদি এটি না হয়, ডেটা একটি আউট-অফ-লাইন TOAST টেবিলে স্থানান্তরিত হবে এবং মূল টেবিলে এই বাহ্যিক ডেটার পয়েন্টার থাকবে৷

  
  

• MAIN : যদি টিপলের আকার TOAST_TUPLE_THRESHOLD ছাড়িয়ে যায়, PostgreSQL বড় আকারের কলামগুলিকে সংকুচিত করার চেষ্টা করবে (যদি সেগুলি TOAST_COMPRESSION_THRESHOLD এর উপরে থাকে)। যদি কম্প্রেশন টিপলটিকে মূল টেবিলের টিপলের মধ্যে ফিট করতে দেয় তবে এটি সেখানেই থেকে যায়। যদি তা না হয়, তথ্যটি তার অসংকুচিত আকারে TOAST টেবিলে সরানো হয়।

  
  

• EXTERNAL : PostgreSQL TOAST_COMPRESSION_THRESHOLD নির্বিশেষে কম্প্রেশন এড়িয়ে যায়। যদি টিপলের আকার TOAST_TUPLE_THRESHOLD এর বাইরে হয়, তাহলে বড় আকারের কলামগুলি TOAST টেবিলের বাইরের লাইনে সংরক্ষণ করা হবে।

  
  

• PLAIN : ডেটা সবসময় মূল টেবিলে সংরক্ষিত হয়। যদি একটি টিপলের আকার পৃষ্ঠার আকারকে অতিক্রম করে (খুব বড় কলাম থাকার কারণে), একটি ত্রুটি উত্থাপিত হয়।

পোস্টগ্রেএসকিউএল-এ ডেটা কম্প্রেশন মেকানিজম হিসাবে টোস্ট কেন যথেষ্ট নয়

এতক্ষণে, আপনি সম্ভবত বুঝতে পারবেন কেন TOAST এমন ডেটা কম্প্রেশন মেকানিজম নয় যা আপনি PostgreSQL-এ চান। আধুনিক অ্যাপ্লিকেশানগুলি বোঝায় যে প্রতিদিন প্রচুর পরিমাণে ডেটা প্রবেশ করা হয়, যার অর্থ ডাটাবেসগুলি দ্রুত বৃদ্ধি পায়।

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

যদিও TOAST তার কৌশলগুলির মধ্যে একটি হিসাবে কম্প্রেশনকে অন্তর্ভুক্ত করে, এটি বোঝা গুরুত্বপূর্ণ যে এটির প্রাথমিক ভূমিকাটি ঐতিহ্যগত অর্থে একটি ডাটাবেস কম্প্রেশন প্রক্রিয়া হিসাবে পরিবেশন করা নয়। TOAST প্রধানত একটি সমস্যার সমাধান: পোস্টগ্রেস পৃষ্ঠার কাঠামোগত সীমার মধ্যে বড় মানগুলি পরিচালনা করা।

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

উদাহরণস্বরূপ, যদি আপনার কাছে ছোট টিপল দিয়ে তৈরি একটি 5 TB ডাটাবেস থাকে, তাহলে TOAST আপনাকে সেই 5 টিবিকে 1 টিবিতে পরিণত করতে সাহায্য করবে না। যদিও TOAST-এর মধ্যে এমন প্যারামিটার রয়েছে যা সামঞ্জস্য করা যেতে পারে, এটি TOAST-কে একটি সাধারণ স্টোরেজ-সেভিং সমাধানে রূপান্তরিত করবে না।

এবং PostgreSQL-এ একটি ঐতিহ্যগত কম্প্রেশন মেকানিজম হিসাবে TOAST ব্যবহার করার সাথে অন্যান্য অন্তর্নিহিত সমস্যা রয়েছে, উদাহরণস্বরূপ:

• TOASTed ডেটা অ্যাক্সেস করা ওভারহেড যোগ করতে পারে, বিশেষ করে যখন ডেটা লাইনের বাইরে সংরক্ষণ করা হয়। এটি আরও স্পষ্ট হয়ে ওঠে যখন অনেক বড় পাঠ্য বা অন্যান্য TOAST-সক্ষম ডেটা প্রকারগুলি ঘন ঘন অ্যাক্সেস করা হয়।

  
  

• TOAST-এর কম্প্রেশন নীতি নির্ধারণের জন্য একটি উচ্চ-স্তরের, ব্যবহারকারী-বান্ধব প্রক্রিয়া নেই। এটি স্টোরেজ খরচ অপ্টিমাইজ করতে বা স্টোরেজ পরিচালনার সুবিধার্থে তৈরি করা হয়নি।

  
  

• TOAST এর কম্প্রেশন বিশেষ করে উচ্চ কম্প্রেশন অনুপাত প্রদান করার জন্য ডিজাইন করা হয়নি। এটি শুধুমাত্র একটি অ্যালগরিদম ( pglz ) ব্যবহার করে যার সংকোচনের হার সাধারণত 25-50 শতাংশ থেকে পরিবর্তিত হয়।

টাইমস্কেল সহ PostgreSQL এ কলামার কম্প্রেশন যোগ করা হচ্ছে

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

আপনার বড় টেবিলে একটি কম্প্রেশন নীতি যোগ করে, আপনি আপনার PostgreSQL ডাটাবেসের আকার 10x পর্যন্ত কমাতে পারেন (+90 শতাংশ কম্প্রেশন রেট অর্জন) .

একটি সময়-ভিত্তিক কম্প্রেশন নীতি নির্ধারণ করে, আপনি নির্দেশ করেন কখন ডেটা সংকুচিত করা উচিত। উদাহরণস্বরূপ, আপনি স্বয়ংক্রিয়ভাবে সাত (7) দিনের বেশি পুরানো ডেটা সংকুচিত করতে বেছে নিতে পারেন:

 -- Compress data older than 7 days SELECT add_compression_policy('my_hypertable', INTERVAL '7 days');

এই কম্প্রেশন নীতির মাধ্যমে, টাইমস্কেল টেবিলটি রূপান্তর করবে পার্টিশন ( যা টাইমস্কেলে স্বয়ংক্রিয়ভাবে তৈরি হয় ) পর্দার পিছনে একটি কলামার বিন্যাসে, একটি অ্যারেতে অনেকগুলি সারি (1,000) একত্রিত করে৷ কম্প্রেসিবিলিটি বাড়ানোর জন্য, টাইমস্কেল ডেটা টাইপের উপর নির্ভর করে বিভিন্ন কম্প্রেশন অ্যালগরিদম প্রয়োগ করবে:

• ফ্লোটের জন্য গরিলা কম্প্রেশন

• ব-দ্বীপের ব-দ্বীপ + সরল-8 খ সঙ্গে রান-দৈর্ঘ্য এনকোডিং টাইমস্ট্যাম্প এবং অন্যান্য পূর্ণসংখ্যার মত ধরনের জন্য সংকোচন

• কয়েকটি পুনরাবৃত্ত মান সহ কলামগুলির জন্য সম্পূর্ণ-সারি অভিধান কম্প্রেশন (+ LZ উপরে কম্প্রেশন)

• অন্য সব ধরনের জন্য LZ-ভিত্তিক অ্যারে কম্প্রেশন

  
  

এই কলামার কম্প্রেশন ডিজাইন PostgreSQL-এ বড় ডেটাসেটের সমস্যার জন্য একটি দক্ষ এবং মাপযোগ্য সমাধান প্রদান করে। এটি আপনাকে আপনার ক্যোয়ারী পারফরম্যান্সে ক্ষতি না করে আরও ডেটা সঞ্চয় করতে কম স্টোরেজ ব্যবহার করতে দেয় (এটি এটিকে উন্নত করে)। এবং TimescaleDB-এর সর্বশেষ সংস্করণগুলিতে, আপনি সংকুচিত ডেটার মাধ্যমে সরাসরি INSERT , DELETE , এবং UPDATE করতে পারেন৷

শেষ করি

আমরা আশা করি এই নিবন্ধটি আপনাকে বুঝতে সাহায্য করেছে যে TOAST একটি PostgreSQL পৃষ্ঠার মধ্যে বড় মানগুলি পরিচালনা করার জন্য একটি সুচিন্তিত প্রক্রিয়া, এটি আধুনিক অ্যাপ্লিকেশনগুলির ক্ষেত্রে ডাটাবেস স্টোরেজ ব্যবহার অপ্টিমাইজ করার জন্য কার্যকর নয়৷

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

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