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

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

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

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

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

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 .

নথি আইডি

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

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

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

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

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

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

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

সূচক

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

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

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

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

সূচক ছাড়

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Writes to the database at a very high rate without gradually increasing traffic.

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

গোপনীয়তা

• Avoid storing sensitive information in a Cloud Project ID. A Cloud Project ID might be retained beyond the life of your project.
• As a data compliance best practice, we recommend not storing sensitive information in document names and document field names.

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

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

Learn more about using Cloud Firestore Security Rules .