मैं उदाहरण के लिए, रेडिस में वर्बोज़ नामों का उपयोग करना पसंद करता हूं set-allBooksBelongToUser:$userId।
क्या यह ठीक है या यह प्रदर्शन को प्रभावित करता है?
मैं उदाहरण के लिए, रेडिस में वर्बोज़ नामों का उपयोग करना पसंद करता हूं set-allBooksBelongToUser:$userId।
क्या यह ठीक है या यह प्रदर्शन को प्रभावित करता है?
जवाबों:
आप जिस कुंजी का उपयोग करने की बात कर रहे हैं वह वास्तव में लंबे समय तक नहीं है।
उदाहरण कुंजी जो आप देते हैं वह सेट, लुकअप विधियों O (1) के लिए है। एक सेट पर अधिक जटिल ऑपरेशन (SDIFF, SUNION, SINTER) O (N) हैं। संभावना है कि आबादी हो$userId एक लंबी कुंजी का उपयोग करने की तुलना में अधिक महंगा ऑपरेशन थी।
Redis एक बेंचमार्क उपयोगिता के साथ आता है redis-benchmark, जिसे यदि आप src / redis-benchmark.c में "GET" परीक्षा को संशोधित करते हैं, ताकि वे कुंजी सिर्फ "foo" हो, आप एक के बाद लघु कुंजी परीक्षण चला सकते हैं make install:
diff --git a/src/redis-benchmark.c b/src/redis-benchmark.c
--- a/src/redis-benchmark.c
+++ b/src/redis-benchmark.c
@@ -475,11 +475,11 @@
benchmark("MSET (10 keys)",cmd,len);
free(cmd);
- len = redisFormatCommand(&cmd,"SET foo:rand:000000000000 %s",data);
+ len = redisFormatCommand(&cmd,"SET foo %s",data);
benchmark("SET",cmd,len);
free(cmd);
- len = redisFormatCommand(&cmd,"GET foo:rand:000000000000");
+ len = redisFormatCommand(&cmd,"GET foo");
benchmark("GET",cmd,len);
free(cmd);
यहां लघु कुंजी "फू" के 3 बाद के रन के लिए GET परीक्षण गति है:
59880.24 requests per second
58139.53 requests per second
58479.53 requests per second
यहाँ स्रोत को फिर से संशोधित करने और "सेट-ऑलबुकबेलटॉउजर: 1234567890" की कुंजी बदलने के बाद यहां जीईटी परीक्षा की गति है:
60240.96 requests per second
60606.06 requests per second
58479.53 requests per second
कुंजी के लिए एक बार फिर बदलना "ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlorem: 1234567890" इस देता है:
58479.53 requests per second
58139.53 requests per second
56179.77 requests per second
तो वास्तव में वास्तव में लंबी चाबियाँ रेडिस की गति पर एक बड़ा प्रभाव नहीं है। और यह GET, O (1) ऑपरेशन पर है। अधिक जटिल ऑपरेशन इसके प्रति कम संवेदनशील होंगे।
मुझे लगता है कि ऐसी कुंजियाँ हैं जो स्पष्ट रूप से पहचानती हैं कि वे कौन से मूल्यों को रखती हैं जो किसी भी छोटी गति के प्रदर्शन से आगे निकल जाते हैं जिसे आप संक्षिप्त कुंजियों से बाहर निकालेंगे।
यदि आप इसे आगे ले जाना चाहते हैं, तो -r [keyspacelen]रेडिस-बेंचमार्क उपयोगिता पर एक पैरामीटर भी है जो इसे यादृच्छिक कुंजी (जब तक उनके पास ': रैंड:' है) बनाने की सुविधा देता है, तो आप सिर्फ उपसर्ग का आकार बढ़ा सकते हैं परीक्षण कोड जो भी आप चाहते थे लंबाई।
Redis को मेमोरी में सभी कीज़ रखना पसंद है। आपकी औसत लंबाई जितनी लंबी होगी, स्मृति में कम रखा जा सकता है। तो हां, कुंजी की लंबाई प्रदर्शन को बहुत प्रभावित कर सकती है लेकिन संभवतः उस तरीके से महत्वपूर्ण नहीं है जिस तरह से आप चिंतित हैं। अर्थात्, एक छोटे से कीस्पेस (जैसे कि एक मेमोरी में आसानी से फिट होने वाला) के साथ, एक 128 बाइट कुंजी और एक 16 बाइट कुंजी नाटकीय रूप से अलग तरीके से प्रदर्शन नहीं करेगी।
मैं किसी भी निश्चितता के साथ इस सवाल का जवाब नहीं दे सकता। हालांकि, मैं इसके बारे में कुछ सवाल पूछ सकता हूं और कुछ टिप्पणियों की पेशकश कर सकता हूं।
मुझे लगता है कि यह स्पष्ट है कि अत्यंत लंबी कुंजियों (नाम) और / या मानों का समग्र प्रदर्शन पर प्रदर्शन प्रभाव पड़ेगा यदि उनका उपयोग किया जा सकता है। ये प्रभाव क्लाइंट में, नेटवर्क पर या सर्वर पर हो सकते हैं। तो आपका पहला सवाल यह होगा कि:
Redis और आपके ग्राहकों के बीच कुंजियाँ और मूल्य कब तक हो सकते हैं?
Redis पर खोज , मुख्य लंबाई और सीमाएं मुझे Redis बनाम मेम्केड पर एक दिलचस्प ब्लॉग प्रविष्टि प्रदान करती हैं जो आपके प्रश्न का उत्तर देना शुरू कर सकती हैं। उस ब्लॉग प्रविष्टि के लिए पहली प्रतिक्रिया रेडिस के निर्माता सल्वाटोर सैंफिलिपो (प्रारंभिक अंतिम गिरावट: 09/2010) द्वारा लिखी गई प्रतीत होती है कि यह सुझाव देता है कि एक अधिक हालिया संस्करण काफी बेहतर परिणाम दिखाएगा। उस से नीचे दो टिप्पणियाँ हमें Salvatore के लिए लिंक रेडिस / मेम्नेच्ड बेंचमार्क से जोड़ती हैं जो कुछ दिन पोस्ट किया गया था के बाद वह मूल "blagger" (जो गुमनाम हो रहा है) के लिए प्रतिक्रिया व्यक्त था।
यह सवालों के जवाब नहीं देता है (कुंजियां कब तक और किन बिंदुओं पर प्रदर्शन पर पता लगाने योग्य प्रभाव पड़ सकती हैं)। हालांकि, यह हमें प्रश्न के दृष्टिकोण के बारे में एक सुराग देता है।
इन दोनों लेखों के लेखकों ने कोड लिखे और इसका परीक्षण किया ... और परिणामों को रेखांकन किया।
हम सभी तरह के अनुमान लगा सकते थे। हम कोड को देख सकते हैं और इसका कारण जानने की कोशिश कर सकते हैं।
हालांकि, इस तरह के एक प्रश्न के दृष्टिकोण के लिए सबसे सार्थक तरीका एक प्रस्तावित उपयोग पैटर्न को मापने के लिए कुछ कोड लिखना है ... और कुछ और परीक्षण करने के लिए (उदाहरण के लिए 8 वर्णों से लेकर प्रमुख लंबाई की एक श्रृंखला ... कैसे कब तक आप चाहेंगे ... 8 किलोबाइट?) ... और इसे मापें।
मुझे नहीं लगता कि चर नाम की लंबाई प्रदर्शन को प्रभावित करेगी, चर एक ही स्थान लेगा क्योंकि कोई भी चर उस डेटाटाइप के लिए ले जाएगा जहां तक आप अधिकतम नाम लंबाई से अधिक नहीं हैं।