এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

ক্লাউড ফায়ারস্টোরের জন্য সর্বোত্তম অনুশীলন

ক্লাউড ফায়ারস্টোর ব্যবহার করে এমন একটি অ্যাপ্লিকেশন তৈরি করার সময় দ্রুত রেফারেন্স হিসাবে এখানে তালিকাভুক্ত সেরা অনুশীলনগুলি ব্যবহার করুন৷

ডাটাবেস অবস্থান

আপনি যখন আপনার ডাটাবেস ইনস্ট্যান্স তৈরি করেন, তখন আপনার ব্যবহারকারীদের নিকটতম ডাটাবেস অবস্থান নির্বাচন করুন এবং সংস্থানগুলি গণনা করুন। সুদূরপ্রসারী নেটওয়ার্ক হপগুলি আরও ত্রুটি-প্রবণ এবং ক্যোয়ারী লেটেন্সি বাড়ায়৷

আপনার অ্যাপ্লিকেশনের প্রাপ্যতা এবং স্থায়িত্ব সর্বাধিক করতে, একটি বহু-অঞ্চল অবস্থান নির্বাচন করুন এবং কমপক্ষে দুটি অঞ্চলে গুরুত্বপূর্ণ গণনা সংস্থান রাখুন।

কম খরচের জন্য একটি আঞ্চলিক অবস্থান নির্বাচন করুন, কম লেখার বিলম্বের জন্য যদি আপনার অ্যাপ্লিকেশনটি লেটেন্সির প্রতি সংবেদনশীল হয়, অথবা অন্যান্য GCP সংস্থানগুলির সাথে সহ-অবস্থানের জন্য।

ডকুমেন্ট আইডি

ডকুমেন্ট আইডি এড়িয়ে চলুন . এবং ..
ডকুমেন্ট আইডিতে ব্যবহার / ফরোয়ার্ড স্ল্যাশ এড়িয়ে চলুন।
একঘেয়ে বাড়ানো ডকুমেন্ট আইডি ব্যবহার করবেন না যেমন:
- Customer1 , Customer2 , Customer3 , ...
- Product 1 , Product 2 , Product 3 , ...
এই ধরনের অনুক্রমিক আইডিগুলি হটস্পটের দিকে নিয়ে যেতে পারে যা লেটেন্সিকে প্রভাবিত করে।

ক্ষেত্রের নাম

ক্ষেত্রের নামগুলিতে নিম্নলিখিত অক্ষরগুলি এড়িয়ে চলুন কারণ তাদের অতিরিক্ত পালানোর প্রয়োজন:
- . সময়কাল
- [ বাম বন্ধনী
- ] ডান বন্ধনী
- * তারকাচিহ্ন
- ` ব্যাকটিক

সূচক

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

সূচক ছাড়

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

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

পড়া এবং লেখা অপারেশন

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

লেনদেন পুনরায় চেষ্টা

ক্লাউড ফায়ারস্টোর SDK এবং ক্লায়েন্ট লাইব্রেরি স্বয়ংক্রিয়ভাবে ক্ষণস্থায়ী ত্রুটিগুলি মোকাবেলা করতে ব্যর্থ লেনদেনগুলি পুনরায় চেষ্টা করে৷ যদি আপনার অ্যাপ্লিকেশনটি SDK-এর পরিবর্তে সরাসরি REST বা RPC API-এর মাধ্যমে ক্লাউড ফায়ারস্টোর অ্যাক্সেস করে, তাহলে নির্ভরযোগ্যতা বাড়ানোর জন্য আপনার অ্যাপ্লিকেশনটিকে লেনদেনের পুনঃপ্রচারগুলি বাস্তবায়ন করা উচিত।

রিয়েলটাইম আপডেট

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

সুপারিশ	বিস্তারিত
স্ন্যাপশট শ্রোতা মন্থন হার হ্রাস	শ্রোতাদের ঘন ঘন মন্থন করা এড়িয়ে চলুন, বিশেষ করে যখন আপনার ডাটাবেস উল্লেখযোগ্য লেখার লোডের অধীনে থাকে আদর্শভাবে, ক্লাউড ফায়ারস্টোরে একটি সংযোগ খোলার পরেই আপনার অ্যাপ্লিকেশনটি সমস্ত প্রয়োজনীয় স্ন্যাপশট শ্রোতাদের সেট আপ করা উচিত। আপনার প্রাথমিক স্ন্যাপশট শ্রোতাদের সেট আপ করার পরে, আপনার একই সংযোগে স্ন্যাপশট শ্রোতাদের দ্রুত যোগ করা বা সরানো এড়ানো উচিত। ডেটা সামঞ্জস্য নিশ্চিত করার জন্য, ক্লাউড ফায়ারস্টোরকে প্রতিটি নতুন স্ন্যাপশট শ্রোতাকে তার উত্স ডেটা থেকে প্রাইম করতে হবে এবং তারপরে নতুন পরিবর্তনগুলি ধরতে হবে। আপনার ডাটাবেসের লেখার হারের উপর নির্ভর করে, এটি একটি ব্যয়বহুল অপারেশন হতে পারে। আপনি যদি রেফারেন্সে ঘন ঘন স্ন্যাপশট শ্রোতাদের যোগ করেন বা মুছে দেন তাহলে আপনার স্ন্যাপশট শ্রোতারা ক্রমবর্ধমান বিলম্ব অনুভব করতে পারে। সাধারণভাবে, একজন ক্রমাগত-সংযুক্ত শ্রোতা একই পরিমাণ ডেটার জন্য সেই অবস্থানে একজন শ্রোতাকে সংযুক্ত এবং বিচ্ছিন্ন করার চেয়ে ভাল পারফর্ম করে। সেরা পারফরম্যান্সের জন্য, স্ন্যাপশট শ্রোতাদের 30 সেকেন্ড বা তার বেশি সময় থাকতে হবে। আপনি যদি আপনার অ্যাপে শ্রোতার পারফরম্যান্সের সমস্যার সম্মুখীন হন, তাহলে আপনার অ্যাপের শ্রবণ এবং অশ্রবণগুলি ট্র্যাক করার চেষ্টা করুন যে সেগুলি খুব ঘন ঘন ঘটছে কিনা তা নির্ধারণ করতে।
ক্লায়েন্ট প্রতি স্ন্যাপশট শ্রোতা সীমিত	100 প্রতি ক্লায়েন্টের স্ন্যাপশট শ্রোতার সংখ্যা 100 এর নিচে রাখুন।
সংগ্রহ লেখার হার সীমিত করুন	1,000 অপারেশন/সেকেন্ড একটি পৃথক সংগ্রহের জন্য 1,000 অপারেশন/সেকেন্ডের নিচে লেখার ক্রিয়াকলাপগুলির হার রাখুন।
স্বতন্ত্র ক্লায়েন্ট পুশ রেট সীমিত করুন	1 নথি/সেকেন্ড 1 নথি/সেকেন্ডের মধ্যে একটি পৃথক ক্লায়েন্টের কাছে ডাটাবেস পুশ করে ডকুমেন্টের হার রাখুন।
বিশ্বব্যাপী ক্লায়েন্ট পুশ রেট সীমিত করুন	1,000,000 নথি/সেকেন্ড 1,000,000 নথি/সেকেন্ডের নিচে সমস্ত ক্লায়েন্টের কাছে ডাটাবেস পুশ করে ডকুমেন্টের হার রাখুন। এটি একটি নরম সীমা। ক্লাউড ফায়ারস্টোর আপনাকে এই থ্রেশহোল্ড অতিক্রম করতে বাধা দেয় না তবে এটি কার্যক্ষমতাকে ব্যাপকভাবে প্রভাবিত করে।
পৃথক নথি পেলোড সীমিত	10 KiB/সেকেন্ড একজন স্বতন্ত্র ক্লায়েন্ট দ্বারা ডাউনলোড করা ডকুমেন্টের সর্বোচ্চ আকার 10 KiB/সেকেন্ডের নিচে রাখুন।
গ্লোবাল ডকুমেন্ট পেলোড সীমিত করুন	1 GiB/সেকেন্ড 1 GiB/সেকেন্ডের নিচে সমস্ত ক্লায়েন্ট জুড়ে ডাউনলোড করা ডকুমেন্টের সর্বোচ্চ আকার রাখুন।
নথি প্রতি ক্ষেত্র সংখ্যা সীমিত	100 আপনার নথিতে 100টিরও কম ক্ষেত্র থাকা উচিত।
ক্লাউড ফায়ারস্টোর স্ট্যান্ডার্ড সীমা বুঝুন	ক্লাউড ফায়ারস্টোরের মান সীমা মনে রাখবেন। নথির জন্য প্রতি সেকেন্ডে 1 লেখার সীমা এবং প্রতি ডাটাবেস প্রতি 1,000,000 সমবর্তী সংযোগের সীমার প্রতি বিশেষ মনোযোগ দিন। এগুলি নরম সীমা যা ক্লাউড ফায়ারস্টোর আপনাকে অতিক্রম করতে বাধা দেয় না। যাইহোক, এই সীমা অতিক্রম করা কর্মক্ষমতা প্রভাবিত করতে পারে, আপনার মোট পড়ার এবং লেখার হারের উপর নির্ভর করে।

স্কেল জন্য ডিজাইনিং

নিম্নলিখিত সর্বোত্তম অনুশীলনগুলি বিবাদের সমস্যা তৈরি করে এমন পরিস্থিতিগুলি কীভাবে এড়াতে হয় তা বর্ণনা করে।

একটি একক নথিতে আপডেট

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

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

একটি সংকীর্ণ নথি পরিসরে উচ্চ পঠন, লিখুন এবং মুছে ফেলার হার

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

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

মুছে ফেলা ডেটা এড়িয়ে যাওয়া এড়িয়ে চলুন

সম্প্রতি মুছে ফেলা ডেটার উপর এড়িয়ে যাওয়া প্রশ্নগুলি এড়িয়ে চলুন। প্রারম্ভিক ক্যোয়ারী ফলাফল সম্প্রতি মুছে ফেলা হলে একটি ক্যোয়ারী অনেক সংখ্যক সূচক এন্ট্রি এড়িয়ে যেতে হতে পারে।

একটি কাজের চাপের একটি উদাহরণ যা অনেকগুলি মুছে ফেলা ডেটাকে এড়িয়ে যেতে হতে পারে যা সবচেয়ে পুরানো সারিবদ্ধ কাজের আইটেমগুলি খুঁজে বের করার চেষ্টা করে৷ ক্যোয়ারী এর মত দেখতে হতে পারে:

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

প্রতিবার এই ক্যোয়ারীটি চালানোর সময় এটি যে কোনো সম্প্রতি মুছে ফেলা নথিতে created ফিল্ডের জন্য সূচক এন্ট্রিগুলির উপর স্ক্যান করে। এটি প্রশ্নগুলিকে ধীর করে দেয়।

কর্মক্ষমতা উন্নত করতে, শুরু করার সেরা জায়গা খুঁজে পেতে start_at পদ্ধতি ব্যবহার করুন। উদাহরণ স্বরূপ:

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

দ্রষ্টব্য: উপরের উদাহরণটি একঘেয়ে ক্রমবর্ধমান ক্ষেত্র ব্যবহার করে যা উচ্চ লেখার হারের জন্য একটি বিরোধী প্যাটার্ন।

ট্রাফিক বৃদ্ধি

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

একটি নতুন সংগ্রহে ট্রাফিক স্থানান্তর করা হচ্ছে

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

একই ধরনের সমস্যা দেখা দিতে পারে যদি আপনি একই সংগ্রহের মধ্যে অনেক নথির ডকুমেন্ট আইডি পরিবর্তন করেন।

একটি নতুন সংগ্রহে ট্রাফিক স্থানান্তর করার জন্য সর্বোত্তম কৌশল আপনার ডেটা মডেলের উপর নির্ভর করে। নীচে একটি উদাহরণ কৌশল যা সমান্তরাল পাঠ হিসাবে পরিচিত। এই কৌশলটি আপনার ডেটার জন্য কার্যকর কিনা তা আপনাকে নির্ধারণ করতে হবে এবং মাইগ্রেশনের সময় সমান্তরাল ক্রিয়াকলাপের খরচের প্রভাব একটি গুরুত্বপূর্ণ বিবেচ্য হবে।

সমান্তরাল পড়ে

একটি নতুন সংগ্রহে ট্রাফিক স্থানান্তরিত করার সাথে সাথে সমান্তরাল পাঠ বাস্তবায়ন করতে, প্রথমে পুরানো সংগ্রহ থেকে পড়ুন। যদি নথিটি অনুপস্থিত থাকে, তাহলে নতুন সংগ্রহ থেকে পড়ুন। অনুপস্থিত নথিগুলির উচ্চ হার পড়ার কারণে হটস্পটিং হতে পারে, তাই নতুন সংগ্রহে ধীরে ধীরে লোড বাড়াতে ভুলবেন না। একটি ভাল কৌশল হল পুরানো নথিটিকে নতুন সংগ্রহে অনুলিপি করা তারপর পুরানো নথিটি মুছে ফেলা। ক্লাউড ফায়ারস্টোর নতুন সংগ্রহে ট্র্যাফিক পরিচালনা করতে পারে তা নিশ্চিত করতে ধীরে ধীরে সমান্তরাল রিডগুলিকে র‍্যাম্প আপ করুন৷

একটি নতুন সংগ্রহে ধীরে ধীরে পঠন বা লেখার জন্য একটি সম্ভাব্য কৌশল হল ব্যবহারকারীর আইডির একটি নির্ধারক হ্যাশ ব্যবহার করে নতুন নথি লেখার চেষ্টাকারী ব্যবহারকারীদের র্যান্ডম শতাংশ নির্বাচন করা। নিশ্চিত করুন যে ব্যবহারকারী আইডি হ্যাশের ফলাফল আপনার ফাংশন বা ব্যবহারকারীর আচরণ দ্বারা তির্যক নয়।

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

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

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

অননুমোদিত প্রবেশ রোধ করুন

ক্লাউড ফায়ারস্টোর নিরাপত্তা নিয়মের সাথে আপনার ডাটাবেসে অননুমোদিত ক্রিয়াকলাপ প্রতিরোধ করুন। উদাহরণস্বরূপ, নিয়মগুলি ব্যবহার করে এমন পরিস্থিতি এড়াতে পারে যেখানে একটি দূষিত ব্যবহারকারী বারবার আপনার সম্পূর্ণ ডাটাবেস ডাউনলোড করে।

ক্লাউড ফায়ারস্টোর নিরাপত্তা নিয়ম ব্যবহার সম্পর্কে আরও জানুন।

ডাটাবেস অবস্থান

ডকুমেন্ট আইডি

ডকুমেন্ট আইডি এড়িয়ে চলুন . এবং ..
ডকুমেন্ট আইডিতে ব্যবহার / ফরোয়ার্ড স্ল্যাশ এড়িয়ে চলুন।
একঘেয়ে বাড়ানো ডকুমেন্ট আইডি ব্যবহার করবেন না যেমন:
- Customer1 , Customer2 , Customer3 , ...
- Product 1 , Product 2 , Product 3 , ...
এই ধরনের অনুক্রমিক আইডিগুলি হটস্পটের দিকে নিয়ে যেতে পারে যা লেটেন্সিকে প্রভাবিত করে।

ক্ষেত্রের নাম

ক্ষেত্রের নামগুলিতে নিম্নলিখিত অক্ষরগুলি এড়িয়ে চলুন কারণ তাদের অতিরিক্ত পালানোর প্রয়োজন:
- . সময়কাল
- [ বাম বন্ধনী
- ] ডান বন্ধনী
- * তারকাচিহ্ন
- ` ব্যাকটিক

সূচক

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

সূচক ছাড়

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

পড়া এবং লেখা অপারেশন

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

লেনদেন পুনরায় চেষ্টা

রিয়েলটাইম আপডেট

সুপারিশ	বিস্তারিত
স্ন্যাপশট শ্রোতা মন্থন হার হ্রাস	শ্রোতাদের ঘন ঘন মন্থন করা এড়িয়ে চলুন, বিশেষ করে যখন আপনার ডাটাবেস উল্লেখযোগ্য লেখার লোডের অধীনে থাকে আদর্শভাবে, ক্লাউড ফায়ারস্টোরে একটি সংযোগ খোলার পরেই আপনার অ্যাপ্লিকেশনটি সমস্ত প্রয়োজনীয় স্ন্যাপশট শ্রোতাদের সেট আপ করা উচিত। আপনার প্রাথমিক স্ন্যাপশট শ্রোতাদের সেট আপ করার পরে, আপনার একই সংযোগে স্ন্যাপশট শ্রোতাদের দ্রুত যোগ করা বা সরানো এড়ানো উচিত। ডেটা সামঞ্জস্য নিশ্চিত করার জন্য, ক্লাউড ফায়ারস্টোরকে প্রতিটি নতুন স্ন্যাপশট শ্রোতাকে তার উত্স ডেটা থেকে প্রাইম করতে হবে এবং তারপরে নতুন পরিবর্তনগুলি ধরতে হবে। আপনার ডাটাবেসের লেখার হারের উপর নির্ভর করে, এটি একটি ব্যয়বহুল অপারেশন হতে পারে। আপনি যদি রেফারেন্সে ঘন ঘন স্ন্যাপশট শ্রোতাদের যোগ করেন বা মুছে দেন তাহলে আপনার স্ন্যাপশট শ্রোতারা ক্রমবর্ধমান বিলম্ব অনুভব করতে পারে। সাধারণভাবে, একজন ক্রমাগত-সংযুক্ত শ্রোতা একই পরিমাণ ডেটার জন্য সেই অবস্থানে একজন শ্রোতাকে সংযুক্ত এবং বিচ্ছিন্ন করার চেয়ে ভাল পারফর্ম করে। সেরা পারফরম্যান্সের জন্য, স্ন্যাপশট শ্রোতাদের 30 সেকেন্ড বা তার বেশি সময় থাকতে হবে। আপনি যদি আপনার অ্যাপে শ্রোতার পারফরম্যান্সের সমস্যার সম্মুখীন হন, তাহলে আপনার অ্যাপের শ্রবণ এবং অশ্রবণগুলি ট্র্যাক করার চেষ্টা করুন যে সেগুলি খুব ঘন ঘন ঘটছে কিনা তা নির্ধারণ করতে।
ক্লায়েন্ট প্রতি স্ন্যাপশট শ্রোতা সীমিত	100 প্রতি ক্লায়েন্টের স্ন্যাপশট শ্রোতার সংখ্যা 100 এর নিচে রাখুন।
সংগ্রহ লেখার হার সীমিত করুন	1,000 অপারেশন/সেকেন্ড একটি পৃথক সংগ্রহের জন্য 1,000 অপারেশন/সেকেন্ডের নিচে লেখার ক্রিয়াকলাপগুলির হার রাখুন।
স্বতন্ত্র ক্লায়েন্ট পুশ রেট সীমিত করুন	1 নথি/সেকেন্ড 1 নথি/সেকেন্ডের মধ্যে একটি পৃথক ক্লায়েন্টের কাছে ডাটাবেস পুশ করে ডকুমেন্টের হার রাখুন।
বিশ্বব্যাপী ক্লায়েন্ট পুশ রেট সীমিত করুন	1,000,000 নথি/সেকেন্ড 1,000,000 নথি/সেকেন্ডের নিচে সমস্ত ক্লায়েন্টের কাছে ডাটাবেস পুশ করে ডকুমেন্টের হার রাখুন। এটি একটি নরম সীমা। ক্লাউড ফায়ারস্টোর আপনাকে এই থ্রেশহোল্ড অতিক্রম করতে বাধা দেয় না তবে এটি কার্যক্ষমতাকে ব্যাপকভাবে প্রভাবিত করে।
পৃথক নথি পেলোড সীমিত	10 KiB/সেকেন্ড একজন স্বতন্ত্র ক্লায়েন্ট দ্বারা ডাউনলোড করা ডকুমেন্টের সর্বোচ্চ আকার 10 KiB/সেকেন্ডের নিচে রাখুন।
গ্লোবাল ডকুমেন্ট পেলোড সীমিত করুন	1 GiB/সেকেন্ড 1 GiB/সেকেন্ডের নিচে সমস্ত ক্লায়েন্ট জুড়ে ডাউনলোড করা ডকুমেন্টের সর্বোচ্চ আকার রাখুন।
নথি প্রতি ক্ষেত্র সংখ্যা সীমিত	100 আপনার নথিতে 100টিরও কম ক্ষেত্র থাকা উচিত।
ক্লাউড ফায়ারস্টোর স্ট্যান্ডার্ড সীমা বুঝুন	ক্লাউড ফায়ারস্টোরের মান সীমা মনে রাখবেন। নথির জন্য প্রতি সেকেন্ডে 1 লেখার সীমা এবং প্রতি ডাটাবেস প্রতি 1,000,000 সমবর্তী সংযোগের সীমার প্রতি বিশেষ মনোযোগ দিন। এগুলি নরম সীমা যা ক্লাউড ফায়ারস্টোর আপনাকে অতিক্রম করতে বাধা দেয় না। যাইহোক, এই সীমা অতিক্রম করা কর্মক্ষমতা প্রভাবিত করতে পারে, আপনার মোট পড়ার এবং লেখার হারের উপর নির্ভর করে।

স্কেল জন্য ডিজাইনিং

একটি একক নথিতে আপডেট

একটি সংকীর্ণ নথি পরিসরে উচ্চ পঠন, লিখুন এবং মুছে ফেলার হার

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

মুছে ফেলা ডেটা এড়িয়ে যাওয়া এড়িয়ে চলুন

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

ট্রাফিক বৃদ্ধি

একটি নতুন সংগ্রহে ট্রাফিক স্থানান্তর করা হচ্ছে

সমান্তরাল পড়ে

অননুমোদিত প্রবেশ রোধ করুন

ক্লাউড ফায়ারস্টোর নিরাপত্তা নিয়ম ব্যবহার সম্পর্কে আরও জানুন।

ডাটাবেস অবস্থান

ডকুমেন্ট আইডি

ডকুমেন্ট আইডি এড়িয়ে চলুন . এবং ..
ডকুমেন্ট আইডিতে ব্যবহার / ফরোয়ার্ড স্ল্যাশ এড়িয়ে চলুন।
একঘেয়ে বাড়ানো ডকুমেন্ট আইডি ব্যবহার করবেন না যেমন:
- Customer1 , Customer2 , Customer3 , ...
- Product 1 , Product 2 , Product 3 , ...
এই ধরনের অনুক্রমিক আইডিগুলি হটস্পটের দিকে নিয়ে যেতে পারে যা লেটেন্সিকে প্রভাবিত করে।

ক্ষেত্রের নাম

ক্ষেত্রের নামগুলিতে নিম্নলিখিত অক্ষরগুলি এড়িয়ে চলুন কারণ তাদের অতিরিক্ত পালানোর প্রয়োজন:
- . সময়কাল
- [ বাম বন্ধনী
- ] ডান বন্ধনী
- * তারকাচিহ্ন
- ` ব্যাকটিক

সূচক

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

সূচক ছাড়

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

পড়া এবং লেখা অপারেশন

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

লেনদেন পুনরায় চেষ্টা

রিয়েলটাইম আপডেট

সুপারিশ	বিস্তারিত
স্ন্যাপশট শ্রোতা মন্থন হার হ্রাস	শ্রোতাদের ঘন ঘন মন্থন করা এড়িয়ে চলুন, বিশেষ করে যখন আপনার ডাটাবেস উল্লেখযোগ্য লেখার লোডের অধীনে থাকে আদর্শভাবে, ক্লাউড ফায়ারস্টোরে একটি সংযোগ খোলার পরেই আপনার অ্যাপ্লিকেশনটি সমস্ত প্রয়োজনীয় স্ন্যাপশট শ্রোতাদের সেট আপ করা উচিত। আপনার প্রাথমিক স্ন্যাপশট শ্রোতাদের সেট আপ করার পরে, আপনার একই সংযোগে স্ন্যাপশট শ্রোতাদের দ্রুত যোগ করা বা সরানো এড়ানো উচিত। ডেটা সামঞ্জস্য নিশ্চিত করার জন্য, ক্লাউড ফায়ারস্টোরকে প্রতিটি নতুন স্ন্যাপশট শ্রোতাকে তার উত্স ডেটা থেকে প্রাইম করতে হবে এবং তারপরে নতুন পরিবর্তনগুলি ধরতে হবে। আপনার ডাটাবেসের লেখার হারের উপর নির্ভর করে, এটি একটি ব্যয়বহুল অপারেশন হতে পারে। আপনি যদি রেফারেন্সে ঘন ঘন স্ন্যাপশট শ্রোতাদের যোগ করেন বা মুছে দেন তাহলে আপনার স্ন্যাপশট শ্রোতারা ক্রমবর্ধমান বিলম্ব অনুভব করতে পারে। সাধারণভাবে, একজন ক্রমাগত-সংযুক্ত শ্রোতা একই পরিমাণ ডেটার জন্য সেই অবস্থানে একজন শ্রোতাকে সংযুক্ত এবং বিচ্ছিন্ন করার চেয়ে ভাল পারফর্ম করে। সেরা পারফরম্যান্সের জন্য, স্ন্যাপশট শ্রোতাদের 30 সেকেন্ড বা তার বেশি সময় থাকতে হবে। আপনি যদি আপনার অ্যাপে শ্রোতার পারফরম্যান্সের সমস্যার সম্মুখীন হন, তাহলে আপনার অ্যাপের শ্রবণ এবং অশ্রবণগুলি ট্র্যাক করার চেষ্টা করুন যে সেগুলি খুব ঘন ঘন ঘটছে কিনা তা নির্ধারণ করতে।
ক্লায়েন্ট প্রতি স্ন্যাপশট শ্রোতা সীমিত	100 প্রতি ক্লায়েন্টের স্ন্যাপশট শ্রোতার সংখ্যা 100 এর নিচে রাখুন।
সংগ্রহ লেখার হার সীমিত করুন	1,000 অপারেশন/সেকেন্ড Keep the rate of write operations for an individual collection under 1,000 operations/second.
Limit the individual client push rate	1 document/second Keep the rate of documents the database pushes to an individual client under 1 document/second.
Limit the global client push rate	1,000,000 documents/second Keep the rate of documents the database pushes to all clients under 1,000,000 documents/second. This is a soft limit. Cloud Firestore does not stop you from surpassing this threshold but it greatly affects performance.
Limit the individual document payload	10 KiB/second Keep the maximum document size downloaded by an individual client under 10 KiB/second.
Limit the global document payload	1 GiB/second Keep the maximum document size downloaded across all clients under 1 GiB/second.
Limit the number of fields per document	100 Your documents should have fewer than 100 fields.
Understand the Cloud Firestore standard limits	Keep in mind the standard limits for Cloud Firestore . Pay special attention to the 1 write per second limit for documents and the limit of 1,000,000 concurrent connections per database. These are soft limits that Cloud Firestore does not stop you from exceeding. However, going over these limits might affect performance, depending on your total read and write rates.

Designing for scale

The following best practices describe how to avoid situations that create contention issues.

Updates to a single document

As you design your app, consider how quickly your app updates single documents. The best way to characterize your workload's performance is to perform load testing. The exact maximum rate that an app can update a single document depends highly on the workload. Factors include the write rate, contention among requests, and the number affected indexes.

A document write operation updates the document and any associated indexes, and Cloud Firestore synchronously applies the write operation across a quorum of replicas. At high enough write rates, the database will start to encounter contention, higher latency, or other errors.

High read, write, and delete rates to a narrow document range

Avoid high read or write rates to lexicographically close documents, or your application will experience contention errors. This issue is known as hotspotting, and your application can experience hotspotting if it does any of the following:

Creates new documents at a very high rate and allocates its own monotonically increasing IDs.
Cloud Firestore allocates document IDs using a scatter algorithm. You should not encounter hotspotting on writes if you create new documents using automatic document IDs.
Creates new documents at a high rate in a collection with few documents.
Creates new documents with a monotonically increasing field, like a timestamp, at a very high rate.
Deletes documents in a collection at a high rate.
Writes to the database at a very high rate without gradually increasing traffic.

Avoid skipping over deleted data

Avoid queries that skip over recently deleted data. A query may have to skip over a large number of index entries if the early query results have recently been deleted.

An example of a workload that might have to skip over a lot of deleted data is one that tries to find the oldest queued work items. The query might look like:

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

Each time this query runs it scans over the index entries for the created field on any recently deleted documents. This slows down queries.

To improve the performance, use the start_at method to find the best place to start. For example:

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

NOTE: The example above uses a monotonically increasing field which is an anti-pattern for high write rates.

Ramping up traffic

You should gradually ramp up traffic to new collections or lexicographically close documents to give Cloud Firestore sufficient time to prepare documents for increased traffic. We recommend starting with a maximum of 500 operations per second to a new collection and then increasing traffic by 50% every 5 minutes. You can similarly ramp up your write traffic, but keep in mind the Cloud Firestore Standard Limits . Be sure that operations are distributed relatively evenly throughout the key range. This is called the "500/50/5" rule.

Migrating traffic to a new collection

Gradual ramp up is particularly important if you migrate app traffic from one collection to another. A simple way to handle this migration is to read from the old collection, and if the document does not exist, then read from the new collection. However, this could cause a sudden increase of traffic to lexicographically close documents in the new collection. Cloud Firestore may be unable to efficiently prepare the new collection for increased traffic, especially when it contains few documents.

A similar problem can occur if you change the document IDs of many documents within the same collection.

The best strategy for migrating traffic to a new collection depends on your data model. Below is an example strategy known as parallel reads . You will need to determine whether or not this strategy is effective for your data, and an important consideration will be the cost impact of parallel operations during the migration.

Parallel reads

To implement parallel reads as you migrate traffic to a new collection, read from the old collection first. If the document is missing, then read from the new collection. A high rate of reads of non-existent documents can lead to hotspotting, so be sure to gradually increase load to the new collection. A better strategy is to copy the old document to the new collection then delete the old document. Ramp up parallel reads gradually to ensure that Cloud Firestore can handle traffic to the new collection.

A possible strategy for gradually ramping up reads or writes to a new collection is to use a deterministic hash of the user ID to select a random percentage of users attempting to write new documents. Be sure that the result of the user ID hash is not skewed either by your function or by user behavior.

Meanwhile, run a batch job that copies all your data from the old documents to the new collection. Your batch job should avoid writes to sequential document IDs in order to prevent hotspots. When the batch job finishes, you can read only from the new collection.

A refinement of this strategy is to migrate small batches of users at a time. Add a field to the user document which tracks migration status of that user. Select a batch of users to migrate based on a hash of the user ID. Use a batch job to migrate documents for that batch of users, and use parallel reads for users in the middle of migration.

Note that you cannot easily roll back unless you do dual writes of both the old and new entities during the migration phase. This would increase Cloud Firestore costs incurred.

Prevent unauthorized access

Prevent unauthorized operations on your database with Cloud Firestore Security Rules. For example, using rules could avoid a scenario where a malicious user repeatedly downloads your entire database.

Learn more about using Cloud Firestore Security Rules .

Use the best practices listed here as a quick reference when building an application that uses Cloud Firestore.

Database location

When you create your database instance, select the database location closest to your users and compute resources. Far-reaching network hops are more error-prone and increase query latency.

To maximize the availability and durability of your application, select a multi-region location and place critical compute resources in at least two regions.

Select a regional location for lower costs, for lower write latency if your application is sensitive to latency, or for co-location with other GCP resources .

Document IDs

Avoid the document IDs . and .. .
Avoid using / forward slashes in document IDs.
Do not use monotonically increasing document IDs such as:
- Customer1 , Customer2 , Customer3 , ...
- Product 1 , Product 2 , Product 3 , ...
Such sequential IDs can lead to hotspots that impact latency.

Field Names

Avoid the following characters in field names because they require extra escaping:
- . period
- [ left bracket
- ] right bracket
- * asterisk
- ` backtick

Indexes

Avoid using too many indexes. An excessive number of indexes can increase write latency and increases storage costs for index entries.
Be aware that indexing fields with monotonically increasing values, such as timestamps, can lead to hotspots which impact latency for applications with high read and write rates.

Index exemptions

For most apps, you can rely on automatic indexing as well as any error message links to manage your indexes. However, you may want to add single-field exemptions in the following cases:

Case	Description
Large string fields	If you have a string field that often holds long string values that you don't use for querying, you can cut storage costs by exempting the field from indexing.
High write rates to a collection containing documents with sequential values	If you index a field that increases or decreases sequentially between documents in a collection, like a timestamp, then the maximum write rate to the collection is 500 writes per second. If you don't query based on the field with sequential values, you can exempt the field from indexing to bypass this limit. In an IoT use case with a high write rate, for example, a collection containing documents with a timestamp field might approach the 500 writes per second limit.
TTL fields	If you use TTL (time-to-live) policies , note that the TTL field must be a timestamp. Indexing on TTL fields is enabled by default and can affect performance at higher traffic rates. As a best practice, add single-field exemptions for your TTL fields.
Large array or map fields	Large array or map fields can approach the limit of 40,000 index entries per document. If you are not querying based on a large array or map field, you should exempt it from indexing.

Read and write operations

The exact maximum rate that an app can update a single document depends highly on the workload. For more information, see Updates to a single document .
Use asynchronous calls where available instead of synchronous calls. Asynchronous calls minimize latency impact. For example, consider an application that needs the result of a document lookup and the results of a query before rendering a response. If the lookup and the query do not have a data dependency, there is no need to synchronously wait until the lookup completes before initiating the query.
Do not use offsets. Instead, use cursors . Using an offset only avoids returning the skipped documents to your application, but these documents are still retrieved internally. The skipped documents affect the latency of the query, and your application is billed for the read operations required to retrieve them.

Transactions retries

The Cloud Firestore SDKs and client libraries automatically retry failed transactions to deal with transient errors. If your application accesses Cloud Firestore through the REST or RPC APIs directly instead of through an SDK, your application should implement transaction retries to increase reliability.

Realtime updates

For the best snapshot listener performance, keep your documents small and control the read rate of your clients. The following recommendations provide guidelines for maximizing performance. Exceeding these recommendations can result in increased notification latency.

Recommendation	Details
Reduce snapshot listener churn rate	Avoid frequently churning listeners, especially when your database is under significant write load Ideally, your application should set up all the required snapshot listeners soon after opening a connection to Cloud Firestore. After setting up your initial snapshot listeners, you should avoid quickly adding or removing snapshot listeners in the same connection. To ensure data consistency, Cloud Firestore needs to prime each new snapshot listener from its source data and then catch up to new changes. Depending on your database's write rate, this can be an expensive operation. Your snapshot listeners can experience increased latency if you frequently add or remove snapshot listeners to references. In general, a constantly-attached listener performs better than attaching and detaching a listener at that location for the same amount of data. For best performance, snapshot listeners should have a lifetime of 30 seconds or longer. If you encounter listener performance issues in your app, try tracking your app's listens and unlistens to determine if they may be happening too frequently.
Limit snapshot listeners per client	100 Keep the number of snapshot listeners per client under 100.
Limit the collection write rate	1,000 operations/second Keep the rate of write operations for an individual collection under 1,000 operations/second.
Limit the individual client push rate	1 document/second Keep the rate of documents the database pushes to an individual client under 1 document/second.
Limit the global client push rate	1,000,000 documents/second Keep the rate of documents the database pushes to all clients under 1,000,000 documents/second. This is a soft limit. Cloud Firestore does not stop you from surpassing this threshold but it greatly affects performance.
Limit the individual document payload	10 KiB/second Keep the maximum document size downloaded by an individual client under 10 KiB/second.
Limit the global document payload	1 GiB/second Keep the maximum document size downloaded across all clients under 1 GiB/second.
Limit the number of fields per document	100 Your documents should have fewer than 100 fields.
Understand the Cloud Firestore standard limits	Keep in mind the standard limits for Cloud Firestore . Pay special attention to the 1 write per second limit for documents and the limit of 1,000,000 concurrent connections per database. These are soft limits that Cloud Firestore does not stop you from exceeding. However, going over these limits might affect performance, depending on your total read and write rates.

Designing for scale

The following best practices describe how to avoid situations that create contention issues.

Updates to a single document

High read, write, and delete rates to a narrow document range

Creates new documents at a very high rate and allocates its own monotonically increasing IDs.
Cloud Firestore allocates document IDs using a scatter algorithm. You should not encounter hotspotting on writes if you create new documents using automatic document IDs.
Creates new documents at a high rate in a collection with few documents.
Creates new documents with a monotonically increasing field, like a timestamp, at a very high rate.
Deletes documents in a collection at a high rate.
Writes to the database at a very high rate without gradually increasing traffic.

Avoid skipping over deleted data

Avoid queries that skip over recently deleted data. A query may have to skip over a large number of index entries if the early query results have recently been deleted.

An example of a workload that might have to skip over a lot of deleted data is one that tries to find the oldest queued work items. The query might look like:

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

Each time this query runs it scans over the index entries for the created field on any recently deleted documents. This slows down queries.

To improve the performance, use the start_at method to find the best place to start. For example:

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

NOTE: The example above uses a monotonically increasing field which is an anti-pattern for high write rates.

Ramping up traffic

Migrating traffic to a new collection

A similar problem can occur if you change the document IDs of many documents within the same collection.

Parallel reads

Note that you cannot easily roll back unless you do dual writes of both the old and new entities during the migration phase. This would increase Cloud Firestore costs incurred.

Prevent unauthorized access

Prevent unauthorized operations on your database with Cloud Firestore Security Rules. For example, using rules could avoid a scenario where a malicious user repeatedly downloads your entire database.

Learn more about using Cloud Firestore Security Rules .