প্রতি সেকেন্ডে হাজার হাজার অপারেশন বা লক্ষ লক্ষ যুগপৎ ব্যবহারকারীর ঊর্ধ্বে আপনার সার্ভারলেস অ্যাপকে স্কেল করার নির্দেশনার জন্য এই ডকুমেন্টটি পড়ুন। এই ডকুমেন্টে উন্নত বিষয়াবলী অন্তর্ভুক্ত রয়েছে যা আপনাকে সিস্টেমটি গভীরভাবে বুঝতে সাহায্য করবে। আপনি যদি Cloud Firestore দিয়ে সবেমাত্র কাজ শুরু করে থাকেন, তবে এর পরিবর্তে কুইকস্টার্ট গাইডটি দেখুন।
Cloud Firestore এবং ফায়ারবেস মোবাইল/ওয়েব এসডিকে-গুলো সার্ভারলেস অ্যাপ তৈরির জন্য একটি শক্তিশালী মডেল প্রদান করে, যেখানে ক্লায়েন্ট-সাইড কোড সরাসরি ডেটাবেস অ্যাক্সেস করে। এই এসডিকে-গুলো ক্লায়েন্টদের রিয়েল-টাইমে ডেটার আপডেট শোনার সুযোগ দেয়। আপনি রিয়েল-টাইম আপডেট ব্যবহার করে রেসপন্সিভ অ্যাপ তৈরি করতে পারেন, যার জন্য সার্ভার পরিকাঠামোর প্রয়োজন হয় না। যদিও কোনো কিছু চালু করা খুব সহজ, Cloud Firestore গঠনকারী সিস্টেমগুলোর সীমাবদ্ধতাগুলো বোঝা সহায়ক, যাতে ট্র্যাফিক বাড়লে আপনার সার্ভারলেস অ্যাপটি স্কেল করতে পারে এবং ভালোভাবে কাজ করে।
আপনার অ্যাপের পরিধি বাড়ানোর পরামর্শের জন্য নিম্নলিখিত বিভাগগুলি দেখুন।
আপনার ব্যবহারকারীদের কাছাকাছি একটি ডাটাবেস অবস্থান বেছে নিন।
নিম্নোক্ত ডায়াগ্রামটি একটি রিয়েল-টাইম অ্যাপের স্থাপত্য প্রদর্শন করে:
যখন ব্যবহারকারীর ডিভাইসে (মোবাইল বা ওয়েব) চলমান কোনো অ্যাপ Cloud Firestore সাথে একটি সংযোগ স্থাপন করে, তখন সেই সংযোগটি আপনার ডেটাবেস যে অঞ্চলে অবস্থিত, সেই একই অঞ্চলের একটি Cloud Firestore ফ্রন্টএন্ড সার্ভারে পাঠানো হয়। উদাহরণস্বরূপ, যদি আপনার ডেটাবেস us-east1 এ থাকে, তাহলে সংযোগটিও us-east1 এ অবস্থিত একটি Cloud Firestore ফ্রন্টএন্ডে যায়। এই সংযোগগুলো দীর্ঘস্থায়ী হয় এবং অ্যাপটি স্পষ্টভাবে বন্ধ না করা পর্যন্ত খোলা থাকে। ফ্রন্টএন্ডটি অন্তর্নিহিত Cloud Firestore স্টোরেজ সিস্টেমগুলো থেকে ডেটা পড়ে।
ব্যবহারকারীর ভৌতিক অবস্থান এবং Cloud Firestore ডেটাবেসের অবস্থানের মধ্যকার দূরত্ব, ব্যবহারকারীর অনুভূত লেটেন্সিকে প্রভাবিত করে। উদাহরণস্বরূপ, ভারতের একজন ব্যবহারকারী যার অ্যাপ উত্তর আমেরিকার Google Cloud অঞ্চলের একটি ডেটাবেসের সাথে সংযোগ স্থাপন করে, তিনি হয়তো অভিজ্ঞতাটি ধীরগতির এবং অ্যাপটিকে কম দ্রুতগতিসম্পন্ন মনে করতে পারেন, যদি ডেটাবেসটি এর পরিবর্তে আরও কাছাকাছি, যেমন ভারতে বা এশিয়ার অন্য কোনো অংশে অবস্থিত থাকত।
নির্ভরযোগ্যতার জন্য ডিজাইন করুন
নিম্নলিখিত বিষয়গুলো আপনার অ্যাপের নির্ভরযোগ্যতা উন্নত করে বা প্রভাবিত করে:
অফলাইন মোড সক্রিয় করুন
ফায়ারবেস এসডিকে অফলাইন ডেটা পার্সিস্টেন্স প্রদান করে। যদি ব্যবহারকারীর ডিভাইসের অ্যাপটি Cloud Firestore সাথে সংযোগ করতে না পারে, তবে স্থানীয়ভাবে ক্যাশ করা ডেটা ব্যবহার করে অ্যাপটি ব্যবহারযোগ্য থাকে। এটি নিশ্চিত করে যে ব্যবহারকারীরা দুর্বল ইন্টারনেট সংযোগের সম্মুখীন হলেও বা কয়েক ঘন্টা বা দিনের জন্য সম্পূর্ণ অ্যাক্সেস হারালেও ডেটা অ্যাক্সেস করতে পারবেন। অফলাইন মোড সম্পর্কে আরও বিস্তারিত জানতে, ‘অফলাইন ডেটা সক্ষম করুন’ দেখুন।
স্বয়ংক্রিয় পুনঃপ্রচেষ্টা বুঝুন
ফায়ারবেস এসডিকে-গুলো অপারেশন পুনরায় চেষ্টা করা এবং বিচ্ছিন্ন সংযোগ পুনঃস্থাপন করার দায়িত্ব নেয়। এটি সার্ভার রিস্টার্ট করা অথবা ক্লায়েন্ট ও ডেটাবেসের মধ্যে নেটওয়ার্ক সমস্যার কারণে সৃষ্ট ক্ষণস্থায়ী ত্রুটিগুলো এড়াতে সাহায্য করে।
আঞ্চলিক এবং বহু-আঞ্চলিক অবস্থানগুলির মধ্যে বেছে নিন
আঞ্চলিক এবং বহু-আঞ্চলিক অবস্থানের মধ্যে বেছে নেওয়ার ক্ষেত্রে বেশ কিছু সুবিধা-অসুবিধা রয়েছে। মূল পার্থক্যটি হলো ডেটা কীভাবে প্রতিলিপি করা হয়। এটি আপনার অ্যাপের প্রাপ্যতার নিশ্চয়তা নির্ধারণ করে। একটি বহু-আঞ্চলিক ইনস্ট্যান্স শক্তিশালী সার্ভিং নির্ভরযোগ্যতা প্রদান করে এবং আপনার ডেটার স্থায়িত্ব বাড়ায়, কিন্তু এর বিনিময়ে খরচ বেশি হয়।
রিয়েল-টাইম কোয়েরি সিস্টেমটি বুঝুন
রিয়েল-টাইম কোয়েরি, যা স্ন্যাপশট লিসেনার নামেও পরিচিত, অ্যাপটিকে ডাটাবেসের পরিবর্তনগুলো পর্যবেক্ষণ করতে এবং ডেটা পরিবর্তন হওয়ার সাথে সাথেই স্বল্প-বিলম্বের নোটিফিকেশন পেতে সাহায্য করে। একটি অ্যাপ পর্যায়ক্রমে আপডেটের জন্য ডাটাবেস পোল করেও একই ফলাফল পেতে পারে, কিন্তু এটি প্রায়শই ধীরগতির, বেশি ব্যয়বহুল এবং এতে আরও বেশি কোডের প্রয়োজন হয়। রিয়েল-টাইম কোয়েরি কীভাবে সেট আপ এবং ব্যবহার করতে হয় তার উদাহরণের জন্য, "রিয়েল-টাইম আপডেট পান" দেখুন। নিম্নলিখিত বিভাগগুলিতে স্ন্যাপশট লিসেনার কীভাবে কাজ করে তার বিশদ বিবরণ দেওয়া হয়েছে এবং পারফরম্যান্স বজায় রেখে রিয়েল-টাইম কোয়েরি স্কেল করার কিছু সেরা অনুশীলন বর্ণনা করা হয়েছে।
ধরুন, দুজন ব্যবহারকারী কোনো একটি মোবাইল এসডিকে দিয়ে তৈরি মেসেজিং অ্যাপের মাধ্যমে 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, Firebase SDK-এর মাধ্যমে
onSnapshot(collection("chatroom"))কল করে Cloud Firestore এর সাথে একটি সংযোগ স্থাপন করে এবং একটি লিসেনার রেজিস্টার করে। এই লিসেনারটি ঘণ্টার পর ঘণ্টা সক্রিয় থাকতে পারে। - Cloud Firestore ফ্রন্টএন্ড ডেটাসেটটি বুটস্ট্র্যাপ করার জন্য অন্তর্নিহিত স্টোরেজ সিস্টেমকে কোয়েরি করে। এটি মিলে যাওয়া ডকুমেন্টগুলোর সম্পূর্ণ ফলাফল সেট লোড করে। আমরা এটিকে পোলিং কোয়েরি বলি। এরপর সিস্টেমটি ব্যবহারকারী এই ডেটা অ্যাক্সেস করতে পারবে কিনা তা যাচাই করার জন্য ডেটাবেসের ফায়ারবেস সিকিউরিটি রুলস মূল্যায়ন করে। যদি ব্যবহারকারী অনুমোদিত হয়, তবে ডেটাবেসটি ব্যবহারকারীকে ডেটা ফেরত দেয়।
- এরপর ক্লায়েন্ট B-এর কোয়েরিটি লিসেন মোডে চলে যায়। লিসেনারটি একটি সাবস্ক্রিপশন হ্যান্ডলারের সাথে রেজিস্টার করে এবং ডেটার আপডেটের জন্য অপেক্ষা করে।
- ক্লায়েন্ট A এখন একটি ডকুমেন্ট পরিবর্তন করার জন্য একটি রাইট অপারেশন পাঠায়।
- ডাটাবেস তার স্টোরেজ সিস্টেমে ডকুমেন্ট পরিবর্তনটি কমিট করে।
- লেনদেনগতভাবে, সিস্টেমটি একটি অভ্যন্তরীণ চেঞ্জলগে একই আপডেট কমিট করে। চেঞ্জলগটি পরিবর্তনগুলি ঘটার সাথে সাথে সেগুলির একটি কঠোর ক্রম প্রতিষ্ঠা করে।
- চেঞ্জলগটি পর্যায়ক্রমে আপডেট করা ডেটা সাবস্ক্রিপশন হ্যান্ডলারের একটি পুলে ছড়িয়ে দেয়।
- একটি রিভার্স কোয়েরি ম্যাচিং টুল কার্যকর হয়ে দেখে যে, আপডেট করা ডকুমেন্টটি বর্তমানে রেজিস্টার করা কোনো স্ন্যাপশট লিসেনারের সাথে মেলে কিনা। এই উদাহরণে, ডকুমেন্টটি ক্লায়েন্ট বি-এর স্ন্যাপশট লিসেনারের সাথে মিলে যায়। নাম থেকেই বোঝা যায়, রিভার্স কোয়েরি ম্যাচিং টুলকে একটি সাধারণ ডাটাবেস কোয়েরির বিপরীত প্রক্রিয়া হিসেবে ভাবা যেতে পারে। কোনো কোয়েরির সাথে মেলে এমন ডকুমেন্ট খোঁজার পরিবর্তে, এটি দক্ষতার সাথে কোয়েরিগুলোর মধ্যে অনুসন্ধান করে আগত ডকুমেন্টের সাথে মেলে এমন কোয়েরিগুলো খুঁজে বের করে। মিল খুঁজে পেলে, সিস্টেমটি সংশ্লিষ্ট ডকুমেন্টটি স্ন্যাপশট লিসেনারগুলোর কাছে পাঠিয়ে দেয়। এরপর, শুধুমাত্র অনুমোদিত ব্যবহারকারীরাই যেন ডেটা পায় তা নিশ্চিত করার জন্য সিস্টেমটি ডাটাবেসের ফায়ারবেস সিকিউরিটি রুলস মূল্যায়ন করে।
- সিস্টেমটি ক্লায়েন্ট B-এর ডিভাইসে থাকা SDK-তে ডকুমেন্ট আপডেটটি ফরোয়ার্ড করে এবং
onSnapshotকলব্যাকটি সক্রিয় হয়। যদি লোকাল পার্সিস্টেন্স সক্রিয় থাকে, তাহলে SDK লোকাল ক্যাশেও আপডেটটি প্রয়োগ করে।
Cloud Firestore স্কেলেবিলিটির একটি মূল অংশ নির্ভর করে চেঞ্জলগ থেকে সাবস্ক্রিপশন হ্যান্ডলার এবং ফ্রন্টএন্ড সার্ভার পর্যন্ত ডেটার ফ্যান-আউটের উপর। এই ফ্যান-আউট একটিমাত্র ডেটা পরিবর্তনকে দক্ষতার সাথে ছড়িয়ে দিয়ে লক্ষ লক্ষ রিয়েল-টাইম কোয়েরি এবং সংযুক্ত ব্যবহারকারীদের পরিষেবা দিতে সাহায্য করে। একাধিক জোনে (অথবা মাল্টি-রিজিওন ডেপ্লয়মেন্টের ক্ষেত্রে একাধিক রিজিয়নে) এই সমস্ত কম্পোনেন্টের অনেকগুলো রেপ্লিকা চালানোর মাধ্যমে Cloud Firestore উচ্চ প্রাপ্যতা এবং স্কেলেবিলিটি অর্জন করে।
এটা উল্লেখ্য যে, মোবাইল এবং ওয়েব SDK থেকে জারি করা সমস্ত রিড অপারেশন উপরের মডেলটি অনুসরণ করে। সামঞ্জস্যের নিশ্চয়তা বজায় রাখার জন্য এগুলি একটি পোলিং কোয়েরি সম্পাদন করে এবং তারপরে লিসেন মোড চালু রাখে। এটি রিয়েল-টাইম লিসেনার, ডকুমেন্ট পুনরুদ্ধার করার কল এবং ওয়ান-শট কোয়েরির ক্ষেত্রেও প্রযোজ্য। আপনি একক ডকুমেন্ট পুনরুদ্ধার এবং ওয়ান-শট কোয়েরিগুলিকে স্বল্পস্থায়ী স্ন্যাপশট লিসেনার হিসাবে ভাবতে পারেন, যেগুলির পারফরম্যান্স সংক্রান্ত একই ধরনের সীমাবদ্ধতা রয়েছে।
রিয়েল-টাইম কোয়েরি স্কেল করার জন্য সর্বোত্তম অনুশীলন প্রয়োগ করুন।
স্কেলেবল রিয়েল-টাইম কোয়েরি ডিজাইন করার জন্য নিম্নলিখিত সেরা অনুশীলনগুলি প্রয়োগ করুন।
সিস্টেমে উচ্চ রাইট ট্র্যাফিক বুঝুন
এই অংশটি আপনাকে বুঝতে সাহায্য করবে যে, ক্রমবর্ধমান সংখ্যক রাইট রিকোয়েস্টের প্রতি সিস্টেম কীভাবে সাড়া দেয়।
Cloud Firestore চেঞ্জলগ, যা রিয়েল-টাইম কোয়েরিগুলোকে চালনা করে, রাইট ট্র্যাফিক বাড়ার সাথে সাথে স্বয়ংক্রিয়ভাবে হরাইজন্টালি স্কেল করে। যখন কোনো ডাটাবেসের রাইট রেট একটিমাত্র সার্ভারের ধারণক্ষমতা ছাড়িয়ে যায়, তখন চেঞ্জলগটি একাধিক সার্ভারে ভাগ করে দেওয়া হয় এবং কোয়েরি প্রসেসিং একটির পরিবর্তে একাধিক সাবস্ক্রিপশন হ্যান্ডলার থেকে ডেটা গ্রহণ করতে শুরু করে। ক্লায়েন্ট এবং SDK-এর দৃষ্টিকোণ থেকে, এই পুরো প্রক্রিয়াটি স্বচ্ছ থাকে এবং ডেটা বিভাজনের সময় অ্যাপের পক্ষ থেকে কোনো পদক্ষেপের প্রয়োজন হয় না। নিচের ডায়াগ্রামটি দেখায় কিভাবে রিয়েল-টাইম কোয়েরিগুলো স্কেল করে:
অটোমেটিক স্কেলিং আপনাকে সীমাহীনভাবে আপনার রাইট ট্র্যাফিক বাড়ানোর সুযোগ দেয়, কিন্তু ট্র্যাফিক বাড়তে থাকলে সিস্টেমের সাড়া দিতে কিছুটা সময় লাগতে পারে। রাইট হটস্পট তৈরি হওয়া এড়াতে ৫-৫-৫ নিয়মের সুপারিশগুলো অনুসরণ করুন। রাইট হটস্পট বিশ্লেষণ করার জন্য কী ভিজ্যুয়ালাইজার একটি কার্যকরী টুল।
অনেক অ্যাপের একটি অনুমানযোগ্য স্বাভাবিক বৃদ্ধি থাকে, যা Cloud Firestore কোনো সতর্কতা ছাড়াই সামাল দিতে পারে। তবে, একটি বড় ডেটাসেট ইম্পোর্ট করার মতো ব্যাচ ওয়ার্কলোডগুলো খুব দ্রুত রাইটের পরিমাণ বাড়িয়ে দিতে পারে। আপনার অ্যাপ ডিজাইন করার সময়, আপনার রাইট ট্র্যাফিক কোথা থেকে আসছে সে সম্পর্কে সচেতন থাকুন।
লেখা ও পড়ার পারস্পরিক ক্রিয়া বুঝুন
আপনি রিয়েল-টাইম কোয়েরি সিস্টেমটিকে একটি পাইপলাইন হিসেবে ভাবতে পারেন, যা রাইট অপারেশনগুলোকে রিডারদের সাথে সংযুক্ত করে। যখনই কোনো ডকুমেন্ট তৈরি, আপডেট বা ডিলিট করা হয়, সেই পরিবর্তনটি স্টোরেজ সিস্টেম থেকে বর্তমানে রেজিস্টার করা লিসেনারগুলোতে ছড়িয়ে পড়ে। Cloud Firestore চেঞ্জলগ কাঠামো শক্তিশালী সামঞ্জস্যতা নিশ্চিত করে, যার অর্থ হলো, ডেটাবেস যখন ডেটা পরিবর্তনগুলো কমিট করে, তার তুলনায় আপনার অ্যাপ কখনোই আপডেটের এমন কোনো নোটিফিকেশন পায় না যা ক্রমানুসারে আসে না। এটি ডেটা সামঞ্জস্যতা সংক্রান্ত এজ কেসগুলো দূর করে অ্যাপ ডেভেলপমেন্টকে সহজ করে তোলে।
এই সংযুক্ত পাইপলাইনের অর্থ হলো, কোনো রাইট অপারেশন যদি হটস্পট বা লক কনটেনশন তৈরি করে, তবে তা রিড অপারেশনকে নেতিবাচকভাবে প্রভাবিত করতে পারে। যখন রাইট অপারেশন ব্যর্থ হয় বা থ্রটলিংয়ের শিকার হয়, তখন চেঞ্জলগ থেকে সামঞ্জস্যপূর্ণ ডেটার জন্য অপেক্ষা করতে গিয়ে একটি রিড অপারেশন আটকে যেতে পারে। আপনার অ্যাপে এমনটা ঘটলে, আপনি একদিকে যেমন ধীরগতির রাইট অপারেশন দেখতে পারেন, তেমনই অন্যদিকে কোয়েরির ক্ষেত্রেও ধীর প্রতিক্রিয়া সময় লক্ষ্য করতে পারেন। এই সমস্যা থেকে দূরে থাকার মূল চাবিকাঠি হলো হটস্পট এড়িয়ে চলা।
নথি এবং লেখার কাজ ছোট রাখুন।
স্ন্যাপশট লিসেনার ব্যবহার করে অ্যাপ তৈরি করার সময়, আপনি সাধারণত চান যেন ব্যবহারকারীরা ডেটার পরিবর্তন সম্পর্কে দ্রুত জানতে পারে। এটি করার জন্য, সবকিছু ছোট রাখার চেষ্টা করুন। সিস্টেমটি কয়েক ডজন ফিল্ড সহ ছোট ডকুমেন্ট খুব দ্রুত প্রসেস করতে পারে। শত শত ফিল্ড এবং বিশাল ডেটা সহ বড় ডকুমেন্ট প্রসেস করতে বেশি সময় লাগে।
একইভাবে, ল্যাটেন্সি কম রাখতে সংক্ষিপ্ত ও দ্রুত কমিট এবং রাইট অপারেশনকে প্রাধান্য দিন। বড় ব্যাচ রাইটারের দৃষ্টিকোণ থেকে আপনাকে উচ্চতর থ্রুপুট দিতে পারে, কিন্তু এটি আসলে স্ন্যাপশট লিসেনারদের জন্য নোটিফিকেশন টাইম বাড়িয়ে দিতে পারে। অন্যান্য ডেটাবেস সিস্টেম ব্যবহারের তুলনায় এটি প্রায়শই স্বজ্ঞাবিরোধী মনে হয়, যেখানে পারফরম্যান্স উন্নত করার জন্য ব্যাচিং ব্যবহার করা হয়ে থাকে।
দক্ষ লিসেনার ব্যবহার করুন
আপনার ডাটাবেসের রাইট রেট বাড়ার সাথে সাথে, Cloud Firestore ডেটা প্রসেসিংকে অনেকগুলো সার্ভারের মধ্যে ভাগ করে দেয়। Cloud Firestore শার্ডিং অ্যালগরিদম একই কালেকশন বা কালেকশন গ্রুপের ডেটাকে একই চেঞ্জলগ সার্ভারে রাখার চেষ্টা করে। সিস্টেমটি একটি কোয়েরি প্রসেসিং-এ জড়িত সার্ভারের সংখ্যা যথাসম্ভব কম রেখে সম্ভাব্য রাইট থ্রুপুটকে সর্বোচ্চ করার চেষ্টা করে।
তবে, কিছু নির্দিষ্ট প্যাটার্নের কারণে স্ন্যাপশট লিসেনারগুলোর আচরণ সর্বোত্তম নাও হতে পারে। উদাহরণস্বরূপ, যদি আপনার অ্যাপ তার বেশিরভাগ ডেটা একটি বড় সংগ্রহে সংরক্ষণ করে, তাহলে প্রয়োজনীয় সমস্ত ডেটা পাওয়ার জন্য লিসেনারটিকে অনেক সার্ভারের সাথে সংযোগ করতে হতে পারে। আপনি কোয়েরি ফিল্টার প্রয়োগ করলেও এটি সত্যি থাকে। অনেক সার্ভারের সাথে সংযোগ করলে ধীরগতির প্রতিক্রিয়ার ঝুঁকি বাড়ে।
এই ধীরগতির প্রতিক্রিয়াগুলো এড়াতে, আপনার স্কিমা এবং অ্যাপটি এমনভাবে ডিজাইন করুন যাতে সিস্টেমটি অনেকগুলো ভিন্ন সার্ভারে না গিয়েই লিসেনারদের পরিষেবা দিতে পারে। আপনার ডেটাকে কম রাইট রেটযুক্ত ছোট ছোট সংগ্রহে ভাগ করে নিলে সবচেয়ে ভালো ফল পাওয়া যেতে পারে।
এটি একটি রিলেশনাল ডাটাবেসের পারফরম্যান্স কোয়েরিগুলো নিয়ে ভাবার মতোই, যেগুলোর জন্য সম্পূর্ণ টেবিল স্ক্যানের প্রয়োজন হয়। একটি রিলেশনাল ডাটাবেসে, যে কোয়েরির জন্য সম্পূর্ণ টেবিল স্ক্যানের প্রয়োজন হয়, তা একটি স্ন্যাপশট লিসেনারের সমতুল্য, যা ঘন ঘন পরিবর্তিত হওয়া কোনো কালেকশনকে পর্যবেক্ষণ করে। এটি এমন একটি কোয়েরির তুলনায় ধীরগতিতে কাজ করতে পারে, যা ডাটাবেস আরও সুনির্দিষ্ট ইনডেক্স ব্যবহার করে সমাধান করতে পারে। আরও সুনির্দিষ্ট ইনডেক্সসহ একটি কোয়েরি হলো এমন একটি স্ন্যাপশট লিসেনারের মতো, যা একটিমাত্র ডকুমেন্ট বা এমন একটি কালেকশনকে পর্যবেক্ষণ করে যা কম ঘন ঘন পরিবর্তিত হয়। আপনার ব্যবহারের ক্ষেত্রের আচরণ এবং প্রয়োজন ভালোভাবে বোঝার জন্য আপনার অ্যাপটি লোড টেস্ট করা উচিত।
পোলিং কোয়েরিগুলো দ্রুত রাখুন
রেসপন্সিভ রিয়েল-টাইম কোয়েরির আরেকটি গুরুত্বপূর্ণ অংশ হলো ডেটা বুটস্ট্র্যাপ করার জন্য ব্যবহৃত পোলিং কোয়েরিটি যেন দ্রুত এবং কার্যকর হয় তা নিশ্চিত করা। যখন একটি নতুন স্ন্যাপশট লিসেনার প্রথমবার সংযোগ স্থাপন করে, তখন লিসেনারটিকে অবশ্যই সম্পূর্ণ রেজাল্ট সেট লোড করে ব্যবহারকারীর ডিভাইসে পাঠাতে হয়। ধীরগতির কোয়েরি আপনার অ্যাপের রেসপন্সিভনেস কমিয়ে দেয়। উদাহরণস্বরূপ, এর মধ্যে রয়েছে এমন কোয়েরি যা অনেকগুলো ডকুমেন্ট পড়ার চেষ্টা করে অথবা এমন কোয়েরি যা যথাযথ ইনডেক্স ব্যবহার করে না।
কিছু পরিস্থিতিতে একজন লিসেনার লিসেনিং স্টেট থেকে পোলিং স্টেটে ফিরে যেতে পারে। এটি স্বয়ংক্রিয়ভাবে ঘটে এবং SDK ও আপনার অ্যাপের কাছে অদৃশ্য থাকে। নিম্নলিখিত শর্তগুলো একটি পোলিং স্টেট চালু করতে পারে:
- লোডের পরিবর্তনের কারণে সিস্টেম চেঞ্জলগটির ভারসাম্য পুনঃস্থাপন করে ।
- হটস্পটের কারণে ডাটাবেসে ডেটা লেখা ব্যর্থ হয় বা বিলম্বিত হয়।
- সার্ভারের সাময়িক পুনঃসূচনা লিসেনারদের ওপর সাময়িকভাবে প্রভাব ফেলে।
আপনার পোলিং কোয়েরিগুলো যথেষ্ট দ্রুত হলে, পোলিং অবস্থাটি আপনার অ্যাপের ব্যবহারকারীদের কাছে অদৃশ্য হয়ে যায়।
দীর্ঘজীবী শ্রোতাদের পক্ষে থাকুন
Cloud Firestore ব্যবহার করে এমন একটি অ্যাপ তৈরি করার জন্য, লিসেনার খোলা রাখা এবং সেগুলোকে যথাসম্ভব দীর্ঘ সময়ের জন্য সচল রাখাই প্রায়শই সবচেয়ে সাশ্রয়ী উপায়। Cloud Firestore ব্যবহার করার সময়, আপনার অ্যাপে ফেরত আসা ডকুমেন্টগুলোর জন্য আপনাকে বিল করা হয়, কোনো খোলা সংযোগ বজায় রাখার জন্য নয়। একটি দীর্ঘস্থায়ী স্ন্যাপশট লিসেনার তার পুরো জীবনকাল জুড়ে শুধুমাত্র কোয়েরিটি সম্পন্ন করার জন্য প্রয়োজনীয় ডেটা পড়ে। এর মধ্যে একটি প্রাথমিক পোলিং অপারেশন এবং ডেটা পরিবর্তিত হলে নোটিফিকেশন অন্তর্ভুক্ত থাকে। অন্যদিকে, ওয়ান-শট কোয়েরিগুলো এমন ডেটা পুনরায় পড়ে যা অ্যাপটি শেষবার কোয়েরি চালানোর পর থেকে হয়তো পরিবর্তিত হয়নি।
যেসব ক্ষেত্রে আপনার অ্যাপকে উচ্চ হারে ডেটা গ্রহণ করতে হয়, সেখানে স্ন্যাপশট লিসেনার উপযুক্ত নাও হতে পারে। উদাহরণস্বরূপ, যদি আপনার ব্যবহারের ক্ষেত্রে একটি সংযোগের মাধ্যমে দীর্ঘ সময় ধরে প্রতি সেকেন্ডে অনেকগুলো ডকুমেন্ট পাঠানো হয়, তবে কম ফ্রিকোয়েন্সিতে চালিত ওয়ান-শট কোয়েরি ব্যবহার করা শ্রেয় হতে পারে।
এরপর কী হবে
- স্ন্যাপশট লিসেনার কীভাবে ব্যবহার করতে হয় তা শিখুন।
- আরও সেরা অনুশীলন সম্পর্কে পড়ুন।