Cloud Firestore-এর জন্য পেশাদার পদ্ধতি

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

ডেটাবেসের লোকেশন

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

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

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

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

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

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

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

ফিল্ডের নাম

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

    • . ফুল স্টপ
    • [ বাঁদিকের ব্র্যাকেট
    • ] ডানদিকের ব্র্যাকেট
    • * অ্যাসটেরিক্স
    • ` ব্যাকটিক

ইন্ডেক্স

রাইট লেটেন্সি কমানো

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

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

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

ইনডেক্স ছাড়

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

কারক বিবরণ
বড় স্ট্রিং ফিল্ড

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

সিকোয়েন্সিয়াল ভ্যালু সহ ডকুমেন্ট আছে এমন কালেকশনে হাই রাইট রেট

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

IoT ব্যবহারের ক্ষেত্রে যেখানে রাইট রেট বেশি, যেমন, টাইমস্ট্যাম্প ফিল্ড সহ ডকুমেন্ট আছে এমন কালেকশন প্রতি সেকেন্ডে ৫০০ বার রাইট করার সীমায় পৌঁছে যেতে পারে।

TTL ফিল্ড

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

বড় অ্যারে বা ম্যাপ ফিল্ড

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

রিড ও রাইট অপারেশন

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

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

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

ট্রানজ্যাকশন আবার চেষ্টা করা হয়েছে

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

নতুন কালেকশনে ট্রাফিক মাইগ্রেট করা হচ্ছে

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

একই কালেকশনের মধ্যে থাকা অনেক ডকুমেন্টের ডকুমেন্ট আইডি পরিবর্তন করলে, একই ধরনের সমস্যা হতে পারে।

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

প্যারালাল রিড

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

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

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

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

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

গোপনীয়তা

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

অননুমোদিত অ্যাক্সেস আটকানো

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

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