13 বছর পরে - রেডিসের কি একটি নতুন আর্কিটেকচার দরকার?

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

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

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

গতি

ড্রাগনফ্লাই বেঞ্চমার্ক একটি মাল্টিথ্রেডেড ড্রাগনফ্লাই ইনস্ট্যান্সের সাথে একটি স্বতন্ত্র একক প্রক্রিয়া রেডিস ইনস্ট্যান্স (যেটি শুধুমাত্র একটি একক কোর ব্যবহার করতে পারে) তুলনা করে (যা একটি VM/সার্ভারে সমস্ত উপলব্ধ কোর ব্যবহার করতে পারে)। দুর্ভাগ্যবশত, এই তুলনা বাস্তব জগতে কিভাবে Redis চালানো হয় তা প্রতিনিধিত্ব করে না। প্রযুক্তি নির্মাতা হিসাবে, আমরা আমাদের প্রযুক্তিগুলি অন্যদের সাথে কীভাবে তুলনা করে তা ঠিক বোঝার চেষ্টা করি, তাই আমরা যা বিশ্বাস করি তা ন্যায্য তুলনা করেছি এবং একটি 40-শার্ড রেডিস 7.0 ক্লাস্টার (যেটি বেশিরভাগ উদাহরণ কোর ব্যবহার করতে পারে) Dragonfly-এর সাথে তুলনা করেছি। ড্রাগনফ্লাই দল তাদের বেঞ্চমার্কে ব্যবহৃত সবচেয়ে বড় ইনস্ট্যান্স টাইপের কর্মক্ষমতা পরীক্ষার সেট, AWS c6gn.16xlarge। আমাদের পরীক্ষায়, আমরা দেখেছি রেডিস Dragonfly থেকে 18% - 40% বেশি থ্রুপুট অর্জন করেছে, এমনকি 64টি vCores-এর মধ্যে মাত্র 40টি ব্যবহার করলেও৷

13 বছর পরে - রেডিসের কি একটি নতুন আর্কিটেকচার দরকার?

স্থাপত্যগত পার্থক্য

কিছু পটভূমি

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

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

আমরা কিছু নীতি শেয়ার করার সিদ্ধান্ত নিয়েছি যা আমরা পর্দার আড়ালে ব্যবহার করি যাতে লোকেদের বুঝতে সাহায্য করে যে আমরা কী বিশ্বাস করি উৎপাদন পরিবেশে রেডিস চালানোর জন্য ভালো ইঞ্জিনিয়ারিং অনুশীলন।

স্থাপত্য নীতি

ভিএম প্রতি একাধিক Redis ইনস্ট্যান্স চালান

VM প্রতি একাধিক Redis ইনস্ট্যান্স চালানো আমাদের করতে দেয়:

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

প্রতিটি Redis প্রক্রিয়াকে একটি যুক্তিসঙ্গত আকারে সীমাবদ্ধ করুন

আমরা একটি একক রেডিস প্রক্রিয়াকে 25 গিগাবাইট আকারের (এবং ফ্ল্যাশে রেডিস চালানোর সময় 50 জিবি) ছাড়িয়ে যেতে দিই না। এটি আমাদের অনুমতি দেয়:

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

অনুভূমিকভাবে স্কেলিং সর্বাপেক্ষা গুরুত্বপূর্ণ

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

উত্তম স্থিতিস্থাপকতা - আপনি আপনার ক্লাস্টারে যত বেশি নোড ব্যবহার করবেন, আপনার ক্লাস্টার তত বেশি শক্তিশালী হবে। উদাহরণস্বরূপ, যদি আপনি একটি 3-নোড ক্লাস্টারে আপনার ডেটাসেট চালান এবং একটি নোড অবনমিত হয়, তাহলে এটি আপনার ক্লাস্টারের 1/3 অংশ যা পারফর্ম করছে না; কিন্তু আপনি যদি একটি 9-নোড ক্লাস্টারে আপনার ডেটাসেট চালান এবং একটি নোড অবনমিত হয়, তবে এটি আপনার ক্লাস্টারের মাত্র 1/9টি পারফর্ম করছে না।
স্কেল করা সহজ - আপনার ক্লাস্টারে একটি অতিরিক্ত নোড যোগ করা এবং আপনার ডেটাসেটের একটি অংশ এটিতে স্থানান্তর করা অনেক সহজ, উল্লম্বভাবে স্কেলিং করার পরিবর্তে, যেখানে আপনাকে একটি বৃহত্তর নোড আনতে হবে এবং আপনার সম্পূর্ণ ডেটাসেটের উপর কপি করতে হবে (এবং সমস্ত খারাপ জিনিস সম্পর্কে চিন্তা করুন) এটি এই সম্ভাব্য দীর্ঘ প্রক্রিয়ার মাঝখানে ঘটতে পারে...)
ধীরে ধীরে স্কেলিং অনেক বেশি খরচ-কার্যকর - উল্লম্বভাবে স্কেলিং, বিশেষ করে ক্লাউডে, ব্যয়বহুল। অনেক ক্ষেত্রে, আপনাকে আপনার ইনস্ট্যান্সের আকার দ্বিগুণ করতে হবে এমনকি যদি আপনাকে আপনার ডেটাসেটে কয়েক GB যোগ করতে হয়।
উচ্চ থ্রুপুট – রেডিস-এ, আমরা অনেক গ্রাহককে দেখতে পাই যারা ছোট ডেটাসেটে উচ্চ থ্রুপুট ওয়ার্কলোড চালাচ্ছেন, খুব উচ্চ নেটওয়ার্ক ব্যান্ডউইথ এবং/অথবা উচ্চ প্যাকেট প্রতি সেকেন্ড (পিপিএস) চাহিদা সহ। 1M+ অপস/সেকেন্ড ব্যবহারের ক্ষেত্রে একটি 1GB ডেটাসেট সম্পর্কে চিন্তা করুন। এটিকে 3-নোড c6gn.xlarge ক্লাস্টারের পরিবর্তে একটি একক-নোড c6gn.16xlarge ক্লাস্টারে (64 CPU সহ 128GB এবং $2.7684/hr তে 100gbps) চালানোর কোন মানে হয়? ) 20% এর কম খরচে এবং অনেক বেশি শক্তিশালী পদ্ধতিতে? খরচ-কার্যকারিতা বজায় রেখে এবং স্থিতিস্থাপকতা উন্নত করার সময় থ্রুপুট বাড়াতে সক্ষম হওয়া প্রশ্নের একটি সহজ উত্তর বলে মনে হয়।
NUMA এর বাস্তবতা - উল্লম্বভাবে স্কেলিং মানে একাধিক কোর এবং বড় DRAM সহ একটি দুই-সকেট সার্ভার চালানো; এই NUMA-ভিত্তিক-আর্কিটেকচারটি Redis-এর মতো মাল্টি-প্রসেসিং আর্কিটেকচারের জন্য দুর্দান্ত কারণ এটি আরও ছোট নোডের নেটওয়ার্কের মতো আচরণ করে। কিন্তু NUMA একটি মাল্টিথ্রেডেড আর্কিটেকচারের জন্য আরও চ্যালেঞ্জিং, এবং অন্যান্য মাল্টিথ্রেডেড প্রকল্পগুলির সাথে আমাদের অভিজ্ঞতা থেকে, NUMA একটি ইন-মেমরি ডেটাস্টোরের কার্যকারিতা 80% পর্যন্ত কমাতে পারে।
স্টোরেজ থ্রুপুট সীমা - AWS EBS এর মত বাহ্যিক ডিস্ক, মেমরি এবং CPU এর মত দ্রুত স্কেল করে না। প্রকৃতপক্ষে, ব্যবহৃত মেশিন ক্লাসের উপর ভিত্তি করে ক্লাউড পরিষেবা প্রদানকারীদের দ্বারা আরোপিত স্টোরেজ থ্রুপুট সীমা রয়েছে। অতএব, ইতিমধ্যে বর্ণিত সমস্যাগুলি এড়াতে এবং উচ্চ ডেটা-অধ্যবসায়ের প্রয়োজনীয়তাগুলি পূরণ করার জন্য একটি ক্লাস্টারকে কার্যকরভাবে স্কেল করার একমাত্র উপায় হ'ল অনুভূমিক স্কেলিং ব্যবহার করা, অর্থাৎ, আরও নোড এবং আরও নেটওয়ার্ক-সংযুক্ত ডিস্ক যুক্ত করা।
এফিমেরাল ডিস্ক - একটি ক্ষণস্থায়ী ডিস্ক হল SSD তে Redis চালানোর একটি চমৎকার উপায় (যেখানে SSD একটি DRAM প্রতিস্থাপন হিসাবে ব্যবহার করা হয়, কিন্তু স্থায়ী স্টোরেজ হিসাবে নয়) এবং Redis গতি বজায় রেখে একটি ডিস্ক-ভিত্তিক ডাটাবেসের খরচ উপভোগ করুন (দেখুন আমরা কীভাবে এটি করি ফ্ল্যাশে রেডিস সহ)। আবার, যখন ক্ষণস্থায়ী ডিস্ক তার সীমাতে পৌঁছে যায়, তখন সর্বোত্তম উপায় এবং অনেক ক্ষেত্রে, আপনার ক্লাস্টার স্কেল করার একমাত্র উপায় হল আরও নোড এবং আরও ক্ষণস্থায়ী ডিস্ক যুক্ত করা।
পণ্য হার্ডওয়্যার – সবশেষে, আমাদের অনেক অন-প্রিমিসেস গ্রাহক আছে যারা স্থানীয় ডেটা-সেন্টার, ব্যক্তিগত ক্লাউড, এমনকি ছোট প্রান্তের ডেটা-সেন্টারেও চলছে; এই পরিবেশে, 64 গিগাবাইটের বেশি মেমরি এবং 8 সিপিইউ সহ মেশিনগুলি খুঁজে পাওয়া কঠিন হতে পারে এবং আবার স্কেল করার একমাত্র উপায় হল অনুভূমিক৷

সারাংশ

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

পরিশিষ্ট রেডিস 7.0 বনাম ড্রাগনফ্লাই বেঞ্চমার্কের বিবরণ

বেঞ্চমার্ক সারাংশ

সংস্করণ:

আমরা Redis 7.0.0 ব্যবহার করেছি এবং এটি উৎস থেকে তৈরি করেছি
ড্রাগনফ্লাই 3 জুন (hash=e806e6ccd8c79e002f721a1a5ecb847bd7a06489) উত্স থেকে তৈরি করা হয়েছিল যেমন https://github.com/Dragonfly/dragonfly#building-from-source এ সুপারিশ করা হয়েছে

লক্ষ্য:

যাচাই করুন যে ড্রাগনফ্লাই ফলাফলগুলি পুনরুত্পাদনযোগ্য এবং সম্পূর্ণ শর্তগুলি নির্ধারণ করুন যেখানে সেগুলি পুনরুদ্ধার করা হয়েছিল (প্রদত্ত মেমটিয়ার_বেঞ্চমার্ক, ওএস সংস্করণ, ইত্যাদিতে কিছু কনফিগার অনুপস্থিত ছিল...) এখানে আরও দেখুন
AWS c6gn.16x বৃহৎ উদাহরণের তুলনায় সেরা অর্জনযোগ্য OSS Redis 7.0.0 ক্লাস্টার পারফরম্যান্স নির্ধারণ করুন, Dragonfly-এর বেঞ্চমার্কের সাথে মেলে

ক্লায়েন্ট কনফিগারেশন:

ওএসএস রেডিস 7.0 সলিউশনের জন্য প্রতিটি মেমটিয়ার_বেঞ্চমার্ক দেওয়া, রেডিস ক্লাস্টারে অনেক বেশি সংখ্যক খোলা সংযোগ প্রয়োজন থ্রেড সব শার্ডের সাথে সংযুক্ত থাকে
OSS Redis 7.0 সমাধান দুটি memtier_benchmark সহ সেরা ফলাফল প্রদান করেছে বেঞ্চমার্ক চলমান প্রক্রিয়াগুলি কিন্তু একই ক্লায়েন্ট VM-তে ড্রাগনফ্লাই বেঞ্চমার্কের সাথে মেলে)

সম্পদ ব্যবহার এবং সর্বোত্তম কনফিগারেশন:

ওএসএস রেডিস ক্লাস্টারটি 40টি প্রাথমিক শার্ডের সাথে সর্বোত্তম ফলাফল অর্জন করেছে, যার অর্থ VM-এ 24টি অতিরিক্ত vCPU রয়েছে। যদিও মেশিনটি সম্পূর্ণরূপে ব্যবহার করা হয়নি, আমরা দেখতে পেয়েছি যে শার্ডের সংখ্যা বাড়ানো সাহায্য করেনি, বরং সামগ্রিক কর্মক্ষমতা হ্রাস করেছে। আমরা এখনও এই আচরণের তদন্ত করছি৷
অন্যদিকে, ড্রাগনফ্লাই সলিউশনটি সম্পূর্ণভাবে VM-কে টপ আপ করেছে এবং সমস্ত 64টি VCPU 100% ব্যবহারে পৌঁছেছে।
উভয় সমাধানের জন্য, আমরা সর্বোত্তম সম্ভাব্য ফলাফল অর্জনের জন্য ক্লায়েন্ট কনফিগারেশনে বৈচিত্র্য এনেছি। নীচে দেখা যাবে, আমরা বেশিরভাগ ড্রাগনফ্লাই ডেটা প্রতিলিপি করতে পেরেছি এবং এমনকি 30 এর সমান পাইপলাইনের জন্য সেরা ফলাফলগুলিকে অতিক্রম করতে পেরেছি৷
এর মানে হল Redis এর মাধ্যমে আমরা যে সংখ্যা অর্জন করেছি তা আরও বাড়ানোর সম্ভাবনা রয়েছে।

সর্বশেষ, আমরা আরও দেখতে পেয়েছি যে Redis এবং Dragonfly উভয়ই নেটওয়ার্ক PPS বা ব্যান্ডউইথ দ্বারা সীমাবদ্ধ ছিল না, আমরা নিশ্চিত করেছি যে 2টি ব্যবহৃত VM (ক্লায়েন্ট এবং সার্ভারের জন্য, c6gn.16xlarge ব্যবহার করে বট) এর মধ্যে আমরা> 10M PPS এবং>300B পেলোড সহ TCP-এর জন্য 30 Gbps।

ফলাফল বিশ্লেষণ করা হচ্ছে

পাইপলাইন 1 সাব-এমএস পান :
- OSS Redis:4.43M ops/sec, যেখানে avg এবং p50 উভয়ই সাব-মিলিসেকেন্ড লেটেন্সি অর্জন করেছে। গড় ক্লায়েন্ট লেটেন্সি ছিল 0.383 ms
- Dragonfly দাবি করেছে 4M ops/sec:
  - আমরা 0.390 ms এর গড় ক্লায়েন্ট লেটেন্সি সহ 3.8M ops/sec পুনরুত্পাদন করতে পেরেছি
- রেডিস বনাম ড্রাগনফ্লাই - রেডিস থ্রুপুট 10% বেশি বনাম ড্রাগনফ্লাই ফলাফল দাবি করেছে এবং 18% দ্বারা বনাম ড্রাগনফ্লাই ফলাফল, যা আমরা পুনরুত্পাদন করতে সক্ষম হয়েছি।

পাইপলাইন 30 পান:
- OSS Redis:2.239 ms এর গড় ক্লায়েন্ট লেটেন্সি সহ 22.9M ops/sec
- Dragonfly দাবি করেছে 15M ops/sec:
  - আমরা 3.99 ms এর গড় ক্লায়েন্ট লেটেন্সি সহ 15.9M ops/sec পুনরুত্পাদন করতে পেরেছি
- রেডিস বনাম ড্রাগনফ্লাই – রেডিস 43% দ্বারা ভাল (বনাম ড্রাগনফ্লাই পুনরুত্পাদিত ফলাফল) এবং 52% দ্বারা (বনাম ড্রাগনফ্লাই ফলাফল দাবি করেছে)
SET পাইপলাইন 1 সাব-ms :
- OSS Redis:4.74M ops/sec, যেখানে avg এবং p50 উভয়ই সাব-মিলিসেকেন্ড লেটেন্সি অর্জন করেছে৷ গড় ক্লায়েন্ট লেটেন্সি ছিল 0.391 ms
- Dragonfly দাবি করেছে 4M ops/sec:
  - আমরা 0.500 ms এর গড় ক্লায়েন্ট লেটেন্সি সহ 4M ops/sec পুনরুত্পাদন করতে পেরেছি
- রেডিস বনাম ড্রাগনফ্লাই – রেডিস 1 দ্বারা ভাল9% (আমরা একই ফলাফল পুনরুত্পাদন করেছি যা ড্রাগনফ্লাই দাবি করেছে)
SET পাইপলাইন 30:
- OSS Redis:19.85M ops/sec, গড় ক্লায়েন্ট লেটেন্সি 2.879 ms
- ড্রাগনফ্লাই 10M ops/sec দাবি করেছে:
  - আমরা 14M ops/sec reproduce করতে পেরেছি, গড় ক্লায়েন্ট লেটেন্সি 4.203 ms)
- রেডিস বনাম ড্রাগনফ্লাই – রেডিস 42% দ্বারা ভাল (বনাম ড্রাগনফ্লাই পুনরুত্পাদিত ফলাফল) এবং 99% (বনাম ড্রাগনফ্লাই ফলাফল দাবি করেছে)

memtier_benchmark প্রতিটি পরিবর্তনের জন্য ব্যবহৃত কমান্ড:

পাইপলাইন 1 সাব-এমএস পান
- রেডিস:
  - 2X:memtier_benchmark –অনুপাত 0:1 -t 24 -c 1 –পরীক্ষার সময় 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 10000000 – -হিস্টোগ্রাম
- ড্রাগনফ্লাই:
  - memtier_benchmark –অনুপাত 0:1 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram

পাইপলাইন 30 পান
- রেডিস:
  - 2X:memtier_benchmark –অনুপাত 0:1 -t 24 -c 1 –পরীক্ষার সময় 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 10000000 – -হিস্টোগ্রাম -পাইপলাইন 30
- ড্রাগনফ্লাই:
  - memtier_benchmark –অনুপাত 0:1 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram –pipeline 30
SET পাইপলাইন 1 সাব-ms
- রেডিস:
  - 2X:memtier_benchmark –অনুপাত 1:0 -t 24 -c 1 –পরীক্ষার সময় 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 10000000 – -হিস্টোগ্রাম
- ড্রাগনফ্লাই:
  - memtier_benchmark –অনুপাত 1:0 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram
SET পাইপলাইন 30
- রেডিস:
  - 2X:memtier_benchmark –অনুপাত 1:0 -t 24 -c 1 –পরীক্ষার সময় 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 10000000 – -হিস্টোগ্রাম -পাইপলাইন 30
- ড্রাগনফ্লাই:
  - memtier_benchmark –অনুপাত 1:0 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram –pipeline 30

অবকাঠামোর বিবরণ

We used the same VM type for both client (for running memtier_benchmark) and the server (for running Redis and Dragonfly), here is the spec:

VM :
- AWS c6gn.16xlarge
  - aarch64
  - ARM Neoverse-N1
  - Core(s) per socket:64
  - Thread(s) per core:1
  - NUMA node(s):1
Kernel:Arm64 Kernel 5.10
Installed Memory: 126GB