যেহেতু আমি সাধারণ ক্যাশিং থেকে মাল্টি-টেরাবাইট আকারের সেটআপ পর্যন্ত বিভিন্ন ব্যবহারের ক্ষেত্রে রেডিস ব্যবহার করে অনেক লোক এবং কোম্পানির সাথে কথা বলার সুযোগ পেয়েছি, যেটি আমাকে অন্য যেকোনো বিষয়ের চেয়ে বেশি সম্বোধন করতে বলা হয়েছে তা হল কর্মক্ষমতা। আপনি যেভাবে পারফরম্যান্সের কাছে যান তার মধ্যে রেডিস ভিন্ন। অনেকের মধ্যে, বেশিরভাগই না হলে, ডাটাবেস সার্ভারে আপনি কর্মক্ষমতা উন্নত করার চেষ্টা করেন। রেডিসের সাথে লক্ষ্য হল এটিকে ধীর না করা। এটি একটি খুব ভিন্ন পদ্ধতি এবং এটির সুবিধা নেওয়ার জন্য একটি ভিন্ন মানসিকতার প্রয়োজন৷
পারফরম্যান্স মেট্রিক্স - কি লেটেন্সি কিং?
রেডিস ব্যবহার করার সময় আপনি প্রাথমিকভাবে দুটি কর্মক্ষমতা মেট্রিক সম্পর্কে উদ্বিগ্ন:প্রতি সেকেন্ডে কতগুলি কমান্ড (বা লেনদেন) আমি কার্যকর করতে পারি এবং সেগুলি কতক্ষণ নেয়৷ আপনি যখন এটি ভেঙে ফেলেন তখন আপনি দেখতে পান যে আগেরটি পরেরটির থেকে একটি গৌণ ফলাফল। যেহেতু রেডিস একক-থ্রেডেড, আপনি কত অপ্স/সেকেন্ড ধাক্কা দিতে পারেন তা সম্পূর্ণরূপে তাদের কতক্ষণ লাগে তার সাথে আবদ্ধ। এইভাবে, শেষ পর্যন্ত গুরুত্বপূর্ণ বিষয় হল আমি যাকে "কমান্ড লেটেন্সি" হিসাবে উল্লেখ করি৷
৷আমি রেডিসের একটি সুবিধা বিবেচনা করি, এটি সরলতা। আপনি আদেশ জারি করেন, প্রশ্ন নয়। কমান্ডগুলি ডেটা টেনে নেওয়ার জন্য অনেক সহজ রুট, এবং এই ক্ষেত্রে সরলতা কমান্ডের গতিতে প্রতিফলিত হয়। এটি ডেভেলপারদের বিভিন্ন প্রশ্নের জন্য অপ্টিমাইজ করার চেষ্টা করার বিপরীতে অপ্টিমাইজ করা কমান্ড প্রদান করার অনুমতি দেয়। এই মার্জিত সরলতা তারপর রেডিস গ্রাসকারী প্রোগ্রামারদের জন্য প্রদান করা হয়। এর অর্থ প্রায়শই সার্ভার সফ্টওয়্যার দ্বারা এটি করার পরিবর্তে ক্লায়েন্ট সাইডে একটি সেট ফিল্টার করার মতো "কোয়েরি" টাইপ অপারেশন করা।
যদিও কেউ কেউ মনে করেন যে এই ধরনের প্রশ্ন সার্ভারে একটি সামঞ্জস্যপূর্ণ উপায়ে করা সর্বোত্তম, আমি বর্তমানে মতামত দিচ্ছি যে এটি আর একটি পছন্দের রুট নয়। কারণ হল যে বাগবিয়ারকে আমরা "স্কেলেবিলিটি" বলি। আপনি যখন একটি "অনুভূমিকভাবে মাপযোগ্য" ওয়েব পরিষেবা বা সাইট চালানো শুরু করেন, উদাহরণস্বরূপ, আপনি প্রায়শই প্রথম দিকে দেখতে পাবেন যে এই প্যাটারটি ভাল কাজ করে। যাইহোক, যখন আপনি ট্র্যাফিকের "অশ্লীল" স্তরগুলি পরিচালনা করা শুরু করেন আপনি দ্রুত শিখবেন যে ডাটাবেস একটি উল্লেখযোগ্য বাধা। এর কিছুক্ষণ পরেই আপনি এই ডাটাবেসটি শিখবেন, সাধারণত একটি SQL স্টোর যেমন MySQL, "অনুভূমিকভাবে মাপযোগ্য" নয়। আপনি সহজভাবে আরো যোগ করতে পারবেন না।
কমান্ড লেটেন্সি
অবশ্যই, রেডিস নয়। তবে এখানে পার্থক্য হল যে ফিল্টারিং লজিক, বাছাই করা এবং যেকোন কিছু রেখে যা আপনি একটি একক রেডিস কমান্ড বা সর্বাধিক কয়েকটি কমান্ডে কার্যকর করতে পারবেন না, আপনি যুক্তি দিয়ে ডিবি লোড করছেন না - এবং এইভাবে "প্রক্রিয়া করার জিনিসগুলি" . Redis একটি "ডেটা স্টোর" হিসাবে ব্যবহার করা উচিত, একটি ঐতিহ্যগত "ডাটাবেস সার্ভার" নয়। এটি "রেডিসকে ধীর করবেন না" এর প্রথম দিকটি আপনাকে গ্রোক করতে হবে। এটা বলার দরকার নেই যে আপনি একবার লুয়া স্ক্রিপ্টিংয়ের পথ শুরু করলে, আপনি নেট কম পারফরম্যান্সের ঝুঁকি চালান। আপনার ট্রাফিক কম থেকে মাঝারি হলে আপনি এটি বিকাশে দেখতে পাবেন না। যাইহোক, আপনি যখন বড় আকারে আঘাত করবেন তখন আপনি এটি দেখতে পাবেন। এবং তারপরে যুক্তিটি প্রায়শই ইতিমধ্যেই বেক হয়ে যায় এবং অ্যাপ্লিকেশন কোডে যাওয়ার জন্য প্রচুর পরিমাণে প্রযুক্তিগত ঋণ হয়ে যায়। আমরা সকলেই জানি যে প্রায়শই প্রযুক্তিগত ঋণ পরিশোধের জন্য কতটা অগ্রাধিকার দেওয়া হয়।
এটি বলার অপেক্ষা রাখে না যে লুয়া স্ক্রিপ্টিংয়ের কোনও জায়গা নেই। এটা শুধুমাত্র মানে এটা অত্যন্ত যাচাই করা উচিত. একটি লুয়া স্ক্রিপ্ট কখন নেট পারফরম্যান্স ক্ষতি হয় বা না হয় সে সম্পর্কে কব্জির একটি ভাল নিয়ম হল আপনি যদি সেই লজিক ক্লায়েন্ট-সাইড পরিচালনা করেন তবে আপনাকে যে অতিরিক্ত রাউন্ড ট্রিপগুলি সম্পাদন করতে হবে তার মূল্য তুলনা করা। তবে, আপনার ক্লায়েন্ট কোড কতক্ষণ এটি করতে পারে তা নয়। এটিকে এভাবে বিবেচনা করুন:আপনি যদি আপনার রাউন্ড ট্রিপের খরচ 2ms কম করেন, কিন্তু স্ক্রিপ্ট এক্সিকিউশনের সময় 3ms যোগ করেন তাহলে আপনি ভুল পথে গেছেন।
এখানে আমাদের একটি একক-থ্রেডেড সার্ভারের প্রকৃতি সম্পর্কে গভীরভাবে সচেতন হওয়া দরকার। যে 3ms স্ক্রিপ্টটি কার্যকর করার সময় সম্ভাব্য শত শত (বা এমনকি হাজার হাজার) কমান্ড ব্লক করছে। আপনি যদি সেগুলিকে একটি (টান) -> (লজিক) -> (টান) অনুক্রমে বিভক্ত করেন তবে সার্ভারটি "(যুক্তি)" পর্যায়ে অতিরিক্ত অনুরোধগুলি প্রক্রিয়া করতে সক্ষম হবে। ক্লায়েন্ট কোডে যুক্তি রেখে আপনি মাল্টি-ক্লায়েন্ট ভিত্তিক সিস্টেমের অন্তর্নিহিত সংগতি সংরক্ষণ করেন। আপনার যদি লেনদেন বা লুয়া স্ক্রিপ্টিংয়ের প্রয়োজন হয় তবে অবশ্যই সেগুলি ব্যবহার করুন। তবে সেগুলি ব্যবহার করবেন না কারণ তারা আপনার কোডকে "সহজ" করে তোলে বলে মনে হচ্ছে। সর্বদা একযোগে পারফরম্যান্স হিট সম্পর্কে সচেতন থাকুন, এটি পরিমাপ করুন এবং সচেতনভাবে পছন্দ করুন।
এটি আমাদেরকে "ডন্ট স্লো রেডিস ডাউন" এর দ্বিতীয় নিয়মের দিকে নিয়ে যায়:স্ক্রিপ্টের মাধ্যমে সার্ভারের যুক্তি এড়িয়ে একযোগে রক্ষা করুন। একটি পার্শ্ব সুবিধা হল আপনার লুয়া স্ক্রিপ্টগুলি পুনঃলিখন বা ডাম্পিং ছাড়াই একটি রেডিস ক্লাস্টার সেটআপে স্থানান্তরিত করার ক্ষমতা যা একাধিক কীগুলিতে কাজ করে৷
অন্যান্য উপায়ে রেডিসকে ধীর করা যায়
রেডিস সার্ভার চালানোর কয়েকটি সিস্টেম-লেভেল বা অপারেশনাল দিক রয়েছে যা রেডিসকে ধীর করে দিতে পারে। I/O রিসোর্স সীমা ব্যবহার করে যেকোনো সার্ভারের মতো Redisকে ধীর করে দিতে পারে। উদাহরণস্বরূপ, আপনার যদি 8GB নেটওয়ার্ক ব্যান্ডউইথের প্রয়োজন হয়, কিন্তু 1GB থাকে, তাহলে এটি আপনার জন্য "ধীর" হবে। যদি আপনার ডেমন প্রক্রিয়াটি কম ওপেন সকেটের মধ্যে সীমাবদ্ধ থাকে তাহলে আপনার সমবর্তী সংযোগের প্রয়োজনে কমান্ড কার্যকর করার পরিবর্তে সংযোগ বন্ধ হওয়ার অপেক্ষায় সময় ব্যয় করা হবে।
সম্ভবত দুটি সবচেয়ে সাধারণ অপারেশনাল পছন্দ যা রেডিসকে ধীর করে দেয় তা হল 1) এটি একটি ভার্চুয়াল মেশিনে রাখুন - বিশেষ করে একটি Xen হাইপারভাইজার ভিত্তিক একটি এবং 2) ভারী ডিস্কের অধ্যবসায়৷
প্রথমটি স্ট্যান্ডার্ড রেডিস সাহিত্যে মোটামুটি ভালভাবে সম্বোধন করা হয়েছে:এটিকে Xen হাইপারভাইজার ভিএমে রাখবেন না। দ্বিতীয়টি, অধ্যবসায়, বলে মনে হচ্ছে কিন্তু এটি আমার অনুমানে যথেষ্ট নয়৷
অবশ্যই, স্ট্যান্ডার্ড সুপারিশ আছে:একটি স্থানীয় দ্রুত ডিস্ক ব্যবহার করুন, নিশ্চিত করুন যে আপনার গাভী নৃত্য পরিচালনা করার জন্য পর্যাপ্ত মেমরি আছে যখন স্থির থাকে – এমনকি শুধুমাত্র ক্রীতদাসদের উপর অধ্যবসায় চালানো। এগুলি প্রকৃতপক্ষে আপনার কমান্ড লেটেন্সির মাধ্যমে প্রভাব ফেলতে পারে। যা অনুপস্থিত তা হল কিভাবে সঠিকভাবে নির্ণয় করা যায়।
এটি পরীক্ষা করার একটি আদর্শ উপায় হল অন্তর্নির্মিত লেটেন্সি টেস্টিং ব্যবহার করা। আমি কীভাবে এটি করতে পারি তার প্রযুক্তিগত বিবরণে যাওয়ার আগে আমি বৃহত্তর "কীভাবে" প্রশ্নের সমাধান করতে চাই। এখানে প্রধান উপসেট হল এই পরীক্ষাগুলি কখন চালানো হবে। প্রথমত, আপনার ডেটা সেট ছোট হলে এই পরীক্ষাটি অর্থহীন হতে পারে। কত ছোট? ডিস্কে আপনার ডেটা ডাম্প করতে কতক্ষণ লাগবে তা নির্ধারণ করুন। আমরা যদি এক বা দুই সেকেন্ডের কথা বলি, হয়তো দশটিও, আপনার অর্থপূর্ণ ডেটা পাওয়ার সম্ভাবনা কম। অবশ্যই, এই সব আপনি একটি সংরক্ষণের পরিবর্তে একটি BGSAVE করার উপর পূর্বাভাস দেয়৷
স্থিরতা বিলম্ব
এটি আমাদেরকে প্রথম নীতির দিকে নিয়ে যায় যা আমি "অধ্যবসায় লেটেন্সি" হিসাবে উল্লেখ করি - সার্ভারে কমান্ড আঘাত করার সময় থেকে ফলাফল কিছু প্রকারের অধ্যবসায়কে আঘাত করা পর্যন্ত সময়:আপনি করতে পারেন এমন অধ্যবসায় বিকল্পের সূচনাকারী সর্বনিম্ন লেটেন্সি খুঁজুন। আপনার নেটওয়ার্ক এবং ডিস্কের উপর নির্ভর করে AoF বা স্লেভ সার্ভার সর্বনিম্ন লেটেন্সি বাম্পিং পারসিসটেন্স বিকল্প হবে, যেখানে RDB আসবে।
RDB শেষ পর্যন্ত আসবে কারণ এতে T সেকেন্ডে N পরিবর্তনের একটি অন্তর্নির্মিত বিলম্ব রয়েছে। সুতরাং, ধরে নিচ্ছি যে আপনার সেই ন্যূনতম সময়কালের মধ্যে যথেষ্ট পরিবর্তন রয়েছে (ছোটতম ডিফল্ট উইন্ডো হল 60 সেকেন্ড) আপনার অধ্যবসায় বিলম্ব হল ব্যবধান T + ডিস্কে RDB লেখার সময়। যদি ডিফল্ট 60 সেকেন্ডের ব্যবধানে সেই মেমরিটিকে ডিস্কে ডাম্প করতে 30 সেকেন্ড সময় লাগে তবে আপনার "অধ্যবসায় লেটেন্সি" হবে (60+30) 90 সেকেন্ড।
এটি, তবে, এই অধ্যবসায়ের বিলম্বতা একটি সমস্যা কিনা তা নিয়ে প্রশ্ন তোলে। এই প্রশ্নের দুটি দিক রয়েছে:1) এটি কি আপনার ব্যবসার প্রয়োজনীয়তার জন্য যথেষ্ট? এবং 2) এটি কি আপনার রেডিসকে মন্থর করে?
প্রথম প্রশ্নটি হল আমি একটি সাধারণ উত্তর দিতে পারি না যা প্রত্যেকের উত্তর দেয়। তবে, আমি বলতে পারি যে যদি আপনার অধ্যবসায়ের লেটেন্সির জন্য প্রয়োজনীয়তাগুলি উপরের সূত্রের চেয়ে কঠোর হয় তবে আপনি উত্তরগুলি পেয়ে যাবেন সম্ভবত RDB এর পরিবর্তে "একটি স্লেভ এবং/অথবা AoF ব্যবহার করুন" এর দিকে প্রবণতা রয়েছে৷ এটি অনুমান করে যে আপনি যে প্ল্যাটফর্মে রেডিস চালাচ্ছেন তাতে আপনি স্পষ্ট ভুল করছেন না। যা আমাদের দ্বিতীয় দিকে নিয়ে আসে:এটি কি রেডিসকে ধীর করে?
কারো কারো জন্য "আরডিবি ফাইল সংরক্ষণ করতে কতক্ষণ সময় লাগে" এই প্রশ্নটি তাদের মনে প্রধান হয়ে ওঠে। আমার দৃষ্টিতে, এটি একটি ভুল। এটা কত সময় লাগে ব্যাপার না? এই প্রশ্নের উত্তর হল "সেভ কি রেডিসকে মন্থর করে"। যদি না হয়, তাহলে 1 সেকেন্ড বা 1 ঘন্টা লাগে কিনা তা আপনার চিন্তা করা উচিত নয়। উদাহরণস্বরূপ, সার্ভার A বিবেচনা করুন যা RDB সংরক্ষণ করতে 1000 সেকেন্ড সময় নেয়। অভ্যন্তরীণ কমান্ড সংরক্ষণ না করার সময় লেটেন্সি পরিসীমা 30-100 মাইক্রোসেকেন্ড। সংরক্ষণের সময় এই লেটেন্সি এখনও 30-100 মাইক্রোসেকেন্ড রেঞ্জের মধ্যে রয়েছে৷ এই ক্ষেত্রে, আপনার খারাপ Redis পারফরম্যান্সের ধারণার অধীনে এই RDB কমাতে সময় বাঁচাতে কাজ করা অকাল অপ্টিমাইজেশন হবে৷
যাইহোক, সার্ভার বি মাত্র 10 সেকেন্ড সময় নেয়, কিন্তু কমান্ড লেটেন্সি 30-100us থেকে 130-250us এ চলে যায়। এখন আপনার কাছে উদ্বিগ্ন হওয়ার কারণ আছে যে আরডিবি ফাইলটি তৈরি হতে কতক্ষণ সময় নেয় কারণ সেভ রেডিসকে ধীর করে দিচ্ছে এবং আপনি এটিকে কমিয়ে আনতে চান। যদি এর অর্থ দ্রুততর ডিস্ক, অন্তত এখন আপনার কাছে সেগুলিকে ন্যায্যতা দেওয়ার কারণ আছে - ধরে নিচ্ছি যে প্রায় 100-150 মাইক্রোসেকেন্ডের বৃদ্ধি আপনার অ্যাপ্লিকেশন(গুলি) এর জন্য কর্মক্ষমতা উদ্বেগ সৃষ্টি করে। যদি তা না হয়, তাহলে আপনি অকাল অপ্টিমাইজেশানে ফিরে এসেছেন৷
৷এখন, সেই লেটেন্সি কীভাবে পরিমাপ করা যায়, আমি এই পোস্টের দ্বিতীয় অংশে আরও বিশদে যাব কারণ এটি ইতিমধ্যে বেশ দীর্ঘ হয়ে গেছে।
