यह सब इस बात पर निर्भर करता है कि आप इसका उपयोग कैसे करने जा रहे हैं। यदि प्रत्येक बाइट मायने रखता है, उदाहरण के लिए जब आपको क्लाउड सेवा में स्थानांतरित प्रत्येक kB के लिए भुगतान करना होता है, तो आप लागतों की गणना कर सकते हैं। गणित सरल है; एक बाइट 'तार पर' एक बाइट है। रेडिस के अंदर, बड़े मूल्यों के लिए यह उतना ही सरल है। छोटे मानों के लिए, Redis कुछ स्मृति अनुकूलन करता है।
आपके HSET . में उदाहरण के लिए, आप सदस्यों को विभाजित करते हैं, जो केवल तभी समझ में आता है जब आपको उन्हें अधिकतर समय एक-दूसरे से अलग करने की आवश्यकता होती है। एक बेहतर तरीका -शायद- be:HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' . अलग-अलग कुंजी/सदस्यों की 'लागत' लंबी स्ट्रिंग्स की तुलना में बहुत अधिक है, प्रदर्शन के अनुसार। यदि आप केवल एक पूर्ण अर्ध-स्थिर इकाई के रूप में उपयोग करने जा रहे हैं, तो आप एक सदस्य में पूरी तालिका या डेटासेट भी रख सकते हैं।
गति और आकार:कुंजी . के बीच एक उल्लेखनीय अंतर है और मान ।
कुंजी: शॉर्टर आमतौर पर अधिक मेमोरी कुशल होने के साथ-साथ गति कुशल भी होता है। यदि आप रेडिस सॉर्ट किए गए सेट का उपयोग करते हैं तो आप 'नंबर' को कुंजी के रूप में भी उपयोग कर सकते हैं (सॉर्ट किए गए सेट 'सदस्य' प्लस 'स्कोर')। मैं 'नंबर' कहता हूं क्योंकि एक स्कोर तकनीकी रूप से एक फ्लोट64 है, लेकिन एक आईडी के रूप में उपयोग करने के लिए इसे -999999999999999 और 999999999999999 के बीच होना चाहिए (जिसमें 15 अंक हैं), बिना किसी आंशिक भाग के। यह वास्तव में मददगार हो सकता है, क्योंकि रेडिस तेजी से और स्केलेबल O(log(n)) ऑन-द-फ्लाई सॉर्ट किए गए सेट (स्किपलिस्ट का उपयोग करके, सरलीकृत) करता है।
मान: MsgPack प्रारूप (असम्पीडित) कम से कम स्थान लेता है, खासकर यदि आप परिभाषाओं को एक बार और कई मानों को संग्रहीत करते हैं। जेएसओएन थोड़ा कम मेमोरी कुशल है, लेकिन निश्चित रूप से ऐसा सामान्य आईपीसी प्रारूप है कि इसे छोड़ा नहीं जाना चाहिए। कच्चे तार, चरित्र अलग, निश्चित लंबाई (यूघ), जो भी आपकी इच्छा है, इसका उपयोग करना संभव है। आप अपने डेटा को Redis में स्टोर करने से पहले हमेशा कंप्रेस कर सकते हैं। अब तक स्मृति दक्षता . जब गति की बात आती है , यह कम सरल है। यदि आप लुआ सर्वर-साइड स्क्रिप्टिंग (जो आपको करना चाहिए) का उपयोग करना चाहते हैं, तो आप संपीड़ित डेटा के साथ कुछ भी नहीं कर सकते हैं। JSON और MsgPack को deserialized किया जा सकता है, लेकिन केवल 'एक पूरे के रूप में'। जो ज्यादातर परिदृश्यों में ठीक है। सबसे लचीला अलग-अलग मूल्यों को संग्रहित कर रहा है (उदाहरण के लिए एचएसईटी के सदस्यों के रूप में), लेकिन यह एक कीमत पर भी आता है (ज्यादातर समय:बहुत अधिक कीमत)। आप इन सभी को मिला भी सकते हैं। हम सबसे अधिक किसका उपयोग करते हैं:दो या तीन सीमांकक-पृथक मानों का एक उपसर्ग, उसके बाद एक MsgPack पेलोड।
मेरी सामान्य सलाह है:केवल एचएसईटी और जेडएसईटी के उपयोग से शुरू करें, एक साथ संबंधित डेटा को विभाजित न करें, 10-25 वर्णों के बीच अपनी चाबियों के लिए वर्णनात्मक पास्कलकेसेड नामों का उपयोग करें, यदि आपको अपनी चाबियों (नामस्थान) में डिलीमीटर की आवश्यकता है तो ':' का उपयोग करें। , JSON के रूप में क्रमबद्ध करें (सरलता के लिए, लेकिन MsgPack पर आसानी से स्विच करने के लिए कोड), Lua स्क्रिप्टिंग का उपयोग करें (भले ही आप Lua को न जानते हों, Redis में आपके द्वारा उपयोग किया जाने वाला सबसेट छोटा है)।
मैं आपके प्रोजेक्ट के स्टार्टअप चरण में इसके बारे में बहुत अधिक चिंता नहीं करता, आप इसे बाद में हमेशा बदल सकते हैं और जैसे ही आपके पास कुछ इंटरपोलेटेबल डेटा होता है, कुछ ए/बी तुलना कर सकते हैं।
आशा है कि यह मदद करता है, TW
