Let’s look at the performance-related complexities that teams commonly face with write-heavy workloads and discuss your options for tackling them লিখতে ভারী ডাটাবেস ওয়ার্ক লোডগুলি পড়তে ভারী লোডগুলির তুলনায় একটি স্পষ্টভাবে আলাদা চ্যালেঞ্জগুলি নিয়ে আসে। স্ক্যালিং লিখা ব্যয়বহুল হতে পারে, বিশেষ করে যদি আপনি প্রতি অপারেশন পরিশোধ করেন এবং লিখা পড়া চেয়ে 5X ব্যয়বহুল হয় লকিং দেরি যোগ করতে পারে এবং ট্রান্সপুট কমাতে পারে I / O বোতলগুলি লেখার শক্তিশালীকরণ এবং দুর্ঘটনার পুনরুদ্ধারকে জটিল করতে পারে ডাটাবেস ব্যাকপ্রেসিং প্রবেশকারী লোডটি হ্রাস করতে পারে যদিও খরচ গুরুত্বপূর্ণ - অনেক ক্ষেত্রে - এটি এমন একটি বিষয় নয় যা আমরা এখানে কভারেজ করতে চাই. বরং, আমরা কর্মক্ষমতা সম্পর্কিত জটিলতাগুলিতে মনোযোগ দেব যা টিমগুলি সাধারণত মুখোমুখি হয় এবং তাদের মোকাবেলা করার জন্য আপনার বিকল্পগুলি আলোচনা করুন। আমরা কি বোঝাতে পারি "একটি বাস্তব সময় লেখার ভারী ওয়ার্কবোর্ড"? প্রথমে, আমরা একটি "প্রাসঙ্গিক সময় লেখার ভারী" ওয়ার্ক লোড দ্বারা আমরা কী বোঝায় তা পরিষ্কার করি. আমরা এমন ওয়ার্ক লোড সম্পর্কে কথা বলছি যা: একটি বড় পরিমাণে ডেটা ইনজেকশন (যেমন, 50K OPS) পড়ার চেয়ে লিখতে বেশি জড়িত কঠোর দীর্ঘস্থায়ী SLAs (যেমন, একক ডিগ্রী মিলিসেকেন্ড P99 দীর্ঘস্থায়ী) দ্বারা বাধ্য বন্যায়, তারা অনলাইন গেমিং থেকে বাস্তব সময় স্টক বিনিময় পর্যন্ত সবকিছুতে ঘটে। আইওটি (IoT) ওয়ার্ক লোডগুলি ছোট কিন্তু প্রায়শই টাইম সিরিজ ডেটা লিখে থাকে. এখানে, ইনজেকশন হারটি মূলত ডেটা সংগ্রহ করে এমন চূড়ান্ত পয়েন্টের সংখ্যা দ্বারা নির্ধারিত হয়. স্মার্ট হোম সেন্সরগুলি বা শিল্প পর্যবেক্ষণ সরঞ্জামগুলি চিন্তা করুন যা ক্রমাগত ডেটা স্ট্রিমগুলি প্রক্রিয়াকরণ এবং সঞ্চয় করতে পাঠায়। লগিং এবং মনিটরিং সিস্টেমগুলি প্রায়শই ডেটা ইনজেকশনগুলি মোকাবেলা করে, তবে তাদের একটি স্থিতিশীল ইনজেকশন হার নেই। অনলাইন গেমিং প্ল্যাটফর্মগুলি রিয়েল টাইম ব্যবহারকারীর ইন্টারেক্টিভেশন প্রক্রিয়াকরণ করতে হবে, গেম স্টেট পরিবর্তনগুলি, খেলোয়াড়ের পদক্ষেপগুলি এবং মেসেজিং সহ। ই-কমার্স এবং খুচরা বিক্রয় ওয়ার্ক লোডগুলি সাধারণত আপডেট ভারী এবং প্রায়ই ব্যাটারি প্রক্রিয়াকরণ অন্তর্ভুক্ত করে. এই সিস্টেমগুলি সঠিক স্টক স্তরগুলি বজায় রাখতে হবে, গ্রাহকদের পর্যালোচনাগুলি প্রক্রিয়াকরণ করতে হবে, অর্ডার অবস্থা ট্র্যাক করতে হবে, এবং কেনাকাটা ক্যারি অপারেশনগুলি পরিচালনা করতে হবে, যা সাধারণত আপডেট করার আগে বিদ্যমান ডেটা পড়তে হবে। বিজ্ঞাপন প্রযুক্তি এবং রিয়েল টাইম অফিং সিস্টেমগুলি ভাগ-সেকেন্ড সিদ্ধান্তগুলি প্রয়োজন। এই সিস্টেমগুলি জটিল অফার প্রক্রিয়াকরণ পরিচালনা করে, ইমেজ ট্র্যাকিং এবং অ্যাকশন ফলাফল সহ, একই সময়ে ক্লিক এবং রূপান্তরগুলির মতো ব্যবহারকারীর ইন্টারেকশনগুলি পর্যবেক্ষণ করে। রিয়েল টাইম এক্সচেঞ্জ সিস্টেমগুলি উচ্চ ফ্রিকোয়েন্সি ট্রেডিং অপারেশনগুলি, ক্রমাগত স্টক মূল্য আপডেট এবং জটিল অর্ডার সমন্বয় প্রক্রিয়াগুলি সমর্থন করতে হবে - সবগুলি নিখুঁত ডেটা সংশ্লিষ্টতা এবং সর্বনিম্ন ল্যাটিনতা রক্ষা করে। তারপরে, চলুন মূল আর্কিটেকচার এবং কনফিগারেশন বিবেচনাগুলি দেখি যা লেখার কর্মক্ষমতাকে প্রভাবিত করে। স্টোরেজ ইঞ্জিন আর্কিটেকচার স্টোরেজ ইঞ্জিন আর্কিটেকচারের পছন্দটি মূলত ডাটাবেসের লেখার কর্মক্ষমতাকে প্রভাবিত করে. দুটি প্রাথমিক পদ্ধতি রয়েছে: LSM ট্রি এবং B-Trees। ডাটাবেসগুলি যেমন ScyllaDB, Apache Cassandra, HBase এবং Google BigTable-এর মতো ডাটাবেসগুলি ডাটাবেসগুলি কার্যকরভাবে হস্তক্ষেপ করার জন্য ব্যবহৃত হয়, লগ-স্ট্রাক্টরিড মেরেজ ট্রি (এলএসএম) ব্যবহার করে। এই আর্কিটেকচারটি বড় পরিমাণে ডাটাবেসগুলি হস্তক্ষেপ করার জন্য আদর্শ। কারণ ডাটাবেসগুলি মেমরিতে অবিলম্বে সংযুক্ত হয়, এটি খুব দ্রুত প্রাথমিক স্টোরেজের অনুমতি দেয়। উদাহরণস্বরূপ, এখানে ScyllaDB লিখার পথটি কীভাবে দেখায়: B-tree কাঠামোগুলির সাথে, প্রতিটি লেখার অপারেশনটি গাছের মধ্যে একটি নোট অবস্থান এবং সংশোধন করতে প্রয়োজন - এবং এটি উভয় সূচকীয় এবং র্যান্ডম আই / ও অন্তর্ভুক্ত করে। Payload আকার পাইলোড আকারেরও প্রভাব ফেলে। ছোট পাইলোডগুলির সাথে, পাইলোড ভাল, কিন্তু CPU প্রক্রিয়াকরণ প্রধান বোতল চাপ। পাইলোড আকার বৃদ্ধির সাথে সাথে, আপনি কম সামগ্রিক পাইলোড পাবেন এবং ডিস্ক ব্যবহারও বৃদ্ধি পায়। অবশেষে, একটি ছোট লিখা সাধারণত সমস্ত বাফারগুলিতে মিলিত হয় এবং সবকিছু খুব দ্রুত প্রক্রিয়াকরণ করা যেতে পারে। এজন্য এটি উচ্চ পারফরম্যান্স পেতে সহজ। বৃহত্তর পাইলোডগুলির জন্য, আপনাকে বৃহত্তর বাফার বা একাধিক বাফার ভাগ করতে হবে। কম্প্রেশন ড্রাইভ ব্যবহার একটি লেখার ভারী ওয়ার্ক লোডের সাথে ঘনিষ্ঠভাবে নজর রাখা কিছু. যদিও স্টোরেজ ক্রমাগত সস্তা হচ্ছে, এটি এখনও বিনামূল্যে নয়। কম্প্রেশন জিনিসগুলি নিয়ন্ত্রণে রাখতে সাহায্য করতে পারে - তাই আপনার কম্প্রেশন কৌশলটি বুদ্ধিমানভাবে নির্বাচন করুন. দ্রুত কম্প্রেশন গতিগুলি লেখার ভারী কাজের লোডগুলির জন্য গুরুত্বপূর্ণ, কিন্তু আপনার উপলব্ধ CPU এবং মেমরি সম্পদগুলি বিবেচনা করুন। নিশ্চিতভাবে দেখুন যে কম্প্রেশন মূলত আপনার ডেটা ছোট ব্লকগুলিতে বিভক্ত করে (বা ছোট ব্লকগুলিতে) এবং তারপর প্রতিটি ব্লককে আলাদাভাবে কম্প্রেশন করে। কম্পিউটার প্যারামিটার অনুভূতি LSM ভিত্তিক ডাটাবেসের ক্ষেত্রে, আপনি যে কম্প্রেশন কৌশলটি নির্বাচন করেন তা লিখার কর্মক্ষমতাকেও প্রভাবিত করে। সংকোচন কৌশল নির্বাচন করার সময়, আপনি কম পাঠ সংকোচন লক্ষ্য করতে পারেন, যা পাঠগুলি যতটা সম্ভব দক্ষ করে তোলে। অথবা, আপনি কম পাঠ সংকোচনকে অত্যন্ত আক্রমণাত্মক হওয়া থেকে রক্ষা করে কম লেখ সংকোচন লক্ষ্য করতে পারেন। অথবা, আপনি কম জায়গা সংকোচনকে অগ্রাধিকার দিতে পারেন এবং সম্ভবত কার্যকরীভাবে সংকোচন পরিষ্কার ডেটা পেতে পারেন। (এবং ক্যাসান্ডার একই ধরনের অফার দেয়): কয়েকটি কম্পিউটার কৌশল STCS (Size-tiered compaction strategy): সিস্টেমটি যথেষ্ট (পূর্বে চারটি) সমান আকারের SSTables আছে তখন চালু করা হয়। লেভেলড কম্প্যাকশন কৌশল (এলসিএস): সিস্টেমটি বিভিন্ন স্তরগুলিতে বিতরণ করা ছোট, স্থিতিশীল আকারের (ডিফল্ট 160 এমবি) SSTables ব্যবহার করে। ক্রমবর্ধমান সংকোচন কৌশল (আইসিএস): STCS এর মত একই পড়া এবং লিখা সংকোচন কারণগুলি ভাগ করে নেয়, কিন্তু এটি বিশাল sstables SSTable রানগুলিতে ভেঙে দ্বারা তার 2x সাময়িক স্পেস সংকোচন সমস্যা সংশোধন করে, যা ছোট (1 গিগাবাইট ডিফল্ট হিসাবে), অ-সম্পর্কিত SSTables একটি সাজানো সেট থেকে গঠিত। টাইম উইন্ডো কম্প্যাকশন কৌশল (TWCS): টাইম সিরিজ ডেটা জন্য ডিজাইন করা হয়েছে। লেখার ভারী কাজের লোডগুলির জন্য, আমরা ব্যবহারকারীদের সতর্ক করি যেকোনো খরচের জন্য স্থিতিশীল সংকোচন এড়াতে। ব্যাচিং ScyllaDB এবং Cassandra মত ডাটাবেসে, ব্যাটিং আসলে একটি ফাঁদ হতে পারে - বিশেষ করে লেখার ভারী ওয়ার্ক লোডের জন্য। যদি আপনি রেডিয়েশনাল ডাটাবেসের জন্য অভ্যস্ত হন, ব্যাটিং একটি উচ্চ ভলিউমের লেখার জন্য একটি ভাল বিকল্প হিসাবে মনে হতে পারে। কিন্তু এটি সত্যিই জিনিসগুলি ধীরে ধীরে ধীরে ধীরে করতে পারে যদি এটি সাবধানে করা হয় না। এখানে কিভাবে আপনি ভারী লেখার সাথে মোকাবেলা করার সময় ব্যাটিং সম্পর্কে চিন্তা করবেন: পার্টিশন কী দ্বারা ব্যাচ: আপনার লেখাগুলি পার্টিশন কী দ্বারা গ্রুপ করুন যাতে ব্যাচটি একটি সমন্বয়কারী নোডে যায় যা ডেটাও মালিকানাধীন। ব্যাটগুলি ছোট এবং টার্গেট রাখুন: ব্যাটগুলি পার্শ্ববর্তীভাবে ছোট ব্যাটগুলিতে ভাগ করে ফেলুন, এটি জিনিসগুলি কার্যকর রাখে। এটি নেটওয়ার্ককে অতিরিক্ত লোড করতে বাধা দেয় এবং প্রতিটি নোটকে শুধুমাত্র তার মালিকানাধীন ডেটাতে কাজ করতে দেয়। Unlogged Batches: Considering you follow the previous points, it is best to use unlogged batches. Logged batches add extra consistency checks, যা সত্যিই লিখতে ধীরে ধীরে করতে পারে. সুতরাং, যদি আপনি লিখতে কঠিন পরিস্থিতিতে আছেন, তাহলে বড়, ক্রস-নোড ব্যাটারিগুলি প্রেরণ করতে পারে এমন দেরিগুলি এড়ানোর জন্য আপনার ব্যাটারিগুলি সাবধানে গঠন করুন। উঁচু করে আমরা বেশ কয়েকটি সতর্কবাণী সরবরাহ করেছি, তবে চিন্তা করবেন না. শিক্ষাগুলির একটি তালিকা সংগ্রহ করা সহজ ছিল কারণ অনেক টিমগুলি বাস্তব সময়ে লেখার ভারী কাজের লোডগুলির সাথে অত্যন্ত সফলভাবে কাজ করে। আপনি যদি আরও জানতে চান তবে এখানে টিমগুলি থেকে কিছু প্রাথমিক দৃষ্টিভঙ্গি রয়েছে যারা বেশ আকর্ষণীয় লেখার ভারী চ্যালেঞ্জগুলি মোকাবেলা করেছে: Zillow: একাধিক ডেটা প্রযোজক থেকে রেকর্ড খরচ করা, যা অর্ডার-অভিনেত্রী লিখতে ফেলেছে যা ভুল আপডেট ফলাফল হতে পারে Tractian: আইওটি ডিভাইস থেকে উচ্চ ফ্রিকোয়েন্সি ডেটা লিখে 10X বৃদ্ধির জন্য প্রস্তুতি Fanatics: এই অনলাইন ক্রীড়া খুচরা জন্য অর্ডার প্রক্রিয়াকরণ, শপিং ক্যারি, এবং পণ্য আপডেট মত ভারী লেখার অপারেশন জিহাদ ট্র্যাকিং ফ্যান্টিক এছাড়াও, নিম্নলিখিত ভিডিওটি দেখুন, যেখানে আমরা এই লেখার ভারী চ্যালেঞ্জগুলিতে আরও গভীরভাবে প্রবেশ করি এবং ScyllaDB এ এই ওয়ার্ক লোডগুলি কীভাবে দেখতে।
