একজন ডেভেলপার KiviDB প্রকাশ করেছেন, যা Rust-এ লেখা একটি ওপেন-সোর্স, মাল্টি-থ্রেডেড Redis ও Valkey বিকল্প। ২০২৬ সালের ফেব্রুয়ারিতে Rust শেখার উদ্দেশ্য নিয়ে প্রকল্পটি শুরু হয়, পাশাপাশি স্ন্যাপশটের পর মেমরি বিস্ফোরণ এবং চলমান পডে আউট-অফ-মেমরি ত্রুটির সমাধান করাও এর লক্ষ্য ছিল, যেগুলো লেখক Dragonfly ব্যবহার করার সময় মুখোমুখি হয়েছিলেন। KiviDB RESP2 ও RESP3 উভয় প্রোটোকল সমর্থন করে, তাই বিদ্যমান Redis ক্লায়েন্টগুলো কোনো পরিবর্তন ছাড়াই কাজ করে। এর কীস্পেস থ্রেড জুড়ে শার্ড করা হয় এবং tokio_uring ক্রেটের মাধ্যমে io_uring ব্যবহার করে Linux-এ এটি সবচেয়ে ভালো পারফর্ম করে, অন্যান্য অপারেটিং সিস্টেমে Tokio ফলব্যাক ব্যবহৃত হয়। মূল ইঞ্জিনটি AGPLv3 লাইসেন্সের অধীনে, এবং লেখক জানিয়েছেন যে Redis 8.10-এর প্রায় 98-99% কমান্ড সমর্থিত।
লেখক একই us-east1 প্লেসমেন্ট গ্রুপের দুটি c7gn.metal সার্ভারে memtier-benchmark ব্যবহার করে বেঞ্চমার্ক চালিয়েছেন, যেখানে ৩২টি কোর জুড়ে প্রতিটি ১০০ বাইটের ১০ মিলিয়ন কী ছিল। ডেপথ ১৬-এর পাইপলাইনিংয়ে KiviDB প্রতি সেকেন্ডে ২১.২ মিলিয়ন GET অপারেশন অর্জন করেছে, যেখানে Dragonfly 2.0-এর ক্ষেত্রে ৯.১ মিলিয়ন, Redis 8.10-এর ক্ষেত্রে ২.৪ মিলিয়ন এবং ৩২-শার্ড Redis Cluster-এর ক্ষেত্রে ৪.৭ মিলিয়ন। পাইপলাইনিং ছাড়া Dragonfly সামান্য দ্রুত ছিল, ৩.৩৫ মিলিয়ন ops/sec বনাম KiviDB-এর ৩.০৭ মিলিয়ন। প্রতি কী-তে মেমরি ব্যবহার ছিল KiviDB-তে ১৭৭ বাইট, Dragonfly-তে ১৩৪ বাইট এবং Redis-এ ১৭৮ বাইট। ভেক্টর ইনজেশন বিকল্পগুলোর তুলনায় ধীর ছিল, অন্যদিকে নিম্ন ef সেটিংয়ে ভেক্টর কোয়েরি দ্রুত ছিল, তবে উচ্চ ef-এ Dragonfly-এর চেয়ে ধীর ছিল।
প্রকল্পে বিল্ট-ইন ফুল-টেক্সট ও ভেক্টর সার্চও অন্তর্ভুক্ত রয়েছে, এবং লেখক AWS, GCP ও Azure জুড়ে একটি ক্লাউড ম্যানেজড সার্ভিসের ধারণা তৈরি করেছেন। পরিচিত কমান্ড ঘাটতিগুলো GitHub-এ ট্র্যাক করা হয় এবং অবদানকারীদের আমন্ত্রণ জানানো হয়েছে। একটি মাত্র Docker কমান্ডের মাধ্যমে প্রকল্পটি পরীক্ষা করা যায়, যা পোর্ট 6380-এ সার্ভার চালু করে।
উৎস: Hacker News · সারাংশ: HeadlinesBriefing