আপনার সার্ভারলেস অ্যাপকে প্রতি সেকেন্ডে হাজার হাজার অপারেশন বা কয়েক লক্ষ সমসাময়িক ব্যবহারকারীর চেয়েও বেশি কীভাবে স্কেল করা যায় তার নির্দেশিকা জানতে এই ডকুমেন্টটি পড়ুন। এই ডকুমেন্টে উন্নত বিষয়গুলি অন্তর্ভুক্ত রয়েছে যা আপনাকে সিস্টেমটি গভীরভাবে বুঝতে সাহায্য করবে। আপনি যদি Cloud Firestore দিয়ে শুরু করেন, তাহলে দ্রুত শুরু করার নির্দেশিকাটি দেখুন।
Cloud Firestore এবং ফায়ারবেস মোবাইল/ওয়েব SDK সার্ভারলেস অ্যাপ তৈরির জন্য একটি শক্তিশালী মডেল প্রদান করে যেখানে ক্লায়েন্ট-সাইড কোড সরাসরি ডাটাবেস অ্যাক্সেস করে। SDK গুলি ক্লায়েন্টদের রিয়েল টাইমে ডেটার আপডেট শুনতে দেয়। আপনি রিয়েল-টাইম আপডেট ব্যবহার করে এমন প্রতিক্রিয়াশীল অ্যাপ তৈরি করতে পারেন যার জন্য সার্ভার অবকাঠামোর প্রয়োজন হয় না। যদিও কিছু চালু করা খুব সহজ, এটি Cloud Firestore তৈরি করে এমন সিস্টেমের সীমাবদ্ধতাগুলি বুঝতে সাহায্য করে যাতে আপনার সার্ভারলেস অ্যাপ ট্র্যাফিক বৃদ্ধি পেলে স্কেল করে এবং ভালভাবে কাজ করে।
আপনার অ্যাপটি কীভাবে স্কেল করবেন সে সম্পর্কে পরামর্শের জন্য নিম্নলিখিত বিভাগগুলি দেখুন।
আপনার ব্যবহারকারীদের কাছাকাছি একটি ডাটাবেস অবস্থান বেছে নিন।
নিম্নলিখিত চিত্রটি একটি রিয়েল-টাইম অ্যাপের স্থাপত্য প্রদর্শন করে:
যখন কোনও ব্যবহারকারীর ডিভাইসে (মোবাইল বা ওয়েব) চলমান কোনও অ্যাপ Cloud Firestore সাথে সংযোগ স্থাপন করে, তখন সংযোগটি আপনার ডাটাবেস যেখানে অবস্থিত সেই অঞ্চলে অবস্থিত একটি Cloud Firestore ফ্রন্টএন্ড সার্ভারে পাঠানো হয়। উদাহরণস্বরূপ, যদি আপনার ডাটাবেস us-east1 এ থাকে, তাহলে সংযোগটি us-east1 এ থাকা একটি Cloud Firestore ফ্রন্টএন্ডেও যায়। এই সংযোগগুলি দীর্ঘস্থায়ী এবং অ্যাপ দ্বারা স্পষ্টভাবে বন্ধ না করা পর্যন্ত খোলা থাকে। ফ্রন্টএন্ড অন্তর্নিহিত Cloud Firestore স্টোরেজ সিস্টেম থেকে ডেটা পড়ে।
ব্যবহারকারীর ভৌত অবস্থান এবং Cloud Firestore ডাটাবেসের অবস্থানের মধ্যে দূরত্ব ব্যবহারকারীর অভিজ্ঞতার লেটেন্সিকে প্রভাবিত করে। উদাহরণস্বরূপ, ভারতের একজন ব্যবহারকারী যার অ্যাপ উত্তর আমেরিকার একটি Google Cloud অঞ্চলের একটি ডাটাবেসের সাথে কথা বলে, তার অভিজ্ঞতা ধীর এবং অ্যাপটি কম দ্রুত হতে পারে যদি ডাটাবেসটি কাছাকাছি অবস্থিত হয়, যেমন ভারত বা এশিয়ার অন্য কোনও অংশে।
নির্ভরযোগ্যতার জন্য নকশা
নিম্নলিখিত বিষয়গুলি আপনার অ্যাপের নির্ভরযোগ্যতা উন্নত করে বা প্রভাবিত করে:
অফলাইন মোড সক্ষম করুন
Firebase SDK গুলি অফলাইন ডেটা স্থায়িত্ব প্রদান করে। ব্যবহারকারীর ডিভাইসে থাকা অ্যাপটি যদি Cloud Firestore সাথে সংযোগ করতে না পারে, তাহলে স্থানীয়ভাবে ক্যাশ করা ডেটা ব্যবহার করে অ্যাপটি ব্যবহারযোগ্য থাকে। এটি ব্যবহারকারীদের ইন্টারনেট সংযোগে সমস্যা থাকলেও বা বেশ কয়েক ঘন্টা বা দিনের জন্য সম্পূর্ণ অ্যাক্সেস হারিয়ে ফেললেও ডেটা অ্যাক্সেস নিশ্চিত করে। অফলাইন মোড সম্পর্কে আরও তথ্যের জন্য, অফলাইন ডেটা সক্ষম করুন দেখুন।
স্বয়ংক্রিয় পুনঃপ্রয়াস বুঝুন
ফায়ারবেস এসডিকেগুলি পুনরায় চেষ্টা করার এবং ভাঙা সংযোগগুলি পুনরায় স্থাপন করার যত্ন নেয়। এটি সার্ভার পুনরায় চালু করার ফলে সৃষ্ট ক্ষণস্থায়ী ত্রুটি বা ক্লায়েন্ট এবং ডাটাবেসের মধ্যে নেটওয়ার্ক সমস্যার সমাধান করতে সহায়তা করে।
আঞ্চলিক এবং বহু-আঞ্চলিক অবস্থানের মধ্যে বেছে নিন
আঞ্চলিক এবং বহু-আঞ্চলিক অবস্থানের মধ্যে নির্বাচন করার সময় বেশ কয়েকটি বিনিময় রয়েছে। মূল পার্থক্য হল ডেটা কীভাবে প্রতিলিপি করা হয়। এটি আপনার অ্যাপের প্রাপ্যতার গ্যারান্টিকে চালিত করে। একটি বহু-অঞ্চল উদাহরণ শক্তিশালী পরিবেশন নির্ভরযোগ্যতা প্রদান করে এবং আপনার ডেটার স্থায়িত্ব বৃদ্ধি করে তবে বিনিময়টি হল ব্যয়।
রিয়েল-টাইম কোয়েরি সিস্টেমটি বুঝুন
রিয়েল-টাইম কোয়েরি, যাকে স্ন্যাপশট লিসেনরও বলা হয়, অ্যাপটিকে ডাটাবেসের পরিবর্তনগুলি শুনতে দেয় এবং ডেটা পরিবর্তনের সাথে সাথে কম-বিলম্বিততার বিজ্ঞপ্তি পেতে দেয়। একটি অ্যাপ আপডেটের জন্য ডাটাবেস পর্যায়ক্রমে পোল করে একই ফলাফল পেতে পারে, তবে এটি প্রায়শই ধীর, আরও ব্যয়বহুল এবং আরও কোডের প্রয়োজন হয়। রিয়েল-টাইম কোয়েরিগুলি কীভাবে সেট আপ এবং ব্যবহার করবেন তার উদাহরণগুলির জন্য, রিয়েল-টাইম আপডেটগুলি পান দেখুন। নিম্নলিখিত বিভাগগুলিতে স্ন্যাপশট লিসেনর কীভাবে কাজ করে তার বিশদ বিবরণ দেওয়া হয়েছে এবং কর্মক্ষমতা ধরে রেখে রিয়েল-টাইম কোয়েরিগুলি স্কেল করার জন্য কিছু সেরা অনুশীলন বর্ণনা করা হয়েছে।
কল্পনা করুন যে দুজন ব্যবহারকারী মোবাইল SDK দিয়ে তৈরি একটি মেসেজিং অ্যাপের মাধ্যমে Cloud Firestore সাথে সংযুক্ত হচ্ছেন।
ক্লায়েন্ট A ডাটাবেসে লেখে chatroom নামক একটি সংগ্রহে নথি যোগ এবং আপডেট করার জন্য:
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Cloud Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
ক্লায়েন্ট B একটি স্ন্যাপশট লিসেনারের সাহায্যে একই সংগ্রহের আপডেটগুলি শোনে। যখনই কেউ একটি নতুন বার্তা তৈরি করে তখন ক্লায়েন্ট B তাৎক্ষণিকভাবে একটি বিজ্ঞপ্তি পায়। নিম্নলিখিত চিত্রটি একটি স্ন্যাপশট লিসেনারের পিছনের স্থাপত্য দেখায়:
ক্লায়েন্ট B যখন একটি স্ন্যাপশট লিসেনারকে ডাটাবেসের সাথে সংযুক্ত করে তখন নিম্নলিখিত ইভেন্টগুলির ক্রম ঘটে:
- ক্লায়েন্ট B Cloud Firestore সাথে একটি সংযোগ খোলে এবং Firebase SDK এর মাধ্যমে
onSnapshot(collection("chatroom"))এ কল করে একজন শ্রোতাকে নিবন্ধন করে। এই শ্রোতা ঘন্টার পর ঘন্টা সক্রিয় থাকতে পারে। - Cloud Firestore ফ্রন্টএন্ড ডেটাসেট বুটস্ট্র্যাপ করার জন্য অন্তর্নিহিত স্টোরেজ সিস্টেমকে কোয়েরি করে। এটি ম্যাচিং ডকুমেন্টের সম্পূর্ণ ফলাফল সেট লোড করে। আমরা এটিকে পোলিং কোয়েরি হিসাবে উল্লেখ করি। এরপর সিস্টেমটি ডাটাবেসের ফায়ারবেস সিকিউরিটি রুলস মূল্যায়ন করে যাচাই করে যে ব্যবহারকারী এই ডেটা অ্যাক্সেস করতে পারে। যদি ব্যবহারকারী অনুমোদিত হয়, তাহলে ডাটাবেস ব্যবহারকারীকে ডেটা ফেরত দেয়।
- ক্লায়েন্ট B এর কোয়েরিটি তখন লিসেন মোডে চলে যায়। লিসেনার একটি সাবস্ক্রিপশন হ্যান্ডলারের সাথে নিবন্ধন করে এবং ডেটা আপডেটের জন্য অপেক্ষা করে।
- ক্লায়েন্ট A এখন একটি নথি পরিবর্তন করার জন্য একটি লেখার অপারেশন পাঠায়।
- ডাটাবেস তার স্টোরেজ সিস্টেমে ডকুমেন্ট পরিবর্তন করে।
- লেনদেনের দিক থেকে, সিস্টেমটি একই আপডেট একটি অভ্যন্তরীণ চেঞ্জলগে পাঠায়। চেঞ্জলগ পরিবর্তনগুলি ঘটার সাথে সাথে একটি কঠোর ক্রম স্থাপন করে।
- চেঞ্জলগটি আপডেট করা ডেটা সাবস্ক্রিপশন হ্যান্ডলারের একটি পুলে পাঠায়।
- একটি রিভার্স কোয়েরি ম্যাচার চালানো হয় যাতে দেখা যায় যে আপডেট করা ডকুমেন্টটি বর্তমানে নিবন্ধিত কোনও স্ন্যাপশট লিসেনারের সাথে মেলে কিনা। এই উদাহরণে, ডকুমেন্টটি ক্লায়েন্ট B-এর স্ন্যাপশট লিসেনারের সাথে মেলে। নাম থেকেই বোঝা যায়, আপনি রিভার্স কোয়েরি ম্যাচারটিকে একটি সাধারণ ডাটাবেস কোয়েরি হিসেবে ভাবতে পারেন কিন্তু বিপরীতভাবে করা হয়। কোনও কোয়েরির সাথে মেলে এমন ডকুমেন্ট খুঁজে বের করার জন্য ডকুমেন্ট অনুসন্ধান করার পরিবর্তে, এটি দক্ষতার সাথে কোয়েরিগুলির মাধ্যমে অনুসন্ধান করে ইনকামিং ডকুমেন্টের সাথে মেলে এমনগুলি খুঁজে বের করে। একটি মিল খুঁজে পাওয়ার পর, সিস্টেমটি প্রশ্নযুক্ত ডকুমেন্টটি স্ন্যাপশট লিসেনারের কাছে ফরোয়ার্ড করে। তারপর সিস্টেমটি ডাটাবেসের ফায়ারবেস সিকিউরিটি রুলস মূল্যায়ন করে যাতে নিশ্চিত করা যায় যে শুধুমাত্র অনুমোদিত ব্যবহারকারীরা ডেটা পাচ্ছেন।
- সিস্টেমটি ক্লায়েন্ট B এর ডিভাইসে ডকুমেন্ট আপডেটটি SDK-তে ফরোয়ার্ড করে এবং
onSnapshotকলব্যাক চালু হয়। যদি স্থানীয় পারসিস্ট্যান্স সক্ষম করা থাকে, তাহলে SDK স্থানীয় ক্যাশেও আপডেটটি প্রয়োগ করে।
Cloud Firestore স্কেলেবিলিটির একটি গুরুত্বপূর্ণ অংশ চেঞ্জলগ থেকে সাবস্ক্রিপশন হ্যান্ডলার এবং ফ্রন্টএন্ড সার্ভারে ফ্যান-আউটের উপর নির্ভর করে। ফ্যান-আউট লক্ষ লক্ষ রিয়েল-টাইম ক্যোয়ারী এবং সংযুক্ত ব্যবহারকারীদের পরিষেবা প্রদানের জন্য দক্ষতার সাথে প্রচারের জন্য একটি একক ডেটা পরিবর্তনকে অনুমতি দেয়। একাধিক অঞ্চলে (অথবা বহু-অঞ্চল স্থাপনের ক্ষেত্রে একাধিক অঞ্চলে) এই সমস্ত উপাদানের অনেক প্রতিলিপি চালানোর মাধ্যমে, Cloud Firestore উচ্চ প্রাপ্যতা এবং স্কেলেবিলিটি অর্জন করে।
এটি লক্ষণীয় যে মোবাইল এবং ওয়েব SDK থেকে জারি করা সমস্ত পঠন ক্রিয়াকলাপ উপরের মডেলটি অনুসরণ করে। ধারাবাহিকতা নিশ্চিত করার জন্য তারা একটি পোলিং কোয়েরি সম্পাদন করে এবং তারপরে লিসেন মোড ব্যবহার করে। এটি রিয়েল-টাইম লিসেনারের ক্ষেত্রে, একটি ডকুমেন্ট পুনরুদ্ধারের জন্য কল এবং ওয়ান-শট কোয়েরির ক্ষেত্রেও প্রযোজ্য। আপনি একক ডকুমেন্ট পুনরুদ্ধার এবং ওয়ান-শট কোয়েরিকে স্বল্পস্থায়ী স্ন্যাপশট লিসেনারের মতো ভাবতে পারেন যার পারফরম্যান্সের ক্ষেত্রে একই রকম সীমাবদ্ধতা রয়েছে।
রিয়েল-টাইম কোয়েরি স্কেল করার জন্য সেরা অনুশীলনগুলি প্রয়োগ করুন
স্কেলেবল রিয়েল-টাইম কোয়েরি ডিজাইন করতে নিম্নলিখিত সেরা অনুশীলনগুলি প্রয়োগ করুন।
সিস্টেমে লেখার ট্র্যাফিক বেশি কিনা তা বুঝুন
এই বিভাগটি আপনাকে বুঝতে সাহায্য করবে যে সিস্টেমটি ক্রমবর্ধমান সংখ্যক লেখার অনুরোধের প্রতি কীভাবে সাড়া দেয়।
Cloud Firestore চেঞ্জলগগুলি যা রিয়েল-টাইম কোয়েরিগুলিকে স্বয়ংক্রিয়ভাবে রাইটিং ট্র্যাফিক বৃদ্ধির সাথে সাথে অনুভূমিকভাবে স্কেল করে। একটি ডাটাবেসের লেখার হার একটি একক সার্ভারের পরিচালনার চেয়ে বেশি বৃদ্ধি পাওয়ার সাথে সাথে, চেঞ্জলগটি একাধিক সার্ভারে বিভক্ত হয়ে যায় এবং কোয়েরি প্রক্রিয়াকরণ একটির পরিবর্তে একাধিক সাবস্ক্রিপশন হ্যান্ডলার থেকে ডেটা ব্যবহার করতে শুরু করে। ক্লায়েন্ট এবং SDK এর দৃষ্টিকোণ থেকে, এটি সম্পূর্ণ স্বচ্ছ এবং যখন স্প্লিট হয় তখন অ্যাপ থেকে কোনও পদক্ষেপ নেওয়ার প্রয়োজন হয় না। নিম্নলিখিত চিত্রটি দেখায় যে রিয়েল-টাইম কোয়েরিগুলি কীভাবে স্কেল হয়:
স্বয়ংক্রিয় স্কেলিং আপনাকে সীমা ছাড়াই আপনার লেখার ট্র্যাফিক বাড়াতে সাহায্য করে, কিন্তু ট্র্যাফিক বাড়ার সাথে সাথে সিস্টেমটি সাড়া দিতে কিছুটা সময় নিতে পারে। লেখার হটস্পট তৈরি এড়াতে 5-5-5 নিয়মের সুপারিশগুলি অনুসরণ করুন। লেখার হটস্পট বিশ্লেষণের জন্য কী ভিজ্যুয়ালাইজার একটি কার্যকর হাতিয়ার।
অনেক অ্যাপের স্বাভাবিক বৃদ্ধি অনুমানযোগ্য, যা Cloud Firestore সতর্কতা ছাড়াই মেনে নিতে পারে। তবে, একটি বড় ডেটাসেট আমদানি করার মতো ব্যাচ ওয়ার্কলোড লেখার পরিমাণ খুব দ্রুত বাড়িয়ে দিতে পারে। আপনার অ্যাপ ডিজাইন করার সময়, আপনার লেখার ট্র্যাফিক কোথা থেকে আসে সে সম্পর্কে সচেতন থাকুন।
লেখা এবং পঠন কীভাবে মিথস্ক্রিয়া করে তা বুঝুন
রিয়েল-টাইম কোয়েরি সিস্টেমকে আপনি পাঠকদের সাথে লেখার ক্রিয়াকলাপ সংযুক্ত করার একটি পাইপলাইন হিসাবে ভাবতে পারেন। যেকোনো সময় একটি ডকুমেন্ট তৈরি, আপডেট বা মুছে ফেলা হয়, পরিবর্তনটি স্টোরেজ সিস্টেম থেকে বর্তমানে নিবন্ধিত শ্রোতাদের কাছে ছড়িয়ে পড়ে। Cloud Firestore চেঞ্জলগ কাঠামো শক্তিশালী ধারাবাহিকতার নিশ্চয়তা দেয়, যার অর্থ হল আপনার অ্যাপটি কখনই এমন আপডেটের বিজ্ঞপ্তি পায় না যা ডাটাবেস যখন ডেটা পরিবর্তন করে তখন তুলনামূলকভাবে অকার্যকর। এটি ডেটা ধারাবাহিকতার আশেপাশের প্রান্তের কেসগুলি সরিয়ে অ্যাপ ডেভেলপমেন্টকে সহজ করে তোলে।
এই সংযুক্ত পাইপলাইনের অর্থ হল, হটস্পট বা লক কনটেন্ট তৈরি করে এমন একটি লেখার অপারেশন পঠন কার্যক্রমকে নেতিবাচকভাবে প্রভাবিত করতে পারে। যখন লেখার অপারেশন ব্যর্থ হয় বা থ্রোটলিংয়ের সম্মুখীন হয়, তখন একটি পড়া চেঞ্জলগ থেকে সামঞ্জস্যপূর্ণ ডেটার জন্য অপেক্ষা করতে থেমে যেতে পারে। যদি আপনার অ্যাপে এটি ঘটে, তাহলে আপনি ধীর লেখার অপারেশন এবং প্রশ্নের জন্য সহ-সহযোগী ধীর প্রতিক্রিয়া সময় উভয়ই দেখতে পাবেন। হটস্পট এড়িয়ে চলাই এই সমস্যা থেকে মুক্তি পাওয়ার মূল চাবিকাঠি।
নথিপত্র এবং লেখার কাজ ছোট রাখুন
স্ন্যাপশট লিসেনারের সাহায্যে অ্যাপ তৈরি করার সময়, আপনি সাধারণত ব্যবহারকারীদের ডেটা পরিবর্তন সম্পর্কে দ্রুত জানতে চান। এটি অর্জনের জন্য, জিনিসগুলিকে ছোট রাখার চেষ্টা করুন। সিস্টেমটি দশটি ক্ষেত্র সহ ছোট নথিগুলিকে খুব দ্রুত সিস্টেমের মাধ্যমে পুশ করতে পারে। শত শত ক্ষেত্র এবং বৃহৎ ডেটা সহ বৃহত্তর নথিগুলি প্রক্রিয়া করতে বেশি সময় নেয়।
একইভাবে, ল্যাটেন্সি কম রাখার জন্য সংক্ষিপ্ত, দ্রুত কমিট এবং লেখার ক্রিয়াকলাপগুলিকে অগ্রাধিকার দিন। লেখকের দৃষ্টিকোণ থেকে বড় ব্যাচগুলি আপনাকে উচ্চতর থ্রুপুট দিতে পারে তবে স্ন্যাপশট শ্রোতাদের জন্য বিজ্ঞপ্তির সময় বাড়িয়ে দিতে পারে। এটি প্রায়শই অন্যান্য ডাটাবেস সিস্টেম ব্যবহারের তুলনায় বিপরীত হয় যেখানে আপনি কর্মক্ষমতা উন্নত করার জন্য ব্যাচিং ব্যবহার করতে পারেন।
দক্ষ শ্রোতা ব্যবহার করুন
আপনার ডাটাবেসের লেখার হার বৃদ্ধির সাথে সাথে, Cloud Firestore অনেক সার্ভারে ডেটা প্রক্রিয়াকরণকে বিভক্ত করে। Cloud Firestore শারডিং অ্যালগরিদম একই সংগ্রহ বা সংগ্রহ গোষ্ঠী থেকে একই চেঞ্জলগ সার্ভারে ডেটা সহ-স্থানান্তর করার চেষ্টা করে। সিস্টেমটি সম্ভাব্য লেখার থ্রুপুট সর্বাধিক করার চেষ্টা করে এবং একটি কোয়েরি প্রক্রিয়াকরণে জড়িত সার্ভারের সংখ্যা যতটা সম্ভব কম রাখে।
তবে, কিছু নির্দিষ্ট প্যাটার্ন এখনও স্ন্যাপশট শ্রোতাদের জন্য অপ্রত্যাশিত আচরণের দিকে পরিচালিত করতে পারে। উদাহরণস্বরূপ, যদি আপনার অ্যাপটি তার বেশিরভাগ ডেটা একটি বৃহৎ সংগ্রহে সংরক্ষণ করে, তাহলে শ্রোতাকে তার প্রয়োজনীয় সমস্ত ডেটা গ্রহণের জন্য অনেক সার্ভারের সাথে সংযোগ স্থাপন করতে হতে পারে। আপনি একটি কোয়েরি ফিল্টার প্রয়োগ করলেও এটি সত্য থাকে। অনেক সার্ভারের সাথে সংযোগ স্থাপন করলে ধীর প্রতিক্রিয়ার ঝুঁকি বেড়ে যায়।
এই ধীর প্রতিক্রিয়াগুলি এড়াতে, আপনার স্কিমা এবং অ্যাপটি এমনভাবে ডিজাইন করুন যাতে সিস্টেমটি বিভিন্ন সার্ভারে না গিয়ে শ্রোতাদের পরিষেবা দিতে পারে। কম লেখার হার সহ আপনার ডেটা ছোট সংগ্রহে বিভক্ত করা সবচেয়ে ভালো কাজ করতে পারে।
এটি একটি রিলেশনাল ডাটাবেসের পারফরম্যান্স কোয়েরি সম্পর্কে চিন্তা করার মতো যার জন্য সম্পূর্ণ টেবিল স্ক্যান প্রয়োজন। একটি রিলেশনাল ডাটাবেসে, একটি কোয়েরি যার জন্য সম্পূর্ণ টেবিল স্ক্যান প্রয়োজন, তা হল একটি স্ন্যাপশট লিসেনারের সমতুল্য যা একটি উচ্চ-মন্থন সংগ্রহ দেখে। এটি একটি কোয়েরির তুলনায় ধীর গতিতে কাজ করতে পারে যা ডাটাবেস আরও নির্দিষ্ট সূচক ব্যবহার করে পরিবেশন করতে পারে। একটি আরও নির্দিষ্ট সূচক সহ একটি কোয়েরি হল একটি স্ন্যাপশট লিসেনারের মতো যা একটি একক নথি বা কম পরিবর্তনশীল সংগ্রহ দেখে। আপনার ব্যবহারের ক্ষেত্রে আচরণ এবং প্রয়োজনীয়তা সর্বোত্তমভাবে বুঝতে আপনার অ্যাপটি লোড করা উচিত।
পোলিং কোয়েরি দ্রুত রাখুন
রেসপন্সিভ রিয়েল-টাইম কোয়েরির আরেকটি গুরুত্বপূর্ণ অংশ হল ডেটা বুটস্ট্র্যাপ করার জন্য পোলিং কোয়েরি দ্রুত এবং দক্ষ কিনা তা নিশ্চিত করা। প্রথমবার যখন একটি নতুন স্ন্যাপশট লিসেনার সংযোগ করে, তখন লিসেনারকে সম্পূর্ণ ফলাফল সেট লোড করতে হবে এবং ব্যবহারকারীর ডিভাইসে পাঠাতে হবে। ধীর কোয়েরি আপনার অ্যাপকে কম রেসপন্সিভ করে তোলে। এর মধ্যে রয়েছে, উদাহরণস্বরূপ, এমন কোয়েরি যা অনেক ডকুমেন্ট পড়ার চেষ্টা করে বা এমন কোয়েরি যা উপযুক্ত সূচী ব্যবহার করে না।
কিছু পরিস্থিতিতে একজন শ্রোতা একটি শ্রোতা অবস্থা থেকে একটি পোলিং অবস্থায় ফিরে যেতে পারেন। এটি স্বয়ংক্রিয়ভাবে ঘটে এবং SDK এবং আপনার অ্যাপের কাছে স্বচ্ছ। নিম্নলিখিত শর্তগুলি একটি পোলিং অবস্থা ট্রিগার করতে পারে:
- লোডের পরিবর্তনের কারণে সিস্টেমটি একটি চেঞ্জলগ পুনরায় ভারসাম্য করে ।
- হটস্পটের কারণে ডাটাবেসে লেখা ব্যর্থ হয় বা বিলম্বিত হয়।
- ক্ষণস্থায়ী সার্ভার পুনরায় চালু হলে শ্রোতাদের উপর সাময়িক প্রভাব পড়ে।
যদি আপনার পোলিং কোয়েরিগুলি যথেষ্ট দ্রুত হয়, তাহলে আপনার অ্যাপ ব্যবহারকারীদের কাছে পোলিং অবস্থা স্বচ্ছ হয়ে ওঠে।
দীর্ঘজীবী শ্রোতাদের পছন্দ করুন
Cloud Firestore ব্যবহার করে এমন একটি অ্যাপ তৈরি করার জন্য শ্রোতাদের খোলা এবং যতক্ষণ সম্ভব বাঁচিয়ে রাখা প্রায়শই সবচেয়ে সাশ্রয়ী উপায়। Cloud Firestore ব্যবহার করার সময়, আপনাকে আপনার অ্যাপে ফেরত দস্তাবেজের জন্য বিল করা হয়, একটি খোলা সংযোগ বজায় রাখার জন্য নয়। দীর্ঘস্থায়ী স্ন্যাপশট শ্রোতা কেবল তার জীবদ্দশায় কোয়েরি পরিবেশন করার জন্য প্রয়োজনীয় ডেটা পড়ে। এর মধ্যে একটি প্রাথমিক পোলিং অপারেশন অন্তর্ভুক্ত থাকে এবং তারপরে ডেটা আসলে পরিবর্তিত হলে বিজ্ঞপ্তিগুলি আসে। অন্যদিকে, এক-শট কোয়েরিগুলি, এমন ডেটা পুনরায় পড়ে যা অ্যাপটি শেষবার কোয়েরিটি কার্যকর করার পর থেকে পরিবর্তিত হয়নি।
যেসব ক্ষেত্রে আপনার অ্যাপকে উচ্চ হারে ডেটা ব্যবহার করতে হয়, সেখানে স্ন্যাপশট লিসেনারের ব্যবহার উপযুক্ত নাও হতে পারে। উদাহরণস্বরূপ, যদি আপনার ব্যবহারের ক্ষেত্রে প্রতি সেকেন্ডে অনেক ডকুমেন্ট একটি সংযোগের মাধ্যমে দীর্ঘ সময়ের জন্য পুশ করা হয়, তাহলে কম ফ্রিকোয়েন্সিতে চালিত ওয়ান-শট কোয়েরি বেছে নেওয়া ভালো হতে পারে।
এরপর কি?
- স্ন্যাপশট লিসেনারের ব্যবহার শিখুন।
- আরও সেরা অনুশীলন সম্পর্কে পড়ুন।