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

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

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

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

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

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

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

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

• একঘেয়েভাবে বর্ধিত ডকুমেন্ট আইডি ব্যবহার করবেন না যেমন:

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

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

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

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

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

সূচী

লেখার বিলম্ব কমানো

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

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

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

সূচক ছাড়

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

পড়া এবং লেখার কাজ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

গোপনীয়তা

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

অননুমোদিত অ্যাক্সেস প্রতিরোধ করুন

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

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