2009-06-24 11 views
10

मेरे पास एक प्रणाली है जो विभिन्न स्थानों से http (> 10k उत्पादक, प्रति दिन 10 लॉग, ~ प्रत्येक पाठ की 100 पंक्तियों) के माध्यम से लॉग फ़ाइलों को प्राप्त कर रही है।कई लॉग फ़ाइलों का संग्रहण

मैं उन्हें विविध गणना करने में सक्षम होने के लिए स्टोर करना चाहता हूं। उन पर आंकड़े रात में, उन्हें निर्यात (आगमन की तारीख या पहली पंक्ति सामग्री द्वारा आदेश दिया गया) ...

मेरा सवाल है: उन्हें स्टोर करने का सबसे अच्छा तरीका क्या है?

  • फ्लैट पाठ फ़ाइलों (उचित ताला के साथ), अपलोड की गई फ़ाइल प्रति एक फ़ाइल, प्रति दिन एक निर्देशिका/निर्माता
  • फ्लैट पाठ फ़ाइलें, एक (बड़ा) सभी उत्पादकों के लिए प्रति दिन फ़ाइल (समस्या यहाँ अनुक्रमण हो जाएगा और लॉकिंग)
  • पाठ के साथ डेटाबेस तालिका (MySQL आंतरिक कारणों से पसंद किया जाता है) (के रूप में बहुत लंबी हो सकती है को नष्ट डीबी पर्ज साथ पंजाब!)
  • sharding साथ
  • डाटाबेस प्रति पाठ की पंक्ति एक रिकॉर्ड (साथ डाटाबेस टेबल प्रति दिन एक टेबल), सरल डेटा शुद्ध करने की इजाजत देता है। (यह विभाजन है। हालांकि mysql के संस्करण के पास (यानी आंतरिक रूप से समर्थित) का उपयोग नहीं है)
  • दस्तावेज़ आधारित डीबी à la couchdb या mongodb (समस्या इंडेक्सिंग/परिपक्वता/इंजेक्शन की गति के साथ हो सकती है)

कोई सलाह?

+1

यह एक sys-admin प्रश्न है, जिसका अर्थ यह है कि यह बहन साइट "सर्वर फॉल्ट" serverfault.com – tylerl

+2

पर है, वास्तव में, जो मैं पूछ रहा हूं उसका उत्तर विकास पर भारी प्रभाव डालता है – makapuf

उत्तर

4

मैं पहला समाधान चुनूंगा।

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

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

2

मैं प्रति अपलोड एक फ़ाइल लिखूंगा, और एक निर्देशिका/दिन जैसा आपने पहली बार सुझाया था। दिन के अंत में, फ़ाइलों पर अपनी प्रसंस्करण चलाएं, और फिर tar.bz2 निर्देशिका।

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

कुल डेटा के लिए, आप एक दिन में लगभग 1 जीबी [सही 10MB] असम्पीडित बात कर रहे हैं। यह संभवतः 100 एमबी या उससे कम तक संपीड़ित होगा। मैंने bzip2 के साथ अपनी लॉग फ़ाइलों पर 200x संपीड़न देखा है। आप बिना किसी चिंता के वर्षों तक संकुचित डेटा को फाइल सिस्टम पर आसानी से स्टोर कर सकते हैं। अतिरिक्त प्रसंस्करण के लिए आप स्क्रिप्ट लिख सकते हैं जो संपीड़ित टैरबॉल खोज सकते हैं और अधिक आंकड़े उत्पन्न कर सकते हैं।

+0

"आप बात कर रहे हैं दिन में लगभग 10 एमबी असंपीड़ित " नहीं, यह प्रति दिन 10 एम लाइन (10k उपयोगकर्ता * 10files * 100lines) है। यदि कोई पंक्ति है, तो 100 बाइट्स कहें, यह 1 जीबी/दिन – makapuf

0

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

+0

धन्यवाद है, लेकिन विचार यह है कि टेबल को एक साथ जोड़ा नहीं जाएगा, उदाहरण के लिए उत्पादन दिवस द्वारा sharding। इसलिए इसे लिखना केवल एक टेबल को संशोधित करेगा। और दिन को हटाने से टेबल छोड़ने के रूप में लागू किया जाएगा। – makapuf

+0

मैं आपका समाधान जांचूंगा। – makapuf

1

चूंकि आप उन्हें विविध गणना करने में सक्षम होने के लिए स्टोर करना चाहते हैं। उन पर आंकड़े हर रात को, उन्हें निर्यात ... आप 100,000 उम्मीद कर रहे हैं एक दिन फ़ाइलें, (आगमन या पहली पंक्ति सामग्री की तिथि के अनुसार क्रमबद्ध) 10,000,000 लाइनों की कुल पर:

मेरा सुझाव चाहते हैं:

  1. निम्न प्रारूपों का उपयोग करके सभी फ़ाइलों को नियमित टेक्स्टफाइल के रूप में स्टोर करें: yyyymmdd/producerid/fileno।
  2. दिन के अंत में, डेटाबेस डेटाबेस साफ़ करें, और दिन के लिए सभी टेक्स्टफाइल लोड करें।
  3. फ़ाइलों को लोड करने के बाद, डेटाबेस से आंकड़े प्राप्त करना आसान होगा, और किसी भी प्रारूप में उन्हें पोस्ट करना आसान होगा। (शायद एक और "आँकड़े" डेटाबेस)। आप ग्राफ उत्पन्न भी कर सकते हैं।
  4. स्थान बचाने के लिए, आप दैनिक फ़ोल्डर को संपीड़ित कर सकते हैं। चूंकि वे टेक्स्टफाइल हैं, वे अच्छी तरह से संपीड़ित होंगे।

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

8

(अस्वीकरण:। मैं MongoDB पर काम)

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

जहां तक ​​स्थिरता चलती है, बहुत से लोग पहले से ही उत्पादन में मोंगोडीबी का उपयोग कर रहे हैं (http://www.mongodb.org/display/DOCS/Production+Deployments देखें)। 1.0 में जाने से पहले हमारे पास कुछ और सुविधाएं हैं जिन्हें हम जोड़ना चाहते हैं।

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