Upstash আপনার AWS Lambda ফাংশনগুলির জন্য সেরা ডাটাবেস বিকল্প হওয়ার একটি মিশন নিয়ে যাত্রা শুরু করেছে। ইতিমধ্যে, আমরা আপনার সার্ভারহীন ফাংশন তৈরি করার জন্য আরেকটি দুর্দান্ত বিকল্প আবিষ্কার করেছি:ক্লাউডফ্লেয়ার ওয়ার্কারস। এটি একটি উত্তেজনাপূর্ণ পণ্য কারণ এটি কম খরচে এবং কোন ঠান্ডা শুরু না করে সারা বিশ্বে একটি ভাল বিলম্বের প্রতিশ্রুতি দেয়। কিন্তু AWS Lambda এর সাথে তুলনা করলে এর অনেক সীমাবদ্ধতা রয়েছে। অতিরিক্ত সীমাবদ্ধতা ডাটাবেস বিকল্পগুলির তালিকাকে ছোট করে তোলে। আমরা এটিকে প্রশ্নটির জন্য একটি দুর্দান্ত সমাধান হিসাবে Upstash অবস্থান করার একটি সুযোগ হিসাবে দেখেছি:CF Workers are stateless. Where should I keep my data then?
চ্যালেঞ্জ
অ্যাক্সেসিবিলিটি
ক্লাউডফ্লেয়ার ওয়ার্কাররা আরও বদ্ধ পরিবেশ। এটা AWS এর মত নয়। আপনি একই অঞ্চলে আপনার নিজস্ব ডাটাবেস সেট আপ করতে এবং VPC এর মাধ্যমে এটি অ্যাক্সেস করতে পারবেন না। তাই আপনাকে Workers ফাংশন থেকে আপনার ডাটাবেস অ্যাক্সেস করতে হবে। ক্লাউডফ্লেয়ার ওয়ার্কাররা রানটাইম হিসাবে V8 আইসোলেট ব্যবহার করে। এটি TCP সংযোগের অনুমতি দেয় না। তাই ডাটাবেস HTTP এর মাধ্যমে অ্যাক্সেসযোগ্য হওয়া উচিত।
গ্লোবাল রেপ্লিকেশন
শ্রমিকদের সর্বত্র মোতায়েন থাকার সুবিধা রয়েছে। যদিও আপনার ফাংশনটি সারা বিশ্ব থেকে কম বিলম্বের সাথে অ্যাক্সেসযোগ্য; আপনার ডাটাবেস অ্যাক্সেস করতে আপনার শত শত মিলিসেকেন্ড ব্যয় করা উচিত নয়। আপনার ডাটাবেস আপনার ফাংশন চালানোর কাছাকাছি হওয়া উচিত। একাধিক অঞ্চল এবং মহাদেশে আপনার ডেটা প্রতিলিপি করে এটি সম্ভব৷
নিম্ন বিলম্ব
৷বিকাশকারীরা প্রান্ত কম্পিউটিং সমাধান পছন্দ করে কারণ তারা সর্বত্র কম বিলম্ব প্রদান করে। ডাটাবেস একটি বাধা হতে হবে না. রেডিসের মতো ইন-মেমরি ডেটাবেস সাব-মিলিসেকেন্ড লেটেন্সি প্রদান করে।
Upstash যাত্রা
REST API
আমরা নেটিভ Redis API সমর্থন সহ Upstash চালু করেছি। সমস্ত রেডিস ক্লায়েন্ট সমর্থিত, এটি লিগ্যাসি রেডিস অ্যাপ্লিকেশনের জন্য উপযুক্ত। কিন্তু শীঘ্রই আমরা ব্যবহারকারীদের সার্ভারহীন ফাংশনে সংযোগ সমস্যা দেখতে শুরু করি। এছাড়াও এটি ক্লাউডফ্লেয়ার কর্মীদের কাছ থেকে অ্যাক্সেসযোগ্য ছিল না। তাই আমরা প্রথমে GraphQL API প্রয়োগ করেছি। কিন্তু আমরা GraphQL API নিয়ে খুশি ছিলাম না, কারণ প্রক্সি লেয়ারের কারণে ওভারহেড পারফরম্যান্সের কারণে। এছাড়াও গ্রাফকিউএল রেডিস কমান্ড চালানোর সবচেয়ে সহজ উপায় ছিল না। আমরা কর্মক্ষমতা ওভারহেড কমাতে ডাটাবেস ইঞ্জিনের ভিতরে একটি REST সার্ভার তৈরি করার সিদ্ধান্ত নিয়েছি। আমরা মনে করি রেডিসের জন্য REST একটি ভাল ফিট। আমরা REST API চালু করেছি এবং দেখেছি যে এটি ডেভেলপারদের মধ্যে বেশ জনপ্রিয় যারা Cloudflare Workers এবং Websembly থেকে Redis অ্যাক্সেস করতে চান৷
এজ ক্যাশিং
৷
REST API-কে ধন্যবাদ, Upstash কর্মীদের কাছ থেকে অ্যাক্সেসযোগ্য ছিল কিন্তু লেটেন্সি আদর্শ ছিল না। কিছু বিকাশকারী রেডিস প্রতিক্রিয়া ক্যাশে করতে ক্লাউডফ্লেয়ারের নিজস্ব ক্যাশিং ব্যবহার করার চেষ্টা করেছিলেন। কিন্তু এটি একটি জটিল সমাধান ছিল। রেডিস ইতিমধ্যেই খুব দ্রুত হওয়া উচিত, তাই এটি cache Redis করতে ভাল লাগছে না অন্য কোথাও. এই কারণেই আমরা প্রান্ত ক্যাশিং তৈরি করার সিদ্ধান্ত নিয়েছি যেখানে আমরা সমস্ত প্রান্তের অবস্থানে Redis REST প্রতিক্রিয়া ক্যাশে করি। আমরা Redis প্রতিক্রিয়া ক্যাশে CDN প্রদানকারী ব্যবহার. 80% পর্যন্ত পারফরম্যান্স লাভ এজ লেটেন্সিতে এটি একটি উল্লেখযোগ্য উন্নতি।
গ্লোবাল ডাটাবেস
এজ ক্যাশিং গ্লোবাল লেটেন্সি সমস্যার একটি দুর্দান্ত সমাধান ছিল তবে কিছু ব্যবহারের ক্ষেত্রে এর কিছু ত্রুটি রয়েছে। প্রথমত, এটি ক্যাশে অবৈধকরণ (পরিষ্কার) সমর্থন করে না। যদি ক্যাশের মেয়াদ শেষ হওয়ার সময় 30 সেকেন্ড হয়; তারপরে একটি 30 সেকেন্ডের উইন্ডো রয়েছে যেখানে আপনার ক্লায়েন্টরা পুরানো ডেটা পড়তে পারে। এটি অনেক ওয়েব ব্যবহারের ক্ষেত্রে সহ্য করা যেতে পারে তবে সব নয়। দ্বিতীয়ত, এজ ক্যাশিং শুধুমাত্র REST API-এর জন্য সমর্থিত। রেডিস ক্লায়েন্টরা এজ ক্যাশিং থেকে উপকৃত হতে পারে না। তাই আমরা একটি নতুন ডাটাবেস টাইপ ডিজাইন করার সিদ্ধান্ত নিয়েছি যা একাধিক অঞ্চলে ডেটা প্রতিলিপি করে। এটি অত্যন্ত উপলব্ধ এবং যথেষ্ট সামঞ্জস্যপূর্ণ হতে এটি ডিজাইন করা খুব চ্যালেঞ্জিং ছিল. বর্তমানে Upstash-এর একটি গ্লোবাল ডাটাবেস অফার রয়েছে যা আপনার ডেটাকে 5টি ভিন্ন AWS অঞ্চলে (পূর্ব এবং পশ্চিম উত্তর আমেরিকা, ইউরোপ, এশিয়া, দক্ষিণ আমেরিকা) প্রতিলিপি করে। গ্লোবাল ডাটাবেস একটি ক্যাশে নয় তাই এটিতে ক্যাশে-অবৈধ সমস্যা নেই। লেখাগুলি অবিলম্বে সমস্ত প্রতিলিপিতে প্রতিলিপি করা হয়। কর্মক্ষমতা এবং প্রাপ্যতার জন্য, গ্লোবাল ডাটাবেসকে শেষ পর্যন্ত সামঞ্জস্যপূর্ণ করার জন্য ডিজাইন করা হয়েছে।
এজ ক্যাশিং বনাম গ্লোবাল ডাটাবেস (বা উভয়)
আপনার এজ সমাধানের জন্য যদি আপনার কেবল একটি ক্যাশের প্রয়োজন হয় তবে এজ ক্যাশিং একটি ভাল সমাধান হতে পারে। কিন্তু ক্যাশে অবিলম্বে বাতিল করার জন্য আপনার লেখার প্রয়োজন হলে, আপনার গ্লোবাল ডাটাবেস পছন্দ করা উচিত। ক্যাশিং ছাড়াও, গ্লোবাল ডাটাবেস একটি অত্যন্ত উপলব্ধ গ্লোবাল ডেটাস্টোর হিসাবে ব্যবহার করা যেতে পারে। এছাড়াও মনে রাখবেন যে এজ ক্যাশিং শুধুমাত্র REST কলের জন্য উপলব্ধ। আপনি যদি রেডিস ক্লায়েন্ট ব্যবহার করেন, তাহলে গ্লোবাল ডাটাবেস হল একমাত্র বিকল্প যেখানে কম লেটেন্সি রয়েছে।
এজ ক্যাশিং এবং গ্লোবাল ডাটাবেস উভয়ই পঠিত বিলম্ব কমানোর জন্য ডিজাইন করা হয়েছে। যদি আপনার ব্যবহারের ক্ষেত্রে 90% লেখা হয় তবে একটি একক অঞ্চল সেটআপ আরও অর্থপূর্ণ হবে। মাল্টি এবং একক উভয় অঞ্চলের ডাটাবেসের জন্য রাইটগুলির একই লেটেন্সি আছে, কিন্তু গ্লোবাল সেটআপে সেগুলি 5 গুণ বেশি ব্যয়বহুল৷
যখন এজ ক্যাশিং সক্ষম করা হয়, তখন Upstash উৎপত্তি থেকে প্রথম অনুরোধ আনে তারপর প্রান্তে ক্যাশে করে। যদি উত্স কাছাকাছি না হয়, তাহলে লেটেন্সি বেশি হবে৷ আপনি যদি সব ক্ষেত্রে সেরা লেটেন্সি চান; আপনি একটি গ্লোবাল ডাটাবেসে এজ ক্যাশিং সক্ষম করে উভয়ই ব্যবহার করতে পারেন।
বেঞ্চমার্ক অ্যাপ্লিকেশন দেখুন যা প্রান্ত ক্যাশিং এবং গ্লোবাল ডাটাবেসের বিলম্বের তুলনা করে৷
এরপর কি?
এখানে কিছু জিনিস যা আমরা এজ এ Upstash উন্নত করতে কাজ করতে পারি:
- লেখার জন্য কম লেটেন্সি:বর্তমানে, গ্লোবাল ডাটাবেস একটি একক লিডার আর্কিটেকচারের সাথে রিড লেটেন্সি অপ্টিমাইজ করার জন্য ডিজাইন করা হয়েছে। আমরা মনে করি এটি বেশিরভাগ ব্যবহারের ক্ষেত্রে কভার করে। কিন্তু আপনার প্রতিক্রিয়া এবং নতুন ব্যবহারের ক্ষেত্রে নির্ভর করে আমরা এমন একটি আর্কিটেকচারে কাজ করতে পারি যা কম লেটেন্সি লেখার পাশাপাশি পড়ারও দেয়৷
- কাফকা সমর্থন:আমরা আগামী সপ্তাহে Redis ছাড়াও Kafka চালু করার পরিকল্পনা করছি। কাফকা প্রান্তে নতুন ব্যবহারের ক্ষেত্রে সক্ষম করবে যেমন ক্লিকস্ট্রিম বিশ্লেষণ বা সার্ভারহীন/এজ ফাংশন থেকে কাফকাতে লগ পুশ করা।
আমরা আপনার প্রতিক্রিয়া দ্বারা পরিচালিত Upstash উন্নত এবং বিকাশ অব্যাহত. টুইটার বা ডিসকর্ডে আপনার চিন্তা আমাদের জানান।
