আপনার সার্ভারবিহীন অ্যাপকে প্রতি সেকেন্ডে হাজার হাজার অপারেশন বা লক্ষ লক্ষ সমবর্তী ব্যবহারকারীর বাইরে স্কেল করার বিষয়ে নির্দেশনার জন্য এই ডকুমেন্টটি পড়ুন। এই ডকুমেন্টে উন্নত বিষয় অন্তর্ভুক্ত আছে যা আপনাকে সিস্টেম সম্পর্কে গভীরভাবে বুঝতে সাহায্য করবে। আপনি যদি সবেমাত্র Cloud Firestore ব্যবহার করা শুরু করে থাকেন, তাহলে এর পরিবর্তে কুইকস্টার্ট গাইড দেখুন।
Cloud Firestore এবং Firebase মোবাইল/ওয়েব SDK, সার্ভারলেস অ্যাপ ডেভেলপ করার জন্য একটি শক্তিশালী মডেল প্রদান করে যেখানে ক্লায়েন্ট-সাইড কোড সরাসরি ডেটাবেস অ্যাক্সেস করে। SDK-এর মাধ্যমে ক্লায়েন্টরা রিয়েল-টাইমে ডেটার আপডেট শুনতে পান। আপনি রিয়েল-টাইম আপডেট ব্যবহার করে রেসপন্সিভ অ্যাপ তৈরি করতে পারেন যার জন্য সার্ভার ইনফ্রাস্ট্রাকচার প্রয়োজন হয় না। কোনও কিছু সেট-আপ করে চালু করা খুব সহজ হলেও, Cloud Firestore-এর সিস্টেমের সীমাবদ্ধতাগুলি বুঝতে পারলে তা সাহায্য করে, যাতে ট্রাফিক বাড়লে আপনার সার্ভারলেস অ্যাপ স্কেল করতে এবং ভাল পারফর্ম করতে পারে।
আপনার অ্যাপ স্কেল করার ব্যাপারে পরামর্শের জন্য নিম্নলিখিত বিভাগগুলি দেখুন।
আপনার ব্যবহারকারীদের কাছাকাছি কোনও ডেটাবেস লোকেশন বেছে নিন
নিচের ডায়াগ্রামটি রিয়েল-টাইম অ্যাপের আর্কিটেকচার দেখায়:
ব্যবহারকারীর ডিভাইসে (মোবাইল বা ওয়েব) চলা কোনও অ্যাপ Cloud Firestore-এর সাথে কানেকশন তৈরি করলে,
কানেকশনটি একই অঞ্চলে অবস্থিত Cloud Firestore ফ্রন্টএন্ড সার্ভারে
রাউট করা হয়, যেখানে আপনার ডেটাবেস রয়েছে। যেমন,
আপনার ডেটাবেস us-east1-এ থাকলে, কানেকশনও us-east1-এ থাকা
Cloud Firestore ফ্রন্টএন্ডে যায়। এইসব কানেকশন
দীর্ঘস্থায়ী এবং অ্যাপের মাধ্যমে স্পষ্টভাবে বন্ধ না করা পর্যন্ত খোলা থাকে।
ফ্রন্টএন্ড, অন্তর্নিহিত Cloud Firestore স্টোরেজ সিস্টেম থেকে ডেটা পড়ে।
ব্যবহারকারীর ফিজিক্যাল লোকেশন এবং Cloud Firestore ডেটাবেস লোকেশনের মধ্যে দূরত্ব ব্যবহারকারীর অভিজ্ঞতার লেটেন্সিকে প্রভাবিত করে। যেমন, ভারতের কোনও ব্যবহারকারীর অ্যাপ যদি উত্তর আমেরিকার Google Cloud অঞ্চলের ডেটাবেসের সাথে কানেক্ট করে, তাহলে তিনি হয়ত লক্ষ্য করবেন যে অ্যাপটি ধীর গতিতে কাজ করছে এবং ডেটাবেসটি যদি কাছাকাছি কোনও অঞ্চলে, যেমন ভারতে বা এশিয়ার অন্য কোনও অংশে অবস্থিত হত, তাহলে অ্যাপটি আরও দ্রুত কাজ করত।
নির্ভরযোগ্যতার জন্য ডিজাইন করা
নিম্নলিখিত বিষয়গুলি আপনার অ্যাপের নির্ভরযোগ্যতা উন্নত করে বা প্রভাবিত করে:
অফলাইন মোড চালু করুন
Firebase SDK অফলাইন ডেটা পারসিস্টেন্স প্রদান করে। ব্যবহারকারীর ডিভাইসে অ্যাপ Cloud Firestore-এর সাথে কানেক্ট করতে না পারলে, অ্যাপটি স্থানীয়ভাবে ক্যাশে করা ডেটার সাথে কাজ করে ব্যবহারযোগ্য থাকে। এটি নিশ্চিত করে যে ব্যবহারকারীর ইন্টারনেট কানেকশন দুর্বল হলেও বা কয়েক ঘণ্টা বা দিনের জন্য সম্পূর্ণভাবে অ্যাক্সেস হারিয়ে ফেললেও ডেটা অ্যাক্সেস করা যাবে। অফলাইন মোড সম্পর্কে আরও জানতে, অফলাইন ডেটা চালু করুন বিকল্প দেখুন।
অটোমেটিক আবার চেষ্টা করার সুবিধা সম্পর্কে বোঝা
Firebase SDK, অপারেশন আবার চেষ্টা করা এবং বিচ্ছিন্ন কানেকশন আবার স্থাপন করার দায়িত্ব নেয়। এটি সার্ভার রিস্টার্ট করার কারণে বা ক্লায়েন্ট এবং ডেটাবেসের মধ্যে নেটওয়ার্ক সমস্যার কারণে হওয়া ক্ষণস্থায়ী সমস্যাগুলি সমাধান করতে সাহায্য করে।
আঞ্চলিক ও মাল্টি-আঞ্চলিক লোকেশনের মধ্যে থেকে বেছে নিন
আঞ্চলিক এবং মাল্টি-রিজিওনাল লোকেশনের মধ্যে বেছে নেওয়ার সময় অনেকগুলি ট্রেড-অফ থাকে। প্রধান পার্থক্য হল ডেটা কীভাবে রেপ্লিকেট করা হয়। এটি আপনার অ্যাপের উপলভ্যতার গ্যারান্টি দেয়। মাল্টি-রিজিয়ন ইনস্ট্যান্স পরিষেবা দেওয়ার ক্ষেত্রে আরও বেশি নির্ভরযোগ্যতা প্রদান করে এবং আপনার ডেটার স্থায়িত্ব বাড়ায়, তবে এর জন্য খরচ বেশি হয়।
রিয়েল-টাইম কোয়েরি সিস্টেম সম্পর্কে বোঝা
রিয়েল-টাইম কোয়েরি, যাকে স্ন্যাপশট লিসেনারও বলা হয়, অ্যাপকে ডেটাবেসে পরিবর্তন শুনতে এবং ডেটা পরিবর্তন হওয়ার সাথে সাথে কম-লেটেন্সি বিজ্ঞপ্তি পেতে সাহায্য করে। আপডেটের জন্য ডেটাবেসকে পর্যায়ক্রমে পোল করার মাধ্যমে একটি অ্যাপ একই ফলাফল পেতে পারে, তবে এটি প্রায়শই ধীরগতির, আরও ব্যয়বহুল এবং আরও কোডের প্রয়োজন হয়। রিয়েল-টাইম কোয়েরি কীভাবে সেট-আপ ও ব্যবহার করতে হয় তার উদাহরণ দেখতে, রিয়েল-টাইম আপডেট পান বিকল্প দেখুন। নিচের বিভাগগুলি স্ন্যাপশট লিসেনার কীভাবে কাজ করে তার বিবরণ দেয় এবং পারফর্ম্যান্স বজায় রেখে রিয়েল-টাইম কোয়েরি স্কেল করার কিছু পেশাদার পদ্ধতি বর্ণনা করে।
মনে করুন, দুজন ব্যবহারকারী মোবাইল 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 ফ্রন্টএন্ড অন্তর্নিহিত স্টোরেজ সিস্টেমকে কোয়েরি করে। এটি মিলে যাওয়া ডকুমেন্টের সম্পূর্ণ ফলাফল সেট লোড করে। আমরা এটিকে পোলিং কোয়েরি হিসেবে উল্লেখ করি। ব্যবহারকারী এই ডেটা অ্যাক্সেস করতে পারবেন কিনা তা যাচাই করতে, সিস্টেম তারপর ডেটাবেসের Firebase Security Rules মূল্যায়ন করে। ব্যবহারকারী অনুমোদিত হলে, ডেটাবেস ব্যবহারকারীকে ডেটা ফেরত দেয়।
- এরপর ক্লায়েন্ট B-এর কোয়েরি লিসেন মোডে চলে যায়। লিসেনার সাবস্ক্রিপশন হ্যান্ডলারের সাথে রেজিস্টার করে এবং ডেটার আপডেটের জন্য অপেক্ষা করে।
- ক্লায়েন্ট A এখন ডকুমেন্ট পরিবর্তন করার জন্য রাইট অপারেশন পাঠায়।
- ডেটাবেস তার স্টোরেজ সিস্টেমে ডকুমেন্টের পরিবর্তন কমিট করে।
- ট্রানজ্যাকশন হিসেবে, সিস্টেম একই আপডেট ইন্টার্নাল চেঞ্জলগে কমিট করে। পরিবর্তনের লগ, পরিবর্তনগুলি যেভাবে ঘটে সেভাবে কঠোরভাবে ক্রম স্থাপন করে।
- পরিবর্তনের লগ, সাবস্ক্রিপশন হ্যান্ডলারের পুলে আপডেট করা ডেটা ফ্যান-আউট করে।
- আপডেট করা ডকুমেন্ট বর্তমানে রেজিস্টার করা কোনও স্ন্যাপশট লিসেনারের সাথে ম্যাচ করছে কিনা তা দেখার জন্য রিভার্স কোয়েরি ম্যাচিং এক্সিকিউট করা হয়। এই উদাহরণে, ডকুমেন্টটি ক্লায়েন্ট B-এর স্ন্যাপশট লিসেনারের সাথে মিলে যায়। নাম থেকেই বোঝা যাচ্ছে, রিভার্স কোয়েরি ম্যাচিংকে আপনি সাধারণ ডেটাবেস কোয়েরির মতো ভাবতে পারেন, তবে এটি উল্টোভাবে করা হয়। কোনও কোয়েরির সাথে ম্যাচ করে এমন ডকুমেন্ট খুঁজে পেতে, সব ডকুমেন্ট সার্চ করার পরিবর্তে, এটি দক্ষতার সাথে কোয়েরি সার্চ করে যাতে ইনকামিং ডকুমেন্টের সাথে ম্যাচ করে এমন ডকুমেন্ট খুঁজে পাওয়া যায়। কোনও মিল খুঁজে পেলে, সিস্টেমটি স্ন্যাপশট লিসেনারদের কাছে প্রশ্ন সহ ডকুমেন্টটি ফরওয়ার্ড করে। তারপর, শুধুমাত্র অনুমোদিত ব্যবহারকারীরাই যাতে ডেটা পান তা নিশ্চিত করতে, সিস্টেম ডেটাবেসের Firebase নিরাপত্তা নিয়ম মূল্যায়ন করে।
- সিস্টেম, ক্লায়েন্ট B-এর ডিভাইসে SDK-তে ডকুমেন্ট আপডেট ফরওয়ার্ড করে এবং
onSnapshotকলব্যাক ফায়ার করে। লোকাল পারসিস্টেন্স চালু করা থাকলে, SDK লোকাল ক্যাশেতেও আপডেট প্রয়োগ করে।
Cloud Firestore-এর স্কেলেবিলিটির একটি মূল অংশ নির্ভর করে চেঞ্জলগ থেকে সাবস্ক্রিপশন হ্যান্ডলার এবং ফ্রন্টএন্ড সার্ভারে ফ্যান-আউটের উপর। ফ্যান-আউট একটি ডেটা পরিবর্তনকে দক্ষতার সাথে প্রচার করতে দেয় যাতে লক্ষ লক্ষ রিয়েল-টাইম কোয়েরি এবং কানেক্ট করা ব্যবহারকারীদের পরিষেবা দেওয়া যায়। একাধিক জোন (বা মাল্টি-রিজিয়ন ডেপ্লয়মেন্টের ক্ষেত্রে একাধিক অঞ্চল) জুড়ে এইসব কম্পোনেন্টের অনেক রেপ্লিকা চালানোর মাধ্যমে, Cloud Firestore উচ্চ প্রাপ্যতা এবং স্কেলেবিলিটি অর্জন করে।
এটি মনে রাখা গুরুত্বপূর্ণ যে মোবাইল এবং ওয়েব SDK থেকে জারি করা সমস্ত রিড অপারেশন উপরের মডেল অনুসরণ করে। তারা ধারাবাহিকতা বজায় রাখার জন্য পোলিং কোয়েরি এবং তারপরে লিসেন মোড ব্যবহার করে। এটি রিয়েল-টাইম লিসেনার, ডকুমেন্ট ফিরিয়ে আনার জন্য কল এবং ওয়ান-শট কোয়েরি-এর ক্ষেত্রেও প্রযোজ্য। আপনি সিঙ্গেল ডকুমেন্ট রিট্রিভাল এবং ওয়ান-শট কোয়েরিকে স্বল্প-স্থায়ী স্ন্যাপশট লিসেনার হিসেবে ভাবতে পারেন, যেগুলি পারফর্ম্যান্সের ক্ষেত্রে একই ধরনের সীমাবদ্ধতা সহ আসে।
রিয়েল-টাইম কোয়েরি স্কেল করার জন্য পেশাদার পদ্ধতি প্রয়োগ করুন
স্কেলেবল রিয়েল-টাইম কোয়েরি ডিজাইন করতে নিম্নলিখিত পেশাদার পদ্ধতি প্রয়োগ করুন।
সিস্টেমে হাই রাইট ট্রাফিক সম্পর্কে বোঝা
এই বিভাগটি আপনাকে বুঝতে সাহায্য করে যে সিস্টেম কীভাবে ক্রমবর্ধমান সংখ্যক লেখার অনুরোধে সাড়া দেয়।
Cloud Firestore চেঞ্জলগ যা রিয়েল-টাইম কোয়েরি চালায় তা রাইট ট্রাফিক বাড়ার সাথে সাথে অটোমেটিক হরাইজন্টালি স্কেল করে। একটি ডেটাবেসের জন্য লেখার হার একটি সার্ভার যা পরিচালনা করতে পারে তার চেয়ে বেশি হলে, চেঞ্জলগ একাধিক সার্ভার জুড়ে বিভক্ত হয় এবং কোয়েরি প্রসেসিং একটির পরিবর্তে একাধিক সাবস্ক্রিপশন হ্যান্ডলার থেকে ডেটা ব্যবহার করতে শুরু করে। ক্লায়েন্ট ও SDK-এর দিক থেকে, এটি সম্পূর্ণ স্বচ্ছ এবং স্প্লিট হওয়ার সময় অ্যাপের কোনও অ্যাকশন নেওয়ার প্রয়োজন হয় না। নিম্নলিখিত ডায়াগ্রামটি দেখায় যে কীভাবে রিয়েল-টাইম কোয়েরি স্কেল করে:
অটোমেটিক স্কেলিং আপনাকে কোনও সীমা ছাড়াই আপনার রাইট ট্রাফিক বাড়াতে দেয়, কিন্তু ট্রাফিক বাড়ার সাথে সাথে সিস্টেমের প্রতিক্রিয়া জানাতে কিছুটা সময় লাগতে পারে। রাইট হটস্পট তৈরি করা এড়াতে ৫-৫-৫ নিয়মের সাজেশন অনুসরণ করুন। Key Visualizer হল রাইট হটস্পট বিশ্লেষণ করার জন্য একটি উপযোগী টুল।
অনেক অ্যাপের ক্ষেত্রে অর্গ্যানিক গ্রোথ অনুমান করা যায়, যা Cloud Firestore সতর্কতা ছাড়াই মানিয়ে নিতে পারে। তবে, বড় ডেটাসেট ইমপোর্ট করার মতো ব্যাচ ওয়ার্কলোড খুব দ্রুত রাইট অপারেশন বাড়িয়ে দিতে পারে। আপনার অ্যাপ ডিজাইন করার সময়, আপনার রাইট ট্রাফিক কোথা থেকে আসে সে সম্পর্কে সচেতন থাকুন।
রাইট ও রিড কীভাবে ইন্টার্যাক্ট করে তা বুঝুন
আপনি রিয়েল-টাইম কোয়েরি সিস্টেমকে এমন একটি পাইপলাইন হিসেবে ভাবতে পারেন যা রাইট অপারেশনকে পাঠকদের সাথে কানেক্ট করে। কোনও ডকুমেন্ট তৈরি, আপডেট বা মুছে ফেলা হলে, স্টোরেজ সিস্টেম থেকে বর্তমানে রেজিস্টার করা লিসনারে পরিবর্তনটি প্রোপাগেট করা হয়। Cloud Firestore-এর চেঞ্জলগ স্ট্রাকচার শক্তিশালী ধারাবাহিকতার গ্যারান্টি দেয়, যার অর্থ হল, ডেটাবেস ডেটা পরিবর্তন করার সময়ের তুলনায় আপনার অ্যাপ কখনই অর্ডারের বাইরে থাকা আপডেটের বিজ্ঞপ্তি পায় না। ডেটা কনসিস্টেন্সি সংক্রান্ত এজ কেস সরিয়ে দেওয়ার মাধ্যমে এটি অ্যাপ ডেভেলপমেন্টকে সহজ করে তোলে।
এই কানেক্ট করা পাইপলাইনের অর্থ হল, হটস্পট বা লক কনটেনশন তৈরি করা রাইট অপারেশন রিড অপারেশনের উপর নেতিবাচক প্রভাব ফেলতে পারে। রাইট অপারেশন ব্যর্থ হলে বা থ্রটলিংয়ের অভিজ্ঞতা হলে, চেঞ্জলগ থেকে সামঞ্জস্যপূর্ণ ডেটার জন্য অপেক্ষা করার সময় রিড অপারেশন স্থগিত হয়ে যেতে পারে। আপনার অ্যাপে এটি হলে, আপনি হয়ত স্লো রাইট অপারেশন এবং কোয়েরির জন্য সম্পর্কিত স্লো রেসপন্স টাইম দেখতে পাবেন। এই সমস্যা এড়ানোর মূল উপায় হল হটস্পট এড়িয়ে চলা।
ডকুমেন্ট ও রাইট অপারেশন ছোট রাখুন
স্ন্যাপশট লিসেনার সহ অ্যাপ তৈরি করার সময়, আপনি সাধারণত চান যে ব্যবহারকারীরা ডেটা পরিবর্তন সম্পর্কে দ্রুত জানতে পারুন। এটি করতে, ভিডিও ছোট রাখার চেষ্টা করুন। সিস্টেমটি খুব দ্রুত সিস্টেমের মাধ্যমে কয়েক ডজন ফিল্ড সহ ছোট ডকুমেন্ট পুশ করতে পারে। শত শত ফিল্ড ও প্রচুর ডেটা সহ বড় ডকুমেন্ট প্রসেস করতে বেশি সময় লাগে।
একইভাবে, লেটেন্সি কম রাখতে ছোট, দ্রুত কমিট ও রাইট অপারেশনকে অগ্রাধিকার দিন। বড় ব্যাচ আপনাকে লেখকের দৃষ্টিকোণ থেকে উচ্চতর থ্রুপুট দিতে পারে কিন্তু আসলে স্ন্যাপশট শ্রোতাদের জন্য বিজ্ঞপ্তি সময় বাড়াতে পারে। অন্যান্য ডেটাবেস সিস্টেম ব্যবহার করার তুলনায় এটি প্রায়শই বিপরীতধর্মী হয়, যেখানে পারফর্ম্যান্স উন্নত করার জন্য আপনি ব্যাচিং ব্যবহার করতে পারেন।
দক্ষ লিসনার ব্যবহার করুন
আপনার ডেটাবেসের জন্য রাইট রেট বাড়ার সাথে সাথে, Cloud Firestore অনেক সার্ভার জুড়ে ডেটা প্রসেসিংকে স্প্লিট করে। Cloud Firestore-এর শার্ডিং অ্যালগরিদম একই কালেকশন বা কালেকশন গ্রুপের ডেটা একই চেঞ্জলগ সার্ভারে কো-লোকেট করার চেষ্টা করে। The system tries to maximize the possible write throughput while keeping the number of servers involved in the processing of a query as low as possible.
তবে, কিছু প্যাটার্ন এখনও স্ন্যাপশট লিসনারের জন্য সাবঅপ্টিমাল আচরণের কারণ হতে পারে। যেমন, আপনার অ্যাপ যদি বেশিরভাগ ডেটা একটি বড় কালেকশনে স্টোর করে, তাহলে প্রয়োজনীয় সব ডেটা পেতে লিসেনারকে অনেক সার্ভারের সাথে কানেক্ট করতে হতে পারে। আপনি কোয়েরি ফিল্টার প্রয়োগ করলেও এটি প্রযোজ্য হবে। অনেক সার্ভারের সাথে কানেক্ট করলে, ধীরে উত্তর পাওয়ার ঝুঁকি বেড়ে যায়।
এই ধরনের ধীরগতির রেসপন্স এড়াতে, আপনার স্কিমা এবং অ্যাপ এমনভাবে ডিজাইন করুন যাতে সিস্টেম অনেকগুলি বিভিন্ন সার্ভারে না গিয়ে শ্রোতাদের পরিষেবা দিতে পারে। আপনার ডেটা ছোট ছোট সংগ্রহে ভাগ করে কম রাইট রেট সহ ব্যবহার করলে সবচেয়ে ভালো কাজ করতে পারে।
এটি রিলেশনাল ডেটাবেসে পারফর্ম্যান্স কোয়েরি সম্পর্কে চিন্তাভাবনা করার মতো, যার জন্য সম্পূর্ণ টেবিল স্ক্যান করতে হয়। রিলেশনাল ডেটাবেসে, যে কোয়েরির জন্য সম্পূর্ণ টেবিল স্ক্যান করতে হয়, সেটি হল হাই-চার্ন কালেকশন দেখতে থাকা স্ন্যাপশট লিসেনারের সমতুল্য। এটি আরও নির্দিষ্ট ইন্ডেক্স ব্যবহার করে ডেটাবেস পরিবেশন করতে পারে এমন কোয়েরির তুলনায় ধীরে কাজ করতে পারে। আরও নির্দিষ্ট ইন্ডেক্স সহ কোয়েরি হল স্ন্যাপশট লিসেনারের মতো যা একটি ডকুমেন্ট বা কালেকশন দেখে যেটি খুব কম পরিবর্তিত হয়। আপনার অ্যাপের ব্যবহার ও প্রয়োজনীয়তা সম্পর্কে আরও ভালোভাবে বুঝতে, অ্যাপের লোড টেস্ট করা উচিত।
পোলিং কোয়েরি দ্রুত রাখুন
রেসপন্সিভ রিয়েল-টাইম কোয়েরির আরেকটি গুরুত্বপূর্ণ অংশ হল, ডেটা বুটস্ট্র্যাপ করার জন্য পোলিং কোয়েরি যাতে দ্রুত ও দক্ষ হয় তা নিশ্চিত করা। প্রথমবার কোনও নতুন স্ন্যাপশট লিসেনার কানেক্ট করলে, লিসেনারকে অবশ্যই সম্পূর্ণ ফলাফল সেট লোড করতে হবে এবং ব্যবহারকারীর ডিভাইসে পাঠাতে হবে। স্লো কোয়েরি আপনার অ্যাপকে কম রেসপন্সিভ করে তোলে। এর মধ্যে, উদাহরণস্বরূপ, এমন কোয়েরি অন্তর্ভুক্ত রয়েছে যা অনেক ডকুমেন্ট পড়ার চেষ্টা করে বা এমন কোয়েরি যা উপযুক্ত ইন্ডেক্স ব্যবহার করে না।
কিছু পরিস্থিতিতে, লিসনার শোনার অবস্থা থেকে পোলিং অবস্থায় ফিরে যেতে পারে। এটি অটোমেটিক হয় এবং SDK ও আপনার অ্যাপের ক্ষেত্রে স্বচ্ছ থাকে। নিম্নলিখিত পরিস্থিতি পোলিং স্টেট ট্রিগার করতে পারে:
- লোড পরিবর্তনের কারণে সিস্টেম চেঞ্জলগ আবার ব্যালেন্স করে।
- হটস্পটের কারণে ডেটাবেসে রাইট করার সময় সমস্যা হয় বা দেরি হয়।
- ট্রানজিয়েন্ট সার্ভার রিস্টার্ট করার ফলে শ্রোতারা সাময়িকভাবে প্রভাবিত হন।
আপনার পোলিং কোয়েরি যথেষ্ট দ্রুত হলে, পোলিং স্টেট আপনার অ্যাপের ব্যবহারকারীদের কাছে স্বচ্ছ হয়ে ওঠে।
দীর্ঘস্থায়ী শ্রোতাদের পক্ষে
Cloud Firestore ব্যবহার করে এমন অ্যাপ তৈরি করার জন্য, লিসেনার খোলা এবং যতটা সম্ভব দীর্ঘ সময়ের জন্য চালু রাখা প্রায়শই সবচেয়ে সাশ্রয়ী উপায়। Cloud Firestore ব্যবহার করার সময়, আপনার অ্যাপে ফেরত আসা ডকুমেন্টের জন্য আপনাকে বিল করা হয়, ওপেন কানেকশন বজায় রাখার জন্য নয়। একটি দীর্ঘস্থায়ী স্ন্যাপশট লিসেনার তার লাইফটাইম জুড়ে কোয়েরি পরিবেশন করার জন্য শুধুমাত্র প্রয়োজনীয় ডেটা পড়ে। এর মধ্যে প্রাথমিক পোলিং অপারেশন এবং ডেটা পরিবর্তন হলে বিজ্ঞপ্তি পাঠানোর সুবিধা অন্তর্ভুক্ত। অন্যদিকে, ওয়ান-শট কোয়েরি ডেটা আবার পড়ে, যা অ্যাপ শেষবার কোয়েরি এক্সিকিউট করার পর থেকে পরিবর্তিত নাও হতে পারে।
আপনার অ্যাপকে যদি বেশি রেটে ডেটা ব্যবহার করতে হয়, তাহলে স্ন্যাপশট লিসেনার উপযুক্ত নাও হতে পারে। যেমন, আপনার ব্যবহারের ক্ষেত্রে যদি দীর্ঘ সময় ধরে কানেকশনের মাধ্যমে প্রতি সেকেন্ডে অনেক ডকুমেন্ট পুশ করা হয়, তাহলে কম ফ্রিকোয়েন্সিতে চলা ওয়ান-শট কোয়েরি বেছে নেওয়া ভালো হতে পারে।
এরপর কী
- স্ন্যাপশট লিসেনার কীভাবে ব্যবহার করতে হয় তা জানুন।
- আরও পেশাদার পদ্ধতি সম্পর্কে পড়ুন।