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