2017-06-12 41 views
12

पर वर्तमान में मेरे पास Google क्लाउड प्लेटफ़ॉर्म पर होस्ट किया गया एक एप्लिकेशन है जो वेब एनालिटिक्स प्रदान करता है और सत्र गतिविधि (क्लिक, डाउनलोड इत्यादि) प्रदान करता है और वेब पंजीकरण के साथ उस वेब गतिविधि से संबंध रखता है।रिलेशनल डेटाबेस से बिग डेटा

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

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

User table 
- id 
- name 
- email 

Profile table (web browser/device) 
- id 
- user id 
- user agent string 

Session table 
- id 
- profile id 
- session string 

Action table 
- id 
- session id 
- action type 
- action details 
- timestamp 

अपना शोध के आधार पर, क्या सबसे अच्छा समाधान होगा की मेरी समझ की तरह एक NoSQL डेटाबेस समाधान में दुकान कार्रवाई के आंकड़ों के होगा:

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

मेरा सवाल है, क्या इन उपकरणों को सही तरीके से लागू करने की मेरी समझ है? या क्या बेहतर समाधान हैं? क्या MySQL से दूर जाने पर विचार करना भी आवश्यक है? और यदि नहीं, तो किस प्रकार के समाधान उपलब्ध हैं जो हमें पृष्ठभूमि में रिपोर्टिंग डेटा को पूर्व-प्रक्रिया/उत्पन्न करने की अनुमति देगा?

+0

क्या सत्र और क्रिया तालिका मान अपडेट किए गए हैं? मेरा मतलब है कि वे केवल इन प्रविष्टियां हैं या क्या अपडेट भी हैं? –

+0

सत्र तालिका को क्रोनबॉज के माध्यम से अपडेट किया जाता है जो सत्र डेटा में प्रति सत्र एक्शन-गिनती जैसे कुछ डेटा एकत्र करता है, हालांकि, क्रियाएं केवल सम्मिलित होती हैं। –

+0

आप MySQL में एक अस्थायी सत्र तालिका रख सकते हैं और एक बार सत्र समाप्त होने के बाद या दिन के अंत में इसे सभी BigQuery में डंप कर सकते हैं। –

उत्तर

6

मानते हैं कि sessions और actions तालिका मान अपडेट नहीं किए गए हैं और केवल सम्मिलित हैं। सबसे अच्छा तरीका डेटाबेस को दो हिस्सों में अलग करना होगा। user और profile तालिकाओं के लिए MySQL DB रखें और actions और sessions के लिए BigQuery का उपयोग करें।

इस तरह आप निम्नलिखित है:

  • आप दोनों ओर (डेटा ग्रहण करने और निकासी)
  • आप काफी डाटा भंडारण की लागत कम हो जाएगा पर क्या करना है परिवर्तन की मात्रा को कम
  • क्वेरी टाइम्स में
  • इससे पहले कि आप इसे जानते हों, आप बड़े डेटा क्षेत्र में होंगे और BigQuery केवल

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

+1

शीर्ष पर चेरी: आप तिथि पर अपनी BigQuery तालिकाओं को विभाजित कर सकते हैं और लंबी अवधि के भंडारण के साथ-साथ रोजमर्रा की प्रश्नों को कम कर सकते हैं। –

3

सवालों की एक जोड़ी/संभावित समाधानों:

  1. प्रोफाइल! यदि यह डेटाबेस को थ्रैश करने के समान प्रश्न हैं, तो अपने प्रश्नों को अनुकूलित करना या अपने सबसे लगातार पृष्ठों के लिए कुछ परिणामों को कैशिंग करना ऑफ़लोड प्रसंस्करण में सहायता कर सकता है। डेटाबेस सेटिंग्स, राम के लिए डिट्टो, आदि
  2. कितना बड़ा अपने डेटाबेस है?यदि यह 64 जीबी से कम है, तो एक बड़े सर्वर तक स्केलिंग जहां डेटाबेस रैम में फिट हो सकता है, एक त्वरित जीत हो सकती है।
  3. आपके डेटा का उपयोग कैसे किया जा रहा है? यदि यह पूरी तरह से ऐतिहासिक डेटा के लिए है, तो आप संभावित रूप से अपने क्लिक को लुकअप टेबल में कम कर सकते हैं, उदाहरण के लिए। प्रति सप्ताह प्रति सत्र या प्रति सप्ताह प्रति उपयोगकर्ता कार्रवाई। यदि डेटा प्रति 5 मिनट/घंटे के साथ एकत्रित किया जाता है, तो कच्चे डेटा को डाउनलोड करना और इसे स्थानीय रूप से प्रोसेस करना भी काम कर सकता है।
  4. आप denormalise, उदाहरण के लिए कर सकते हैं। उपयोगकर्ता एजेंट | सत्र | क्रिया प्रकार | विवरण | एक पंक्ति में टाइमस्टैम्प गठबंधन करें, लेकिन आप संभावित रूप से अपनी संग्रहण आवश्यकताओं और लुकअप समय को बढ़ाते हैं।
  5. वैकल्पिक रूप से, अधिक सामान्यीकरण भी मदद कर सकता है। उपयोगकर्ता एजेंट स्ट्रिंग को अपनी तालिका में तोड़कर उस तालिका की डेटा आवश्यकताएं कम हो जाएंगी और चीजों को गति दे सकती है।
  6. ऐसा लगता है जैसे आपका डेटा उपयोगकर्ता द्वारा विभाजित/शेड किया जा सकता है, ताकि यह एक और विकल्प हो।

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

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

+0

1. अनुकूलन एक सतत संघर्ष रहा है क्योंकि हमारी मुख्य परफ-हत्या क्वेरी लगभग 100 लाइनों की एसक्यूएल है और बहुत जटिल 2. वर्तमान में यह 64 जीबी से कम है, और हम स्केलिंग कर रहे हैं, लेकिन यह अस्थायी समाधान जैसा लगता है 3।डेटा को लिखने के रूप में लिखना और रिपोर्ट बनाना 4-5। संभवतः, मुझे लगता है कि डेटा भंडारण के बजाय समस्या एकत्रीकरण में निहित है 6. शेर्डिंग काम कर सकती है, लेकिन उस मामले में एकत्रीकरण प्रश्नों का क्या होगा? –

+0

1. 100 लाइनें बहुत बड़ी लगती हैं, निश्चित रूप से इसे पहले सरल बनाने/कैशिंग करने का प्रयास करें। 2. यदि आप स्केलिंग कर रहे हैं, तो अधिकांश चीजें अस्थायी समाधान हैं। अतिरिक्त रैम आपको अधिक समय खरीद सकता है और आपको कूल्हे पर ले जा सकता है। 3. समय से पहले उन रिपोर्टों (या उनमें से कुछ हिस्सों) को उत्पन्न/संग्रहित करने में मदद मिल सकती है। 4,5। भंडारण "घनत्व" होता है तो एकत्रीकरण तेजी से हो सकता है 6. सबसे अच्छा मामला, आपका वर्कलोड एन द्वारा विभाजित किया गया है। हालांकि, अभ्यास में इसे हासिल करने के लिए आपको भारी उपयोगकर्ताओं को मैन्युअल रूप से फैलाने की आवश्यकता हो सकती है। –

0

यदि व्यावहारिक है, तो बड़ी मात्रा में डेटा स्टोर न करें!

इसके बजाय, आंकड़ों के सारांश के रूप में सारांश (कुल) सारांश सारांशित करें, फिर सारांश संग्रहित करें।

लाभ:

  • शायद दसवां के रूप में ज्यादा डिस्क स्थान की आवश्यकता थी;
  • रिपोर्ट शायद 10 गुना तेज है,
  • मौजूदा आरडीबीएमएस में किया जा सकता है।

नुकसान:

  • आप एक अलग संक्षिप्तीकरण पुनः स्थापित नहीं कर सकते। (ठीक है, आप कच्चे डेटा को रख सकते हैं और शुरू कर सकते हैं; यह वैसे भी बेहतर हो सकता है।)
  • अधिक कोड जटिलता।

Discussion सारांश सारणी के।

संबंधित मुद्दे