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

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

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

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

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

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

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

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

• একটানা বৃদ্ধি পাওয়া ডকুমেন্ট আইডি ব্যবহার করবেন না, যেমন:

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

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

ফিল্ডের নাম

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

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

ইন্ডেক্স

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

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

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

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

ইনডেক্স সংক্রান্ত ছাড়

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

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

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

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

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

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

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