Redis
 sql >> डेटाबेस >  >> NoSQL >> Redis

रेडिस डेटा संरचनाओं का परिचय:हैश

Redis हैश (सहज रूप से पर्याप्त!) हैश हैं जो स्ट्रिंग नामों को स्ट्रिंग मानों में मैप करते हैं। वे अनिवार्य रूप से अद्वितीय क्षेत्रों और उनके मूल्यों के कंटेनर नामित हैं। वे रेडिस डेटा संरचना के रूप में किसी वस्तु का प्रतिनिधित्व करने का सही तरीका हैं। जैसा कि अपेक्षित था, वे निरंतर समय बुनियादी संचालन प्रदान करते हैं जैसे कि प्राप्त, सेट, मौजूद आदि। उन्नत संचालन का एक समूह भी प्रदान किया जाता है। हैश कमांड की पूरी सूची यहां है।

आइए इसे redis-cli से एक स्पिन के लिए लेते हैं ।

# hmset key field value [field value ...] :  Insert elements in a hash. O(N), N is # of field being set
127.0.0.1:6379> hmset std:101 name "John Smith" dob "01-01-2000" gender M active 0 cgpa 2.9
OK

# hgetall key : key all keys and values in the hash. O(N), N is size of hash
127.0.0.1:6379> hgetall std:101
 1) "name"
 2) "John Smith"
 3) "dob"
 4) "01-01-2000"
 5) "gender"
 6) "M"
 7) "active"
 8) "0"
 9) "cgpa"
10) "2.9"
127.0.0.1:6379> hmset std:102 name "Jane" name "Ann"
OK
# If duplicates are found, only the last set is valid
127.0.0.1:6379> hgetall std:102
1) "name"
2) "Ann"

# hexists key field: does field exist in the hash with key. O(1)
127.0.0.1:6379> hexists std:102 cgpa
(integer) 0

# hincrby key field increment: Increment the integer field by increment. O(1)
127.0.0.1:6379> hincrby std:101 active 1
(integer) 1

# hget key field : the value for field in the hash stored at key. O(1)
127.0.0.1:6379> hget std:101 active
1) "1"
# If field doesn't exist, hincrby sets it to 0 and then applies increment
127.0.0.1:6379> hincrby std:102 active 2
(integer) 2

# hmget key field [field ...]: the values of the fields requested for the hash with key. O(N), N is # of keys requested
127.0.0.1:6379> hmget std:102 active
1) "2"

# hincrbyfloat key field increment: Increment the float value in field by increment. O(1) 
127.0.0.1:6379> HINCRBYFLOAT std:101 cgpa 1.0
"3.9"

# HSETNX key field value: set field to value if not alread set. O(1)
127.0.0.1:6379> hsetnx std:102 cgpa 4.0
(integer) 1
127.0.0.1:6379> hget std:102 cgpa
"4.0"

# hlen key: number of fields in the hash. O(1)
127.0.0.1:6379> hlen std:101
(integer) 5

# hkeys key : all fields in the hash. O(N), N is size of hash
127.0.0.1:6379> hkeys std:101
1) "name"
2) "dob"
3) "gender"
4) "active"
5) "cgpa"

जैसा कि हम डेटा संरचना सर्वर के रूप में Redis™* के लिए अपनी होस्टिंग से उम्मीद करते आए हैं, हम देखते हैं कि Redis हैश पर काफी उपयोगी और उन्नत संचालन प्रदान करता है।

आंतरिक

Redis Sets की तरह, Redis हैश को भी शब्दकोशों के रूप में लागू किया जाता है। रेडिस में डिक्शनरी को हैश टेबल के रूप में लागू किया जाता है जो हैश फ़ंक्शन मुरमुरहैश 2 का उपयोग करता है और वृद्धिशील आकार के माध्यम से बढ़ता है। हैश टकराव को जंजीर द्वारा नियंत्रित किया जाता है। शब्दकोश के रेडिस कार्यान्वयन में अधिक विवरण dict.c पर पाया जा सकता है।
सेट के साथ के रूप में, छोटे हैश के लिए स्टोरेज ऑप्टिमाइज़ेशन बनाया गया है। Redis कार्यान्वयन में इस डेटा संरचना को ziplist कहा जाता है (Redis 2.6 से पहले zipmap नामक एक अलग डेटा संरचना का उपयोग करके हैश अनुकूलन किया गया था)। यह अनिवार्य रूप से एक विशेष रूप से एन्कोडेड डबल लिंक्ड सूची है जिसे स्मृति बचत के लिए अनुकूलित किया गया है। डेटा, साथ ही पॉइंटर्स इनलाइन संग्रहीत किए जाते हैं। Ziplist का उपयोग छोटे सॉर्ट किए गए सेट और सूचियों के भंडारण को अनुकूलित करने के लिए भी किया जाता है। एक हैश जब ऐसी सूची में चपटा होता है, तो कुछ ऐसा दिखता है, [key1, value1, key2, value2, ...]। सादा चाबियों की तुलना में यह अधिक कुशल कैसे है? कुछ चाबियों वाले हैश को इस रैखिक सरणी जैसे संरचना (यानी ज़िपलिस्ट) में चतुराई से पैक किया जा सकता है, जबकि अभी भी प्राप्त और सेट के लिए परिशोधन ओ (1) प्रदर्शन की गारंटी देता है। जाहिर है कि हैश फ़ील्ड बढ़ने के साथ यह जारी नहीं रह सकता है। जैसे-जैसे हैश बढ़ता है, इसे ओ (1) प्रदर्शन को बनाए रखने के लिए मानक शब्दकोश संरचना में परिवर्तित किया जाता है और अंतरिक्ष बचत खो जाती है। इस परिवर्तन को नियंत्रित करने वाले रेडिस कॉन्फ़िगरेशन पैरामीटर हैं:

  • list-max-ziplist-entries डिफ़ॉल्ट (512):यदि हैश इस सीमा से बड़ा हो जाता है तो मानक प्रतिनिधित्व में बदलें।
  • सूची-अधिकतम-ज़िपसूची-मान डिफ़ॉल्ट (64):यदि हैश में सबसे बड़ा तत्व इस सीमा से बड़ा हो जाता है, तो मानक प्रतिनिधित्व में बदलें।

अधिक विवरण को यहां दिए गए कार्यान्वयन में कोड और टिप्पणियों से समझा जा सकता है। इस विशेष अनुकूलन का उपयोग करने से स्मृति बचत महत्वपूर्ण है। हम अगले भाग में अधिक विवरण के बारे में बात करेंगे।

स्मृति अनुकूलन

Redis का उपयोग करते समय स्मृति बचत के लिए प्रसिद्ध अनुशंसाओं में से एक सादे तारों के बजाय हैश का उपयोग करना है। वास्तविक दुनिया के अनुप्रयोगों में रेडिस हैश की शक्ति का उपयोग करने के लिए यह एक महत्वपूर्ण उपयोग-मामला है। मेमोरी ऑप्टिमाइज़ेशन पर आधिकारिक रेडिस दस्तावेज़ीकरण से:

<ब्लॉकक्वॉट>

जब संभव हो हैश का उपयोग करें

छोटे हैश बहुत छोटे स्थान में एन्कोड किए जाते हैं, इसलिए आपको हर बार संभव होने पर हैश का उपयोग करके अपने डेटा का प्रतिनिधित्व करने का प्रयास करना चाहिए। उदाहरण के लिए यदि आपके पास वेब एप्लिकेशन में उपयोगकर्ताओं का प्रतिनिधित्व करने वाली वस्तुएं हैं, तो नाम, उपनाम, ईमेल, पासवर्ड के लिए अलग-अलग कुंजियों का उपयोग करने के बजाय, सभी आवश्यक फ़ील्ड के साथ एक हैश का उपयोग करें।

उस पोस्ट में स्मृति बचत का लाभ उठाने के लिए वस्तुओं की एक श्रृंखला को हैश के एक सेट में मैप करने का एक तरीका प्रस्तावित किया जाता है। इंस्टाग्राम, एक बहुत लोकप्रिय ब्लॉग पोस्ट में, एक समान तकनीक का उपयोग करने का वर्णन करता है जिससे उन्हें संभावित बचत के परिमाण के आदेश प्राप्त करने में मदद मिली। एक अन्य ब्लॉग जो अनुकूलन के लाभों को मापने का प्रयास करता है वह यह है।

अनुप्रयोग

  • Redis Hashes स्वाभाविक रूप से वस्तुओं को संग्रहीत करने के लिए उपयुक्त हैं:सत्र, उपयोगकर्ता, विज़िटर आदि। यह इसे Redis द्वारा प्रदान की गई प्रमुख डेटा संरचनाओं में से एक बनाता है।
  • अपने मेमोरी अनुकूलित रूप में, यह बड़ी मात्रा में डेटा को संचित करने के लिए एक उत्कृष्ट विकल्प है।

ऑब्जेक्ट एड्रेस स्टोर

चूंकि, मेमोरी ऑप्टिमाइज़ेशन हैश के लिए एक महत्वपूर्ण उपयोग का मामला है, आइए Instagram परिनियोजन के समान एक उदाहरण पर चर्चा करें कि यह दिखाने के लिए कि Redis हैश की मेमोरी सेविंग सुविधाओं का उपयोग कैसे किया जाए। मान लीजिए, हमारे पास एक विशाल सामग्री-एड्रेसेबल स्टोरेज (सीएएस) परिनियोजन है जिसमें करोड़ों ऑब्जेक्ट संग्रहीत हैं। प्रत्येक वस्तु का स्थान एक हैश स्ट्रिंग है। हम ऑब्जेक्ट के स्थान का पता लगाने के लिए एक लुकअप सिस्टम विकसित करने का इरादा रखते हैं, जिसे इसकी आईडी दी गई है। Redis में ऐसा करने का सामान्य तरीका एक स्ट्रिंग का उपयोग करना होगा।

set object:14590860 "007f80f0a62408..."
set object:11678 "009f80abcd0a60..."
...

यह तरीका ठीक काम करता है। हालाँकि, चूंकि हमारे पास बड़ी संख्या में ऑब्जेक्ट हैं, इसलिए हमें रेडिस के लिए बहुत अधिक मेमोरी की आवश्यकता होगी। हम बेहतर करना चाहते हैं। आइए इस समस्या के लिए स्मृति अनुकूलित हैश दृष्टिकोण लें। हमें सूची-अधिकतम-ज़िपलिस्ट-प्रविष्टियों के लिए सही मान चुनना होगा और सूची-अधिकतम-ज़िपसूची-मान . सूची-अधिकतम-ज़िपसूची-मान . के लिए सही मान स्टोरेज एड्रेस हैश स्ट्रिंग की अधिकतम लंबाई जो भी हो सकती है। सूची-अधिकतम-ziplist-प्रविष्टियों . का मान पर्याप्त रूप से कम रखा जाना चाहिए और यह उस कुल हैश बकेट की संख्या पर निर्भर करेगा जिसे हम बनाना चाहते हैं। यह सबसे अच्छा अनुभवजन्य रूप से पता लगाया जाएगा। उदाहरण के लिए 100 मिलियन वस्तुओं के लिए हम 100k हैश का उपयोग करना चुन सकते हैं। उस स्थिति में अधिकतम प्रविष्टियाँ 100m / 100k =1000 होंगी। यह तय करने के लिए एप्लिकेशन का तर्क हो सकता है कि किसी ऑब्जेक्ट का स्टोरेज एड्रेस किस हैश में जाता है:ऑब्जेक्ट आईडी को 100k से विभाजित करें और शेष को छोड़ दें। इस प्रकार ऑब्जेक्ट आईडी 14590860 हैश (14590860/100k) =145 यानी में चला जाएगा


hset object:145 14590860 "007f80f0a62408..."
hget object:145 14590860
> "007f80f0a62408..."

यह कार्यान्वयन न केवल स्मृति पर बहुत हल्का होगा बल्कि अच्छा कैशे लोकैलिटी भी प्रदान करेगा।

Redis डेटा संरचना श्रृंखला में हमारी अन्य पोस्ट यहां दी गई हैं।

  • रेडिस सेट
  • रेडिस बिटमैप्स
  • रेडिस सॉर्ट किए गए सेट

  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. विभिन्न मेजबानों पर रेडिस क्लस्टरिंग के क्या लाभ हैं?

  2. नेस्टेड कुंजियों की रेडिस सूची

  3. लार्वा निजी चैनल और लार्वा-इको-सर्वर के साथ प्रमाणीकरण समस्या

  4. रेडिस सिंगल-थ्रेडेड है, तो यह समवर्ती I/O कैसे करता है?

  5. एक रेडिस डीबी के मूल्यों में खोज रहे हैं