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

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 ব্যবহার সম্পর্কে আরও জানুন।