Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More

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

সেভ করা পৃষ্ঠা গুছিয়ে রাখতে 'সংগ্রহ' ব্যবহার করুন আপনার পছন্দ অনুযায়ী কন্টেন্ট সেভ করুন ও সঠিক বিভাগে রাখুন।

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

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

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

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

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

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

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

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

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

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

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

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

সূচক

  • অত্যধিক সূচক ব্যবহার এড়িয়ে চলুন. অত্যধিক সংখ্যক সূচী লেখার লেটেন্সি বাড়াতে পারে এবং ইনডেক্স এন্ট্রির জন্য স্টোরেজ খরচ বাড়াতে পারে।

  • সচেতন থাকুন যে একঘেয়ে ক্রমবর্ধমান মানগুলির সাথে সূচীকরণ ক্ষেত্রগুলি, যেমন টাইমস্ট্যাম্প, হটস্পটগুলির দিকে নিয়ে যেতে পারে যা উচ্চ পঠন এবং লেখার হার সহ অ্যাপ্লিকেশনগুলির জন্য লেটেন্সিকে প্রভাবিত করে৷

সূচক ছাড়

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

মামলা বর্ণনা
বড় স্ট্রিং ক্ষেত্র

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

ক্রমিক মান সহ নথি সমন্বিত একটি সংগ্রহে উচ্চ লেখার হার

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

একটি উচ্চ লেখার হার সহ একটি IoT ব্যবহারের ক্ষেত্রে, উদাহরণস্বরূপ, একটি টাইমস্ট্যাম্প ফিল্ড সহ নথি সমন্বিত একটি সংগ্রহ প্রতি সেকেন্ডে 500 রাইটের কাছে যেতে পারে।

TTL ক্ষেত্র

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

বড় অ্যারে বা মানচিত্র ক্ষেত্র

বড় অ্যারে বা মানচিত্র ক্ষেত্রগুলি প্রতি নথিতে 40,000 সূচক এন্ট্রির সীমার কাছে যেতে পারে। যদি আপনি একটি বড় অ্যারে বা মানচিত্র ক্ষেত্রের উপর ভিত্তি করে অনুসন্ধান না করেন, তাহলে আপনার এটিকে সূচীকরণ থেকে অব্যাহতি দেওয়া উচিত।

পড়া এবং লেখা অপারেশন

  • একটি নথিতে প্রতি সেকেন্ডে একাধিকবার লেখা এড়িয়ে চলুন। আরও তথ্যের জন্য, একটি একক নথির আপডেট দেখুন।

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

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

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

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

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

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

সুপারিশ বিস্তারিত
স্ন্যাপশট শ্রোতা মন্থন হার হ্রাস

শ্রোতাদের ঘন ঘন মন্থন করা এড়িয়ে চলুন, বিশেষ করে যখন আপনার ডাটাবেস উল্লেখযোগ্য লেখার লোডের অধীনে থাকে

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

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

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

ক্লায়েন্ট প্রতি স্ন্যাপশট শ্রোতা সীমিত

100

প্রতি ক্লায়েন্টের স্ন্যাপশট শ্রোতার সংখ্যা 100 এর নিচে রাখুন।

সংগ্রহ লেখার হার সীমিত করুন

1,000 অপারেশন/সেকেন্ড

একটি পৃথক সংগ্রহের জন্য 1,000 অপারেশন/সেকেন্ডের নিচে লেখার ক্রিয়াকলাপগুলির হার রাখুন।

স্বতন্ত্র ক্লায়েন্ট পুশ রেট সীমিত করুন

1 নথি/সেকেন্ড

1 নথি/সেকেন্ডের মধ্যে একটি পৃথক ক্লায়েন্টের কাছে ডাটাবেস পুশ করে ডকুমেন্টের হার রাখুন।

বিশ্বব্যাপী ক্লায়েন্ট পুশ রেট সীমিত করুন

1,000,000 নথি/সেকেন্ড

1,000,000 নথি/সেকেন্ডের নিচে সমস্ত ক্লায়েন্টের কাছে ডাটাবেস পুশ করে ডকুমেন্টের হার রাখুন।

এটি একটি নরম সীমা। ক্লাউড ফায়ারস্টোর আপনাকে এই থ্রেশহোল্ড অতিক্রম করতে বাধা দেয় না তবে এটি কার্যক্ষমতাকে ব্যাপকভাবে প্রভাবিত করে।

পৃথক নথি পেলোড সীমিত

10 KiB/সেকেন্ড

একজন স্বতন্ত্র ক্লায়েন্ট দ্বারা ডাউনলোড করা ডকুমেন্টের সর্বোচ্চ আকার 10 KiB/সেকেন্ডের নিচে রাখুন।

গ্লোবাল ডকুমেন্ট পেলোড সীমিত করুন

1 GiB/সেকেন্ড

1 GiB/সেকেন্ডের নিচে সমস্ত ক্লায়েন্ট জুড়ে ডাউনলোড করা ডকুমেন্টের সর্বোচ্চ আকার রাখুন।

নথি প্রতি ক্ষেত্র সংখ্যা সীমিত

100

আপনার নথিতে 100টিরও কম ক্ষেত্র থাকা উচিত।

ক্লাউড ফায়ারস্টোর স্ট্যান্ডার্ড সীমা বুঝুন

ক্লাউড ফায়ারস্টোরের মান সীমা মনে রাখবেন।

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

স্কেল জন্য ডিজাইনিং

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

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

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

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

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

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

  • খুব উচ্চ হারে নতুন নথি তৈরি করে এবং নিজস্ব একঘেয়েভাবে ক্রমবর্ধমান আইডি বরাদ্দ করে।

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

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

  • টাইমস্ট্যাম্পের মতো একঘেয়ে ক্রমবর্ধমান ক্ষেত্রের সাথে খুব উচ্চ হারে নতুন নথি তৈরি করে।

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

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

মুছে ফেলা ডেটা এড়িয়ে যাওয়া এড়িয়ে চলুন

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

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

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

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

ট্রাফিক ramping আপ

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

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

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

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

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

সমান্তরাল পড়ে

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

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

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

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

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

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

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

ক্লাউড ফায়ারস্টোর নিরাপত্তা নিয়ম ব্যবহার সম্পর্কে আরও জানুন।