रेडिस बनाम MySQL?

Question

मुझे एहसास है कि यह प्रश्न बहुत अच्छी तरह से चर्चा की गई है, हालांकि मैं अपनी विशिष्ट आवश्यकताओं के संदर्भ में अपना इनपुट प्राप्त करना चाहता हूं।

मैं एक रीयलटाइम वित्तीय डेटाबेस विकसित कर रहा हूं जो एक बार नेट से कई बार स्टॉक कोट्स पकड़ता है और इसे डेटाबेस में संग्रहीत करता है। मैं वर्तमान में MySQL पर SQLAlchemy के साथ काम कर रहा हूं, लेकिन मैं रेडिस में आया और यह दिलचस्प लग रहा है। यह विशेष रूप से इसके प्रदर्शन की वजह से अच्छा लगता है, जो मेरे आवेदन में महत्वपूर्ण है। मुझे पता है कि MySQL भी तेज हो सकता है, मुझे लगता है कि भारी कैशिंग लागू करने की तरह दर्द होता है।

जो डेटा मैं सहेज रहा हूं वह अब तक ज्यादातर दशमलव मानों से है। मैं इन दशमलव मानों (एक अलग आवेदन में) के साथ विभाजन और गुणाओं की एक महत्वपूर्ण मात्रा भी कर रहा हूं।

डेटा आकार के संदर्भ में, मैं एक मिनट में कई बार 10,000 प्रतीकों को पकड़ रहा हूं। यह सालाना लगभग 3 टीबी डेटा है।

मैं रेडिस की प्रमुख मात्रा सीमा (2^32) से भी चिंतित हूं। क्या रेडिस यहां एक अच्छा समाधान है? मेरे अन्य निर्णय या तो MySQL या Redis के लिए निर्णय लेने में मदद कर सकते हैं?

धन्यवाद!

Answer 1

Redis एक में स्मृति दुकान है। सभी डेटा स्मृति में फिट होना चाहिए। इसलिए यदि आपके पास डेटा के प्रति वर्ष 3 टीबी रैम है, तो यह सही विकल्प नहीं है। 2^32 सीमा वास्तव में अभ्यास में कोई मुद्दा नहीं है, क्योंकि आपको शायद अपने डेटा को किसी भी तरह से शेड करना होगा (यानी कई उदाहरणों का उपयोग करें), और क्योंकि सीमा वास्तव में 2^32 कुंजी 2^32 आइटम प्रति कुंजी के साथ है।https://github.com/antirez/redis-timeseries

तुम भी एक उचित समय श्रृंखला जोड़ने के लिए Redis पैच करने के लिए चाहते हो सकता है:

आप पर्याप्त स्मृति है और अभी भी उपयोग करना चाहते हैं (sharded) Redis, यहाँ आप कैसे अंतरिक्ष कुशल समय श्रृंखला स्टोर कर सकते हैं है डेटा संरचना। पर लुका Sbardella के कार्यान्वयन देखें:

https://github.com/lsbardel/redis

http://lsbardel.github.com/python-stdnet/contrib/redis_timeseries.html

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

पारंपरिक संबंधपरक डेटाबेस समय श्रृंखला को स्टोर करने के लिए इतना बुरा नहीं हैं। लोग इस विषय से सारी किताबों समर्पित कर दिया है:

Developing Time-Oriented Database Applications in SQL

एक अन्य विकल्प पर विचार करने की एक bigdata समाधान का उपयोग कर रहा है कर सकते हैं:

storing massive ordered time series data in bigtable derivatives

मुख्य बिंदु (जो भी भंडारण इंजन) IMO इन आंकड़ों तक पहुंच पैटर्न का मूल्यांकन करना है। आप इन डेटा का उपयोग किसके लिए करना चाहते हैं? एक बार संग्रहीत किए जाने के बाद आप इन डेटा तक कैसे पहुंचेंगे? क्या आपको किसी दिए गए प्रतीक से संबंधित सभी डेटा पुनर्प्राप्त करने की आवश्यकता है? क्या आपको किसी दिए गए समय सीमा में कई प्रतीकों के विकास को पुनः प्राप्त करने की आवश्यकता है? क्या आपको समय के साथ विभिन्न प्रतीकों के मूल्यों को सहसंबंधित करने की आवश्यकता है? आदि ...

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

MySQL उपयोग के संबंध में, मैं निश्चित रूप से डेटा की मात्रा के कारण table partitioning पर विचार करता हूं। पहुंच पैटर्न के आधार पर, मैं ARCHIVE engine पर भी विचार करूंगा। यह इंजन संकुचित फ्लैट फ़ाइलों में डेटा स्टोर करता है। यह अंतरिक्ष कुशल है। इसका विभाजन विभाजन के साथ किया जा सकता है, इसलिए यह डेटा को इंडेक्स नहीं करता है, लेकिन विभाजन ग्रैन्युलरिटी सावधानी से चुने जाने पर यह डेटा के सबसेट को पुनः प्राप्त करने में सक्षम हो सकता है।

Answer 2

आपको पहली बार डेटा चयन और एकत्रीकरण के संदर्भ में रेडिस की पेशकश की जाने वाली सुविधाओं की जांच करनी चाहिए। एक SQL डेटाबेस की तुलना में, रेडिस सीमित है।

वास्तव में, 'रेडिस बनाम माईएसक्यूएल' आमतौर पर सही सवाल नहीं है, क्योंकि वे सेब और नाशपाती हैं। यदि आप अपने डेटाबेस में डेटा को ताज़ा कर रहे हैं (नियमित रूप से भी हटा रहे हैं), MySQL विभाजन को देखें। उदाहरण देखें इस सवाल का जवाब मैं What is the best way to delete old rows from MySQL on a rolling basis?

को पत्र लिखा>

चेक बाहर MySQL Partitioning:

डाटा कि विभाजन छोड़ने (या विभाजन) द्वारा अक्सर आसानी से partitioned तालिका से हटाया जा सकता इसकी उपयोगिता खो देता है ही नहीं युक्त डेटा। इसके विपरीत, कुछ डेटा में विशेष रूप से उस डेटा को संग्रहीत करने के लिए एक या अधिक नए विभाजन जोड़कर नए डेटा को जोड़ने की प्रक्रिया बहुत सुविधाजनक हो सकती है।

उदा। इस पोस्ट के लिए कि यह कैसे लागू करने के लिए पर कुछ विचार पाने के लिए:

Using Partitioning and Event Scheduler to Prune Archive Tables

और यह एक:

Partitioning by dates: the quick how-to

Answer 3

आपको कैसंड्रा या हबेस पर विचार करना चाहिए। दोनों संगत भंडारण और तेज़ परिशिष्ट की अनुमति देते हैं, ताकि जब पूछताछ की बात आती है, तो आपको बड़ा प्रदर्शन मिलता है। दोनों प्रति सेकंड हजारों अंक आसानी से निगलना होगा।

कुंजी बिंदु आपके क्वेरी आयामों (आमतौर पर टिकर द्वारा) में से एक के साथ है, आप डिस्क (एसएसडी या कताई), संगत तक पहुंच रहे हैं। आपको लाखों बार सूचकांक हिट नहीं करना पड़ेगा। आप मोंगो/एसक्यूएल में समान प्रदर्शन प्राप्त करने के लिए चीजों को मॉडल कर सकते हैं, लेकिन यह अधिक परेशानी है, और आप कॉलर लड़कों के साथ बॉक्स के बाहर "मुफ्त में" प्राप्त कर सकते हैं, बिना किसी क्लाइंट साइड शेंगेनियों को ब्लब्स को मर्ज करने के लिए।

कैसंद्रा के साथ मेरा अनुभव यह है कि यह मोंगो डीबी की तुलना में 10x तेज है, जो कि समय श्रृंखला उपयोग के मामले के लिए पहले से ही अधिक रिलेशनल डेटाबेस से अधिक तेज़ है, और जैसे ही डेटा का आकार बढ़ता है, दूसरों के ऊपर इसका लाभ भी बढ़ता है। यह एक मशीन पर भी सच है। Here वह जगह है जहां आपको शुरू करना चाहिए।

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

हबेस के साथ कम परिचित लेकिन यह अधिक सुसंगत होने का दावा करता है (सीएपी प्रमेय की लागत कहीं और होगी), लेकिन यह हैबेज स्टैक को स्थापित करने की प्रतिबद्धता है।