স্কেল এ পড়া এবং লেখা বুঝতে

উচ্চ কার্যকারিতা এবং নির্ভরযোগ্যতার জন্য আপনার অ্যাপ্লিকেশনগুলিকে আর্কিটেক্ট করার বিষয়ে সচেতন সিদ্ধান্ত নিতে এই নথিটি পড়ুন। এই নথিতে উন্নত Cloud Firestore বিষয় অন্তর্ভুক্ত রয়েছে। আপনি যদি সবেমাত্র Cloud Firestore দিয়ে শুরু করেন, তাহলে এর পরিবর্তে দ্রুত স্টার্ট নির্দেশিকাটি দেখুন।

Cloud Firestore হল Firebase এবং Google Cloud থেকে মোবাইল ডিভাইস, ওয়েব এবং সার্ভার ডেভেলপমেন্টের জন্য একটি নমনীয়, মাপযোগ্য ডাটাবেস। Cloud Firestore সাথে শুরু করা এবং সমৃদ্ধ এবং শক্তিশালী অ্যাপ্লিকেশন লেখা খুবই সহজ।

আপনার ডাটাবেসের আকার এবং ট্র্যাফিক বৃদ্ধির সাথে সাথে আপনার অ্যাপ্লিকেশনগুলি ভালভাবে কাজ করে চলেছে তা নিশ্চিত করতে, এটি Cloud Firestore ব্যাকএন্ডে পড়া এবং লেখার মেকানিক্স বুঝতে সহায়তা করে। আপনাকে অবশ্যই স্টোরেজ স্তরের সাথে আপনার পড়া এবং লেখার মিথস্ক্রিয়া এবং কর্মক্ষমতা প্রভাবিত করতে পারে এমন অন্তর্নিহিত সীমাবদ্ধতাগুলি বুঝতে হবে।

আপনার অ্যাপ্লিকেশন আর্কিটেক্ট করার আগে সেরা অনুশীলনের জন্য নিম্নলিখিত বিভাগগুলি দেখুন।

উচ্চ স্তরের উপাদান বুঝতে

নিম্নলিখিত চিত্রটি একটি Cloud Firestore API অনুরোধের সাথে জড়িত উচ্চ স্তরের উপাদানগুলিকে দেখায়৷

উচ্চ স্তরের উপাদান

Cloud Firestore SDK এবং ক্লায়েন্ট লাইব্রেরি

Cloud Firestore বিভিন্ন প্ল্যাটফর্মের জন্য SDK এবং ক্লায়েন্ট লাইব্রেরি সমর্থন করে। যদিও একটি অ্যাপ Cloud Firestore এপিআই-তে সরাসরি HTTP এবং RPC কল করতে পারে, ক্লায়েন্ট লাইব্রেরিগুলি API ব্যবহার সহজ করতে এবং সর্বোত্তম অনুশীলনগুলি বাস্তবায়নের জন্য বিমূর্ততার একটি স্তর সরবরাহ করে। তারা অতিরিক্ত বৈশিষ্ট্য যেমন অফলাইন অ্যাক্সেস, ক্যাশে ইত্যাদি প্রদান করতে পারে।

গুগল ফ্রন্ট এন্ড (GFE)

এটি একটি অবকাঠামো পরিষেবা যা সমস্ত Google ক্লাউড পরিষেবাগুলির জন্য সাধারণ৷ GFE আগত অনুরোধগুলি গ্রহণ করে এবং সেগুলিকে প্রাসঙ্গিক Google পরিষেবাতে ফরোয়ার্ড করে (এই প্রসঙ্গে Cloud Firestore পরিষেবা)৷ এটি অন্যান্য গুরুত্বপূর্ণ কার্যকারিতা প্রদান করে, যার মধ্যে পরিষেবা অস্বীকারের আক্রমণ থেকে সুরক্ষা রয়েছে৷

Cloud Firestore পরিষেবা

Cloud Firestore পরিষেবা API অনুরোধে পরীক্ষা করে, যার মধ্যে প্রমাণীকরণ, অনুমোদন, কোটা চেক এবং নিরাপত্তা নিয়ম রয়েছে এবং লেনদেন পরিচালনা করে। এই Cloud Firestore পরিষেবাটিতে একটি স্টোরেজ ক্লায়েন্ট রয়েছে যা ডেটা পড়ার এবং লেখার জন্য স্টোরেজ স্তরের সাথে ইন্টারঅ্যাক্ট করে।

Cloud Firestore স্টোরেজ লেয়ার

Cloud Firestore স্টোরেজ স্তরটি Cloud Firestore দ্বারা সরবরাহ করা ডেটা এবং মেটাডেটা এবং সংশ্লিষ্ট ডাটাবেস বৈশিষ্ট্য উভয়ই সঞ্চয় করার জন্য দায়ী। নিম্নলিখিত বিভাগগুলি Cloud Firestore স্টোরেজ স্তরে ডেটা কীভাবে সংগঠিত হয় এবং কীভাবে সিস্টেম স্কেল হয় তা বর্ণনা করে৷ ডেটা কীভাবে সংগঠিত হয় সে সম্পর্কে শেখা আপনাকে একটি মাপযোগ্য ডেটা মডেল ডিজাইন করতে এবং Cloud Firestore সেরা অনুশীলনগুলি আরও ভালভাবে বুঝতে সাহায্য করতে পারে৷

কী রেঞ্জ এবং স্প্লিট

Cloud Firestore একটি NoSQL, নথি-ভিত্তিক ডাটাবেস। আপনি নথিতে ডেটা সঞ্চয় করেন, যা সংগ্রহের শ্রেণিবিন্যাসে সংগঠিত হয়। সংগ্রহের শ্রেণিবিন্যাস এবং নথি আইডি প্রতিটি নথির জন্য একটি একক কীতে অনুবাদ করা হয়। নথিগুলি এই একক কী দ্বারা যৌক্তিকভাবে সংরক্ষণ করা হয় এবং অভিধানিকভাবে আদেশ করা হয়। আমরা কী পরিসীমা শব্দটি ব্যবহার করি একটি আভিধানিকভাবে সংলগ্ন কীগুলির পরিসর বোঝাতে।

একটি সাধারণ Cloud Firestore ডাটাবেস একটি একক ফিজিক্যাল মেশিনে ফিট করার জন্য খুব বড়। এমন পরিস্থিতিও রয়েছে যেখানে ডেটার কাজের চাপ একটি মেশিনের পক্ষে পরিচালনা করার পক্ষে খুব ভারী। বড় কাজের চাপ সামলানোর জন্য, Cloud Firestore ডেটাকে আলাদা আলাদা অংশে বিভাজন করে যা একাধিক মেশিন বা স্টোরেজ সার্ভারে সংরক্ষণ এবং পরিবেশন করা যেতে পারে। এই পার্টিশনগুলি ডাটাবেস টেবিলে কী রেঞ্জের ব্লকগুলিতে তৈরি করা হয় যাকে স্প্লিট বলা হয়।

সিঙ্ক্রোনাস প্রতিলিপি

এটা মনে রাখা গুরুত্বপূর্ণ যে ডাটাবেস সবসময় স্বয়ংক্রিয়ভাবে এবং সিঙ্ক্রোনাসভাবে প্রতিলিপি করা হচ্ছে। ডেটার বিভাজনগুলির প্রতিলিপিগুলি বিভিন্ন অঞ্চলে রয়েছে যাতে সেগুলি উপলব্ধ রাখা যায় এমনকি যখন একটি অঞ্চল অ্যাক্সেসযোগ্য হয়ে ওঠে। বিভক্তের বিভিন্ন অনুলিপিতে সামঞ্জস্যপূর্ণ প্রতিলিপি ঐক্যমতের জন্য প্যাক্সোস অ্যালগরিদম দ্বারা পরিচালিত হয়। প্রতিটি বিভক্তির একটি প্রতিলিপি পক্সোস নেতা হিসাবে কাজ করার জন্য নির্বাচিত হয়, যেটি সেই বিভক্তিতে লেখাগুলি পরিচালনা করার জন্য দায়ী। সিঙ্ক্রোনাস প্রতিলিপি আপনাকে সবসময় Cloud Firestore থেকে ডেটার সর্বশেষ সংস্করণ পড়তে সক্ষম হওয়ার ক্ষমতা দেয়৷

এর সামগ্রিক ফলাফল হল একটি পরিমাপযোগ্য এবং অত্যন্ত উপলব্ধ সিস্টেম যা পড়া এবং লেখা উভয়ের জন্যই কম বিলম্ব প্রদান করে, ভারী কাজের চাপ এবং খুব বড় পরিসরে।

ডেটা লেআউট

Cloud Firestore একটি স্কিমলেস ডকুমেন্ট ডাটাবেস। যাইহোক, অভ্যন্তরীণভাবে এটি তার স্টোরেজ লেয়ারে দুটি রিলেশনাল ডাটাবেস-স্টাইল টেবিলে প্রাথমিকভাবে ডেটা রাখে:

  • ডকুমেন্ট টেবিল: ডকুমেন্ট এই টেবিলে সংরক্ষণ করা হয়।
  • সূচীপত্রের সারণী: সূচী এন্ট্রি যা দক্ষতার সাথে ফলাফল পাওয়া সম্ভব করে এবং সূচকের মান অনুসারে সাজানো হয় সেগুলি এই টেবিলে সংরক্ষিত হয়।

নিম্নলিখিত চিত্রটি দেখায় যে Cloud Firestore ডাটাবেসের জন্য টেবিলগুলি বিভক্তগুলির সাথে কেমন হতে পারে৷ বিভক্তগুলি তিনটি ভিন্ন অঞ্চলে প্রতিলিপি করা হয় এবং প্রতিটি বিভাজনের জন্য একটি নির্ধারিত প্যাক্সোস নেতা থাকে।

ডেটা লেআউট

একক অঞ্চল বনাম বহু-অঞ্চল

যখন আপনি একটি ডাটাবেস তৈরি করেন, আপনাকে অবশ্যই একটি অঞ্চল বা বহু-অঞ্চল নির্বাচন করতে হবে।

একটি একক আঞ্চলিক অবস্থান হল একটি নির্দিষ্ট ভৌগলিক অবস্থান, যেমন us-west1 । একটি Cloud Firestore ডাটাবেসের ডেটার বিভাজন নির্বাচিত অঞ্চলের বিভিন্ন অঞ্চলে প্রতিলিপি রয়েছে, যেমনটি আগে ব্যাখ্যা করা হয়েছে।

একটি মাল্টি-রিজিওন অবস্থানে এমন অঞ্চলগুলির একটি সংজ্ঞায়িত সেট থাকে যেখানে ডাটাবেসের প্রতিলিপিগুলি সংরক্ষণ করা হয়। Cloud Firestore একটি মাল্টি-রিজিওন ডিপ্লোয়মেন্টে, দুটি অঞ্চলে ডাটাবেসের সম্পূর্ণ ডেটার সম্পূর্ণ প্রতিলিপি রয়েছে। একটি তৃতীয় অঞ্চলে একটি সাক্ষী প্রতিরূপ রয়েছে যা ডেটার সম্পূর্ণ সেট বজায় রাখে না, তবে প্রতিলিপিতে অংশ নেয়। একাধিক অঞ্চলের মধ্যে ডেটা প্রতিলিপি করে, একটি সমগ্র অঞ্চল হারিয়ে গেলেও ডেটা লেখা এবং পড়ার জন্য উপলব্ধ।

একটি অঞ্চলের অবস্থান সম্পর্কে আরও তথ্যের জন্য, Cloud Firestore অবস্থানগুলি দেখুন।

একক অঞ্চল বনাম বহু-অঞ্চল

Cloud Firestore লেখার জীবন বুঝুন

একটি Cloud Firestore ক্লায়েন্ট একটি একক নথি তৈরি, আপডেট বা মুছে ডেটা লিখতে পারে। একটি একক নথিতে লেখার জন্য সঞ্চয়স্থান স্তরে পারমাণবিকভাবে নথি এবং এর সম্পর্কিত সূচক এন্ট্রি উভয়ই আপডেট করা প্রয়োজন। Cloud Firestore একাধিক রিড এবং/অথবা এক বা একাধিক নথিতে লেখা সমন্বিত পারমাণবিক ক্রিয়াকলাপগুলিকে সমর্থন করে।

সব ধরনের লেখার জন্য, Cloud Firestore রিলেশনাল ডাটাবেসের ACID বৈশিষ্ট্য (পরমাণু, সামঞ্জস্য, বিচ্ছিন্নতা এবং স্থায়িত্ব) প্রদান করে। Cloud Firestore ক্রমিকযোগ্যতা প্রদান করে, যার অর্থ সমস্ত লেনদেন একটি সিরিয়াল ক্রমে সম্পাদিত হওয়ার মতো দেখায়৷

একটি লিখিত লেনদেনের উচ্চ-স্তরের পদক্ষেপ

Cloud Firestore ক্লায়েন্ট যখন পূর্বে উল্লিখিত যেকোন পদ্ধতি ব্যবহার করে একটি লিখন বা একটি লেনদেন করে, অভ্যন্তরীণভাবে এটি স্টোরেজ স্তরে একটি ডাটাবেস রিড-রাইট লেনদেন হিসাবে সম্পাদিত হয়। লেনদেনটি Cloud Firestore পূর্বে উল্লিখিত ACID বৈশিষ্ট্যগুলি প্রদান করতে সক্ষম করে৷

একটি লেনদেনের প্রথম ধাপ হিসাবে, Cloud Firestore বিদ্যমান নথিটি পড়ে, এবং নথি টেবিলের ডেটাতে করা মিউটেশনগুলি নির্ধারণ করে৷

এর মধ্যে নিম্নরূপ সূচী সারণীতে প্রয়োজনীয় আপডেট করা অন্তর্ভুক্ত:

  • নথিতে যে ক্ষেত্রগুলি যোগ করা হচ্ছে সেগুলির জন্য ইনডেক্স টেবিলে সংশ্লিষ্ট সন্নিবেশ প্রয়োজন৷
  • যে ক্ষেত্রগুলি নথিগুলি থেকে সরানো হচ্ছে সেগুলির জন্য সূচী সারণীতে সংশ্লিষ্ট মুছে ফেলা দরকার৷
  • নথিতে যে ক্ষেত্রগুলি পরিবর্তন করা হচ্ছে, সেগুলির জন্য ইনডেক্স টেবিলে মুছে ফেলা (পুরানো মানগুলির জন্য) এবং সন্নিবেশ (নতুন মানগুলির জন্য) উভয়ই প্রয়োজন৷

পূর্বে উল্লিখিত মিউটেশনগুলি গণনা করতে, Cloud Firestore প্রকল্পের জন্য ইন্ডেক্সিং কনফিগারেশন পড়ে। ইন্ডেক্সিং কনফিগারেশন একটি প্রকল্পের জন্য সূচী সম্পর্কে তথ্য সঞ্চয় করে। Cloud Firestore দুটি ধরণের সূচক ব্যবহার করে: একক-ক্ষেত্র এবং যৌগিক। Cloud Firestore তৈরি সূচীগুলির বিস্তারিত বোঝার জন্য, Cloud Firestore সূচকের প্রকারগুলি দেখুন৷

একবার মিউটেশনগুলি গণনা করা হলে, Cloud Firestore একটি লেনদেনের মধ্যে সেগুলি সংগ্রহ করে এবং তারপরে এটি করে।

স্টোরেজ লেয়ারে একটি লেখার লেনদেন বুঝুন

যেমনটি আগে আলোচনা করা হয়েছে, Cloud Firestore একটি লেখার সাথে স্টোরেজ স্তরে একটি রিড-রাইট লেনদেন জড়িত। ডেটা লেআউটের উপর নির্ভর করে, একটি লেখার মধ্যে এক বা একাধিক বিভাজন থাকতে পারে যেমন ডেটা লেআউটে দেখা যায়।

নিম্নলিখিত চিত্রে, Cloud Firestore ডাটাবেসের একটি একক জোনে তিনটি আলাদা স্টোরেজ সার্ভারে হোস্ট করা আটটি স্প্লিট (1-8 চিহ্নিত) রয়েছে এবং প্রতিটি বিভাজন 3টি (বা তার বেশি) বিভিন্ন অঞ্চলে প্রতিলিপি করা হয়েছে৷ প্রতিটি বিভাজনের একটি প্যাক্সোস নেতা থাকে, যা বিভিন্ন বিভাজনের জন্য একটি ভিন্ন জোনে থাকতে পারে।

<span শ্রেণী= ক্লাউড ফায়ারস্টোর ডাটাবেস বিভাজন">

একটি Cloud Firestore ডাটাবেস বিবেচনা করুন যেখানে নিম্নরূপ Restaurants সংগ্রহ রয়েছে:

রেস্টুরেন্ট সংগ্রহ

Cloud Firestore ক্লায়েন্ট priceCategory ক্ষেত্রের মান আপডেট করে Restaurant সংগ্রহের একটি নথিতে নিম্নলিখিত পরিবর্তনের জন্য অনুরোধ করে।

সংগ্রহে থাকা একটি নথিতে পরিবর্তন করুন

নিম্নলিখিত উচ্চ-স্তরের পদক্ষেপগুলি লেখার অংশ হিসাবে কী ঘটে তা বর্ণনা করে:

  1. একটি রিড-রাইট লেনদেন তৈরি করুন।
  2. স্টোরেজ লেয়ার থেকে ডকুমেন্ট টেবিল থেকে Restaurants সংগ্রহে restaurant1 ডকুমেন্ট পড়ুন।
  3. ইনডেক্স টেবিল থেকে নথির জন্য সূচী পড়ুন।
  4. ডেটাতে করা মিউটেশনগুলি গণনা করুন। এই ক্ষেত্রে, পাঁচটি মিউটেশন রয়েছে:
    • M1: priceCategory ক্ষেত্রের মান পরিবর্তন প্রতিফলিত করতে ডকুমেন্ট টেবিলে restaurant1 এর জন্য সারি আপডেট করুন।
    • M2 এবং M3: ইনডেক্স টেবিলে priceCategory পুরানো মানের জন্য সারিগুলি মুছুন ইনডেক্সের অবরোহ এবং ঊর্ধ্বে।
    • M4 এবং M5: সূচী সারণীতে priceCategory নতুন মানের জন্য সারিগুলি সন্নিবেশ করান সূচী অবরোহ ও ঊর্ধ্বে।
  5. এই মিউটেশন কমিট.

Cloud Firestore পরিষেবার স্টোরেজ ক্লায়েন্ট সেই স্প্লিটগুলি দেখে যা পরিবর্তন করার জন্য সারিগুলির কীগুলির মালিক৷ আসুন একটি কেস বিবেচনা করি যেখানে স্প্লিট 3 M1 পরিবেশন করে এবং স্প্লিট 6 M2-M5 পরিবেশন করে। অংশগ্রহণকারী হিসাবে এই সমস্ত বিভাজন জড়িত একটি বিতরণ লেনদেন আছে। অংশগ্রহণকারী বিভাজন অন্য কোনো বিভাজনও অন্তর্ভুক্ত করতে পারে যেখান থেকে পঠন-লিখতে লেনদেনের অংশ হিসেবে ডেটা আগে পড়া হয়েছিল।

কমিটের অংশ হিসাবে কী ঘটে তা নিম্নলিখিত পদক্ষেপগুলি বর্ণনা করে:

  1. স্টোরেজ ক্লায়েন্ট একটি কমিট জারি করে। কমিটটিতে M1-M5 মিউটেশন রয়েছে।
  2. স্প্লিট 3 এবং 6 এই লেনদেনের অংশগ্রহণকারী। অংশগ্রহণকারীদের মধ্যে একজনকে সমন্বয়কারী হিসাবে নির্বাচিত করা হয়, যেমন স্প্লিট 3। সমন্বয়কারীর কাজ হল সমস্ত অংশগ্রহণকারীদের মধ্যে লেনদেন হয় কমিট বা পারমাণবিকভাবে বাতিল করা হয় তা নিশ্চিত করা।
    • এই বিভাজনগুলির নেতা প্রতিলিপিগুলি অংশগ্রহণকারীদের এবং সমন্বয়কারীদের দ্বারা সম্পন্ন কাজের জন্য দায়ী।
  3. প্রতিটি অংশগ্রহণকারী এবং সমন্বয়কারী তাদের নিজ নিজ প্রতিলিপি সহ একটি Paxos অ্যালগরিদম চালায়।
    • নেতা প্রতিলিপিগুলির সাথে একটি প্যাক্সোস অ্যালগরিদম চালান। কোরাম অর্জিত হয় যদি বেশিরভাগ প্রতিলিপি লিডারের কাছে প্রতিক্রিয়া ok to commit ।
    • প্রতিটি অংশগ্রহণকারী তারপর সমন্বয়কারীকে অবহিত করে যখন তারা প্রস্তুত হয় (দুই-পর্যায়ের প্রতিশ্রুতির প্রথম পর্যায়)। যদি কোনো অংশগ্রহণকারী লেনদেন করতে না পারে, তাহলে পুরো লেনদেন aborts ।
  4. একবার সমন্বয়কারী জানে যে সমস্ত অংশগ্রহণকারীরা, নিজে সহ, প্রস্তুত, এটি সমস্ত অংশগ্রহণকারীদের কাছে accept লেনদেনের ফলাফলের সাথে যোগাযোগ করে (দুই-পর্যায়ের প্রতিশ্রুতির দ্বিতীয় পর্যায়)। এই পর্যায়ে, প্রতিটি অংশগ্রহণকারী স্থিতিশীল সঞ্চয়স্থানের প্রতিশ্রুতিবদ্ধ সিদ্ধান্ত রেকর্ড করে এবং লেনদেন প্রতিশ্রুতিবদ্ধ হয়।
  5. সমন্বয়কারী Cloud Firestore স্টোরেজ ক্লায়েন্টকে উত্তর দেয় যে লেনদেন করা হয়েছে। সমান্তরালভাবে, সমন্বয়কারী এবং সমস্ত অংশগ্রহণকারীরা ডেটাতে মিউটেশনগুলি প্রয়োগ করে।

প্রতিশ্রুতিবদ্ধ জীবনচক্র

যখন Cloud Firestore ডাটাবেস ছোট হয়, তখন এটি ঘটতে পারে যে একটি একক বিভাজন M1-M5 মিউটেশনের সমস্ত কীগুলির মালিক। এই ধরনের ক্ষেত্রে, লেনদেনে শুধুমাত্র একজন অংশগ্রহণকারী থাকে এবং পূর্বে উল্লিখিত দুই-পর্যায়ের প্রতিশ্রুতির প্রয়োজন হয় না, এইভাবে লেখাগুলি দ্রুততর হয়।

বহু-অঞ্চলে লেখেন

একটি বহু-অঞ্চল স্থাপনায়, অঞ্চল জুড়ে প্রতিলিপিগুলির বিস্তার প্রাপ্যতা বাড়ায়, কিন্তু কার্যক্ষমতার খরচ সহ আসে। বিভিন্ন অঞ্চলে প্রতিলিপিগুলির মধ্যে যোগাযোগের জন্য দীর্ঘ রাউন্ড ট্রিপ সময় লাগে। তাই, Cloud Firestore অপারেশনের জন্য বেসলাইন লেটেন্সি একক অঞ্চলের স্থাপনার তুলনায় সামান্য বেশি।

আমরা প্রতিলিপিগুলিকে এমনভাবে কনফিগার করি যাতে বিভাজনের নেতৃত্ব সর্বদা প্রাথমিক অঞ্চলে থাকে। Cloud Firestore সার্ভারে যেখান থেকে ট্রাফিক ইনকাম করা হয় সেটি হল প্রাথমিক অঞ্চল। নেতৃত্বের এই সিদ্ধান্ত Cloud Firestore স্টোরেজ ক্লায়েন্ট এবং রেপ্লিকা লিডার (বা মাল্টি-বিভক্ত লেনদেনের জন্য সমন্বয়কারী) মধ্যে যোগাযোগের রাউন্ড-ট্রিপ বিলম্বকে কমিয়ে দেয়।

Cloud Firestore প্রতিটি লেখার সাথে Cloud Firestore রিয়েল-টাইম ইঞ্জিনের সাথে কিছু মিথস্ক্রিয়াও জড়িত। রিয়েল-টাইম কোয়েরি সম্পর্কে আরও তথ্যের জন্য, স্কেলে রিয়েল-টাইম কোয়েরি বুঝতে দেখুন।

Cloud Firestore পড়ার জীবনকে বুঝুন

এই বিভাগটি Cloud Firestore স্বতন্ত্র, নন-রিয়েলটাইম পঠিত বিষয়গুলি নিয়ে আলোচনা করে। অভ্যন্তরীণভাবে, Cloud Firestore সার্ভার দুটি প্রধান পর্যায়ে এই প্রশ্নগুলির বেশিরভাগ পরিচালনা করে:

  1. সূচী সারণীতে একটি একক পরিসর স্ক্যান
  2. আগের স্ক্যানের ফলাফলের উপর ভিত্তি করে ডকুমেন্ট টেবিলে পয়েন্ট লুকআপ
Cloud Firestore এমন কিছু প্রশ্ন থাকতে পারে যার জন্য কম প্রক্রিয়াকরণ বা বেশি প্রক্রিয়াকরণের প্রয়োজন (উদাহরণস্বরূপ, IN কোয়েরি)।

স্টোরেজ লেয়ার থেকে পড়া ডেটা অভ্যন্তরীণভাবে একটি ডাটাবেস লেনদেন ব্যবহার করে করা হয় যাতে ধারাবাহিকভাবে পড়া নিশ্চিত করা যায়। যাইহোক, লেখার জন্য ব্যবহৃত লেনদেনের বিপরীতে, এই লেনদেন লক লাগে না। পরিবর্তে, তারা একটি টাইমস্ট্যাম্প বেছে নিয়ে কাজ করে, তারপর সেই টাইমস্ট্যাম্পে সমস্ত পঠন সম্পাদন করে। যেহেতু তারা লকগুলি অর্জন করে না, তাই তারা একযোগে পড়া-লেখার লেনদেনগুলিকে ব্লক করে না। এই লেনদেনটি চালানোর জন্য, Cloud Firestore স্টোরেজ ক্লায়েন্ট একটি টাইমস্ট্যাম্প বাউন্ড নির্দিষ্ট করে, যা স্টোরেজ স্তরকে বলে যে কীভাবে একটি রিড টাইমস্ট্যাম্প বেছে নিতে হয়। Cloud Firestore স্টোরেজ ক্লায়েন্ট দ্বারা বেছে নেওয়া টাইমস্ট্যাম্পের ধরনটি রিড রিকোয়েস্টের রিড অপশন দ্বারা নির্ধারিত হয়।

স্টোরেজ লেয়ারে একটি পঠিত লেনদেন বুঝুন

এই বিভাগটি Cloud Firestore স্টোরেজ লেয়ারে পড়ার ধরন এবং কীভাবে সেগুলি প্রক্রিয়া করা হয় তা বর্ণনা করে।

দৃঢ় পড়া

ডিফল্টরূপে, Cloud Firestore রিডগুলি দৃঢ়ভাবে সামঞ্জস্যপূর্ণ । এই দৃঢ় সামঞ্জস্যের অর্থ হল একটি Cloud Firestore রিড ডেটার সর্বশেষ সংস্করণ প্রদান করে যা পড়া শুরু হওয়া পর্যন্ত প্রতিশ্রুতিবদ্ধ সমস্ত লেখা প্রতিফলিত করে।

একক বিভক্ত পড়া

Cloud Firestore স্টোরেজ ক্লায়েন্ট পড়ার জন্য সারিগুলির কীগুলির মালিকানাধীন বিভক্তগুলি সন্ধান করে৷ আসুন ধরে নিই যে এটিকে পূর্ববর্তী বিভাগ থেকে স্প্লিট 3 থেকে পড়তে হবে। রাউন্ড ট্রিপ লেটেন্সি কমাতে ক্লায়েন্ট নিকটতম প্রতিলিপিতে পড়ার অনুরোধ পাঠায়।

এই মুহুর্তে, নির্বাচিত প্রতিরূপের উপর নির্ভর করে নিম্নলিখিত ক্ষেত্রে ঘটতে পারে:

  • রিড রিকোয়েস্ট লিডার রেপ্লিকাতে যায় (জোন এ)।
    • যেহেতু নেতা সবসময় আপ টু ডেট থাকে, তাই পড়া সরাসরি এগিয়ে যেতে পারে।
  • পড়ার অনুরোধ একটি নন-লিডার রেপ্লিকাতে যায় (যেমন, জোন বি)
    • স্প্লিট 3 এর অভ্যন্তরীণ অবস্থার দ্বারা জানতে পারে যে এটিকে পড়ার জন্য যথেষ্ট তথ্য রয়েছে এবং বিভক্তটি তা করে।
    • স্প্লিট 3 সর্বশেষ তথ্য দেখেছে কিনা তা নিশ্চিত নয়। এটি পঠিত পরিবেশন করার জন্য আবেদন করার জন্য প্রয়োজনীয় শেষ লেনদেনের টাইমস্ট্যাম্পটি চাইতে নেতাকে একটি বার্তা পাঠায়। একবার সেই লেনদেনটি প্রয়োগ করা হলে, পড়া এগিয়ে যেতে পারে।

Cloud Firestore তারপরে তার ক্লায়েন্টকে প্রতিক্রিয়া ফেরত দেয়।

মাল্টি-বিভক্ত পড়া

যে পরিস্থিতিতে একাধিক বিভাজন থেকে রিডগুলি করতে হয়, একই প্রক্রিয়া সমস্ত বিভাজন জুড়ে ঘটে। একবার সমস্ত বিভক্ত থেকে ডেটা ফেরত দেওয়া হলে, Cloud Firestore স্টোরেজ ক্লায়েন্ট ফলাফলগুলিকে একত্রিত করে। Cloud Firestore তারপর এই ডেটা দিয়ে তার ক্লায়েন্টকে সাড়া দেয়।

বাসি পড়ে

Cloud Firestore স্ট্রং রিডগুলি ডিফল্ট মোড। যাইহোক, এটি নেতার সাথে প্রয়োজনীয় যোগাযোগের কারণে সম্ভাব্য উচ্চ বিলম্বের খরচে আসে। প্রায়শই আপনার Cloud Firestore অ্যাপ্লিকেশনটির ডেটার সর্বশেষ সংস্করণ পড়ার প্রয়োজন হয় না এবং কার্যকারিতা এমন ডেটার সাথে ভালভাবে কাজ করে যা কয়েক সেকেন্ডের বাসি হতে পারে।

এই ধরনের ক্ষেত্রে, ক্লায়েন্ট read_time রিড বিকল্পগুলি ব্যবহার করে পুরানো রিডগুলি গ্রহণ করতে বেছে নিতে পারে। এই ক্ষেত্রে, পঠন করা হয় যেহেতু ডেটাটি read_time এ ছিল, এবং নিকটতম প্রতিলিপিটি ইতিমধ্যেই নির্দিষ্ট read_time এ ডেটা রয়েছে তা যাচাই করে নেওয়ার সম্ভাবনা বেশি। লক্ষণীয়ভাবে ভাল পারফরম্যান্সের জন্য, 15 সেকেন্ড একটি যুক্তিসঙ্গত অচলতার মান। এমনকি বাসি পাঠের জন্যও, সারি পাওয়া যায় একে অপরের সাথে সামঞ্জস্যপূর্ণ।

হটস্পট এড়িয়ে চলুন

Cloud Firestore বিভাজনগুলি স্বয়ংক্রিয়ভাবে ছোট ছোট টুকরোগুলিতে বিভক্ত হয়ে যায় যাতে প্রয়োজনের সময় বা মূল স্থান প্রসারিত হলে আরও স্টোরেজ সার্ভারে ট্র্যাফিক পরিবেশনের কাজ বিতরণ করা হয়। অতিরিক্ত ট্র্যাফিক পরিচালনা করার জন্য তৈরি করা স্প্লিটগুলি প্রায় 24 ঘন্টা ধরে রাখা হয় যদিও ট্র্যাফিক চলে যায়। তাই যদি পুনরাবৃত্ত ট্র্যাফিক স্পাইক থাকে, বিভাজন বজায় রাখা হয় এবং যখনই প্রয়োজন হয় তখন আরও বিভাজন চালু করা হয়। এই প্রক্রিয়াগুলি Cloud Firestore ডেটাবেসগুলিকে ক্রমবর্ধমান ট্রাফিক লোড বা ডাটাবেসের আকারের অধীনে অটোস্কেল করতে সহায়তা করে। যাইহোক, নীচে ব্যাখ্যা করা হিসাবে সচেতন হতে কিছু সীমাবদ্ধতা আছে।

সঞ্চয়স্থান এবং লোড বিভক্ত করতে সময় লাগে এবং খুব দ্রুত ট্র্যাফিক র‌্যাম্প করা উচ্চ বিলম্ব বা সময়সীমা অতিক্রম করার ত্রুটির কারণ হতে পারে, সাধারণভাবে হটস্পট হিসাবে উল্লেখ করা হয়, যখন পরিষেবাটি সামঞ্জস্য করে। প্রতি সেকেন্ডে 500টি ক্রিয়াকলাপ সহ একটি ডাটাবেসের সংগ্রহে ট্র্যাফিক বৃদ্ধি করার সময় সর্বোত্তম অনুশীলনটি কী পরিসর জুড়ে অপারেশনগুলি বিতরণ করা। এই ধীরে ধীরে র‌্যাম্প আপ করার পরে, প্রতি পাঁচ মিনিটে 50% পর্যন্ত ট্রাফিক বাড়ান। এই প্রক্রিয়াটিকে 500/50/5 নিয়ম বলা হয় এবং আপনার কাজের চাপ মেটাতে সর্বোত্তমভাবে স্কেল করার জন্য ডাটাবেসকে অবস্থান করে।

যদিও স্প্লিটগুলি ক্রমবর্ধমান লোডের সাথে স্বয়ংক্রিয়ভাবে তৈরি হয়, Cloud Firestore শুধুমাত্র একটি মূল পরিসরকে বিভক্ত করতে পারে যতক্ষণ না এটি প্রতিলিপিকৃত স্টোরেজ সার্ভারগুলির একটি ডেডিকেটেড সেট ব্যবহার করে একটি একক নথি পরিবেশন করছে৷ ফলস্বরূপ, একটি একক নথিতে সমসাময়িক অপারেশনগুলির উচ্চ এবং টেকসই ভলিউম সেই নথিতে একটি হটস্পট হতে পারে। আপনি যদি একটি একক নথিতে দীর্ঘস্থায়ী উচ্চ বিলম্বের সম্মুখীন হন, তবে একাধিক নথিতে ডেটা বিভক্ত বা প্রতিলিপি করার জন্য আপনার ডেটা মডেল পরিবর্তন করার কথা বিবেচনা করা উচিত।

কন্টেন্ট ত্রুটি ঘটবে যখন একাধিক ক্রিয়াকলাপ একই সাথে একই নথি পড়ার এবং/বা লেখার চেষ্টা করে।

হটস্পটিংয়ের আরেকটি বিশেষ ঘটনা ঘটে যখন Cloud Firestore ডকুমেন্ট আইডি হিসেবে ক্রমাগতভাবে বৃদ্ধি/হ্রাস করা কী ব্যবহার করা হয় এবং প্রতি সেকেন্ডে যথেষ্ট পরিমাণে অপারেশন হয়। আরও বিভাজন তৈরি করা এখানে সাহায্য করে না কারণ ট্র্যাফিকের ঢেউ কেবল নতুন তৈরি করা বিভাজনে চলে যায়। যেহেতু Cloud Firestore স্বয়ংক্রিয়ভাবে নথির সমস্ত ক্ষেত্রকে ডিফল্টরূপে সূচী করে, তাই এই ধরনের চলমান হটস্পটগুলি একটি নথি ক্ষেত্রের জন্য সূচী স্থানেও তৈরি করা যেতে পারে যাতে একটি টাইমস্ট্যাম্পের মতো ক্রমান্বয়ে বৃদ্ধি/হ্রাসমান মান থাকে৷

মনে রাখবেন যে উপরে বর্ণিত অনুশীলনগুলি অনুসরণ করে, Cloud Firestore আপনাকে কোনও কনফিগারেশন সামঞ্জস্য না করেই ইচ্ছামত বড় কাজের চাপ পরিবেশন করতে পারে।

সমস্যা সমাধান

Cloud Firestore একটি ডায়াগনস্টিক টুল হিসাবে কী ভিজ্যুয়ালাইজার সরবরাহ করে যা ব্যবহারের ধরণগুলি বিশ্লেষণ করতে এবং হটস্পটিং সমস্যাগুলির সমস্যা সমাধানের জন্য ডিজাইন করা হয়েছে৷

পরবর্তী কি