रेडिस के साथ रीयल-टाइम ट्रेडिंग प्लेटफॉर्म का निर्माण

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

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

इन उन्मत्त समय के दौरान, अधिकांश निवेशक अपने पोर्टफोलियो के बारे में दो डेटा बिंदुओं की तलाश में हैं, जिनकी उन्हें हर समय पहुंच की आवश्यकता होती है:

1. उस समय पोर्टफोलियो का कुल मूल्य कितना था?
2. उनके पोर्टफोलियो में विशिष्ट प्रतिभूतियों के लाभ या हानि क्या हैं?

इन सवालों के जवाब निवेशक को विशिष्ट प्रतिभूतियों को खरीदने, बेचने या रखने के लिए प्रेरित कर सकते हैं। आज के तेजी से बढ़ते बाजारों में, किसी भी देरी का मतलब खोया हुआ अवसर और मुनाफा हो सकता है। इन सवालों के जवाब देने के लिए आपको कीमतों तक रीयल-टाइम पहुंच की आवश्यकता है—फिर भी दो बड़ी चुनौतियां हैं:

• हजारों प्रतिभूतियों की कीमतों को एक साथ अपडेट करना
• ग्राहकों के लाखों अनुरोधों का एक साथ जवाब देना।

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

अनिवार्य रूप से, हम एक रीयल-टाइम स्टॉक चार्ट बना रहे हैं। कई ब्रोकरेज ऐप इसे बड़े पैमाने पर करने की कोशिश नहीं करते हैं। इसके बजाय, ये ऐप लाखों ग्राहकों को कीमतों को आगे बढ़ाने के बजाय नवीनतम कीमतों को खींचते हैं। उदाहरण के लिए, उनके पोर्टफोलियो पेज पर एक रिफ्रेश बटन हो सकता है।

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

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

इस ब्लॉग पोस्ट में हम निम्नलिखित को कवर करेंगे:

• Redis Enterprise पर एक उच्च-प्रदर्शन और स्केलेबल प्रतिभूति पोर्टफोलियो डेटा मॉडल का एक नमूना कार्यान्वयन।
• रिअल-टाइम में पोर्टफोलियो में प्रतिभूतियों की कीमतों को अपडेट करें क्योंकि ब्रोकरेज को एक्सचेंजों से नवीनतम मूल्य प्राप्त होते हैं।

एक बार जब क्लाइंट ऐप ने पोर्टफोलियो को पुनः प्राप्त कर लिया और नवीनतम मूल्य प्राप्त कर रहा है, तो यह कर सकता है:

• पोर्टफोलियो के कुल पोर्टफोलियो मूल्य की गणना करें।
• प्रत्येक पोर्टफोलियो होल्डिंग पर लाभ या हानि की गणना करें।

प्रतिभूतियां पोर्टफोलियो डेटा मॉडल

आइए एक पोर्टफोलियो में होल्डिंग मॉडलिंग करके शुरू करें। नीचे दिए गए उदाहरण में, CVS Health Corp. (NYSE: CVS) हमारे उदाहरण होल्डिंग्स में से एक है। CVS के दो अलग-अलग लॉट थे—पहला 4 जनवरी, 2021 को और दूसरा 1 मार्च, 2021 को अधिग्रहित किया गया था। समान संख्या में शेयर खरीदें के दौरान खरीदे गए थे   प्रत्येक लॉट के लिए व्यापार। दोनों ट्रेड 10 शेयरों के लिए थे, हालांकि अलग-अलग कीमत प्रति शेयर - पहले लॉट के लिए $68.3378 और दूसरे के लिए $68.82। पोर्टफोलियो में सीवीएस होल्डिंग की कुल मात्रा 20 है जिसकी औसत लागत की गणना निम्नानुसार की जाती है:(($ 68.3378 * 10) + ($ 68.82 * 10))/20 =$ 68.5789 प्रति शेयर।

आवश्यकताओं को लागू करना

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

यहां डेटा मॉडल में निम्नलिखित संस्थाओं का उल्लेख है:

एक ईआर आरेख एक दृश्य प्रतिनिधित्व प्रदान करता है जो किसी को यह देखने में मदद कर सकता है कि क्या हो रहा है।

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

समग्र वास्तुकला

इस प्रणाली के बारे में जिन मुख्य बिंदुओं पर विचार करने की आवश्यकता है उनमें शामिल हैं:

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

इन बिंदुओं को देखते हुए, कुछ सामान्य दृष्टिकोण हैं:

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

यहाँ प्रमुख कम्प्यूटेशनल घटक और डेटा प्रवाह हैं:

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

Redis Enterprise घटक

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

• RedisTimeSeries डेटाबेस, मूल्य परिवर्तन के इतिहास का ट्रैक रखने के लिए (साथ ही किसी भी क्लाइंट को जोड़ने के लिए नवीनतम मूल्य रिकॉर्ड करें)
• पब/सब ब्रोकर चैनल उन ग्राहकों को मूल्य परिवर्तन सूचनाएं भेजने के लिए जिन्होंने उस चैनल की सदस्यता ली है (अर्थात निवेशक जिनके पोर्टफोलियो में वह सुरक्षा शामिल है)

निम्नलिखित आरेख वास्तुकला के इस भाग का विवरण देता है:

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

हम निम्नलिखित जानकारी को एक ठोस उदाहरण के रूप में उपयोग करेंगे:

हम फ्लोट से बचने और सब कुछ पूर्णांक में रखने के लिए न्यूनतम संभव मुद्रा मूल्यवर्ग में मूल्य निर्धारण कर रहे हैं। हम ग्राहक को डॉलर और सेंट में परिवर्तन को संभालने की अनुमति दे सकते हैं। इस उदाहरण में, हम दो दशमलव स्थानों की सटीकता के साथ कीमतों का उपयोग कर रहे हैं।

डेटा मॉडल A

हमारा पहला कार्यान्वयन खाता आईडी द्वारा पहचाने गए SET का उपयोग करके खाते में सभी लॉट के आईडी को रिकॉर्ड करता है, और फिर फ़ील्ड के रूप में टिकर, मात्रा और खरीद मूल्य के साथ LOT आईडी द्वारा पहचाने गए प्रति LOT में एक Redis HASH का उपयोग करता है। दूसरे शब्दों में, हम प्रत्येक विशेषता के साथ, LOT निकाय संरचना को मॉडल करने के लिए HASH का उपयोग कर रहे हैं एक फ़ील्ड . होने के नाते LOT निकाय का रेडिस हैश में।

इस डेटा मॉडल के साथ हमारे पास प्रत्येक खाते के लिए एक कुंजी होती है और एक मान होता है जिसमें उस खाते के लिए सभी लॉट आईडी होते हैं जो एक Redis SET के रूप में संग्रहीत होते हैं:

इसके अलावा, प्रत्येक लॉटिड के लिए, हमारे पास एक HASH होगा जिसका क्षेत्र टिकर, मात्रा और खरीद मूल्य है:

सीधे तौर पर, हम इस तरह की कुंजियाँ बनाएंगे:

127.0.0.1:6379> SADD lotids:ACC-1001 LOT-9001 LOT-9002
(integer) 2
127.0.0.1:6379> HMSET lot:LOT-9001 ticker AAPL quantity 200 price 12556
OK
127.0.0.1:6379> HMSET lot:LOT-9002 ticker CAT quantity 1200 price 18063
OK

RedisTimeSeries मॉड्यूल समय और मूल्यों के संबंधित जोड़े के भंडारण और पुनर्प्राप्ति की अनुमति देता है, साथ ही उच्च-वॉल्यूम आवेषण और कम-विलंबता पढ़ता है। हम संबंधित समय श्रृंखला कुंजियों का उपयोग करते समय ग्राहक द्वारा उपयोग की जाने वाली रुचि के टिकर के लिए नवीनतम मूल्य प्राप्त करने जा रहे हैं:

127.0.0.1:6379> TS.GET price_history:APPL
1) (integer) 1619456853061
2) 12572
127.0.0.1:6379> TS.GET price_history:CAT
1) (integer) 1619456854120
2) 18021

और अपडेट के लिए मूल्य निर्धारण चैनल की सदस्यता लें:

सभी डेटा प्राप्त करने के लिए, क्लाइंट निम्नलिखित कार्य करेगा:

1. एक बार SMEMBERS लॉटिड्स . पर कुंजी—समय जटिलता O(N) जिसमें N लॉट की संख्या है
2. एन बार HGETALL लॉट . पर कुंजियाँ—समय जटिलता N गुना O(1)
3. T बार TS.GET price_history . पर कुंजियाँ - समय जटिलता T गुना O(1) जिसमें T टिकरों की संख्या है
4. . पर 1 बार SUBSCRIBE करें चैनल - समय की जटिलता O(T) (कोई एक ही कॉल में सभी चैनलों को सब्सक्राइब कर सकता है)

कुल समय जटिलता O(N +T) है।

सीधे तौर पर, संचालन एक और दो होंगे:

127.0.0.1:6379> SMEMBERS lotids:ACC1001
1) "LOT-9001"
2) "LOT-9002"
127.0.0.1:6379> HGETALL lot:LOT-9001
1) "ticker"
2) "AAPL"
3) "quantity"
4) "200"
5) "price"
6) "12556"
127.0.0.1:6379> HGETALL lot:LOT-9002
1) "ticker"
2) "CAT"
3) "quantity"
4) "1200"
5) "price"
6) "18063"

हम पाइपलाइनिंग (क्लाइंट साइड पर बैचिंग का एक रूप) और/या LUA स्क्रिप्ट के बार-बार उपयोग (SCRIPT LOAD & EVALSHA का उपयोग करके) नेटवर्क विलंबता को कम कर सकते हैं। साइड नोट:लेन-देन को पाइपलाइनों का उपयोग करके कार्यान्वित किया जा सकता है और कम नेटवर्क विलंबता प्रदान कर सकता है, लेकिन यह क्लाइंट विशिष्ट है और उनका लक्ष्य सर्वर पर परमाणुता है, इसलिए वे वास्तव में नेटवर्क विलंबता समस्या का समाधान नहीं करते हैं। पाइपलाइन में कमांड होते हैं जिनके इनपुट और आउटपुट एक दूसरे से स्वतंत्र होने चाहिए। LUA स्क्रिप्ट के लिए ज़रूरी है कि सभी कुंजियां पहले से उपलब्ध कराई जाएं और कि सभी कुंजियों को एक ही स्लॉट में हैश किया गया है (अधिक विवरण के लिए इस विषय पर Redis Enterprise डॉक्स देखें)।

इन बाधाओं को देखते हुए हम देख सकते हैं कि पाइपलाइनों के संचालन का कार्य है:

• पाइपलाइन 1:संचालन #1 का एकल आदेश
• पाइपलाइन 2:ऑपरेशन #2 के सभी N आदेश
• पाइपलाइन 3:#3 और #4 संचालन के सभी N आदेश

और यह कि LUA स्क्रिप्ट का उपयोग करना संभव नहीं है क्योंकि प्रत्येक ऑपरेशन अलग-अलग कुंजियों का उपयोग करता है और उन कुंजियों का कोई सामान्य भाग नहीं होता है जिसे एक ही स्लॉट में हैश किया जा सकता है।

इस मॉडल का उपयोग करने में हमारे पास O(N+T) और तीन नेटवर्क हॉप्स की समय जटिलता है।

डेटा मॉडल B

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

tickers_by_lot: <ACCOUNT_ID> HASH <LOTID TICKER>

quantities_by_lot:<ACCOUNT_ID> HASH <LOTID INTEGER>

prices_by_lot:<ACCOUNT_ID> HASH <LOTID INTEGER>

ये हैश डेटा मॉडल A से LOTID और LOT कुंजियों को बदल देंगे, जबकि price_history और <TICKER> कुंजियाँ वही रहेंगी।

कुंजियाँ बनाना:

HSET tickers_by_lot:ACC-1001 LOT-9001 AAPL LOT-9002 CAT
HSET quantities_by_lot:ACC-1001 LOT-9001 200 LOT-9002 1200
HSET prices_by_lot:ACC-1001 LOT-9001 125.56 LOT-9002 180.63

मान पुनर्प्राप्त करना:

127.0.0.1:6379> HGETALL tickers_by_lot:ACC-1001
1) "LOT-9001"
2) "AAPL"
3) "LOT-9002"
4) "CAT"
127.0.0.1:6379> HGETALL quantities_by_lot:ACC-1001
1) "LOT-9001"
2) "200"
3) "LOT-9002"
4) "1200"
127.0.0.1:6379> HGETALL prices_by_lot:ACC-1001
1) "LOT-9001"
2) "12556"
3) "LOT-9002"
4) "18063"

क्लाइंट के लिए आवश्यक ऑपरेशन अब होंगे:

1. HGETALL को lot_quantity . पर 1 बार कुंजियाँ—समय जटिलता N x O(1)
2. lot_ticker . पर 1 बार HGETALL कुंजियाँ—समय जटिलता N x O(1)
3. lot_price . पर 1 बार HGETALL कुंजियाँ—समय जटिलता N x O(1)
4. T गुना TS.GET price_history . पर कुंजियाँ—समय जटिलता T x O(1) जिसमें T टिकरों की संख्या है
5. . पर 1 बार SUBSCRIBE करें चैनल—समय जटिलता 1 x O(T)

इसमें ओ (एन + टी) की समग्र समय जटिलता है - पहले की तरह।

पाइपलाइन के दृष्टिकोण से यह बन जाता है:

• पाइपलाइन वन—ऑपरेशन के सभी आदेश #1, #2, और  #3
• पाइपलाइन टू—ऑपरेशन #4 और #5 के सभी टी कमांड

इसलिए हमने नेटवर्क हॉप्स की संख्या को एक-एक करके कम कर दिया है - निरपेक्ष रूप से बहुत अधिक नहीं, बल्कि सापेक्ष रूप से 33%।

इसके अलावा, हम आसानी से LUA का उपयोग कर सकते हैं क्योंकि हम कुंजियों को जानते हैं, और हम किसी भी विशिष्ट खाते के लिए सभी कुंजियों को एक ही स्लॉट में मैप कर सकते हैं। संचालन की सरलता को देखते हुए हम आगे LUA में खुदाई नहीं करेंगे, लेकिन ध्यान दें कि यह डिज़ाइन इसे कम से कम संभव बनाता है!

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

सारांश

इस ब्लॉग में, हमने Redis डेटा प्रकारों का उपयोग करते हुए Entity मॉडल के दो संभावित कार्यान्वयन दिखाए हैं। हमने समय जटिलता विश्लेषण भी पेश किया है जो नेटवर्क प्रदर्शन सुधारों पर विचार के साथ-साथ रेडिस डेटा प्रकार चुनते समय किया जाना चाहिए-बड़े पैमाने पर और उच्च प्रदर्शन की आवश्यकता होने पर एक महत्वपूर्ण कदम। बाद के ब्लॉगों में, हम इन विचारों पर और विस्तार करेंगे क्योंकि डेटा मॉडल का विस्तार किया गया है।

हमने बड़े पैमाने पर प्रतिभूतियों के पोर्टफोलियो के प्रबंधन में कुछ व्यावसायिक चुनौतियों का परिचय दिया है और निम्नलिखित दिखाया है:

• एक रीयल-टाइम और स्केलेबल सिक्योरिटीज पोर्टफोलियो को लागू करने के लिए एक रेडिस डेटा मॉडल।
• एक उच्च-प्रदर्शन, रीयल-टाइम मूल्य अद्यतन प्रणाली जिसका उपयोग किसी पोर्टफोलियो के कुल मूल्य और प्रत्येक होल्डिंग के लाभ या हानि की गणना के लिए किया जा सकता है।

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