সার্ভারহীন ডাটাবেসের দিকে - কিভাবে এবং কেন

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

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

এই নিবন্ধে, আমার রিপোর্ট উপর ভিত্তি করে অনলাইন উৎসব RIT++2020, আমি এই প্রশ্নের উত্তর দেব. প্রতিবেদনটির একটি ভিডিও সংস্করণ এখানে উপলব্ধ ইউটিউব.

সাধারণভাবে পরিচিত ডাটাবেস 2020

এটা 2020, আমি চারপাশে তাকিয়ে তিন ধরনের ডাটাবেস দেখেছি।

প্রথম প্রকার- ক্লাসিক OLTP ডাটাবেস: PostgreSQL, SQL সার্ভার, Oracle, MySQL। এগুলি অনেক আগে লেখা হয়েছিল, কিন্তু এখনও প্রাসঙ্গিক কারণ তারা বিকাশকারী সম্প্রদায়ের কাছে খুব পরিচিত৷

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

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

এই ধরনের ডাটাবেসের উদাহরণ:

• AWS RDS হল PostgreSQL/MySQL-এর জন্য একটি পরিচালিত মোড়ক।
• DynamoDB হল একটি ডকুমেন্ট ভিত্তিক ডাটাবেসের একটি AWS অ্যানালগ, Redis এবং MongoDB এর মতো।
• Amazon Redshift হল একটি পরিচালিত বিশ্লেষণাত্মক ডাটাবেস।

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

বিঃদ্রঃ. উদাহরণগুলি AWS পরিবেশের জন্য নেওয়া হয়েছে, তবে তাদের অ্যানালগগুলি Microsoft Azure, Google Cloud বা Yandex.Cloud-এও বিদ্যমান।

এই সম্পর্কে নতুন কি? 2020 সালে, এর কিছুই নয়।

সার্ভারহীন ধারণা

2020 সালে বাজারে সত্যিই নতুন যা আছে তা হল সার্ভারহীন বা সার্ভারহীন সমাধান।

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

অন্য কোন উপায আছে কি? সার্ভারহীন সেবা দিয়ে আপনি করতে পারেন।

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

আমি ছবি দিয়ে এই পদ্ধতির ব্যাখ্যা করার চেষ্টা করব।


ক্লাসিক স্থাপনা. আমরা একটি নির্দিষ্ট লোড সঙ্গে একটি পরিষেবা আছে. আমরা দুটি দৃষ্টান্ত উত্থাপন করি: শারীরিক সার্ভার বা AWS-এ দৃষ্টান্ত। বাহ্যিক অনুরোধগুলি এই দৃষ্টান্তগুলিতে পাঠানো হয় এবং সেখানে প্রক্রিয়া করা হয়।

আপনি ছবিতে দেখতে পাচ্ছেন, সার্ভারগুলি সমানভাবে নিষ্পত্তি করা হয় না। একটি 100% ব্যবহার করা হয়েছে, দুটি অনুরোধ রয়েছে এবং একটি মাত্র 50% - আংশিকভাবে নিষ্ক্রিয়৷ যদি তিনটি অনুরোধ না আসে তবে 30টি, তবে পুরো সিস্টেমটি লোডের সাথে মানিয়ে নিতে সক্ষম হবে না এবং ধীর হতে শুরু করবে।

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

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

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

এই সব ডাটাবেসের সাধারণ সীমাবদ্ধতা কি? এগুলি একটি ক্রমাগত ব্যবহৃত ক্লাউড বা হার্ডওয়্যার সার্ভারের (বা একাধিক সার্ভার) খরচ। আমরা একটি ক্লাসিক বা পরিচালিত ডাটাবেস ব্যবহার করি কিনা তা বিবেচ্য নয়, আমাদের Devops এবং একজন প্রশাসক থাকুক বা না থাকুক, আমরা এখনও হার্ডওয়্যার, বিদ্যুৎ এবং ডেটা সেন্টার ভাড়া 24/7 এর জন্য অর্থ প্রদান করি। যদি আমাদের একটি ক্লাসিক বেস থাকে তবে আমরা মাস্টার এবং স্লেভের জন্য অর্থ প্রদান করি। যদি এটি একটি উচ্চ লোড শার্ড ডাটাবেস হয়, আমরা 10, 20 বা 30 সার্ভারের জন্য অর্থ প্রদান করি এবং আমরা ক্রমাগত অর্থ প্রদান করি।

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

সার্ভারহীন ডাটাবেস - তত্ত্ব

2020 সালের প্রশ্ন: ডাটাবেস সার্ভারহীন করা কি সম্ভব? সবাই সার্ভারহীন ব্যাকএন্ড সম্পর্কে শুনেছে... আসুন ডাটাবেস সার্ভারহীন করার চেষ্টা করি?

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

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

তদনুসারে, ধারণাটি হল: যদি যুক্তির অংশটি রাষ্ট্রহীন মৃত্যুদন্ডের অনুমতি দেয় তবে কেন বেসটিকে রাষ্ট্রীয় এবং রাষ্ট্রহীন অংশে বিভক্ত করা হবে না।

OLAP সমাধানের জন্য সার্ভারহীন

ব্যবহারিক উদাহরণ ব্যবহার করে একটি ডাটাবেসকে স্টেটফুল এবং স্টেটলেস অংশে কাটা কেমন হতে পারে তা দেখা যাক।

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

এই স্কিমে, ETL শর্তসাপেক্ষে একবার সঞ্চালিত হয়। তারপরে আপনাকে ক্রমাগত সার্ভারগুলির জন্য অর্থ প্রদান করতে হবে যেগুলির উপর ডাটাবেসটি ETL দিয়ে ভরা ডেটা দিয়ে চালিত হয়, যাতে প্রশ্নগুলি পাঠানোর মতো কিছু থাকে৷

আসুন AWS Athena Serverless এ বাস্তবায়িত একটি বিকল্প পদ্ধতির দিকে তাকাই। কোন স্থায়ীভাবে ডেডিকেটেড হার্ডওয়্যার নেই যেখানে ডাউনলোড করা ডেটা সংরক্ষণ করা হয়। এটার পরিবর্তে:

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

এই আর্কিটেকচারে, আমরা শুধুমাত্র অনুরোধটি কার্যকর করার প্রক্রিয়ার জন্য অর্থ প্রদান করি। কোন অনুরোধ - কোন খরচ.

এটি একটি কার্যকরী পদ্ধতি এবং এটি শুধুমাত্র অ্যাথেনা সার্ভারলেস নয়, রেডশিফ্ট স্পেকট্রামেও (AWS-এ) প্রয়োগ করা হয়।

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

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

OLTP সমাধানের জন্য সার্ভারহীন

পূর্ববর্তী উদাহরণটি OLAP (বিশ্লেষণমূলক) কাজগুলিকে দেখেছে। এবার আসুন OLTP এর কাজগুলো দেখি।

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

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

অরোরার মধ্যে অরোরা ক্যাপাসিটি ইউনিট, ACU এর ধারণা রয়েছে। এটি (শর্তগতভাবে) একটি উদাহরণ (সার্ভার)। প্রতিটি নির্দিষ্ট ACU একজন প্রভু বা দাস হতে পারে। প্রতিটি ক্যাপাসিটি ইউনিটের নিজস্ব RAM, প্রসেসর এবং ন্যূনতম ডিস্ক রয়েছে। তদনুসারে, একজন মাস্টার, বাকিরা কেবলমাত্র প্রতিলিপি পাঠ করা হয়।

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

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

অরোরা সার্ভারলেস বেস রিডিং লোড স্কেল করতে পারে। কিন্তু ডকুমেন্টেশন সরাসরি এটা বলে না। এটা মনে হতে পারে যে তারা একটি মাল্টি-মাস্টার উত্তোলন করতে পারে। কোন জাদু নেই.

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

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

কোন জাদু নেই - এটি নিয়মিত PostgreSQL। কিন্তু মেশিন যোগ করার এবং তাদের সংযোগ বিচ্ছিন্ন করার প্রক্রিয়াটি আংশিকভাবে স্বয়ংক্রিয়।

ডিজাইন দ্বারা সার্ভারহীন

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

এই বেসটিকে স্নোফ্লেক বলা হয়। এটিতে তিনটি কী ব্লক রয়েছে।

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

দ্বিতীয় ব্লকটি গণনার জন্য ভার্চুয়াল কম্পিউটিং ক্লাস্টারগুলির একটি সেট (চিত্রে নীল বৃত্তের একটি সেট রয়েছে)।

তৃতীয় ব্লকটি S3 এর উপর ভিত্তি করে একটি ডেটা স্টোরেজ সিস্টেম। S3 হল AWS-এ মাত্রাবিহীন অবজেক্ট স্টোরেজ, ব্যবসার জন্য মাত্রাবিহীন ড্রপবক্সের মতো।

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

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

এর পরে, পরিষেবাটি কম্পিউটিং ক্লাস্টার চালু করা শুরু করে। একটি কম্পিউটিং ক্লাস্টার হল সার্ভারের একটি ক্লাস্টার যা গণনা সম্পাদন করে। অর্থাৎ, এটি একটি ক্লাস্টার যা 1 সার্ভার, 2 সার্ভার, 4, 8, 16, 32 ধারণ করতে পারে - যতগুলি আপনি চান। আপনি একটি অনুরোধ নিক্ষেপ করুন এবং এই ক্লাস্টারটির লঞ্চ অবিলম্বে শুরু হবে। এটা সত্যিই সেকেন্ড লাগে.

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

প্রতিটি SQL ক্যোয়ারী শুধুমাত্র পূর্বে লোড করা ডেটা থেকে সমষ্টি পড়তে পারে না, কিন্তু ডাটাবেসে নতুন ডেটা লোড/জেনারেট করতে পারে। অর্থাৎ, এটি একটি ক্যোয়ারী হতে পারে যা, উদাহরণস্বরূপ, অন্য টেবিলে নতুন রেকর্ড সন্নিবেশ করায়, যা কম্পিউটিং ক্লাস্টারে একটি নতুন পার্টিশনের উপস্থিতির দিকে নিয়ে যায়, যা, একটি একক S3 স্টোরেজে স্বয়ংক্রিয়ভাবে সংরক্ষিত হয়।

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

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

একটি একক-ব্যবহারকারী সেটিংয়ে স্নোফ্লেক ব্যবহার করে বর্ণিত প্রথম দৃশ্য। এখন কল্পনা করা যাক যে অনেক ব্যবহারকারী আছে, যা বাস্তব দৃশ্যের কাছাকাছি।

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

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

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

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

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

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

উপরে বর্ণিত সুযোগটি আপনাকে কেবল 2টি নয়, আরও অনেক ধরণের কাজের চাপকে ক্লাস্টারে ভাগ করতে দেয় (ETL, পর্যবেক্ষণ, প্রতিবেদনের বস্তুগতকরণ,...)।

চলুন সংক্ষিপ্ত করা যাক Snowflake. ভিত্তিটি একটি সুন্দর ধারণা এবং একটি কার্যকরী বাস্তবায়নকে একত্রিত করে। ManyChat এ, আমরা আমাদের কাছে থাকা সমস্ত ডেটা বিশ্লেষণ করতে স্নোফ্লেক ব্যবহার করি। আমাদের কাছে উদাহরণের মতো তিনটি ক্লাস্টার নেই, তবে 5 থেকে 9 পর্যন্ত বিভিন্ন আকারের। আমাদের কাছে প্রচলিত 16-মেশিন, 2-মেশিন এবং কিছু কাজের জন্য অতি-ছোট 1-মেশিন রয়েছে। তারা সফলভাবে লোড বিতরণ করে এবং আমাদের অনেক সঞ্চয় করতে দেয়।

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

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

ফলাফল

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

এসকিউএল কোয়েরি চালানোকে হালকা-স্টেট পরিষেবা হিসাবেও বিবেচনা করা যেতে পারে যা সার্ভারলেস মোডে পপ আপ করতে পারে, যেমন স্নোফ্লেক কম্পিউটিং ক্লাস্টার, শুধুমাত্র প্রয়োজনীয় ডেটা ডাউনলোড করতে পারে, ক্যোয়ারীটি চালাতে পারে এবং "আউট যান"।

সার্ভারলেস প্রোডাকশন লেভেল ডেটাবেস ইতিমধ্যেই ব্যবহারের জন্য উপলব্ধ, তারা কাজ করছে। এই সার্ভারহীন ডাটাবেসগুলি ইতিমধ্যেই OLAP কাজগুলি পরিচালনা করার জন্য প্রস্তুত৷ দুর্ভাগ্যবশত, OLTP কাজের জন্য এগুলি ব্যবহার করা হয়... সূক্ষ্মতা সহ, যেহেতু সীমাবদ্ধতা রয়েছে। একদিকে, এটি একটি বিয়োগ। কিন্তু, অন্যদিকে, এটি একটি সুযোগ। সম্ভবত পাঠকদের মধ্যে একজন অরোরার সীমাবদ্ধতা ছাড়াই একটি OLTP ডাটাবেসকে সম্পূর্ণরূপে সার্ভারহীন করার উপায় খুঁজে পাবেন।

আমি আশা করি আপনি এটি আকর্ষণীয় খুঁজে পেয়েছেন. সার্ভারহীন ভবিষ্যত :)

উত্স: www.habr.com