An in-depth look at database and cache internals, and the tradeoffs in each. ScyllaDB এই প্রকল্পে তাদের অবদানের জন্য dormando (Memcached maintenance) এবং Danny Koppingকে প্রকাশ্যে স্বীকৃতি দিতে চায়, এবং তাদের সমর্থন এবং ধৈর্যের জন্য ধন্যবাদ জানাতে চায়। ঘুম ড্যানি কোপিং ScyllaDB এর পিছনে প্রকৌশলীরা - পরিমাপের জন্য পূর্বাভাসযোগ্য কর্মক্ষমতা জন্য ডাটাবেস - দুটি প্রযুক্তির সামঞ্জস্যপূর্ণ, বিক্রেতা নিরপেক্ষভাবে সামঞ্জস্যপূর্ণভাবে তুলনা করার জন্য Memcached ম্যান্টেনার ডোমেন্ডোয়ের সাথে তাদের শক্তি জড়িয়েছে। ফলাফল দেখায় যে: Memcached এবং ScyllaDB উভয়ই ডিস্ক এবং নেটওয়ার্ক ব্যান্ডবাইডকে সর্বোচ্চ করে তুলনা করে, একই অবস্থার মধ্যে চাপ দেয়, সামগ্রিকভাবে একই ধরনের পারফরম্যান্স বজায় রাখে। যখন ScyllaDB নেটওয়ার্ক পারফরম্যান্স সম্পূর্ণরূপে পরিপূর্ণ করার জন্য ডেটা মডেলিং পরিবর্তন প্রয়োজন, Memcached ডিস্ক I / O পরিপূর্ণ করার জন্য অতিরিক্ত আইও থ্রেড প্রয়োজন। যদিও ডিস্কের জন্য Memcached পাইপলাইন অনুরোধগুলির তুলনায় ScyllaDB ভাল দেরি দেখায়, Memcached দেরিগুলি ব্যক্তিগত অনুরোধগুলির জন্য ভাল ছিল। এই ডকুমেন্টটি এই পরীক্ষার জন্য আমাদের উদ্দেশ্য ব্যাখ্যা করে, পরীক্ষিত পরিস্থিতি এবং ফলাফলগুলির একটি সারসংক্ষেপ সরবরাহ করে, তারপরে ScyllaDB এবং Memcached এর মধ্যে সিদ্ধান্ত নিতে পারে এমন কেউ জন্য সুপারিশগুলি উপস্থাপন করে। এছাড়াও আছে টেস্ট এবং ফলাফলগুলি এবং নির্দিষ্ট কনফিগারেশনগুলির লিঙ্কগুলি আরও বিস্তৃতভাবে দেখুন যা আপনি নিজেই টেস্টগুলি পরিচালনা করতে ব্যবহার করতে পারেন। এই প্রকল্পের জন্য একটি বিস্তারিত Gitbook, বোনাস: dormando এবং আমি সম্প্রতি P99 CONF এ এই প্রকল্পটি আলোচনা করেছি, যা কর্মক্ষমতা এবং কম দেরি প্রকৌশল সম্পর্কে একটি উচ্চ প্রযুক্তিগত সম্মেলন। চাহিদা দেখুন বোনাস: dormando এবং আমি সম্প্রতি P99 CONF এ এই প্রকল্পটি আলোচনা করেছি, যা কর্মক্ষমতা এবং কম দেরি প্রকৌশল সম্পর্কে একটি উচ্চ প্রযুক্তিগত সম্মেলন। Watch on demand চাহিদা দেখুন আমরা কেন এটা করেছি? প্রথমত, ScyllaDB আমাদের ডাটাবেসটি অপ্টিমাইজ করার জন্য অনেক সময় এবং প্রকৌশল সম্পদ বিনিয়োগ করেছে যাতে বাস্তব সময়ে ডেটা-প্রবাহিত অ্যাপ্লিকেশনগুলির জন্য পূর্বাভাসযোগ্য কম দেরি সরবরাহ করা যায়। ভাগ্যবান আর্কিটেকচার, এবং (পূর্ণরূপে লিনাক্স পৃষ্ঠা ক্যাশ অতিক্রম) এই ধরনের অপ্টিমাইজেশনের কিছু উল্লেখযোগ্য উদাহরণ। হালকা-কোর UserSpace I/O টাইমস অভ্যন্তরীণ ক্যাশ বাস্তবায়ন দ্বিতীয়ত: পারফরম্যান্স সময়ের সাথে মিলিত হয়. ইন-মেমোরি ক্যাশগুলি (দীর্ঘ সময় ধরে) সবচেয়ে দ্রুততম অবকাঠামো উপাদানগুলির মধ্যে একটি হিসাবে বিবেচনা করা হয়েছে। If an in-memory cache can rely on flash storage, then why can’t a persistent database also work as a cache? ৩. আমরা আগেই আলোচনা করেছি সম্প্রতি আমরা দেখেছি কতটা সফল হয়েছে দলগুলো। . আপনার ডাটাবেসের সামনে একটি ক্যাশ না রাখার 7 কারণ তাদের ক্যাশগুলি ScyllaDB দিয়ে প্রতিস্থাপন করুন চতুর্থতঃ গত বছরের P99 CONF এ, ড্যানি কোপিং আমাদের একটি উজ্জ্বল বক্তব্য দিয়েছিলেন, , যেখানে তিনি ব্যাখ্যা করেছিলেন যে কিভাবে Memcached Extstore গ্রাফানা ল্যাবকে খরচ হ্রাস করার সময় তাদের ক্যাশ ফাঁদ 42x পরিমাপ করতে সাহায্য করে। পারলে আমাকে লুকিয়ে রাখুন এবং অবশেষে, কর্মক্ষমতা রেফারেন্সগুলি পেয়ে যাওয়া সমালোচনা (মূল্যবান) সত্ত্বেও, তারা অবশ্যই উদ্ভাবনের জন্য গুরুত্বপূর্ণ ভূমিকা পালন করে. রেফারেন্সগুলি অভ্যন্তরীণ অপ্টিমাইজেশন সুযোগ খুঁজছেন ইঞ্জিনিয়ারদের জন্য একটি উপকারী সম্পদ। এখন তুলনা নিয়ে আসি। সেটিং আদালত পরীক্ষাগুলি নিম্নলিখিত AWS ইনস্ট্যান্স টাইপগুলি ব্যবহার করে পরিচালিত হয়েছিল: লোডার: c7i.16xlarge (64 vCPUs, 128GB RAM) Memcached: i4i.4xlarge (16 vCPUs, 128GB RAM, 3.75TB NVMe) ScyllaDB: i4i.4xlarge (16 vCPUs, 128GB RAM, 3.75TB NVMe) প্রত্যেকটি বিভাগই সরবরাহ করতে পারে 25Gbps নেটওয়ার্ক ব্যাঙ্ক বিস্তার. মনে রাখবেন যে বিশেষ করে পরীক্ষার সময় প্রতিশ্রুতিবদ্ধ নেটওয়ার্ক ক্ষমতা সর্বোচ্চ করা, আমরা লক্ষ্য করেছি . উপরে ব্যান্ডউইডটি ইনস্টিটিউটগুলির বেসলাইন ক্যাপাসিটিতে নিচে নেমে আসে। অপ্টিমাইজেশন এবং সেটিংস সম্ভাব্য বোতলগুলি অতিক্রম করার জন্য, নিম্নলিখিত অপ্টিমাইজেশন এবং সেটিংস প্রয়োগ করা হয়েছে: AWS পাশাপাশি: সমস্ত ইনস্টিটিউটগুলি AWS ডকুমেন্টগুলি অনুসরণ করে একটি ক্লাস্টার পজিশনিং কৌশল ব্যবহার করে: "এই কৌশলটি কাজের লোডগুলিকে নিম্ন দীর্ঘস্থায়ী নেটওয়ার্ক কর্মক্ষমতা অর্জন করতে সক্ষম করে যা উচ্চ পারফরম্যান্স কম্পিউটিং (এইচপি) অ্যাপ্লিকেশনগুলির জন্য প্রচলিত কঠোরভাবে সংযুক্ত নোট-নোড যোগাযোগের জন্য প্রয়োজন হয়। Memcached: সংস্করণ 1.6.25, Extstore অনুমোদিত সঙ্গে সংগৃহীত. যেখানে উল্লেখ করা ব্যতীত, 14 থ্রেড, নির্দিষ্ট CPUs উপর পিপিং সঙ্গে চালানো. বাকি 2 vCPUs CPU 0 (কোর & HT ভাই) নেটওয়ার্ক IRQs হস্তক্ষেপ করতে নির্ধারিত হিসাবে সংগৃহীত হয়, seastar perftune.py মধ্যে sq_split মোড দ্বারা নির্ধারিত. CAS অপারেশনগুলি প্রতিটি আইটেম ওভারহেড উপর জায়গা সংরক্ষণ করার জন্য অক্ষম ছিল. সম্পূর্ণ কমান্ড লাইন আর্গমেন্ট ছিল:taskset -c 1-7,9-15 /usr/local/memcached/bin/memcached -v -A -r -m 114100 - ScyllaDB: একটি i4i.4xlarge মধ্যে ScyllaDB Enterprise 2024.1.2 AMI (ami-id: ami-018335b47ba6bdf9a) দ্বারা কনফিগার করা ডিফল্ট সেটিংস। স্ট্রেস লোডারদের জন্য, আমরা ব্যবহার করেছি , memcached এর অফিসিয়াল টেস্ট সেটের অংশ. প্রযোজ্য চাপ প্রোফাইলগুলি GitHub রিপোজিটর মাইক্রোসফট ফেয়ার-মেন্ডস / Shredders ScyllaDB জন্য, আমরা ব্যবহার করেছি , ScyllaDB এর সাথে পাঠানো হিসাবে, এবং Memcached এর জন্য ব্যবহৃত হিসাবে তুলনামূলক কাজ লোড নির্দিষ্ট। ক্যাসিনো স্ট্রেস পরীক্ষা এবং ফলাফল নিম্নলিখিতটি আমাদের পরিচালিত পরীক্ষার একটি সংক্ষিপ্ত সংক্ষিপ্ত এবং তাদের ফলাফল. আপনি যদি আরো বিস্তারিত বর্ণনা এবং বিশ্লেষণ চান, যান . এই প্রকল্পের বিস্তৃত লেখাপড়া রাম ক্যাশিং দক্ষতা যত বেশি আইটেম আপনি র্যামে রাখতে পারেন, ক্যাশ হিট পেতে আপনার সম্ভাবনা আরও ভাল। এই প্রকল্পটি প্রতিটি ডাটা স্টোরে আমরা কতটি আইটেম সংরক্ষণ করতে পারি তা পরিমাপ করে শুরু করে। আমাদের পরীক্ষার সময়, কী 4 থেকে 12 বাইট (key0 .. keyN) এর মধ্যে ছিল Memcached এবং ScyllaDB এর জন্য 12 বাইট। মেম্বার মেমক্যাচিং শুরু হওয়ার আগে প্রায় 101 মিলিয়ন আইটেম সংরক্ষণ করে। এটি মেমরি দক্ষ। মেমক্যাচিং এর 114G নির্ধারিত মেমরি থেকে, এটি মূল্যগুলির প্রায় 101G মূল্য, চাবি আকার এবং অন্যান্য পতাকা বিবেচনা না করে: ScyllaDB ScyllaDB 60 থেকে 61 মিলিয়ন আইটেমের মধ্যে সংরক্ষণ করা হয়, যতক্ষণ না ড্রাইভিং শুরু হয়. এটি কোনও বিস্ময়কর নয়, যেহেতু তার প্রোটোকলটি লিখার অংশ হিসাবে সংরক্ষণ করা আরও ডেটা প্রয়োজন (যেমন ইতিহাস থেকে লিখার টাইমস্ট্যাম্প, লাইভ লাইভিং ইত্যাদি)। Takeaways Memcached ScyllaDB এর চেয়ে প্রায় 65% বেশি মেমরি আইটেম সংরক্ষণ করে। ScyllaDB লাইনগুলি একটি বিস্তৃত কলাম দিকনির্দেশনা সমর্থন করার জন্য প্রতিটি আইটেমের জন্য উচ্চতর ওভারহেড রয়েছে। ScyllaDB এ, ব্লুম ফিল্টার, ইন্ডেক্স ক্যাশিং এবং অন্যান্য উপাদানগুলি দক্ষ ডিস্ক অনুসন্ধানগুলি সমর্থন করার জন্য মেমোরিতে সংরক্ষণ করা হয়, যা আরও একটি স্তরের ওভারহেডকে সহায়তা করে। In-Memory Workload শুধুমাত্র পড়া এর একটি ক্যাশের জন্য (যদিও অবিশ্বাস্য) ওয়ার্ক লোড এমন একটি যেখানে সমস্ত ডেটা র্যামের মধ্যে মিলিত হয় - যাতে পাঠকদের ডিস্ক অ্যাক্সেসের প্রয়োজন হয় না এবং কোনও প্রত্যাহার বা অনুপস্থিতি ঘটে না। আদর্শ ইমেজ থেকে বহিষ্কার এবং ক্যাশ মিস করা উভয় ডাটা স্টোরের জন্য পারফরম্যান্স বেসলাইন পরিমাপ এবং সেট করতে সাহায্য করে. এটি এই ধরনের কাজের লোডগুলির জন্য সবচেয়ে গুরুত্বপূর্ণ বিষয়গুলির উপর মনোযোগ দেয়: পড়া পাসপোর্ট এবং অনুরোধ ল্যাটেনশন. এই পরীক্ষায়, আমরা প্রথমে পূর্ববর্তী পরীক্ষার সময় ব্যবহৃত একই উপযোগী লোড আকারের সাথে উভয় দোকান উষ্ণ করেছি. তারপর, আমরা 30 মিনিটের জন্য তাদের প্রাসঙ্গিক পরিসরে পাঠ শুরু করেছি। Memcached Memcached প্রতি সেকেন্ডে আকর্ষণীয় 3 মিলিয়ন Gets অর্জন করে, AWS NIC ব্যাঙ্ক বিস্তার (25 Gbps) সম্পূর্ণরূপে সর্বোচ্চ! Memcached একটি স্থিতিশীল 3M rps বজায় রাখা, সম্পূর্ণরূপে NIC পারফরম্যান্স সর্বোচ্চ প্যারিস প্রদর্শন করে যে p99.999 উত্তর 1ms এর নিচে সম্পন্ন: ফলাফল স্ট্যাটাস: cmd_get : মোট অপারেশন: 5503513496 গতি: 3060908 / সেকেন্ড মাত্রা = মাত্রা = ১-১০% 0 0 0 0 10-99us 343504394 6.238% 100-999us 5163057634 93.762% 1-2ms 11500 0.00021% ScyllaDB ScyllaDB এর আরও লাইন পড়তে, আমাদের প্রোটোকল বৈশিষ্ট্যগুলির কারণে ক্লায়েন্ট অনুরোধগুলির জন্য একটি ভাল ডেটা মডেল ডিজাইন করতে হয়েছিল (বিশেষত, কোনও পাইপলাইনিং নেই)। একটি ক্লাস্টারিং কী দিয়ে, আমরা ScyllaDB এর ক্যাশকে সম্পূর্ণরূপে সর্বোচ্চ করতে পারতাম, যা ক্যাশিং লাইনগুলির সংখ্যাকে উল্লেখযোগ্যভাবে উন্নত করে। ফলস্বরূপ, ক্যাশের মধ্যে রেকর্ডের সংখ্যা পূর্বে প্রদর্শিত কী-ওয়ার্ড সংখ্যাগুলির তুলনায় উল্লেখযোগ্যভাবে উন্নত হয়। যেমন dormando সঠিকভাবে উল্লেখ করেছেন (হ্যালো!), এই কনফিগারেশনটি আগের Memcached সেটিং-আপের তুলনায় উল্লেখযোগ্যভাবে আলাদা। যদিও Memcached ওয়ার্ক লোড সবসময় একটি নির্দিষ্ট কী-ওয়ার্ড জুটি আঘাত করে, ScyllaDB এ একক অনুরোধের ফলে কয়েকটি লাইন ফেরত দেওয়া হয়। আমরা এই পরিবর্তনের কারণগুলো ব্যাখ্যা করেছি। সেখানে, আমরা CQL প্রোটোকলের বৈশিষ্ট্যগুলি (যেমন প্রতিটি আইটেমের ওভারহেড [মেমক্যাচের সাথে তুলনা করা] এবং পাইপলাইনিংয়ের জন্য কোন সমর্থন) ব্যাপক করেছি যা ScyllaDB এ একক কী পুনরুদ্ধারগুলির চেয়ে বেশি কার্যকরী করে তোলে। বিস্তারিত লিখুন এই সমন্বয়গুলির সাথে, আমাদের লোডারগুলি 30 মিনিটের জন্য প্রতি সেকেন্ডে মোট 187K পড়া অপারেশন পরিচালনা করে। memcached এর মত, ScyllaDB এছাড়াও NIC পাসপোর্ট সর্বোচ্চ. এটি মেমরি ডেটা থেকে শুধুমাত্র প্রায় 3 মিলিয়ন লাইন / সেকেন্ড সেবা: ScyllaDB সার্ভার পাশের দীর্ঘস্থায়ী তথ্য প্রদর্শন করে, যা নেটওয়ার্ক ছাড়া দীর্ঘস্থায়ী বিশ্লেষণের জন্য উপকারী। ক্লায়েন্ট-সাইড শতকরা, আশ্চর্যজনকভাবে, 0.9ms এর একটি পড়া P99 সঙ্গে সার্ভার-সাইড ল্যাটিনেশনের চেয়ে উচ্চ। Takeaways Memcached এবং ScyllaDB উভয়ই নেটওয়ার্ককে সম্পূর্ণরূপে পরিপূর্ণ করে; প্রতি সেকেন্ডে সর্বোচ্চ নেটওয়ার্ক প্যাকেটগুলির পরিপূর্ণতা প্রতিরোধ করার জন্য, Memcached অনুরোধ পাইপলাইনিং উপর নির্ভর করে, যখন ScyllaDB একটি বিস্তৃত কলাম অন্তর্ভুক্ত করে। ScyllaDB এর ক্যাশ একটি বিস্তৃত কলাম পরিকল্পনা অনুসরণ করে উল্লেখযোগ্য লাভ দেখিয়েছে, পূর্ববর্তী সহজ কী-ওয়ার্ড দিকনির্দেশনা তুলনায় আরো আইটেম সংরক্ষণ করতে সক্ষম। প্রোটোকল স্তরে, Memcached এর প্রোটোকল সহজ এবং হালকা, যখন ScyllaDB এর CQL আরো সমৃদ্ধ বৈশিষ্ট্য সরবরাহ করে কিন্তু আরো ভারী হতে পারে। ছবিতে ডিস্ক যোগ করুন ফ্ল্যাশ স্টোরেজ কর্মক্ষমতা পরিমাপ করা তার নিজস্ব চ্যালেঞ্জগুলি সৃষ্টি করে, যা একটি নির্দিষ্ট কাজ লোডকে সম্পূর্ণরূপে বাস্তবভাবে চিহ্নিত করা প্রায় অসম্ভব করে তোলে। ডিস্ক সম্পর্কিত পরীক্ষার জন্য, আমরা সবচেয়ে নিষ্ঠুর পরিস্থিতি পরিমাপ করার সিদ্ধান্ত নিয়েছি: উভয় সমাধানের তুলনা করে যা ব্লক স্টোরেজ থেকে ডেটা (বিশেষত) সরবরাহ করে, জানতে পারি যে: এই কাজ করার বাস্তব কাজের লোডের সম্ভাবনা কোথাও শূন্যের কাছাকাছি ব্যবহারকারীদের পূর্ববর্তী অপ্টিমাইজিস্ট ক্যাশ ওয়ার্ক লোড এবং বাস্তবে অত্যন্ত অপেক্ষাকৃত ডিস্ক-ভিত্তিক ওয়ার্ক লোডের মধ্যে সংখ্যা আশা করা উচিত। Memcached Extstore এর সমাধানের অভ্যন্তরীণ কাজের ব্যাপক বিস্তারিত তথ্য প্রদান করে. উচ্চ পর্যায়ে, এটি memcached এর হ্যাশ টেবিল এবং কীগুলি মেমোরিতে রাখতে দেয়, কিন্তু মূল্যগুলি বাইরের স্টোরেজে সংরক্ষণ করে। উইকিপিডিয়া পাতা আমাদের পরীক্ষার সময়, আমরা 1.25B আইটেমের সাথে memcached পরিপূর্ণ করেছি, 1KB এর একটি মানের আকার এবং 14 বাইট পর্যন্ত একটি কীবোর্ড আকার: Extstore এর সাথে, আমরা পূর্ববর্তী মেমরি ওয়ার্ক লোডের তুলনায় প্রায় 11X আইটেম সংখ্যাটি সংরক্ষণ করেছি যতক্ষণ না প্রত্যাহারগুলি শুরু হয় (যেমন উপরের ইমেজে ডান হাত প্যানেলটি দেখায়)। Read-Only Performance বাস্তব কর্মক্ষমতা পরীক্ষার জন্য, আমরা 1KB এবং 8KB এর আইটেম আকারের বিরুদ্ধে Extstore তুলে ধরেছি. নিচের টেবিলটি ফলাফল সংক্ষিপ্ত করে: Test Type Items per GET Payload Size IO Threads GET Rate P99 perfrun_metaget_pipe 16 1KB 32 188K/s 4~5 ms perfrun_metaget 1 1KB 32 182K/s <1ms perfrun_metaget_pipe 16 1KB 64 261K/s 5~6 ms perfrun_metaget 1 1KB 64 256K/s 1~2ms perfrun_metaget_pipe 16 8KB 16 92K/s 5~6 ms perfrun_metaget 1 8KB 16 90K/s <1ms perfrun_metaget_pipe 16 8KB 32 110K/s 3~4 ms perfrun_metaget 1 8KB 32 105K/s <1ms পাইপ_পাইপ পাইপ 16 ১ কেজি 32 ১৮৮ কেজি ৪ থেকে ৫ এমএস মেডিকেল - মেডিকেল 1 ১ কেজি 32 ১৮০ কেজি ১ এমএস পাইপ_পাইপ পাইপ 16 ১ কেজি 64 261K / সেকেন্ড ৫-৬ এমএস মেডিকেল - মেডিকেল 1 ১ কেজি 64 256K / সেকেন্ড 1 ~ 2ms perfrun_metaget_pipe 16 ৮ কেজি 16 ৯২ কেজি ৫-৬ এমএস মেডিকেল - মেডিকেল 1 ৮ কেজি 16 ৯০ কেজি ১ এমএস পাইপ_পাইপ পাইপ 16 ৮ কেজি 32 ১০০ কেজি ৩-৪ এমএস মেডিকেল - মেডিকেল 1 ৮ কেজি 32 105K / সেকেন্ড ১ এমএস ScyllaDB আমরা memcached জন্য ব্যবহৃত একই সংখ্যক আইটেমগুলির সাথে ScyllaDB পরিপূর্ণ করেছি. যদিও ScyllaDB memcached তুলনায় উচ্চ GET হার প্রদর্শন করেছিল, তবে এটি memcached এর অ-pipelining ওয়ার্ক লোডের তুলনায় কিছুটা উচ্চ রেকর্ড লেনদেনের অধীনে করেছিল। Test Type Items per GET Payload Size GET Rate Server-side P99 Client-side P99 1KB Read 1 1KB 268.8K/s 2ms 2.4ms 8KB Read 1 8KB 156.8K/s 1.54ms 1.9ms 1KB পড়া 1 ১ কেজি ২৬.৮ কেজি 2 এমএস ২.৪ এমএস 8KB পড়া 1 ৮ কেজি 156.8K / সেকেন্ড ১.৫৪ এমএস ১.৯ এমএস Takeaways Extstore তার সেটিংসগুলির জন্য উল্লেখযোগ্য টুনিং প্রয়োজন ছিল যাতে ফ্ল্যাশ স্টোরেজ I / O সম্পূর্ণরূপে পরিপূর্ণ হয়। Memcached আর্কিটেকচারের কারণে, ছোট পাইলোডগুলি উপলব্ধ ডিস্ক স্থানটি সম্পূর্ণরূপে ব্যবহার করতে সক্ষম নয়, ScyllaDB তুলনায় ছোট লাভগুলি প্রদান করে। ScyllaDB হারগুলি প্রধান মানের দিক থেকে Memcached তুলনায় মোটামুটি উচ্চতর ছিল, বিশেষ করে উচ্চতর পাইলোড আকারের মধ্যে. Latencies were better than pipelineed requests, but slightly higher than individual GETs in Memcached. অতিরিক্ত ওয়ার্কলোড আমাদের পূর্ববর্তী ডিস্ক ফলাফল অনুসরণ করে, আমরা উভয় সমাধানের তুলনা করেছিলাম, যা একই পাসপোর্ট (250K অপশন / সেকেন্ড) লক্ষ্য করে যা বেশিরভাগই পড়া কাজের লোডে রয়েছে। ১০ শতাংশ ক্ষতিগ্রস্তকে ‘অর্ধেক ক্ষতিগ্রস্ত’ বলে অভিহিত করা হয়েছে। Extstore এর জন্য ‘Basic’ টেস্ট Memcached Memcached টেস্টের সময় 249K এর সামান্য নিচে একটি হার অর্জন করেছে. যদিও টেস্টের সময় টেস্টের সময় লিখার হার স্থিতিশীল ছিল, আমরা লক্ষ্য করেছি যে পড়া সামান্য পরিবর্তিত হয় : পুরো দৌড়ের আমরা একটু উঁচুও দেখেছি। মেট্রিকালগুলি পড়ার তুলনায় কমে গেছে, কিন্তু দেরিগুলি এখনও কম ছিল। প্রচ্ছদ / প্রচ্ছদ Operation IO Threads Rate P99 Latency cmd_get 64 224K/s 1~2 ms cmd_set 64 24.8K/s <1ms সিএমডি-জেট 64 224K / সেকেন্ড ১/২ এমএস সিএমডি সেট 64 ২৪.৮ কেজি ১ এমএস ScyllaDB ScyllaDB পরীক্ষাটি 2 লোডার ব্যবহার করে চালানো হয়েছিল, প্রত্যেকটি টার্গেট রেটের অর্ধেকের সাথে। যদিও ScyllaDB একটি কিছুটা উচ্চতর পারফরম্যান্স (259.5K) অর্জন করেছিল, তবে প্রত্যেকটি লোডের সময় লিখার দেরি কম রাখা হয়েছিল এবং পড়ার দেরি উচ্চতর ছিল (memcached এর মত)। নিম্নলিখিত টেবিলটি দুই লোডারগুলির মধ্যে ক্লায়েন্ট-সাইড রান ফলাফল সংক্ষেপ করে: Loader Rate Write P99 Read P99 loader1 124.9K/s 1.4ms 2.6 ms loader2 124.6K/s 1.3ms 2.6 ms লোড 1 124.9K / সেকেন্ড ১.৪ এমএস ২.৬ এমএস লোডার2 124.6K / সেকেন্ড ১.৩ এমএস ২.৬ এমএস Takeaways উভয় Memcached এবং ScyllaDB লিখার হার স্থিতিশীল ছিল, পড়া সারা দিকে একটু পরিবর্তিত ছিল ScyllaDB এখনও commitlog ওভারহেডের জন্য অ্যাকাউন্ট লিখে, যা হট লেখার পথটিতে বসবাস করে ScyllaDB সার্ভার পাশের দেরিগুলি Memcached ফলাফলের সাথে অনুরূপ ছিল, যদিও ক্লায়েন্ট পাশের দেরিগুলি কিছুটা উচ্চতর ছিল। এই প্রকল্পের জন্য Gitbook এ আরও বিস্তারিত বিশ্লেষণ পড়ুন উঁচু করে memcached এবং ScyllaDB উভয়ই সমস্ত পরীক্ষায় ভিত্তিক হার্ডওয়্যার ব্যবহার সর্বোচ্চ করতে সক্ষম হয়েছিল এবং দেরিগুলি পূর্বাভাসযোগ্যভাবে কম রাখে। যদি আপনার বিদ্যমান ওয়ার্কবোর্ড একটি সহজ কী-ওয়ার্ড মডেলের জন্য উপলব্ধ হতে পারে এবং এটি পাইপলাইনিং থেকে উপকৃত হয়, তবে memcached আপনার চাহিদাগুলির জন্য আরও উপযুক্ত হওয়া উচিত। Memcached সঙ্গে আটকে থাকার আরেকটি কারণ: এটি সহজেই ট্র্যাফিক সরবরাহ করে যা একটি NIC বজায় রাখতে পারে। , dormando উল্লেখ করেছিলেন যে তিনি একটি উল্লেখযোগ্যভাবে বৃহত্তর সার্ভার জন্য 55 মিলিয়ন পড়া অপশন / সেকেন্ডের উপর এটি স্ক্যালিং করতে পারেন. যেহেতু, আপনি একটি অনুরূপ কাজ লোড বজায় রাখার জন্য ছোট এবং / অথবা সস্তা ইনস্ট্যান্স টাইপগুলি ব্যবহার করতে পারেন, যতক্ষণ পর্যন্ত আপনার কাজ লোড প্রয়োজনীয়তাগুলির জন্য উপলব্ধ মেমরি এবং ডিস্ক ফাঁদ যথেষ্ট। এই হ্যাকার নিউজ টিউন একটি ভিন্ন দৃষ্টিভঙ্গি বিবেচনা করা উচিত ডাটা সেট আকার. যদিও Extstore আপনাকে র্যামের বাইরে আইটেমগুলি সঞ্চয় করার অনুমতি দেয় দ্বারা বড় খরচ সঞ্চয় প্রদান করে, প্রতি গিগাবাইটের মেমরি প্রতি কতটি কী সঞ্চয় করতে পারে তার উপর একটি সীমা রয়েছে. খুব ছোট আইটেমগুলির সাথে ওয়ার্ক লোডগুলি বড় আইটেমগুলির তুলনায় ছোট অর্জন দেখতে হবে. ScyllaDB এর ক্ষেত্রে এটি নয়, যা আপনাকে তাদের আকারের উপর নির্ভর করে বিলিয়ন আইটেমগুলি সঞ্চয় করতে দেয়। ডেটা স্থায়ীতা প্রয়োজন কিনা তা বিবেচনা করাও গুরুত্বপূর্ণ। ) যে পুনরাবৃত্তি আপনার কার্যকরী ক্যাশের আকারকে অর্ধেক করে দেয়। দুর্ভাগ্যক্রমে, Extstore গরম পুনরায় চালু করতে সমর্থন করে না এবং অতএব একক নোটের ব্যর্থতা বা রক্ষণাবেক্ষণ আপনার ক্যাশ মিস রেটিংগুলি উত্থাপন করতে পারে। এটি গ্রহণযোগ্য কিনা তা আপনার অ্যাপ্লিকেশন সিমেন্টিক উপর নির্ভর করে না: যদি ক্যাশ মিস ডাটাবেসের একটি রাউন্ড ট্রিপের সাথে মিলিত হয়, তাহলে এন্ড-টান-এন্ড ল্যাটিনেশন মুহূর্তে উচ্চতর হবে। সঠিক ভাবে দেশ গঠন সামঞ্জস্যপূর্ণ হ্যাশিংয়ের ক্ষেত্রে, memcached ক্লায়েন্টগুলি আপনার ভাগ করা সার্ভারগুলিতে কীগুলি বিতরণ করার জন্য দায়ী। এটি কিছু হিককুপ প্রবর্তন করতে পারে, কারণ বিভিন্ন ক্লায়েন্ট কনফিগারেশনগুলি ক্লায়েন্টগুলি আলাদাভাবে সংযুক্ত করতে পারে এবং কিছু বাস্তবায়নগুলি একে অপরের সাথে সামঞ্জস্যপূর্ণ হতে পারে না। ScyllaDB একটি ভিন্ন পদ্ধতি গ্রহণ করে: সার্ভার স্তরে একত্রিত হ্যাশিং করা হয় এবং সংযোগটি প্রথম স্থাপন করার সময় ক্লায়েন্টগুলিতে প্রচার করা হয়. এটি নিশ্চিত করে যে সমস্ত সংযুক্ত ক্লায়েন্ট সবসময় একই টোপোলজি পর্যবেক্ষণ করে যখন আপনি স্ক্যালিং করেন। Memcached এর Configuringক্লায়েন্ট উইকি সুতরাং কে জিতেছে (অথবা কে হারিয়েছে)? ঠিক ... এটি একটি প্রতিযোগিতা হতে হবে না, এমনকি প্রতিটি সমাধানের জন্য প্রতিটি বিবেচনার তালিকাভুক্ত একটি সম্পূর্ণ তালিকাও হতে হবে না। আমরা ScyllaDB শিল্প স্বীকৃত Memcached এর সংখ্যাগুলির সাথে সামঞ্জস্য দেখে খুশি ছিলাম. অবশ্যই, আমরা আমাদের ডাটাবেসের জন্য "গতিশীল" হওয়ার আশা করিনি. প্রকৃতপক্ষে, যখন আমরা মাইক্রো সেকেন্ডের দেরিগুলির কাছাকাছি যাই, তখন দ্রুতের সংজ্ঞাটি বেশ সাবজেক্টিক হয়ে উঠে।
