एक स्केल करने योग्य हिट/एनालिटिक्स सिस्टम डिज़ाइन करने का सबसे अच्छा तरीका?

Question

जिस कंपनी के लिए मैं काम करता हूं वह ब्लैकबेरी मंच के लिए अनुप्रयोग बनाता है।

हम एक मालिकाना "एनालिटिक्स सिस्टम" पर काम कर रहे हैं जो हमें हमारे अनुप्रयोगों के भीतर कोड एम्बेड करने की अनुमति देता है और जब भी वे दौड़ते हैं तो एप्लिकेशन हमारे केंद्रीय सर्वर पर कुछ आंकड़े वापस रिपोर्ट करते हैं। वर्तमान में, सिस्टम ठीक काम करता है; हालांकि यह प्रति घंटा 100-200 हिट के साथ बीटा में है। समस्या के बिना सर्वर पर "हिट" भेजे जाते हैं। हमने हिट की स्वीकृति और संग्रहण (एक MySQL डीबी में) को संभालने के लिए एक बहुत ही ठोस API बनाया है। हमने भार का परीक्षण किया है और हमें बिना किसी समस्या के सैकड़ों हजारों हिट समायोजित करने में सक्षम होना चाहिए। यह वास्तव में एक समस्या नहीं है।

समस्या आंकड़े दिखा रही है। हमने मिंट्स (हैमैंटिंट डॉट कॉम) के समान डिस्प्ले पैनल बनाया है, यह प्रत्येक घंटे, पिछले दिन, महीनों, हफ्तों, वर्षों ... आदि पर हिट दिखाता है। मुट्ठी संस्करण हिट टेबल से डेटा खींचने और फ्लाई पर व्याख्या करने के सीधे प्रश्नों को चलाता है। यह बहुत लंबे समय तक काम नहीं करता था। हमारा वर्तमान समाधान यह है कि हिट प्रसंस्करण के लिए "कतारबद्ध" हैं और हमारे पास प्रत्येक 5 मिनट के दौरान हिट लेने और उन्हें प्रत्येक घंटे, दिन, सप्ताह, महीने, वर्ष ... आदि के लिए "कैश" में सॉर्ट करने के माध्यम से एक क्रॉन आ जाता है। यह अद्भुत काम करता है और यह अविश्वसनीय रूप से मापनीय है; हालांकि, यह केवल 1 टाइमज़ोन के लिए काम करता है। चूंकि पूरी कंपनी के पास इसका उपयोग है, इसलिए हम विभिन्न समय क्षेत्रों में कुछ सौ उपयोगकर्ताओं से निपट रहे हैं। सैन जोस में "आज" के रूप में परिभाषित किया गया है जो लंदन में मेरे सहयोगी आज के रूप में परिभाषित करता है उससे काफी अलग है। चूंकि वर्तमान समाधान केवल 1 टाइमज़ोन पर कैश किया गया है, यह किसी भी व्यक्ति के लिए एक दुःस्वप्न है जो हमारे टाइमज़ोन के बाहर डेटा की जांच कर रहा है।

यह तय करने की हमारी वर्तमान योजना हर टाइमज़ोन (कुल में 40) के लिए कैश बनाने के लिए है; हालांकि, इसका मतलब यह होगा कि हम 40 से डेटा की मात्रा गुणा कर रहे हैं ... यह मेरे लिए भयानक है और यह देखते हुए कि कैश बहुत बड़े हो सकते हैं, इसे गुणा करना सिर्फ एक बुरा विचार की तरह लगता है; इसके अलावा, जब हम कतार को संसाधित करने के लिए जाते हैं, तो उन्हें 40 अलग-अलग कैशों में रखने के लिए बहुत अधिक CPU समय लग जाएगा।

किसी और को इस समस्या को हल करने का बेहतर विचार है?

(इतने लंबे question..it के लिए खेद है समझाने के लिए वास्तव में आसान नहीं है। धन्यवाद सब!)

Answer 1

के तहत कार्यान्वित करने के लिए यह पता लगाने के लिए कि आप जिस समाधान का प्रस्ताव दे रहे हैं, वह बहुत अधिक रिडंडेंसी है। मैं सुझाव दूंगा कि आप डेटा को प्रति घंटा की बजाय कम से कम 30-मिनट की बाल्टी में स्टोर करें और समय क्षेत्र को यूटीसी को सामान्यीकृत किया जाए।

30-मिनट की बाल्टी के साथ, यदि कोई उपयोगकर्ता -4.5 यूटीसी से 1 - 2 पीएम के लिए प्रति घंटा डेटा का अनुरोध करता है तो आप अपने सिस्टम से 5:30 - 6:30 अपराह्न के लिए डेटा प्राप्त कर सकते हैं और उसे दिखा सकते हैं। यदि आप एक घंटे की वृद्धि में डेटा संग्रहीत करते हैं तो आप एन + 0.5 घंटे के अंतर के साथ समय क्षेत्र में उपयोगकर्ताओं के लिए सेवा अनुरोध नहीं कर सकते हैं।

दैनिक संख्याओं के लिए आपको 48 अर्ध-घंटे स्लॉट एकत्र करने की आवश्यकता होगी। लेने के लिए स्लॉट उपयोगकर्ता के समय क्षेत्र द्वारा निर्धारित किया जाएगा।

जब आप वार्षिक डेटा प्राप्त करते हैं तो यह दिलचस्प हो जाता है क्योंकि आप 17,520 आधे घंटे की बाल्टी को पूरा करते हैं। उस गणना को कम करने के लिए मैं सुझाव दूंगा कि आप प्रति यूटीसी समय के पूर्व-समेकित वार्षिक डेटा प्राप्त करें और वर्ष के 4.5 घंटे के लिए पहले के लिए कुल डेटा घटाएं और अगले वर्ष के पहले 4.5 घंटों के लिए कुल डेटा जोड़ें। यह अनिवार्य रूप से पूरे वर्ष 4.5 घंटे तक बदल जाएगा और काम इतना नहीं है। यहां से काम करते हुए, आप सिस्टम को आगे बढ़ा सकते हैं।

संपादित करें: काठमांडू बाहर निकलता है +5.45 जीएमटी है तो आपको 30 मिनट की बाल्टी के बजाय 15 मिनट की बाल्टी में डेटा स्टोर करने की आवश्यकता होगी।

संपादित करें 2: एक और आसान सुधार सालाना कुल मिलाकर है, इसलिए आपको प्रत्येक बार 17,520 बाल्टी जोड़ने और प्रति देश एक कुल की आवश्यकता के बिना जोड़ने की आवश्यकता नहीं है। 02 जनवरी से 30 दिसंबर तक वार्षिक डेटा एकत्र करें। चूंकि किसी भी दो देशों के बीच अधिकतम समय क्षेत्र अंतर 23 घंटे है, इसका मतलब है कि आप वार्षिक डेटा (02 जनवरी - 30 दिसंबर) ले सकते हैं और पहले और बाद में कुछ बाल्टी जोड़ सकते हैं के रूप में उपयुक्त। उदाहरण के लिए -5 यूटीसी टाइमज़ोन के लिए आप 0500 के बाद 01 जनवरी को सभी बाल्टी, 31 दिसंबर को सभी बाल्टी और अगले वर्ष 01 जनवरी को 0500 घंटे तक जोड़ देंगे।

Answer 2

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

आपके मामले में, यूटीसी में कैश रखने और यूटीसी में परिवर्तित होने के अनुरोधों को समायोजित करने में मदद करनी चाहिए। "आज" होने के रूप में एक स्टेट को स्टोर न करें, इसे 00: 00: 00UTC से 23: 59: 59UTC तक स्टोर करें और जब कोई न्यूयॉर्क में आज के आंकड़ों के लिए पूछता है, तो रूपांतरण करें।

Answer 3

जहां तक ​​मैं देख सकता हूं, आप यहां डेटा वेयरहाउस सिस्टम के संग्रहण हिस्से की तलाश में हैं (आपकी रिपोर्ट फ्रंट एंड होगी)।

असल में, जिस तरह से वाणिज्यिक सिस्टम इसे कर रहे हैं, वह कैश है जिसे आपने वर्णित किया है: अपनी टेबल को अलग करें और उनमें से कैश बनाएं। अपने प्रश्नों को तेज करने का एकमात्र तरीका डेटाबेस सिस्टम को उनके लिए कम करना है। इसका मतलब है कम डेटा, जिसका अर्थ है कि सूचकांक में डेटा या कम डेटा को फिर से चलाने में कम समय व्यतीत होता है।

उस ने कहा, मैं या तो "40 कैश समाधान" का प्रस्ताव दूंगा (वास्तव में 24 से अधिक समय क्षेत्र हैं)। आप डेटा की प्रतियां बनाकर सॉर्टिंग कतार को त्रिकोणीय रूप से समानांतर करने में सक्षम होना चाहिए।

ऐसा करने का एक और तरीका, घंटों में घुलनशीलता पर कैश करना होगा और फिर घंटों को समेकित करना होगा (या 30 मिनट यदि आपके टाइमज़ोन को इसकी आवश्यकता हो)। इसका मतलब है कि आप अपने दैनिक कैश की तुलना में एक बेहतर ग्रैन्युलरिटी पर कैश करते हैं लेकिन मूल डेटा की तुलना में एक कोरसर ग्रैन्युलरिटी पर।

Answer 4

इस प्रकार का डेटा आमतौर पर राउंड-रॉबिन या सर्कुलर डेटाबेस का उपयोग करके संग्रहीत किया जाता है। यह http://www.shinguz.ch/MySQL/mysql_20070223.html और यह http://techblog.tilllate.com/2008/06/22/round-robin-data-storage-in-mysql/ यह जानने के लिए कि वे कैसे काम करते हैं और इसे MySQL