মঙ্গোডিবিতে ডেটা মাইগ্রেশন অপ্টিমাইজ করুন: গতি এবং স্কেলেবিলিটির জন্য রিশার্ডিং টেকনিক

একটি 2TB সংগ্রহ এবং 24 ঘন্টার মধ্যে আপনার সমস্ত শার্ড জুড়ে ডেটা বিতরণ করতে হবে? আপনার ডেটা স্থানান্তরকে ত্বরান্বিত করতে রিশার্ডিংয়ের সুবিধা নিন!

এই পোস্টে, আমরা "রিশার্ড-টু-শার্ড" নামক একটি কৌশল কভার করব যা আপনার ক্লাস্টারে দ্রুত ডাটা ছড়িয়ে দিতে রিশার্ডিং ব্যবহার করে।

আমরা যাব:

1. মাইগ্রেশনের আগে এবং সময় বিবেচনা।
2. দ্রুত ডেটা মাইগ্রেশন কীভাবে শুরু করবেন, নিরীক্ষণ করবেন এবং বাতিল করবেন।

আপনি যদি শার্ডিং-এ নতুন হন বা MongoDB কীভাবে অনুভূমিক মাপযোগ্যতা প্রদান করে সে সম্পর্কে একটি রিফ্রেশার চান, অনুগ্রহ করে দেখুন MongoDB ম্যানুয়াল .

সুচিপত্র

• পটভূমি
• রিশার্ড-টু-শার্ডের সুবিধা কী?
• আমি কখন রিশার্ড-টু-শার্ড ব্যবহার করব?
• কখন আমি reshard-to-sard ব্যবহার করব না?
• রিশার্ড-টু-শার্ড পূর্বশর্তগুলি কী কী?
• রিশার্ড-টু-শার্ড টেকনিক ওভারভিউ
• reshard-to-shard উদাহরণ
• FAQs

পটভূমি

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

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

রিশার্ড-টু-শার্ডের সুবিধা কী?

প্রথমত, এটা অনেক দ্রুত! রিশার্ডিং সুবিধার মাধ্যমে, একজন গ্রাহক 22.5 ঘন্টার মধ্যে 4টি শার্ড জুড়ে তাদের 3.5TB সংগ্রহ শার্ড এবং বিতরণ করতে সক্ষম হয়েছিল। খণ্ড মাইগ্রেশনের ব্যালেন্সারের ডিফল্ট পদ্ধতিতে ছেড়ে দিলে একই প্রক্রিয়াটি 30 দিন সময় নেয়।

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

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

উদাহরণস্বরূপ, একজন গ্রাহক তাদের বৃহত্তম সংগ্রহের রিশার্ডিং অপারেশন সম্পূর্ণ হওয়ার আগে shard0-এ প্রায় 2.8TB ব্যবহার করছিলেন।

রিশার্ডিং শেষ হলে, 1.9TB স্টোরেজ স্পেস অবিলম্বে ফিরিয়ে দেওয়া হয়েছিল! তারা 2.7TB স্টোরেজ থেকে 873GB সঞ্চয়স্থানে চলে গেছে।

আমি কখন রিশার্ড-টু-শার্ড ব্যবহার করব?

উত্তর: আপনি যখন প্রাথমিকভাবে যেকোন সংখ্যক শার্ড জুড়ে যেকোন আকারের একটি সংগ্রহ ভাগ করছেন।

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

কখন আমি reshard-to-sard ব্যবহার করব না?

আপনার রিশার্ড-টু-শার্ড কৌশলটি ব্যবহার করা উচিত নয় যখন:

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

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

    
    

• আপনার সংগ্রহ একটি সময়-সিরিজ সংগ্রহ
  • আপনি যদি একটি টাইম-সিরিজ সংগ্রহ পুনরায় ভাগ করার চেষ্টা করেন তবে আপনি একটি ত্রুটি বার্তা পাবেন যাতে বলা হয় যে একটি সময়-সিরিজ সংগ্রহ পুনরায় ভাগ করা সমর্থিত নয়।

উপরে তালিকাভুক্ত পরিস্থিতিগুলির জন্য, একটি সংগ্রহকে শার্ড করার এবং ব্যালেন্সারকে ডেটা স্থানান্তরিত করার ঐতিহ্যগত পদ্ধতি ব্যবহার করুন।

রিশার্ড-টু-শার্ড পূর্বশর্তগুলি কী কী?

1. MongoDB 5.0 বা তার বেশি চলমান একটি MongoDB ক্লাস্টার

   1. MongoDB 5.0 বা 6.0 চালালে নিশ্চিত করুন যে আপনার ক্লাস্টার 5.0.14 বা 6.0.3-এর চেয়ে বেশি প্যাচ রিলিজ চালাচ্ছে

2. আপনার সংগ্রহের জন্য আপনাকে অবশ্যই একটি উপযুক্ত শার্ড কী নির্বাচন করতে হবে।

3. অস্থায়ী শার্ড কী এবং পছন্দসই শার্ড কী উভয় সমর্থন করার জন্য প্রয়োজনীয় সূচীগুলি তৈরি করুন।

4. উপরন্তু, যেহেতু আপনি ডেটা মাইগ্রেশনের গতি ত্বরান্বিত করতে রিশার্ডিং ব্যবহার করবেন, অনুগ্রহ করে নিজেকে এর সাথে পরিচিত করুন রিশার্ডিং প্রয়োজনীয়তা এবং সীমাবদ্ধতা .

একটি রিশার্ডিং অপারেশন সফলভাবে চালানোর জন্য আপনার ক্লাস্টারে থাকা উচিত:

• প্রতিটি শার্ডে উপলব্ধ সংগ্রহের আকার প্রতি শার্ডের 2.2 গুণ।
  • উদাহরণস্বরূপ, আপনি যদি 4 টি শার্ড জুড়ে একটি 1TB সংগ্রহ ভাগ করছেন, 4 টি শার্ড জুড়ে বিতরণ করা হলে শার্ড সংগ্রহের আকার প্রতি শার্ড 250GB হয়। আপনি প্রতিটি শার্ডে ন্যূনতম 550GB সঞ্চয়স্থান পেতে চান।
• I/O ক্ষমতা 50% এর নিচে
• 80% এর নিচে CPU ব্যবহার

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

রিশার্ড-টু-শার্ড টেকনিক ওভারভিউ

রিশার্ড-টু-শার্ড অপারেশন চালানোর জন্য দুটি খুব সহজ ধাপ রয়েছে:

1. একটি অস্থায়ী শার্ড কী মধ্যে Shard
2. আপনার পছন্দসই শার্ড কীতে পুনরায় যোগ করুন

কেন আমি প্রথমে একটি অস্থায়ী শার্ড কী-তে শার্ড করব, এবং এটি আমার অ্যাপ্লিকেশনের ক্ষতি করবে না?

এর ব্যাখ্যা করা যাক!

প্রথম ধাপ: একটি অস্থায়ী শার্ড কী দিয়ে শার্ড

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

অস্থায়ী শার্ড কী আপনার শার্ড কী ক্ষেত্রের একটির জন্য আলাদা পার্টিশন কৌশল নির্বাচন করা উচিত। কিছু নির্দিষ্ট প্রশ্নের সীমাবদ্ধতার কারণে যেমন updateOne(), updateMany(), deleteOne(), ইত্যাদির জন্য শার্ড কী অন্তর্ভুক্ত করার জন্য ক্যোয়ারী প্রয়োজন, আপনি একটি আলাদা পার্টিশন কৌশল ব্যবহার করবেন। MongoDB পার্টিশনিং কৌশলগুলিকে শুধুমাত্র একটি উপায় হিসাবে ব্যবহার করে যে কীভাবে আপনার ক্লাস্টারের সমস্ত অংশে আপনার ডেটা বিতরণ করা যায় এবং এটি নথির মান পরিবর্তন করে না। এর মানে হল যে আপনার অ্যাপ্লিকেশনটি একটি updateOne বা অন্য একটি কোয়েরি ব্যবহার করতে পারে যার জন্য উভয় পার্টিশনিং কৌশল সহ শার্ড কী প্রয়োজন।

উদাহরণস্বরূপ, যদি আপনি আপনার সংগ্রহের জন্য পছন্দসই শার্ড কীটি নির্বাচন করেন:

 {"_id": "hashed"}

আপনার সংগ্রহের জন্য প্রাথমিকভাবে ব্যবহার করার জন্য অস্থায়ী শার্ড কীটি হওয়া উচিত:

 {"_id": 1}

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

 { launch_vehicle: 1, payload: 1}

আপনার অস্থায়ী শার্ড কীটি হওয়া উচিত:

 { launch_vehicle: 1}

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

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

ধাপ দুই: আপনার কাঙ্খিত শার্ড কী পুনরায় শেড করুন

দ্বিতীয় ধাপটি হল একটি স্বাভাবিক রিশার্ডিং অপারেশন চালানো ছাড়া আপনি কীভাবে রিশার্ডিং আপনার সুবিধার জন্য কাজ করে তার একটি পার্শ্বপ্রতিক্রিয়া ব্যবহার করছেন।

রিশার্ডিংয়ের চারটি প্রধান পর্যায় রয়েছে:

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

  
  

• ইনডেক্স - রিশার্ডিং অপারেশনটি নতুন শার্ড কী-এর উপর ভিত্তি করে সমস্ত শার্ডে একটি নতুন খালি অস্থায়ী শার্ড সংগ্রহ তৈরি করে এবং বিদ্যমান সংগ্রহকে সমর্থন করে এমন নন-শার্ড কী সূচকগুলি সহ সূচকগুলি তৈরি করে।

  
  

• ক্লোন, ক্যাচ-আপ এবং প্রয়োগ করুন - নথিগুলিকে নতুন শার্ড কী অনুসারে শার্ডগুলিতে ক্লোন করা হয়, এবং পুনরায় শার্ডিং অপারেশন চালানোর সময় নথিতে যে কোনও পরিবর্তন প্রয়োগ করা হয়।

  
  

• প্রতিশ্রুতি দিন - অস্থায়ী সংগ্রহের নাম পরিবর্তন করা হয়েছে এবং সংগ্রহের স্থানটি পুনরায় সংযোজন করা হয়েছে এবং এখন পুরানো সংগ্রহটি বাদ দেওয়া হয়েছে।

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

রিশার্ডিং অপারেশন সম্পূর্ণ হয়ে গেলে, আপনি ক্লিন-আপ অপারেশন পরিচালনা করতে পারেন যেমন অস্থায়ী শার্ড কী সূচকটি ড্রপ করা এবং আপনার ক্লাস্টার এবং/অথবা আপনার স্থির-স্থিতির প্রয়োজনের জন্য আপনার স্টোরেজকে স্কেল করা।

reshard-to-shard উদাহরণ

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

আপনার সংগ্রহের জন্য আপনি যে শার্ড কীটি নির্বাচন করেছেন তা হল:

 { airline: 1, flight_number: 1, date: "hashed" }

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

তাই আপনি যে অস্থায়ী শার্ড কীটি নির্বাচন করেছেন তা হল:

 { airline: 1, flight_number: 1 }

এর পরে, আপনি অস্থায়ী এবং চূড়ান্ত শার্ড কী উভয় সমর্থন করার জন্য সূচীগুলি তৈরি করেন।

db.collection.createIndex() বা db.collection.createIndexes() এর মাধ্যমে মঙ্গো শেল ব্যবহার করে সূচী তৈরি করা যেতে পারে।

যেহেতু পছন্দসই শার্ড কীটি একটি যৌগিক শার্ড কী আপনাকে শুধুমাত্র একটি সূচক তৈরি করতে হবে db.collection.createIndexes() এর মাধ্যমে :

 db.flight_tracker.createIndex( { "airline": 1, "flight_number": 1, date: "hashed" } )

নিম্নলিখিত কমান্ডের মাধ্যমে মঙ্গো শেল ব্যবহার করে ইনডেক্স বিল্ডগুলি পর্যবেক্ষণ করা যেতে পারে:

 db.adminCommand({ currentOp: true, $or: [ { op: "command", "command.createIndexes": { $exists: true } }, { op: "none", "msg" : /^Index Build/ } ] })

যদি আপনার MongoDB ক্লাস্টারটি Atlas-এ স্থাপন করা হয়, তাহলে আপনি Atlas UI ব্যবহার করে সহজেই উপলব্ধ মেট্রিকগুলি পর্যালোচনা করতে পারেন যা আপনাকে জানায় যে আপনার ক্লাস্টারে পর্যাপ্ত বিনামূল্যের সঞ্চয়স্থানের পাশাপাশি CPU এবং I/O হেডরুম একটি রিশার্ডিং অপারেশন পরিচালনা করতে পারে।

যদি পর্যাপ্ত স্টোরেজ স্পেস না থাকে বা I/O হেডরুম না থাকে, আপনি স্টোরেজ স্কেল করতে পারেন। CPU হেডরুমের অভাবের জন্য আপনি ক্লাস্টার স্কেল করতে পারেন। অ্যাটলাস UI এর মাধ্যমে স্টোরেজ এবং ক্লাস্টার উভয়ই স্কেল করা সহজে করা যায়।

ক্লাস্টার কনফিগারেশন অ্যাক্সেস করা সহজ এবং আপনার গ্রুপের ওভারভিউ স্ক্রীন থেকে করা যেতে পারে যা গ্রুপের জন্য স্থাপন করা সমস্ত ক্লাস্টার প্রদর্শন করে।

সমস্ত পূর্বশর্ত পূরণের সাথে, আপনি রিশার্ড-টু-শার্ড প্রক্রিয়ার প্রথম অংশ শুরু করতে পারেন - অস্থায়ী শার্ড কী দিয়ে সংগ্রহটি শার্ড করা।

তারপরে আপনি সংগ্রহটি শার্ড করতে মঙ্গো শেল এবং sh.shardCollection() কমান্ড ব্যবহার করতে পারেন:

 sh.shardCollection("main.flight_tracker", { airline: 1, flight_number: 1 })

sh.shardCollection() সম্পূর্ণ হলে একটি নথি ফেরত দেবে, যদি অপারেশনটি সফল হয় তাহলে ক্ষেত্রের ok এর মান 1 হবে।

 { collectionsharded: 'main.flight_tracker', ok: 1, '$clusterTime': { clusterTime: Timestamp({ t: 1684160896, i: 25 }), signature: { hash: Binary(Buffer.from("7cb424a56cacd56e47bf155bc036e4a4da4ad6b6", "hex"), 0), keyId: Long("7233411438331559942") } }, operationTime: Timestamp({ t: 1684160896, i: 21 }) }

সংগ্রহটি শার্ড হয়ে গেলে, ক্লাস্টারের প্রতিটি শার্ডে এক খণ্ড স্থানান্তরিত হওয়ার জন্য অপেক্ষা করুন। আপনি মঙ্গো শেলে sh.status() এর মাধ্যমে প্রতিটি শার্ডের একটি অংশ আছে কিনা তা পরীক্ষা করতে পারেন:

 sh.status()

আপনার সংগ্রহটি পছন্দসই শার্ড কীতে পুনরায় ভাগ করতে মঙ্গো শেলে sh.reshardCollection() ব্যবহার করুন:

 sh.reshardCollection("main.flight_tracker", { airline: 1, flight_number: 1, date: "hashed" })

আপনি যদি মঙ্গো শেলে sh.status() কমান্ডটি চালান তাহলে আপনি আউটপুটে একটি নতুন সংগ্রহ দেখতে পাবেন যার নামের বিন্যাসে নতুন সংগ্রহটি হচ্ছে <db_name>.system.resharding.<UUID> । এটি সেই সংগ্রহ যা রিশার্ডিং আপনার পছন্দসই শার্ড কী অনুসারে ডেটা তৈরি এবং বিতরণ করছে

ফ্লাইট_ট্র্যাকার সংগ্রহের জন্য রিশার্ডিং অপারেশনের স্থিতি নিরীক্ষণ করতে আপনি নিম্নলিখিত কমান্ডটি ব্যবহার করতে পারেন

 db.getSiblingDB("admin").aggregate([ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "main.flight_tracker" } } ])

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

পুনঃশার্ডিং অপারেশন সমাপ্তির কাছাকাছি হওয়া উচিত যখন প্রতিটি শার্ডের ডেটা আকার সংগ্রহের আকার দ্বারা বৃদ্ধি পেয়েছে ক্লাস্টারে শার্ডের সংখ্যা দ্বারা ভাগ করা হয়েছে। উদাহরণস্বরূপ একটি 1TB সংগ্রহ 4 টি শার্ড জুড়ে পুনরায় ভাগ করা হচ্ছে যখন প্রতিটি শার্ড 250GB লেখা থাকে তখন রিশার্ডিং অপারেশনটি সম্পূর্ণ হওয়া উচিত (শার্ডে অন্যান্য ডেটা সন্নিবেশ করা, আপডেট করা বা মুছে ফেলার জন্য অ্যাকাউন্টিং নয়)।

যদি আপনার ক্লাস্টারটি অ্যাটলাসে স্থাপন করা হয় তবে আপনি ক্লাস্টারের মেট্রিক্স ট্যাব ব্যবহার করে অ্যাটলাস UI এর মাধ্যমে রিশার্ডিং অপারেশনের অগ্রগতি নিরীক্ষণ করতে পারেন।

• MongoDB 6.0 এবং তার চেয়ে বেশি চলমান Atlas ক্লাস্টারগুলির জন্য - আপনি শার্ড ডেটা আকার প্রদর্শন বিকল্পটি ব্যবহার করতে পারেন এবং তারপর <db_name>.system.resharding.<UUID> এর একটি সিনট্যাক্স সহ একটি সংগ্রহ নির্বাচন করতে পারেন। এই দৃশ্যটি অস্থায়ী সংগ্রহকে বিচ্ছিন্ন করে এবং শুধুমাত্র নতুন সংগ্রহের ডেটা আকার বৃদ্ধি প্রদর্শন করবে।

  
  

• MongoDB 5.0 চলমান Atlas ক্লাস্টারগুলির জন্য - আপনি db লজিক্যাল ডেটা আকার প্রদর্শন বিকল্পটি ব্যবহার করতে পারেন। এই দৃষ্টিভঙ্গি সংগ্রহ-স্তরের বিচ্ছিন্নতার অনুমতি দেয় না।

  
  

রিশার্ডিং চালানোর সময়, ক্লাস্টারের তিনটি মেট্রিক যা আপনার প্রাথমিকভাবে পর্যবেক্ষণ করা উচিত:

• উপলব্ধ সঞ্চয়স্থান - সমস্ত উপলব্ধ সঞ্চয়স্থান গ্রাস করলে ক্লাস্টার অস্থিরতা হতে পারে
• সিপিইউ ইউটিলাইজেশন - উচ্চ সিপিইউ ইউটিলাইজেশন ক্লাস্টার পারফরম্যান্সের অবনতি ঘটাতে পারে
• I/O ব্যবহার - আপনার ধারণক্ষমতার বেশি I/O ব্যবহার ক্লাস্টারের কর্মক্ষমতা হ্রাস করতে পারে

আপনি যদি আপনার ক্লাস্টারকে নেতিবাচকভাবে প্রভাবিত করে রিশার্ডিং সম্পর্কে উদ্বিগ্ন হন তবে নিম্নলিখিত কমান্ডের মাধ্যমে প্রক্রিয়াটির কমিট অংশে পৌঁছানোর আগে আপনি তাত্ক্ষণিকভাবে রিশার্ডিং অপারেশনটি বাতিল করতে পারেন:

 sh.abortReshardCollection("main.flight_tracker")

রিশার্ডিং অপারেশন শেষ হলে ফিরে আসবে যদি অপারেশনটি সফল হয় বা না আহ্বানকারী ক্লায়েন্টের কাছে।

যেহেতু রিশার্ডিং একটি দীর্ঘস্থায়ী অপারেশন এবং আপনি হয়ত সেই মঙ্গো শেল সেশনটি বন্ধ করে দিয়েছেন, আপনি যদি বিশদ বিবরণ চান বা __ sh.status() __ অস্থায়ী কিনা তা দেখতে রিশার্ডিং মনিটরিং অ্যাগ্রিগেশন ব্যবহার করে আপনি শার্ডিং অপারেশনটি এখনও কার্যকর হচ্ছে কিনা তা পরীক্ষা করতে পারেন সংগ্রহ এখনও আউটপুট উপস্থিত. যদি রিশার্ডিং অ্যাগ্রিগেশন কিছু ফেরত না দেয় বা আপনি যদি sh.status() এর আউটপুটে আর একটি অস্থায়ী সংগ্রহ দেখতে না পান তবে রিশার্ডিং অপারেশন শেষ হয়ে গেছে।

অপারেশন সফল হয়েছে কিনা তা নিশ্চিত করতে আপনি db.collection.getShardDistribution ব্যবহার করতে পারেন:

 db.flight_tracker.getShardDistribution()

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

• MongoDB 6.0 এর জন্য এবং তার চেয়ে বেশি সমানতা প্রতি শার্ড ডেটার আকার দ্বারা নির্ধারিত হয় তাই আপনি db.collection.getShardDistribution-এর আউটপুটে প্রতিটি শার্ডে প্রায় সমান পরিমাণ ডেটা দেখতে পাবেন।

  
  

• MongoDB 5.0-এর জন্য সমানতা প্রতি শার্ডের সংখ্যা দ্বারা নির্ধারিত হয় তাই আপনি db.collection.getShardDistribution-এর আউটপুটে প্রতিটি শার্ডে সমান সংখ্যক খণ্ড দেখতে পাবেন।

যদি আপনার ক্লাস্টারটি Atlas এ স্থাপন করা হয় তাহলে আপনি মেট্রিক্স ট্যাবের মাধ্যমে Atlas UI ব্যবহার করতে পারেন রিশার্ডিং অপারেশন সফল কিনা তা নির্ধারণ করতে।

• MongoDB 6.0 এবং তার চেয়ে বেশি চলমান অ্যাটলাস ক্লাস্টারগুলির জন্য - আপনি শার্ড ডেটা সাইজ প্রদর্শন বিকল্পটি ব্যবহার করতে পারেন এবং তারপরে আপনার সংগ্রহটি নির্বাচন করতে পারেন যা রিশার্ডিং হয়েছে৷ আপনি প্রদর্শিত শার্ড প্রতি সমান পরিমাণ ডেটা দেখতে হবে।

  
  

• MongoDB 5.0 চালিত Atlas ক্লাস্টারগুলির জন্য - আপনি খণ্ড প্রদর্শন বিকল্পটি ব্যবহার করতে পারেন এবং তারপরে আপনার সংগ্রহটি নির্বাচন করতে পারেন যা রিশার্ডিং হয়েছে। আপনার ক্লাস্টারের সমস্ত শার্ড জুড়ে প্রায় সমান সংখ্যক খণ্ড প্রদর্শিত হবে।

  
  

শার্ড ডেটা সাইজ এবং খণ্ডের সংখ্যা উভয়ের জন্যই Atlas UI প্রাসঙ্গিক মেট্রিকে একটি তীক্ষ্ণ বৃদ্ধি প্রদর্শন করবে কারণ <db_name>.system.resharding.<UUID> অস্থায়ীভাবে এটির নাম পরিবর্তন করার আগে এবং পুরানোটি বাদ দেওয়ার আগে পুরানো শার্ড কী দিয়ে সংগ্রহ করুন।

রিশার্ডিং বাতিল করা হলে, db.collection.getShardDistribution এর আউটপুট সম্ভবত শার্ডের বেশিরভাগ ডেটা দেখাবে যেটি সংগ্রহটি প্রাথমিকভাবে শার্ড করা হয়েছিল। রিশার্ডিং সহ বাতিল করা বিরল এবং সম্ভবত কারণ রিশার্ডিং 2 সেকেন্ড বা তার কম সময়ে সংগ্রহ কাটওভার পরিচালনা করতে পারেনি৷

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

রিশার্ডিং অপারেশন সম্পূর্ণ হয়ে গেলে আপনি ক্লিন-আপ অপারেশন পরিচালনা করতে পারেন যেমন অস্থায়ী শার্ড কী সূচক ড্রপ করা এবং আপনার ক্লাস্টার এবং/অথবা আপনার স্থির-স্থিতির প্রয়োজনের জন্য আপনার স্টোরেজকে স্কেল করা।

FAQs

1. রিশার্ড-টু-শার্ড কতক্ষণ লাগে?

   
   

   • এটি আপনার সংগ্রহের আকার, আপনার সংগ্রহের জন্য সূচীর সংখ্যা এবং আকার এবং আপনার ক্লাস্টারে শার্ডের সংখ্যার উপর নির্ভর করে, তবে আমরা নিশ্চিত যে আপনি 48টি শার্ড জুড়ে 10টি সূচী সহ একটি 4TB সংগ্রহ পুনরায় ভাগ করতে পারবেন। ঘন্টা বা তার কম। ব্যালেন্সারকে মাইগ্রেশন পরিচালনা করতে 30 দিন বা তার বেশি সময় লাগবে।

     
     

2. ব্যালেন্সারকে ডেটা মাইগ্রেট করতে দেওয়ার চেয়ে রিশার্ডিং কেন দ্রুত?

   
   

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

     
     

3. আমি এমন একটি সংগ্রহে রিশার্ড-টু-শার্ড ব্যবহার করতে চাই যার একটি অনন্যতা সীমাবদ্ধতা রয়েছে এবং হ্যাশ সূচকগুলি স্বতন্ত্রতা প্রয়োগ করা সমর্থন করে না।

   
   

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

     
     

      { launch_vehicle: 1, payload: 1}

     
     

   • আপনার অস্থায়ী শার্ড কী হবে:

      { launch_vehicle: 1, payload: 1, launch_pad: 1}

     
     

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

   
   

4. আমি কিভাবে একটি চলমান রিশার্ডিং অপারেশন নিরীক্ষণ করব?

   • নিম্নলিখিত কমান্ড চালান:

      db.getSiblingDB("admin").aggregate([ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "<database>.<collection>" } } ])

   
   

5. আমি কিভাবে একটি চলমান রিশার্ডিং অপারেশন বন্ধ করব?

   
   

   • নিম্নলিখিত কমান্ডটি চালান, যা অবিলম্বে রিশার্ডিং অপারেশন বাতিল করে:

      sh.abortReshardCollection("<database>.<collection>")

   
   

6. আমি আমার ক্লাস্টার পারফরম্যান্সকে প্রভাবিত করার রিশার্ডিং সম্পর্কে উদ্বিগ্ন।

   
   

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

     
     

7. রিশার্ডিং অপারেশন চালানোর সময় আমার ক্লাস্টারের কোন মেট্রিকগুলি পর্যবেক্ষণ করা উচিত?

   
   

   • স্টোরেজ স্পেস উপলব্ধ - যদি আপনার কোনো শার্ডে 100GB-এর কম স্টোরেজ পাওয়া যায় তাহলে আপনাকে রিশার্ডিং বাতিল করতে হবে

   • সিপিইউ ব্যবহার - যদি আপনার ক্লাস্টার উপলব্ধ সমস্ত গণনা সংস্থানগুলি গ্রাস করে থাকে তবে আপনি সংস্থান বিবাদের কারণ হতে পারেন এবং রিশার্ডিং বাতিল করা উচিত

   • I/O খরচ - যদি আপনার ক্লাস্টার উপলব্ধ সমস্ত IOPS গ্রাস করে তবে আপনি রিসোর্স বিবাদের কারণ হতে পারেন এবং রিশার্ডিং বাতিল করা উচিত।

     
     

8. অস্থায়ী সংগ্রহটি আপাতদৃষ্টিতে আমার সমস্ত শার্ড জুড়ে সমানভাবে বিতরণ করা হয়েছে, কেন রিশার্ডিং সম্পূর্ণ হয় না?

   
   

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