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

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

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

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

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

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

নথি আইডি

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

• একমুখীভাবে ক্রমবর্ধমান ডকুমেন্ট আইডি ব্যবহার করবেন না, যেমন:

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

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

ফিল্ডের নাম

• ফিল্ডের নামে নিম্নলিখিত অক্ষরগুলি ব্যবহার করা থেকে বিরত থাকুন, কারণ এগুলির জন্য অতিরিক্ত এস্কেপিং প্রয়োজন হয়:

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

সূচক

রাইট ল্যাটেন্সি হ্রাস করুন

রাইট ল্যাটেন্সির প্রধান কারণ হলো ইনডেক্স ফ্যানআউট। ইনডেক্স ফ্যানআউট কমানোর সেরা উপায়গুলো হলো:

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

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

সূচক ছাড়

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

পঠন এবং লিখন কার্যক্রম

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

• 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.

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

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

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

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

রিয়েল-টাইম আপডেট সম্পর্কিত সেরা অনুশীলনগুলির জন্য, "Understand real-time queries at scale" দেখুন।

বৃহৎ পরিসরের জন্য ডিজাইন করা

নিম্নলিখিত সর্বোত্তম অনুশীলনগুলি বর্ণনা করে যে কীভাবে বিরোধপূর্ণ সমস্যা সৃষ্টিকারী পরিস্থিতি এড়ানো যায়।

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

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

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

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

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

• অত্যন্ত উচ্চ হারে নতুন ডকুমেন্ট তৈরি করে এবং সেগুলোর জন্য নিজস্ব ক্রমবর্ধমান আইডি বরাদ্দ করে।

  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.

• অল্প সংখ্যক ডকুমেন্ট থাকা কোনো কালেকশনে উচ্চ হারে নতুন ডকুমেন্ট তৈরি করে।

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

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

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

মুছে ফেলা ডেটা এড়িয়ে যাওয়া থেকে বিরত থাকুন।

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

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

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.

পারফরম্যান্স উন্নত করতে, শুরু করার সেরা জায়গা খুঁজে বের করার জন্য 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 বর্ধিত ট্র্যাফিকের জন্য ডকুমেন্ট প্রস্তুত করার পর্যাপ্ত সময় দিতে, আপনার নতুন কালেকশনগুলিতে ট্র্যাফিক ধীরে ধীরে বাড়ানো উচিত অথবা ডকুমেন্টগুলি লেক্সিকোগ্রাফিকভাবে বন্ধ করা উচিত। আমরা একটি নতুন কালেকশনে প্রতি সেকেন্ডে সর্বোচ্চ ৫০০টি অপারেশন দিয়ে শুরু করার এবং তারপর প্রতি ৫ মিনিটে ট্র্যাফিক ৫০% করে বাড়ানোর পরামর্শ দিই। আপনি একইভাবে আপনার রাইট ট্র্যাফিকও বাড়াতে পারেন, তবে Cloud Firestore স্ট্যান্ডার্ড লিমিটগুলো মনে রাখবেন। নিশ্চিত করুন যে অপারেশনগুলো কী রেঞ্জ জুড়ে তুলনামূলকভাবে সমানভাবে বণ্টিত হয়েছে। একে "৫০০/৫০/৫" নিয়ম বলা হয়।

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

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

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

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

সমান্তরাল পাঠ

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.

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

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

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

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

গোপনীয়তা

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

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

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

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