paint-brush
ডায়নামিক পোস্টগ্রেএসকিউএল-এর সাথে দেখা করুন: ক্লাউড ডেটাবেসের প্রাকৃতিক বিবর্তনদ্বারা@timescale
3,388 পড়া
3,388 পড়া

ডায়নামিক পোস্টগ্রেএসকিউএল-এর সাথে দেখা করুন: ক্লাউড ডেটাবেসের প্রাকৃতিক বিবর্তন

দ্বারা Timescale10m2023/11/08
Read on Terminal Reader

অতিদীর্ঘ; পড়তে

টাইমস্কেল ডাইনামিক পোস্টগ্রেএসকিউএল চালু করেছে, যা প্রভিশনড এবং সার্ভারহীন ডাটাবেসের সমস্যা সমাধান করে। এটি একটি পূর্বনির্ধারিত সীমার মধ্যে তাত্ক্ষণিকভাবে গণনা করে যাতে আপনি যা ব্যবহার করেন তার জন্য আপনি শুধুমাত্র অর্থ প্রদান করেন। গ্রাহকরা 10-20% বনাম RDS এবং 50-70% বনাম অরোরা সার্ভারহীন সাশ্রয় করে৷
featured image - ডায়নামিক পোস্টগ্রেএসকিউএল-এর সাথে দেখা করুন: ক্লাউড ডেটাবেসের প্রাকৃতিক বিবর্তন
Timescale HackerNoon profile picture


আজ থেকে শুরু, আপনি টাইমস্কেলে ডায়নামিক পোস্টগ্রেএসকিউএল ডাটাবেস তৈরি করতে পারেন .


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


এর ফলে অতুলনীয় মূল্যের কার্যকারিতা দেখা যায়: উৎপাদন কাজের লোড চালানো গ্রাহকরা PostgreSQL-এর জন্য AWS RDS থেকে মাইগ্রেট করার সময় 10-20% এবং AWS Aurora সার্ভারলেস থেকে মাইগ্রেট করার সময় 50-70% সাশ্রয় করবে।


আপনি আজ ডায়নামিক পোস্টগ্রেএসকিউএল চেষ্টা করে দেখতে পারেন। আমরা একটি বিনামূল্যে ট্রায়াল অফার করি—কোন ক্রেডিট কার্ডের প্রয়োজন নেই—যা আপনাকে 30 দিনের জন্য প্ল্যাটফর্মে সম্পূর্ণ অ্যাক্সেস দেয়৷


একটি ডায়নামিক PostgreSQL পরিষেবা তৈরি করতে, টাইমস্কেলে লগ ইন করার সময় শুধুমাত্র PostgreSQL বিকল্পটি নির্বাচন করুন:


আপনি এখন টাইমস্কেল প্ল্যাটফর্মে টাইম সিরিজ পরিষেবা এবং পোস্টগ্রেএসকিউএল পরিষেবা তৈরি করতে পারেন


আপনার আবেদন সবসময় চালু থাকে, কেন আপনার ডাটাবেস হওয়া উচিত নয়?


ভবিষ্যতে স্বাগতম.


সমস্যা 1: বিকাশকারীরা তাদের প্রয়োজনের চেয়ে অনেক বেশি গণনা করে

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


আমরা একটি জিনিস শিখেছি যে বিকাশকারীরা প্রায়শই তাদের প্রকৃতপক্ষে প্রয়োজনের তুলনায় অনেক বেশি গণনা প্রদান করে।


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




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


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


সমস্যা 2: সার্ভারহীন ডাটাবেস উৎপাদন কাজের চাপের জন্য কম পড়ে

আপনাদের মধ্যে কেউ কেউ হয়তো জিজ্ঞাসা করছেন, "সার্ভারহীন ডাটাবেস সম্পর্কে কি?"


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


বিকাশকারীরা তখন নিজেদেরকে জিজ্ঞাসা করেছিল, "যখন আমি এটি ব্যবহার করছি না তখন কেন আমার ডাটাবেসের জন্য অর্থ প্রদান করব?" প্রকৃত প্রশ্ন ভালো: নষ্ট সম্পদ একটি বিশাল ডাটাবেস সমস্যা। এবং একটি নির্দিষ্ট সার্ভার উদাহরণে (বলুন, একটি db.m6gd.2xlarge) একটি AWS RDS ডাটাবেসের ব্যবস্থা করার অনুশীলন আধুনিক বা নমনীয় বলে মনে হয় না: স্থির CPU, স্থায়ী মেমরি, স্থায়ী স্থানীয় ডিস্ক। বেশিরভাগ সময়ই এর বেশির ভাগই কম ব্যবহার করা হয়।


তবে এখানেই জিনিসগুলি জটিল হয়ে যায়: ডাটাবেসগুলি ল্যাম্বডা ফাংশন থেকে খুব আলাদা।


সার্ভারহীন ডাটাবেসগুলি আজ দুটি প্রধান কারণে বেশিরভাগ উত্পাদন কাজের চাপের জন্য ভুল:


  • সার্ভারবিহীন ডাটাবেসগুলি উপরে এবং নিচের স্কেলিং করার জন্য চরমের উপর ফোকাস করে, এমনকি শূন্য পর্যন্ত।

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


আসুন "স্কেল থেকে শূন্য" এর আলোচিত বিষয় নিয়ে আলোচনা করে শুরু করা যাক। বাস্তবতা হল যে বেশিরভাগ উত্পাদন ডাটাবেসের প্রয়োজন নেই এবং আসলে শূন্য থেকে স্কেলিং করে উপকৃত হবে না।


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


কিন্তু আপনার উৎপাদন ডাটাবেসের জন্য এবং আরো কর্মক্ষম সেটিংসে? আপনি শূন্য স্কেল করতে চান না.


শূন্যে স্কেল করার মানে হল রিস্টার্ট করার সময় একটি "কোল্ড বুট": খালি ডাটাবেস ভাগ করা বাফার, খালি OS ক্যাশে, খালি ক্যাটালগ ক্যাশে (PostgreSQL এর ক্ষেত্রে)।


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


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


সুতরাং, অনেক পরিস্থিতিতে, সার্ভারহীন ডাটাবেসগুলি উচ্চতর এবং অপ্রত্যাশিত মূল্যের সাথে শেষ হয়।


উদাহরণস্বরূপ, আপনি যদি Aurora Serverless-এর সাথে Amazon RDS-এর তুলনা করেন, আপনি দেখতে পাবেন যে 8 vCPU কম্পিউট এবং 500 GB স্টোরেজ সার্ভারলেস RDS ($1,097 বনাম $593) থেকে 85% বেশি ব্যয়বহুল। এবং এটি অরোরা I/O অপ্টিমাইজড এবং এর আরও অনুমানযোগ্য স্টোরেজ দাম ব্যবহার করছে, যা মাত্র ছয় মাস আগে চালু হয়েছে। (যদিও, এখানেও, আমাদের এখনও এর প্রকৃত গণনা ক্ষমতা অনুমান করতে হবে, অরোরা সার্ভারলেস মূল্যগুলি অস্বচ্ছ "অরোরা ক্যাপাসিটি ইউনিট" বিভ্রান্ত করে, যা আমাদের সর্বোত্তম-অনুমানিত অনুমান হল 1 ACU = 0.25 vCPU।)


সম্পাদকের দ্রষ্টব্য: আমরা শীঘ্রই সেই ফলাফলগুলিকে সমর্থন করে একটি সম্পূর্ণ বেঞ্চমার্ক প্রকাশ করব৷ সাথে থাকুন.


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


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


বিকাশকারীর দ্বিধা


এখানেই আমরা শেষ করেছি:


  • অনেক ডেভেলপার এখনও তাদের নির্ভরযোগ্য কর্মক্ষমতা, নিয়ন্ত্রণ এবং বোধগম্যতার কারণে উত্পাদন অ্যাপ্লিকেশনগুলির জন্য প্রভিশন সহ ঐতিহ্যগত DBaaS পরিষেবাগুলি বেছে নেয়, কিন্তু অতিরিক্ত ব্যবস্থার প্রয়োজনীয়তা থেকে উদ্ভূত বর্জ্যকে ঘৃণা করে।


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


নিজেদের বিকাশকারী হিসাবে, এই বিকল্পগুলির কোনটিই খুব আকর্ষণীয় নয়! আরও ভালো করার সুযোগ আছে।


সমাধান: ডায়নামিক পোস্টগ্রেএসকিউএল প্রবর্তন করা হচ্ছে

এজন্য আমরা Dynamic PostgreSQL তৈরি করেছি।


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


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


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


আপনার CPU পরিসরের বেস (ন্যূনতম) ঠিক প্রভিশন করা DBaaS মডেলের মতো কাজ করে: আপনার অ্যাপ্লিকেশন চালানোর জন্য সর্বনিম্ন CPU সর্বদা আপনার পরিষেবাতে নিবেদিত থাকে। আপনার লোড বাড়ার সাথে সাথে-হয় আপনার বাহ্যিক অ্যাপ্লিকেশনের চাহিদার কারণে বা এমনকি মাঝে মাঝে অভ্যন্তরীণ ডাটাবেস কাজ যেমন ক্রমবর্ধমান ব্যাকআপ বা টেবিল অটো-ভ্যাকুয়ামিং-এর কারণে-আপনার ডাটাবেস শূন্য বিলম্বের সাথে আপনার CPU পরিসরের সর্বোচ্চ (সর্বোচ্চ) পর্যন্ত ব্যবহার করতে পারে।


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


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





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


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


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



আপনার টাকা বাঁচাতে ইঞ্জিনিয়ারড

আমরা বর্তমানে আপনার কাজের চাপের আকারের উপর ভিত্তি করে পাঁচটি ভিন্ন কম্পিউট রেঞ্জ অফার করি, আপনার তাত্ক্ষণিক ব্যবহার নির্বিশেষে রেঞ্জের জন্য আপনি প্রাপ্ত সংশ্লিষ্ট কার্যকর মেমরি সহ।



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


আমরা আপনার অর্থ বাঁচাতে ইচ্ছাকৃতভাবে Dynamic PostgreSQL তৈরি করেছি। প্রোডাকশন ওয়ার্কলোড চালানো গ্রাহকরা সাধারণত PostgreSQL এর জন্য AWS RDS থেকে মাইগ্রেট করার সময় 10-20% এবং AWS Aurora সার্ভারলেস থেকে মাইগ্রেট করার সময় 50-70% সাশ্রয় করে।


মাসের শেষে, আপনার বিলে দুটি সহজ, সহজে বোঝা যায় এমন মেট্রিক থাকে: (1) আপনার কম্পিউট খরচ, আপনার ঘন্টার বেস কম্পিউট হিসাবে বিল করা হয় এবং এর উপরে যেকোন ভগ্নাংশ CPU ব্যবহার কিন্তু আপনার সর্বোচ্চের চেয়ে বেশি নয়; এবং (2) আপনার স্টোরেজ খরচ, GB-ঘন্টায় ডেটা খরচ হিসাবে বিল করা হয়। পরিমাপ বা বোঝার জন্য কোন নতুন মেট্রিক্স বা প্রাপ্ত একক নেই।


আপনি যা ব্যবহার করেন তার জন্য শুধু অর্থ প্রদান করুন। শূন্য অতিরিক্ত খরচ বা লুকানো ফি.


  • গণনা: অনুমানযোগ্য, একটি সংজ্ঞায়িত পরিসরের উপর ভিত্তি করে

  • সঞ্চয়স্থান: আপনি যা সঞ্চয় করেন তার জন্য শুধুমাত্র অর্থ প্রদান করুন


কোন অপচয় সম্পদ. কোন অতিরিক্ত অর্থ প্রদান. রাতে ঘুম হয় না। একটি বিল আপনি আপনার বসকে ব্যাখ্যা করতে পারেন।


আজই চেষ্টা করে দেখুন

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


আপনি এখন টাইমস্কেল প্ল্যাটফর্মে টাইম সিরিজ পরিষেবা এবং পোস্টগ্রেএসকিউএল পরিষেবা তৈরি করতে পারেন


প্ল্যাটফর্মটি এখন আপনার ডাটাবেসের নির্দিষ্ট চাহিদা মেটানোর জন্য দুটি ধরনের পরিষেবা প্রদান করে:


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


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


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




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



যদি আপনার কোন প্রশ্ন থাকে তাহলে, আমাদের কাছে পৌঁছান . আমরা আপনার প্রতিক্রিয়া শুনতে এবং আপনার PostgreSQL ব্যবহারের ক্ষেত্রে (টাইম সিরিজ বা না) আপনাকে সাহায্য করতে চাই!


এটা মাত্র শুরু। আমরা পরপর তিনটি লঞ্চ সপ্তাহের মাঝখানে আছি, এবং এটি মাত্র 2 সপ্তাহের শুরু: ডায়নামিক ইনফ্রা সপ্তাহ। এই সপ্তাহে, এই মাসে, এই বছর এবং আগামী অনেক বছরগুলির জন্য আরও কিছুর জন্য সাথে থাকুন৷ 🙂


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