বড় পোস্টগ্রেএসকিউএল ডেটাবেসে কলামার কম্প্রেশন বাস্তবায়নের কৌশল

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

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

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

আরও মাপযোগ্য PostgreSQL-এ স্বাগতম!

বিষয়বস্তু ওভারভিউ

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

কেন PostgreSQL এর ডাটাবেস কম্প্রেশন প্রয়োজন

কিন্তু আমরা কীভাবে কম্প্রেশন তৈরি করেছি তার বিশদ বিবরণে যাওয়ার আগে, আসুন এই প্রশ্নের উত্তর দিতে কয়েক মিনিট সময় ব্যয় করি: কেন পোস্টগ্রেএসকিউএল-এ একটি নতুন ডাটাবেস কম্প্রেশন মেকানিজম যুক্ত করা প্রয়োজন?

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

আমরা পোস্টগ্রেসকে ভালবাসি: আমরা বিশ্বাস করি যে এটি অ্যাপ্লিকেশন তৈরির জন্য সর্বোত্তম ভিত্তি কারণ এটির নির্ভরযোগ্যতা, নমনীয়তা এবং সমৃদ্ধ ইকোসিস্টেমের সংমিশ্রণ অন্য কোনো ডাটাবেসের সাথে মেলানো খুব কঠিন। কিন্তু পোস্টগ্রেসের জন্ম কয়েক দশক আগে—এই দৃঢ়তা কোনো খারাপ দিক ছাড়া আসে না।

আজ, বিকাশকারীরা প্রথাগত OLTP (অনলাইন লেনদেন প্রক্রিয়াকরণ) ব্যবহারের ক্ষেত্রে পোস্টগ্রেএসকিউএল ব্যবহার করছেন যা এটি সবচেয়ে বেশি পরিচিত। অনেক ডেটা-ইনটেনসিভ, চাহিদাপূর্ণ অ্যাপ্লিকেশন- 24/7 চলমান এবং ডেটার ক্রমবর্ধমান ভলিউম পরিচালনা করে- PostgreSQL দ্বারা চালিত হয়:

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

  
  

• শক্তি সংস্থাগুলি স্মার্ট গ্রিড এবং পুনর্নবীকরণযোগ্য শক্তির উত্সগুলি থেকে মেট্রিক্স সংরক্ষণ এবং বিশ্লেষণ করতে PostgreSQL ব্যবহার করছে৷

  
  

• আর্থিক খাতে, PostgreSQL হল রিয়েল-টাইমে মার্কেট টিক ডেটা ট্র্যাক করার সিস্টেমের মূলে।

• ই-কমার্স প্ল্যাটফর্মগুলি ব্যবহারকারীর মিথস্ক্রিয়া দ্বারা উত্পন্ন ইভেন্টগুলি ট্র্যাক এবং বিশ্লেষণ করতে PostgreSQL ব্যবহার করছে।

  
  

• পোস্টগ্রেস এমনকি এআই অ্যাপ্লিকেশনের নতুন তরঙ্গকে শক্তি দিতে ভেক্টর ডাটাবেস হিসাবে ব্যবহার করা হচ্ছে।

  
  

ফলস্বরূপ পোস্টগ্রেস টেবিলগুলি খুব দ্রুত বৃদ্ধি পাচ্ছে, এবং টেবিলগুলি বিলিয়ন সারিগুলিতে পৌঁছানো উৎপাদনে নতুন স্বাভাবিক।

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

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

কিন্তু TOAST সম্পর্কে কি?

কিন্তু PostgreSQL এর বিদ্যমান TOAST পদ্ধতি সম্পর্কে কি? এর আশ্চর্যজনক নাম থাকা সত্ত্বেও 🍞😋, আপনার বৃহৎ PostgreSQL ডাটাবেসের আকার পদ্ধতিগতভাবে কমাতে TOAST কার্যকর নয় .

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

উদাহরণ স্বরূপ, যদি আপনার কাছে ছোট টিপল দিয়ে তৈরি একটি 1 TB ডাটাবেস থাকে, তাহলে TOAST আপনাকে পদ্ধতিগতভাবে সেই 1 TB কে 80 GB তে পরিণত করতে সাহায্য করবে না, আপনি যতই সূক্ষ্ম টিউন করার চেষ্টা করুন না কেন। TOAST স্বয়ংক্রিয়ভাবে একটি সারিতে বড় আকারের বৈশিষ্ট্যগুলিকে সংকুচিত করবে কারণ সেগুলি 2 KB-এর থ্রেশহোল্ড অতিক্রম করে, তবে TOAST ছোট মানগুলির (টুপল) জন্য সাহায্য করে না, বা আপনি আরও উন্নত ব্যবহারকারী-কনফিগারযোগ্য কনফিগারেশন প্রয়োগ করতে পারবেন না যেমন এক মাসের বেশি পুরানো সমস্ত ডেটা সংকুচিত করা একটি নির্দিষ্ট টেবিলে। TOAST এর সংকোচন কঠোরভাবে পৃথক কলামের মানের আকারের উপর ভিত্তি করে, বিস্তৃত টেবিল বা ডেটাসেট বৈশিষ্ট্যের উপর নয়।

TOAST উল্লেখযোগ্য I/O ওভারহেডও প্রবর্তন করতে পারে, বিশেষ করে ঘন ঘন বড় আকারের কলাম সহ বড় টেবিলের জন্য। এই ধরনের ক্ষেত্রে, PostgreSQL-কে TOAST টেবিল থেকে আউট-অফ-লাইন ডেটা পুনরুদ্ধার করতে হবে, যা একটি পৃথক I/O ক্রিয়াকলাপ যা মূল টেবিলে অ্যাক্সেস করা থেকে, কারণ পোস্টগ্রেএসকিউএলকে অবশ্যই প্রধান টেবিল থেকে TOAST টেবিলে পয়েন্টার অনুসরণ করতে হবে। সম্পূর্ণ তথ্য। এটি সাধারণত খারাপ কর্মক্ষমতা বাড়ে.

সবশেষে, TOAST এর কম্প্রেশন বিশেষ করে উচ্চ কম্প্রেশন অনুপাত প্রদান করার জন্য ডিজাইন করা হয়নি, কারণ এটি সমস্ত ডেটা প্রকারের জন্য একটি স্ট্যান্ডার্ড অ্যালগরিদম ব্যবহার করে।

কেন কম্প্রেশন পোস্টগ্রেএসকিউএল নেটিভ নয়? সারি বনাম কলাম-ওরিয়েন্টেড ডেটাবেসের একটি ভূমিকা

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

এর এই ভেঙ্গে দেওয়া যাক. ঐতিহ্যগতভাবে, ডাটাবেস দুটি বিভাগের একটিতে পড়ে:

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

  
  

• কলাম-ভিত্তিক (ওরফে "কলামার") ডেটাবেস , অন্যদিকে, কলাম দ্বারা ডেটা সংগঠিত করে। প্রতিটি কলাম একাধিক রেকর্ড জুড়ে একটি নির্দিষ্ট বৈশিষ্ট্যের জন্য সমস্ত ডেটা সঞ্চয় করে। এগুলি সাধারণত OLAP সিস্টেমের জন্য অপ্টিমাইজ করা হয় (অনলাইন বিশ্লেষণাত্মক প্রক্রিয়াকরণ), যেখানে প্রশ্নগুলি প্রায়শই অনেক রেকর্ড জুড়ে একত্রিতকরণ এবং ক্রিয়াকলাপ জড়িত থাকে।

  
  

একটি উদাহরণ দিয়ে এটি ব্যাখ্যা করা যাক। বলুন আমাদের চারটি কলাম সহ একটি users টেবিল রয়েছে: user_id , name , logins , এবং last_login । যদি এই টেবিলটি এক মিলিয়ন ব্যবহারকারীর জন্য ডেটা সঞ্চয় করে, তবে এটি কার্যকরভাবে এক মিলিয়ন সারি এবং চারটি কলাম থাকবে, শারীরিকভাবে প্রতিটি ব্যবহারকারীর ডেটা (অর্থাৎ, প্রতিটি সারি) ডিস্কে অবিচ্ছিন্নভাবে সংরক্ষণ করবে।

এই সারি-ভিত্তিক সেটআপে, user_id = 500,000-এর জন্য সম্পূর্ণ সারিটি সংরক্ষিত হয়, যা দ্রুত পুনরুদ্ধার করে। ফলস্বরূপ, একটি সারি স্টোরে অগভীর এবং প্রশস্ত প্রশ্নগুলি দ্রুততর হবে (যেমন, "ব্যবহারকারী X এর জন্য সমস্ত ডেটা আনুন"):

 -- Create table CREATE TABLE users ( user_id SERIAL PRIMARY KEY, name VARCHAR(100), logins INT DEFAULT 0, last_login TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- Assume we have inserted 1M user records into the 'users' table -- Shallow-and-wide query example (faster in row store) SELECT * FROM users WHERE user_id = 500000;

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

 -- Deep-and-narrow query example (faster in column store) SELECT AVG(logins) FROM users;

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

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

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

কিন্তু এমনকি যদি তারা OLAP-শৈলীর প্রশ্ন এবং সংকোচনের সুবিধাগুলি দেখায়, কলামার স্টোরগুলি ট্রেড-অফ ছাড়া নয়:

• পৃথক সারি পুনরুদ্ধার করা প্রশ্নগুলি অনেক কম কার্যকরী (কখনও কখনও চালানোও অসম্ভব)।

  
  

• তাদের স্থাপত্য ঐতিহ্যগত ACID লেনদেনের জন্য উপযুক্ত নয়।

  
  

• কলামার স্টোরগুলিতে আপডেট করা প্রায়শই সম্ভব হয় না।

  
  

• সারি-ভিত্তিক দোকানগুলির পক্ষে সুবিধা নেওয়া সহজ সূচক (যেমন, বি-ট্রি) দ্রুত উপযুক্ত রেকর্ড খুঁজে বের করতে।

  
  

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

সারি বনাম কলাম-ওরিয়েন্টেড ডেটাবেস: কি বেছে নেবেন?

সুতরাং, কি ভাল: সারি-ভিত্তিক বা কলামার?

ঐতিহ্যগতভাবে, আপনি আপনার কাজের চাপের উপর নির্ভর করে উভয়ের মধ্যে ট্রেড-অফ মূল্যায়ন করবেন। আপনি যদি একটি সাধারণ OLTP ব্যবহার কেস চালান, আপনি সম্ভবত একটি সারি-ভিত্তিক রিলেশনাল ডাটাবেস যেমন PostgreSQL বেছে নেবেন; যদি আপনার ব্যবহারের ক্ষেত্রে স্পষ্টভাবে OLAP হয়, তাহলে আপনি ক্লিকহাউসের মতো একটি কলামার দোকানের দিকে ঝুঁকতে পারেন।

কিন্তু যদি আপনার কাজের চাপ আসলে উভয়ের মিশ্রণ হয়?

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

  
  

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

  
  

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

  
  

• আপনার ডেটা যুক্ত-বেশিরভাগই , তবে অগত্যা কেবল-সংযোজন নয়। আপনাকে মাঝে মাঝে পুরানো রেকর্ড আপডেট করতে হতে পারে বা সম্ভবত দেরিতে আসা বা অর্ডারের বাইরে থাকা ডেটা রেকর্ড করতে হবে।

  
  

এই কাজের চাপটি ঐতিহ্যগত অর্থে OLTP বা OLAP নয়। পরিবর্তে, এটি উভয়ের উপাদান অন্তর্ভুক্ত করে। তো এখন কি করা?

হাইব্রিড যান!

একটি সারি-ওরিয়েন্টেড ডেটাবেসে কলামার স্টোরেজ তৈরি করা

পূর্ববর্তী উদাহরণের মতো একটি কাজের চাপ পরিবেশন করতে, একটি একক ডাটাবেসে নিম্নলিখিতগুলি অন্তর্ভুক্ত করতে হবে:

• উচ্চ সন্নিবেশ হার বজায় রাখার ক্ষমতা, সহজেই প্রতি সেকেন্ডে হাজার হাজার লেখার মধ্যে

  
  

• দেরী বা অর্ডারের বাইরের ডেটা সন্নিবেশ করার জন্য সমর্থন, সেইসাথে বিদ্যমান ডেটা পরিবর্তন করার জন্য

  
  

• একটি বৃহৎ ডেটাসেট জুড়ে অগভীর-এবং-প্রশস্ত এবং গভীর-এবং-সংকীর্ণ প্রশ্নগুলিকে দক্ষতার সাথে প্রক্রিয়া করার জন্য যথেষ্ট নমনীয়তা

  
  

• স্টোরেজ দক্ষতা উন্নত করতে ডেটাবেসের আকার উল্লেখযোগ্যভাবে হ্রাস করতে সক্ষম একটি কম্প্রেশন প্রক্রিয়া

  
  

TimescaleDB তে (এবং তাই, PostgreSQL) কলামার কম্প্রেশন যোগ করার সময় আমরা এটি অর্জন করার লক্ষ্য রেখেছিলাম।

PostgreSQL কে একটি হাইব্রিড সারি-কলামার স্টোরে পরিণত করা হচ্ছে

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

তাত্ত্বিকভাবে, এর অর্থ হল TimescaleDB পোস্টগ্রেএসকিউএল-এর সারি-ভিত্তিক স্টোরেজ বিন্যাসেও লক করা হয়েছে, এর পরিমিত সংকোচনযোগ্যতা সহ। বাস্তবে, এমন কিছু নেই যা সামান্য প্রকৌশল সমাধান করতে পারে না।

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

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

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

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

 -- Find the most recent data from a specific device SELECT * FROM temperature_data WHERE device_id = 'A' ORDER BY timestamp DESC LIMIT 1; -- Find all devices in the past hour that are above a temperature threshold SELECT DISTINCT device_id, MAX(temperature) FROM temperature WHERE timestamp > NOW() - INTERVAL '1 hour'   AND temperature > 40.0;

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

 -- Add a compression policy to compress temperature data older than 1 week SELECT add_compression_policy('temperature_data', INTERVAL '7 days');

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

 -- Find daily max temperature for a specific device across past year SELECT time_bucket('1 day', timestamp) AS day, MAX(temperature) FROM temperature_data WHERE timestamp > NOW() - INTERVAL '1 year'   AND device_id = 'A' ORDER BY day; -- Find monthly average temperatures across all devices SELECT device_id, time_bucket('1 month', timestamp) AS month, AVG(temperature) FROM temperature_data WHERE timestamp < NOW() - INTERVAL '2 weeks' GROUP BY device_id, month ORDER BY month;

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

এই হাইব্রিড সারি-কলামার স্টোরেজ ইঞ্জিনটি বৃহৎ PostgreSQL ডাটাবেসে ক্যোয়ারী পারফরম্যান্স অপ্টিমাইজ করার জন্য একটি অবিশ্বাস্যভাবে শক্তিশালী টুল যা নাটকীয়ভাবে স্টোরেজ ফুটপ্রিন্ট কমিয়ে দেয়। আমরা এই নিবন্ধে পরে দেখব, ডেটাকে কলামার ফর্ম্যাটে রূপান্তরিত করে এবং বিশেষ কম্প্রেশন মেকানিজম প্রয়োগ করে, আমরা শুধুমাত্র আপনার বিশ্লেষণাত্মক প্রশ্নের গতি বাড়াতে সক্ষম নই, কিন্তু আমরা 98% পর্যন্ত কম্প্রেশন রেটও অর্জন করতে পারি। কল্পনা করুন এটি আপনার স্টোরেজ বিলের সাথে কী করে!

পর্দার পিছনে: সারি ডেটা থেকে সংকুচিত কলামার অ্যারে পর্যন্ত

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

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

এটি ব্যাখ্যা করার জন্য, এর মতো একটি টেবিল কল্পনা করা যাক:

 | Timestamp | Device ID | Status Code | Temperature | |-----------|-----------|-------------|-------------| | 12:00:01 | A | 0 | 70.11 | | 12:00:01 | B | 0 | 69.70 | | 12:00:02 | A | 0 | 70.12 | | 12:00:02 | B | 0 | 69.69 | | 12:00:03 | A | 0 | 70.14 | | 12:00:03 | B | 4 | 69.70 |

কম্প্রেশনের জন্য এই ডেটা প্রস্তুত করার জন্য, টাইমস্কেল প্রথমে এই ট্যাবুলার ডেটাটিকে একটি কলামার স্টোরে রূপান্তরিত করবে। ডেটার একটি ব্যাচ (~1,000 সারি) দেওয়া, প্রতিটি কলামের ডেটা একটি অ্যারেতে একত্রিত করা হয়, প্রতিটি অ্যারের উপাদান মূল সারিগুলির একটি থেকে মানের সাথে সম্পর্কিত। প্রক্রিয়াটি একটি একক সারিতে পরিণত হয়, প্রতিটি কলাম সেই ব্যাচ থেকে মানগুলির একটি অ্যারে সংরক্ষণ করে।

 | Timestamp | Device ID | Status Code | Temperature | |------------------------------|--------------------|--------------------|-------------------------------| | [12:00:01, 12:00:01, 12...] | [A, B, A, B, A, B] | [0, 0, 0, 0, 0, 4] | [70.11, 69.70, 70.12, 69....] |

এমনকি কম্প্রেশন অ্যালগরিদম প্রয়োগ করার আগে, এই বিন্যাসটি টাইমস্কেলের অভ্যন্তরীণ প্রতি-সারির ওভারহেডকে ব্যাপকভাবে হ্রাস করে সঞ্চয়স্থান সংরক্ষণ করে। PostgreSQL সাধারণত প্রতি সারিতে ওভারহেডের ~27 বাইট যোগ করে (যেমন, মাল্টি-ভার্সন কনকারেন্সি কন্ট্রোল বা MVCC এর জন্য)। সুতরাং এমনকি কোনো কম্প্রেশন ছাড়াই, যদি আমাদের উপরের স্কিমাটি হয়, বলুন, 32 বাইট, তাহলে একটি ব্যাচ থেকে 1,000 সারি ডেটা যা আগে [1,000 * (32 + 27)] ~= 59 কিলোবাইট নেয় এখন [1,000 * 32 + 27] ] ~= এই বিন্যাসে 32 কিলোবাইট ।

[ একপাশে : একটি বড় টেবিলকে ছোট ব্যাচগুলিতে "গ্রুপ করা" এবং তারপর প্রতিটি ব্যাচের কলামগুলিকে সংলগ্নভাবে সংরক্ষণ করার এই ধারণাটি আসলে Apache Parquet ফাইল বিন্যাসে "সারি গ্রুপগুলির" অনুরূপ পদ্ধতি। যদিও আমরা সত্যের পরেই সেই মিল উপলব্ধি করেছি!]

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

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

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

  
  

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

  
  

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

  
  

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

  
  

আমরা বিপরীত ক্রমে ডিকম্প্রেসিং ডেটা পরিচালনা করতে গরিলা এবং সিম্পল-8বি প্রসারিত করেছি, যা আমাদের ব্যাকওয়ার্ড স্ক্যান ব্যবহার করে এমন প্রশ্নের গতি বাড়ানোর অনুমতি দেয়।

আমরা এই টাইপ-নির্দিষ্ট কম্প্রেশনটিকে বেশ শক্তিশালী খুঁজে পেয়েছি: উচ্চ সংকোচনযোগ্যতা ছাড়াও, কিছু কৌশল যেমন গরিলা এবং ডেল্টা-অফ-ডেল্টা ডিকোডিংয়ের সময় LZ-ভিত্তিক কম্প্রেশনের চেয়ে 40x দ্রুততর হতে পারে, যা অনেক উন্নত ক্যোয়ারী কর্মক্ষমতার দিকে পরিচালিত করে। .

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

দক্ষতার সাথে সংকুচিত ডেটা অনুসন্ধান করা

পূর্ববর্তী অ্যারে-ভিত্তিক বিন্যাসটি একটি চ্যালেঞ্জ উপস্থাপন করে: যথা, কোন প্রশ্নের সমাধান করার জন্য ডাটাবেসটি কোন সারি আনতে এবং ডিকম্প্রেস করতে হবে?

আবার আমাদের তাপমাত্রা ডেটা উদাহরণ নেওয়া যাক। বেশ কয়েকটি প্রাকৃতিক ধরণের প্রশ্ন বারবার আবির্ভূত হয়: সময় সীমা অনুসারে ডেটা নির্বাচন এবং অর্ডার করা বা ডিভাইস আইডির উপর ভিত্তি করে ডেটা নির্বাচন করা (হয় WHERE ক্লজে বা GROUP BY এর মাধ্যমে)। কিভাবে আমরা এই ধরনের প্রশ্নগুলিকে দক্ষতার সাথে সমর্থন করতে পারি?

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

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

এর কলামার বিন্যাসে নির্দিষ্ট প্রশ্নের জন্য ডেটা দক্ষতার সাথে সনাক্তকরণ এবং ডিকম্প্রেস করার চ্যালেঞ্জ সমাধান করতে, টাইমস্কেল "সেগমেন্ট বাই" এবং "অর্ডার বাই" কলামের ধারণা প্রবর্তন করে .

কলাম দ্বারা segmentby দ্বারা সাধারণত জিজ্ঞাসা করা ডেটা গ্রুপ করা

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

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

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

 | Device ID | Timestamp | Status Code | Temperature | |-----------|--------------------------------|-------------|-----------------------| | A | [12:00:01, 12:00:02, 12:00:03] | [0, 0, 0] | [70.11, 70.12, 70.14] | | B | [12:00:01, 12:00:02, 12:00:03] | [0, 0, 4] | [69.70, 69.69, 69.70] |

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

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

 SELECT AVG(temperature) FROM sensor_data WHERE device_id = 'A'   AND time >= '2023-01-01'   AND time < '2023-02-01';

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

কলাম segmentby সংজ্ঞায়িত করা

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

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

আপনি যদি আর ডেটার 1,000 রেকর্ড ব্যাচ তৈরি করতে না পারেন তবে তার পরিবর্তে শুধুমাত্র পাঁচটি রেকর্ড থাকে যা একটি নির্দিষ্ট অংশের মধ্যে নির্দিষ্ট সেগমেন্টবাই কী আছে, এটি মোটেও ভালভাবে সংকুচিত হবে না!

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

 ALTER TABLE temperature_data SET (   timescaledb.compress,   timescaledb.compress_segmentby = 'device_id' );

orderby মাধ্যমে উন্নত ফাইন-টিউনিং

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

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

যাইহোক, সংকুচিত ডেটার সাথে পরিস্থিতি ভিন্ন: টাইমস্ট্যাম্পগুলি সংকুচিত হয় এবং সম্পূর্ণ ব্যাচগুলিকে ডিকম্প্রেস না করে অ্যাক্সেস করা যায় না। প্রতিটি পৃথক টাইমস্ট্যাম্পে একটি সূচক তৈরি করা বিপরীতমুখী হবে, কারণ এটি অত্যধিক বড় হয়ে কম্প্রেশনের সুবিধাগুলিকে অস্বীকার করতে পারে।

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

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

TimescaleDB-এর বিভাজন এবং অর্ডারের সংমিশ্রণ উল্লেখযোগ্যভাবে সাধারণ সময়-সিরিজ এবং বিশ্লেষণাত্মক প্রশ্নের কর্মক্ষমতা বাড়ায়। এই অপ্টিমাইজেশানটি উভয় সময় ( orderby এর মাধ্যমে) এবং স্থান ( segmentby মাধ্যমে) জুড়ে নিশ্চিত করে যে TimescaleDB কার্যকরভাবে বৃহৎ-স্কেল টাইম-সিরিজ ডেটা পরিচালনা করে এবং অনুসন্ধান করে, কম্প্রেশন এবং অ্যাক্সেসযোগ্যতার মধ্যে একটি অপ্টিমাইজ করা ভারসাম্য অফার করে।

টাইমস্কেল এর কম্প্রেশন বিবর্তন

আমাদের কম্প্রেশন ডিজাইনের প্রথম সংস্করণটি 2019 সালে TimescaleDB 1.5 সহ প্রকাশিত হয়েছিল। অনেক রিলিজ পরে, টাইমস্কেল সংকোচন একটি দীর্ঘ পথ এসেছে।

আমাদের প্রাথমিক প্রকাশের প্রধান সীমাবদ্ধতাগুলির মধ্যে একটি হল যে আমরা ডেটার আর কোনো পরিবর্তনের অনুমতি দিইনি—যেমন, INSERTs, UPDATEs, DELETEs-একবার ডেটা সংকুচিত হয়ে যাওয়ার পরে সম্পূর্ণ হাইপারটেবল খণ্ডটি যেখানে এটি ছিল তা ম্যানুয়ালি ডিকম্প্রেস না করে।

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

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

আজ, এই সমস্ত সীমাবদ্ধতা মুছে ফেলা হয়েছে। টাইমস্কেল এখন আপনাকে সম্পূর্ণ ডেটা ম্যানিপুলেশন ল্যাঙ্গুয়েজ (DML) এবং ডেটা ডেফিনিশন ল্যাঙ্গুয়েজ (DDL) ক্রিয়াকলাপগুলি সংকুচিত ডেটার উপর সম্পাদন করতে দেয়:

• আপনি সংকুচিত অংশগুলির উপর ডেটা সন্নিবেশ করতে পারেন (দারুণ কর্মক্ষমতা সহ)।

• আপনি আপডেট, UPSERT এবং ডিলিট করতে পারেন।

  
  

• আপনি ডিফল্ট মান সহ কলাম যোগ করতে পারেন।

  
  

• আপনি কলামের নাম পরিবর্তন এবং ড্রপ করতে পারেন।

  
  

সংকুচিত ডেটার উপর ডেটা পরিবর্তন স্বয়ংক্রিয় করতে (আমাদের ব্যবহারকারীদের জন্য এটিকে নির্বিঘ্ন করতে), আমরা একটি "স্টেজিং এরিয়া" প্রবর্তন করে আমাদের কম্প্রেশন পদ্ধতির পরিবর্তন করেছি - মূলত, একটি ওভারল্যাপিং অংশ যা কম্প্রেসড থাকে না এবং যেখানে আমরা "অসংকুচিত ডেটা" এর অধীনে অপারেশন করি পর্দা.

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

স্টেজিং এরিয়ার মাধ্যমে এই ডিজাইনটি INSERT গুলিকে আনকম্প্রেসড খণ্ডগুলিতে ঢোকানোর মতো দ্রুত করে তোলে কারণ এটি সত্যিই ঘটছে (যখন আপনি একটি সংকুচিত অংশে ঢোকান, আপনি এখন স্টেজিং এলাকায় লিখছেন)। এটি আমাদের সরাসরি আপডেট, UPSERT এবং ডিলিট সমর্থন করার অনুমতি দেয়: যখন একটি মান পরিবর্তন করার প্রয়োজন হয়, তখন ইঞ্জিন সংকুচিত ডেটার একটি প্রাসঙ্গিক অংশকে স্টেজিং এরিয়াতে নিয়ে যায়, এটিকে ডিকম্প্রেস করে, পরিবর্তন করে এবং (অসিঙ্ক্রোনাসভাবে) এটিকে আবার সরিয়ে দেয়। সংকুচিত আকারে প্রধান টেবিলে।

(ডেটার এই অঞ্চলটি সাধারণত 1,000 পর্যন্ত মানের সংকুচিত "মিনি-ব্যাচ" এর স্কেলে কাজ করে যা অন্তর্নিহিত PostgreSQL স্টোরেজে একটি "সারি" ধারণ করে যাতে পরিমার্জন সমর্থন করার জন্য সংকুচিত হওয়া প্রয়োজন এমন ডেটার পরিমাণ কমিয়ে আনা যায়।)

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

শেষ ফলাফল: বড় পোস্টগ্রেএসকিউএল ডেটাবেসের জন্য দ্রুত প্রশ্ন, কম সঞ্চয়স্থানের পদচিহ্ন

এই মুহুর্তে, পরবর্তী যৌক্তিক প্রশ্ন জিজ্ঞাসা করা হল: শেষ ফলাফল কি? কিভাবে কম্প্রেশন ক্যোয়ারী কর্মক্ষমতা প্রভাবিত করে, এবং এটি ব্যবহার করে আমি কত ডিস্কের আকার সংরক্ষণ করতে পারি?

ক্যোয়ারী কর্মক্ষমতা আগে বনাম. পরে কম্প্রেশন

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

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

নিম্নলিখিত প্রশ্নটি বিবেচনা করুন, একটি নির্দিষ্ট সময়সীমার মধ্যে ট্যাক্সি ডেটাসেটের একটি উপসেট থেকে সর্বোচ্চ ভাড়ার পরিমাণ জিজ্ঞাসা করুন:

 SELECT max(fare_amount) FROM demo.yellow_compressed_ht WHERE   tpep_pickup_datetime >= '2019-09-01' AND   tpep_pickup_datetime <= '2019-12-01';

সংকুচিত ডেটাসেটের বিরুদ্ধে চালানো হলে, ক্যোয়ারী কার্যকর করার সময় দাঁড়ায় 4.7 সেকেন্ড। আমরা একটি ছোট, অপ্টিমাইজ করা টেস্টিং পরিষেবা ব্যবহার করছি এবং লক্ষ লক্ষ সারি অনুসন্ধান করছি, তাই এই পারফরম্যান্সটি সেরা নয়৷ কিন্তু ডেটা সংকুচিত করার পরে, প্রতিক্রিয়া সময় 77.074 মিলিসেকেন্ডে নেমে আসে:

আরেকটি উদাহরণ শেয়ার করা যাক। এই প্রশ্নটি একটি নির্দিষ্ট সময়সীমার মধ্যে একটি নির্দিষ্ট রেট কোড সহ ট্রিপের সংখ্যা গণনা করে:

 SELECT COUNT(*) FROM demo.yellow_compressed_ht WHERE   tpep_pickup_datetime >= '2019-09-01' AND   tpep_pickup_datetime <= '2019-12-01' AND   "RatecodeID" = 99;

সংকুচিত ডেটার বিপরীতে কার্যকর করা হলে, এই ক্যোয়ারীটি সম্পূর্ণ হতে 1.6 সেকেন্ড সময় লাগবে। সংকুচিত ডেটার বিরুদ্ধে চলমান একই প্রশ্নটি মাত্র 18.953 মিলিসেকেন্ডে শেষ হয়। আবার, আমরা একটি তাত্ক্ষণিক উন্নতি দেখতে! এগুলি কেবল দ্রুত উদাহরণ, তবে তারা আপনার প্রশ্নের গতি বাড়ানোর জন্য কতটা শক্তিশালী কম্প্রেশন হতে পারে তা ব্যাখ্যা করে।

কিভাবে টাইমস্কেলের কম্প্রেশন PostgreSQL স্টোরেজের আকার হ্রাস করে: বাস্তব-বিশ্বের উদাহরণ

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

এই স্টোরেজ সঞ্চয়গুলি সরাসরি অর্থ সঞ্চয় করে: টাইমস্কেল প্ল্যাটফর্ম স্টোরেজের জন্য ব্যবহার-ভিত্তিক মূল্য ব্যবহার করে , তাই আপনার সঞ্চয়স্থান সঙ্কুচিত হলে, আপনার বিল আনুপাতিকভাবে সঙ্কুচিত হবে।

আপনি শেষ পর্যন্ত যে কম্প্রেশন রেট অর্জন করবেন তা আপনার ডেটা টাইপ এবং অ্যাক্সেস প্যাটার্ন সহ বিভিন্ন কারণের উপর নির্ভর করে। কিন্তু আপনি দেখতে পাচ্ছেন, টাইমস্কেল কম্প্রেশন অত্যন্ত দক্ষ হতে পারে- এমনকি আমরা 96% কম্প্রেশন সহ আমাদের গ্রাহক-মুখী অন্তর্দৃষ্টি পণ্যকে শক্তি দিতে অভ্যন্তরীণভাবে এটি ব্যাপকভাবে ব্যবহার করি .

আমাদের দল আপনাকে যতটা সম্ভব অর্থ সাশ্রয় করতে আপনাকে সূক্ষ্ম-টিউন কম্প্রেশনে সাহায্য করতে পারে, তাই যোগাযোগ করতে দ্বিধা করবেন না .

"সংকোচনের সাথে, আমরা গড়ে 97 শতাংশ হ্রাস [ডিস্কের আকারে] দেখেছি।"

(মাইকেল গ্যাগলিয়ার্ডো, এনডস্ট্রিয়াল)

“আমরা টাইমস্কেলের কম্প্রেশন অনুপাতকে একেবারে অসাধারণ বলে খুঁজে পেয়েছি! আমরা বর্তমানে 26-এর বেশি কম্প্রেশন রেশিওতে রয়েছি, আমাদের সমস্ত ডেটা সঞ্চয় করার জন্য প্রয়োজনীয় ডিস্কের স্থানকে ব্যাপকভাবে হ্রাস করছি।"

(নিকোলাস কুইন্টিন, অক্টেভ)

"টাইমসকেলের কম্প্রেশন বিজ্ঞাপনের মতোই ভাল ছিল, যা আমাদের অন্তর্নিহিত হাইপারটেবিলে আমাদের +90% [ডিস্ক] স্থান সঞ্চয় দিয়েছে।"

(পাওলো বার্গ্যান্টিনো, মিটার গ্রুপ)

কম্প্রেশন এবং টায়ার্ড স্টোরেজ: টাইমস্কেল স্টোরেজ লাইফসাইকেল

সবশেষে, আমরা টাইমস্কেলের টায়ার্ড স্টোরেজের উল্লেখ ছাড়া এই নিবন্ধটি শেষ করতে পারিনি, যা আমরা সবেমাত্র সাধারণ উপলব্ধতায় চালু করেছি .

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

এই স্বল্প-মূল্যের স্টোরেজ স্তরটির ডেটার জন্য প্রতি GB/মাস $0.021 এর সমতল মূল্য রয়েছে—Amazon S3-এর চেয়ে সস্তা—আপনাকে খরচের একটি ভগ্নাংশের জন্য আপনার PostgreSQL ডাটাবেসে অনেকগুলি টিবি রাখার অনুমতি দেয়৷

টাইমস্কেল প্ল্যাটফর্মে আমাদের টায়ার্ড স্টোরেজ ব্যাকএন্ড এইভাবে কাজ করে এবং কম্প্রেশনের সাথে লো-স্টোরেজ টিয়ার কীভাবে কাজ করে:

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

  
  

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

  
  

• একবার আপনার ডাটাবেসে এই ডেটা আর রাখতে হবে না, আপনি এটি একটি ধারণ নীতির মাধ্যমে ফেলে দিতে পারেন। উদাহরণস্বরূপ, আপনি পাঁচ বছর পরে সমস্ত ডেটা মুছে ফেলতে পারেন।

PostgreSQL এর সাথে থাকুন

আমরা পোস্টগ্রেসকে কলামার কম্প্রেশন ক্ষমতা যুক্ত করে একটি কার্যকর ডাটাবেস কম্প্রেশন মেকানিজম দিয়েছি। আজকের ডেটা-ইনটেনসিভ বিশ্বে PostgreSQL ডাটাবেসগুলিকে স্কেল করার জন্য এটি একটি অপরিহার্য বৈশিষ্ট্য: কম্প্রেশন ডিস্কের ব্যবহারে বিশাল সঞ্চয় (সস্তার জন্য আরও ডেটা সঞ্চয় করা) এবং কর্মক্ষমতা উন্নতি (মিলিসেকেন্ডে বৃহৎ পরিমাণে বিশ্লেষণাত্মক প্রশ্নগুলি চালানো) জন্য অনুমতি দেয়।

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

কিন্তু অনেক কলামার ইঞ্জিনের বিপরীতে, টাইমস্কেল ACID লেনদেনের শব্দার্থবিদ্যাকে সমর্থন করে এবং সংকুচিত কলামার ডেটাতে পরিবর্তনের (INSERTs, UPDATEs, UPSERTs, DELETE) জন্য সরাসরি সমর্থন করে। যেহেতু "লেনদেনমূলক কাজের জন্য একটি ডাটাবেস, বিশ্লেষণের জন্য আরেকটি" এর পুরানো মডেলটি অপ্রচলিত, অনেক আধুনিক অ্যাপ্লিকেশনগুলি উভয় প্যাটার্নের সাথে মানানসই কাজের চাপ চালায়। তাহলে কেন দুটি পৃথক ডাটাবেস বজায় রাখবেন যখন আপনি এটি পোস্টগ্রেএসকিউএল-এ করতে পারেন?

টাইমস্কেল আপনাকে PostgreSQL শুরু করতে, PostgreSQL দিয়ে স্কেল করতে, PostgreSQL এর সাথে থাকার অনুমতি দেয়।

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

- কার্লোটা সোটো এবং মাইক ফ্রিডম্যান লিখেছেন।