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

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

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

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

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

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

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

  • ডকুমেন্ট আইডি এড়িয়ে চলুন . এবং ..
  • ডকুমেন্ট আইডিতে ব্যবহার / ফরোয়ার্ড স্ল্যাশ এড়িয়ে চলুন।
  • একঘেয়ে বাড়ানো ডকুমেন্ট আইডি ব্যবহার করবেন না যেমন:

    • Customer1 , Customer2 , Customer3 , ...
    • Product 1 , Product 2 , Product 3 , ...

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

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

  • ক্ষেত্রের নামগুলিতে নিম্নলিখিত অক্ষরগুলি এড়িয়ে চলুন কারণ তাদের অতিরিক্ত পালানোর প্রয়োজন:

    • . সময়কাল
    • [ বাম বন্ধনী
    • ] ডান বন্ধনী
    • * তারকাচিহ্ন
    • ` ব্যাকটিক

সূচক

লেখার বিলম্ব কমিয়ে দিন

লেটেন্সি লেখার প্রধান অবদানকারী হল ইনডেক্স ফ্যানআউট। সূচক ফ্যানআউট কমাতে সর্বোত্তম অনুশীলনগুলি হল:

  • সংগ্রহ-স্তরের সূচক ছাড় সেট করুন। একটি সহজ ডিফল্ট হল ডিসেন্ডিং এবং অ্যারে ইন্ডেক্সিং অক্ষম করা। অব্যবহৃত সূচীকৃত মানগুলি সরানোর ফলে স্টোরেজ খরচও কম হবে।

  • একটি লেনদেনে নথির সংখ্যা হ্রাস করুন। বিপুল সংখ্যক নথি লেখার জন্য, পারমাণবিক ব্যাচ লেখকের পরিবর্তে একটি বাল্ক রাইটার ব্যবহার করার কথা বিবেচনা করুন।

সূচক ছাড়

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

মামলা বর্ণনা
বড় স্ট্রিং ক্ষেত্র

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

ক্রমিক মান সহ নথি সমন্বিত একটি সংগ্রহে উচ্চ লেখার হার

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

একটি উচ্চ লেখার হার সহ একটি IoT ব্যবহারের ক্ষেত্রে, উদাহরণস্বরূপ, একটি টাইমস্ট্যাম্প ফিল্ড সহ নথি সমন্বিত একটি সংগ্রহ প্রতি সেকেন্ডে 500 রাইটের কাছে যেতে পারে।

TTL ক্ষেত্র

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

বড় অ্যারে বা মানচিত্র ক্ষেত্র

বড় অ্যারে বা মানচিত্র ক্ষেত্রগুলি প্রতি নথিতে 40,000 সূচক এন্ট্রির সীমার কাছে যেতে পারে। যদি আপনি একটি বড় অ্যারে বা মানচিত্র ক্ষেত্রের উপর ভিত্তি করে অনুসন্ধান না করেন, তাহলে আপনার এটিকে সূচীকরণ থেকে অব্যাহতি দেওয়া উচিত।

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

  • একটি অ্যাপ একটি একক নথি আপডেট করতে পারে এমন সঠিক সর্বোচ্চ হার কাজের চাপের উপর নির্ভর করে। আরও তথ্যের জন্য, একটি একক নথির আপডেট দেখুন।

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

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

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

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

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

রিয়েল-টাইম আপডেটের সাথে সম্পর্কিত সর্বোত্তম অনুশীলনের জন্য, স্কেলে রিয়েল-টাইম প্রশ্নগুলি বুঝতে দেখুন।

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

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

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

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

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

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

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

  • খুব উচ্চ হারে নতুন নথি তৈরি করে এবং নিজস্ব একঘেয়েভাবে ক্রমবর্ধমান আইডি বরাদ্দ করে।

    Cloud Firestore একটি স্ক্যাটার অ্যালগরিদম ব্যবহার করে ডকুমেন্ট আইডি বরাদ্দ করে। আপনি যদি স্বয়ংক্রিয় ডকুমেন্ট আইডি ব্যবহার করে নতুন নথি তৈরি করেন তবে আপনার লেখাগুলিতে হটস্পটিংয়ের সম্মুখীন হওয়া উচিত নয়।

  • কিছু নথি সহ একটি সংগ্রহে উচ্চ হারে নতুন নথি তৈরি করে।

  • টাইমস্ট্যাম্পের মতো একঘেয়ে ক্রমবর্ধমান ক্ষেত্রের সাথে খুব উচ্চ হারে নতুন নথি তৈরি করে।

  • একটি উচ্চ হারে একটি সংগ্রহে নথি মুছে দেয়।

  • ধীরে ধীরে ট্রাফিক বৃদ্ধি না করে খুব উচ্চ হারে ডাটাবেসে লিখুন।

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

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

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

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()

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

ট্রাফিক ramping আপ

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

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

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

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

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

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

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

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

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

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

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

গোপনীয়তা

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

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

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

Cloud Firestore Security Rules ব্যবহার সম্পর্কে আরও জানুন।

,

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

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

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

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

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

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

  • ডকুমেন্ট আইডি এড়িয়ে চলুন . এবং ..
  • ডকুমেন্ট আইডিতে ব্যবহার / ফরোয়ার্ড স্ল্যাশ এড়িয়ে চলুন।
  • একঘেয়ে বাড়ানো ডকুমেন্ট আইডি ব্যবহার করবেন না যেমন:

    • Customer1 , Customer2 , Customer3 , ...
    • Product 1 , Product 2 , Product 3 , ...

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

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

  • ক্ষেত্রের নামগুলিতে নিম্নলিখিত অক্ষরগুলি এড়িয়ে চলুন কারণ তাদের অতিরিক্ত পালানোর প্রয়োজন:

    • . সময়কাল
    • [ বাম বন্ধনী
    • ] ডান বন্ধনী
    • * তারকাচিহ্ন
    • ` ব্যাকটিক

সূচক

লেখার বিলম্ব কমিয়ে দিন

লেটেন্সি লেখার প্রধান অবদানকারী হল ইনডেক্স ফ্যানআউট। সূচক ফ্যানআউট কমাতে সর্বোত্তম অনুশীলনগুলি হল:

  • সংগ্রহ-স্তরের সূচক ছাড় সেট করুন। একটি সহজ ডিফল্ট হল ডিসেন্ডিং এবং অ্যারে ইন্ডেক্সিং অক্ষম করা। অব্যবহৃত সূচীকৃত মানগুলি সরানোর ফলে স্টোরেজ খরচও কম হবে।

  • একটি লেনদেনে নথির সংখ্যা হ্রাস করুন। বিপুল সংখ্যক নথি লেখার জন্য, পারমাণবিক ব্যাচ লেখকের পরিবর্তে একটি বাল্ক রাইটার ব্যবহার করার কথা বিবেচনা করুন।

সূচক ছাড়

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

মামলা বর্ণনা
বড় স্ট্রিং ক্ষেত্র

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

ক্রমিক মান সহ নথি সমন্বিত একটি সংগ্রহে উচ্চ লেখার হার

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

একটি উচ্চ লেখার হার সহ একটি IoT ব্যবহারের ক্ষেত্রে, উদাহরণস্বরূপ, একটি টাইমস্ট্যাম্প ফিল্ড সহ নথি সমন্বিত একটি সংগ্রহ প্রতি সেকেন্ডে 500 রাইটের কাছে যেতে পারে।

TTL ক্ষেত্র

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

বড় অ্যারে বা মানচিত্র ক্ষেত্র

বড় অ্যারে বা মানচিত্র ক্ষেত্রগুলি প্রতি নথিতে 40,000 সূচক এন্ট্রির সীমার কাছে যেতে পারে। যদি আপনি একটি বড় অ্যারে বা মানচিত্র ক্ষেত্রের উপর ভিত্তি করে অনুসন্ধান না করেন, তাহলে আপনার এটিকে সূচীকরণ থেকে অব্যাহতি দেওয়া উচিত।

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

  • একটি অ্যাপ একটি একক নথি আপডেট করতে পারে এমন সঠিক সর্বোচ্চ হার কাজের চাপের উপর নির্ভর করে। আরও তথ্যের জন্য, একটি একক নথির আপডেট দেখুন।

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

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

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

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

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

রিয়েল-টাইম আপডেটের সাথে সম্পর্কিত সর্বোত্তম অনুশীলনের জন্য, স্কেলে রিয়েল-টাইম প্রশ্নগুলি বুঝতে দেখুন।

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

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

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

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

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

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

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

  • খুব উচ্চ হারে নতুন নথি তৈরি করে এবং নিজস্ব একঘেয়েভাবে ক্রমবর্ধমান আইডি বরাদ্দ করে।

    Cloud Firestore একটি স্ক্যাটার অ্যালগরিদম ব্যবহার করে ডকুমেন্ট আইডি বরাদ্দ করে। আপনি যদি স্বয়ংক্রিয় ডকুমেন্ট আইডি ব্যবহার করে নতুন নথি তৈরি করেন তবে আপনার লেখাগুলিতে হটস্পটিংয়ের সম্মুখীন হওয়া উচিত নয়।

  • কিছু নথি সহ একটি সংগ্রহে উচ্চ হারে নতুন নথি তৈরি করে।

  • টাইমস্ট্যাম্পের মতো একঘেয়ে ক্রমবর্ধমান ক্ষেত্রের সাথে খুব উচ্চ হারে নতুন নথি তৈরি করে।

  • একটি উচ্চ হারে একটি সংগ্রহে নথি মুছে দেয়।

  • ধীরে ধীরে ট্রাফিক বৃদ্ধি না করে খুব উচ্চ হারে ডাটাবেসে লিখুন।

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

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

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

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()

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

ট্রাফিক ramping আপ

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

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

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

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

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

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

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

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

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

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

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

গোপনীয়তা

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

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

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

Cloud Firestore Security Rules ব্যবহার সম্পর্কে আরও জানুন।

,

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

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

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

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

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

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

  • ডকুমেন্ট আইডি এড়িয়ে চলুন . এবং ..
  • ডকুমেন্ট আইডিতে ব্যবহার / ফরোয়ার্ড স্ল্যাশ এড়িয়ে চলুন।
  • একঘেয়ে বাড়ানো ডকুমেন্ট আইডি ব্যবহার করবেন না যেমন:

    • Customer1 , Customer2 , Customer3 , ...
    • Product 1 , Product 2 , Product 3 , ...

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

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

  • ক্ষেত্রের নামগুলিতে নিম্নলিখিত অক্ষরগুলি এড়িয়ে চলুন কারণ তাদের অতিরিক্ত পালানোর প্রয়োজন:

    • . সময়কাল
    • [ বাম বন্ধনী
    • ] ডান বন্ধনী
    • * তারকাচিহ্ন
    • ` ব্যাকটিক

সূচক

লেখার বিলম্ব কমিয়ে দিন

লেটেন্সি লেখার প্রধান অবদানকারী হল ইনডেক্স ফ্যানআউট। সূচক ফ্যানআউট কমাতে সর্বোত্তম অনুশীলনগুলি হল:

  • সংগ্রহ-স্তরের সূচক ছাড় সেট করুন। একটি সহজ ডিফল্ট হল ডিসেন্ডিং এবং অ্যারে ইন্ডেক্সিং অক্ষম করা। অব্যবহৃত সূচীকৃত মানগুলি সরানোর ফলে স্টোরেজ খরচও কম হবে।

  • একটি লেনদেনে নথির সংখ্যা হ্রাস করুন। বিপুল সংখ্যক নথি লেখার জন্য, পারমাণবিক ব্যাচ লেখকের পরিবর্তে একটি বাল্ক রাইটার ব্যবহার করার কথা বিবেচনা করুন।

সূচক ছাড়

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

মামলা বর্ণনা
বড় স্ট্রিং ক্ষেত্র

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

ক্রমিক মান সহ নথি সমন্বিত একটি সংগ্রহে উচ্চ লেখার হার

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

একটি উচ্চ লেখার হার সহ একটি IoT ব্যবহারের ক্ষেত্রে, উদাহরণস্বরূপ, একটি টাইমস্ট্যাম্প ফিল্ড সহ নথি সমন্বিত একটি সংগ্রহ প্রতি সেকেন্ডে 500 রাইটের কাছে যেতে পারে।

TTL ক্ষেত্র

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

বড় অ্যারে বা মানচিত্র ক্ষেত্র

বড় অ্যারে বা মানচিত্র ক্ষেত্রগুলি প্রতি নথিতে 40,000 সূচক এন্ট্রির সীমার কাছে যেতে পারে। যদি আপনি একটি বড় অ্যারে বা মানচিত্র ক্ষেত্রের উপর ভিত্তি করে অনুসন্ধান না করেন, তাহলে আপনার এটিকে সূচীকরণ থেকে অব্যাহতি দেওয়া উচিত।

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

  • একটি অ্যাপ একটি একক নথি আপডেট করতে পারে এমন সঠিক সর্বোচ্চ হার কাজের চাপের উপর নির্ভর করে। আরও তথ্যের জন্য, একটি একক নথির আপডেট দেখুন।

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

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

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

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

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

রিয়েল-টাইম আপডেটের সাথে সম্পর্কিত সর্বোত্তম অনুশীলনের জন্য, স্কেলে রিয়েল-টাইম প্রশ্নগুলি বুঝতে দেখুন।

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

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

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

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

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

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

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

  • খুব উচ্চ হারে নতুন নথি তৈরি করে এবং নিজস্ব একঘেয়েভাবে ক্রমবর্ধমান আইডি বরাদ্দ করে।

    Cloud Firestore একটি স্ক্যাটার অ্যালগরিদম ব্যবহার করে ডকুমেন্ট আইডি বরাদ্দ করে। আপনি যদি স্বয়ংক্রিয় ডকুমেন্ট আইডি ব্যবহার করে নতুন নথি তৈরি করেন তবে আপনার লেখাগুলিতে হটস্পটিংয়ের সম্মুখীন হওয়া উচিত নয়।

  • কিছু নথি সহ একটি সংগ্রহে উচ্চ হারে নতুন নথি তৈরি করে।

  • টাইমস্ট্যাম্পের মতো একঘেয়ে ক্রমবর্ধমান ক্ষেত্রের সাথে খুব উচ্চ হারে নতুন নথি তৈরি করে।

  • একটি উচ্চ হারে একটি সংগ্রহে নথি মুছে দেয়।

  • ধীরে ধীরে ট্রাফিক বৃদ্ধি না করে খুব উচ্চ হারে ডাটাবেসে লিখুন।

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

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

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

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()

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

ট্রাফিক ramping আপ

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

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

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

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

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

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

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

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

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

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

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

গোপনীয়তা

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

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

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

Cloud Firestore Security Rules ব্যবহার সম্পর্কে আরও জানুন।

,

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

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

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

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

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

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

  • ডকুমেন্ট আইডি এড়িয়ে চলুন . এবং ..
  • ডকুমেন্ট আইডিতে ব্যবহার / ফরোয়ার্ড স্ল্যাশ এড়িয়ে চলুন।
  • একঘেয়ে বাড়ানো ডকুমেন্ট আইডি ব্যবহার করবেন না যেমন:

    • Customer1 , Customer2 , Customer3 , ...
    • Product 1 , Product 2 , Product 3 , ...

    এই জাতীয় অনুক্রমিক আইডিগুলি হটস্পটগুলিতে নেতৃত্ব দিতে পারে যা বিলম্বকে প্রভাবিত করে।

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

  • ক্ষেত্রের নামগুলিতে নিম্নলিখিত অক্ষরগুলি এড়িয়ে চলুন কারণ তাদের অতিরিক্ত পলায়ন প্রয়োজন:

    • . সময়কাল
    • [ বাম বন্ধনী
    • ] ডান ব্র্যাকেট
    • * তারকাচিহ্ন
    • ` ব্যাকটিক

সূচক

লেখার বিলম্ব হ্রাস করুন

লেটেন্সি লেখার প্রধান অবদানকারী হ'ল সূচক ফ্যানআউট। সূচক ফ্যানআউট হ্রাস করার জন্য সেরা অনুশীলনগুলি হ'ল:

  • সংগ্রহ-স্তরের সূচক ছাড়গুলি সেট করুন। একটি সহজ ডিফল্ট হ'ল অবতরণ এবং অ্যারে ইনডেক্সিং অক্ষম করা। অব্যবহৃত সূচকযুক্ত মানগুলি অপসারণও স্টোরেজ ব্যয়ও কম করবে।

  • একটি লেনদেনে নথির সংখ্যা হ্রাস করুন। বিপুল সংখ্যক নথি লেখার জন্য, পারমাণবিক ব্যাচ লেখকের পরিবর্তে একটি বাল্ক লেখক ব্যবহার করার বিষয়টি বিবেচনা করুন।

সূচক ছাড়

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

মামলা বর্ণনা
বড় স্ট্রিং ক্ষেত্র

আপনার যদি এমন একটি স্ট্রিং ক্ষেত্র থাকে যা প্রায়শই দীর্ঘ স্ট্রিং মান রাখে যা আপনি জিজ্ঞাসা করার জন্য ব্যবহার করেন না, আপনি ক্ষেত্রটিকে সূচক থেকে ছাড় দিয়ে স্টোরেজ ব্যয় কেটে ফেলতে পারেন।

অনুক্রমিক মান সহ নথিযুক্ত একটি সংগ্রহে উচ্চ লেখার হার

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

একটি উচ্চ লেখার হারের সাথে আইওটি ব্যবহারের ক্ষেত্রে, উদাহরণস্বরূপ, টাইমস্ট্যাম্প ক্ষেত্র সহ নথিযুক্ত একটি সংগ্রহ প্রতি সেকেন্ডে 500 লেখার কাছে যেতে পারে।

টিটিএল ক্ষেত্রগুলি

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

বড় অ্যারে বা মানচিত্রের ক্ষেত্রগুলি

বড় অ্যারে বা মানচিত্রের ক্ষেত্রগুলি নথিতে প্রতি 40,000 সূচক এন্ট্রিগুলির সীমাটির কাছে যেতে পারে। আপনি যদি কোনও বৃহত অ্যারে বা মানচিত্রের ক্ষেত্রের উপর ভিত্তি করে জিজ্ঞাসা করছেন না তবে আপনার এটিকে সূচক থেকে অব্যাহতি দেওয়া উচিত।

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

  • একটি অ্যাপ্লিকেশন একটি একক নথি আপডেট করতে পারে সঠিক সর্বোচ্চ হার কাজের চাপের উপর নির্ভর করে। আরও তথ্যের জন্য, একটি একক নথিতে আপডেট দেখুন।

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

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

লেনদেন পুনরুদ্ধার

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

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

রিয়েল-টাইম আপডেটগুলির সাথে সম্পর্কিত সেরা অনুশীলনের জন্য, স্কেলটিতে রিয়েল-টাইম কোয়েরিগুলি বুঝতে দেখুন।

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

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

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

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

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

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

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

  • খুব উচ্চ হারে নতুন ডকুমেন্ট তৈরি করে এবং নিজস্ব একঘেয়েভাবে বর্ধমান আইডি বরাদ্দ করে।

    Cloud Firestore একটি স্ক্যাটার অ্যালগরিদম ব্যবহার করে ডকুমেন্ট আইডি বরাদ্দ করে। আপনি যদি স্বয়ংক্রিয় ডকুমেন্ট আইডি ব্যবহার করে নতুন ডকুমেন্ট তৈরি করেন তবে আপনার লেখার উপর হটস্পটিংয়ের মুখোমুখি হওয়া উচিত নয়।

  • কয়েকটি নথি সহ সংগ্রহে উচ্চ হারে নতুন নথি তৈরি করে।

  • খুব উচ্চ হারে টাইমস্ট্যাম্পের মতো একঘেয়েভাবে বর্ধমান ক্ষেত্রের সাথে নতুন নথি তৈরি করে।

  • উচ্চ হারে সংগ্রহে নথিগুলি মুছে দেয়।

  • ধীরে ধীরে ট্র্যাফিক না বাড়িয়ে খুব উচ্চ হারে ডাটাবেসে লেখেন।

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

সম্প্রতি মুছে ফেলা ডেটা এড়িয়ে যাওয়া প্রশ্নগুলি এড়িয়ে চলুন। যদি প্রাথমিক ক্যোয়ারির ফলাফলগুলি সম্প্রতি মুছে ফেলা হয় তবে একটি ক্যোয়ারীকে প্রচুর পরিমাণে সূচক এন্ট্রি এড়িয়ে যেতে হতে পারে।

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

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()

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

ট্র্যাফিক র‌্যাম্পিং

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

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

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

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

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

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

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

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

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

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

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

গোপনীয়তা

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

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

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

Cloud Firestore Security Rules ব্যবহার সম্পর্কে আরও জানুন।