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