RDBMS के बजाय लॉग के लिए फाइल सिस्टम को क्यों पसंद किया जाता है?

44

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

RDMS के लिए हमें सिर्फ SQL क्वेरी लिखनी है और यह काम करेगा जबकि फाइलों के लिए हमें एक विशेष प्रारूप तय करना होगा और फिर regex लिखना होगा या उन्हें हेरफेर करने के लिए पार्सर हो सकता है। और वे भी विशेष परिस्थितियों में विफल हो सकते हैं यदि महान देखभाल का भुगतान नहीं किया गया था।

फिर भी हर कोई लॉग्स को बनाए रखने के लिए फाइल सिस्टम को प्राथमिकता देता है। मैं इनमें से किसी भी तरीके के खिलाफ पक्षपाती नहीं हूं, लेकिन मैं यह जानना चाहूंगा कि ऐसा क्यों किया जाता है। क्या यह गति या स्थिरता या कुछ और है?

— यासिर
स्रोत

10

तो अगर आप लॉगिंग सिस्टम को DB में लॉग करते हैं तो आप DB त्रुटियों (उदाहरण के लिए अनुपलब्ध) कैसे लॉग इन करेंगे?

— मार्जन वेनेमा जूल

17

अगर यह विफल हो जाता है तो मैं कैसे फाइल सिस्टम त्रुटियों को लॉग करूंगा?

— यासिर

5

यह सच है, लेकिन अगर वह विफल रहता है, तो संभावना है कि आपका DB भी दुर्गम है ... आखिरकार, यह कहाँ / कैसे फाइल सिस्टम के बिना इसकी मेज पर लिखेगा?

— मार्जन वेनेमा

2

@ यासिर: फाइलसिस्टम में लॉग इन करने से पहले सभी लॉग संदेशों को एक syslog सर्वर पर भेजें :)

— ब्रायन

1

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

— एंडी

37

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

— user281377
स्रोत

1

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

— जिमीजैम

1

हालांकि, लॉग्स रखने के लिए इन्फ्लेक्सडीबी जैसे टाइम-सीरीज डेटाबेस सिस्टम का उपयोग करने पर विचार किया जा सकता है; यह मुझे लगता है कि यह कार्य के लिए थोड़ा बेहतर है, उदाहरण के लिए, PostgreSQL। फिर भी, पुराने जमाने के लॉगफाइल्स पर फायदा शायद ही हो।

— user281377

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

— जिम्मीजम्स

# 4 वास्तव में कोई समस्या नहीं है। DELETE FROM dbo.Log WHERE LogDate < today minus 2 weeks

— रॉबर्ट हार्वे

@RobertHarvey यह तब तक अच्छी तरह से काम करता है जब तक कि आप इसे एक भारी लोड वाले वातावरण में नहीं आज़माते, जहाँ इस तरह के बल्क ऑपरेशन बिना अतिरिक्त सावधानी के गंभीर समस्या पैदा कर सकते हैं। Redo आपके डिस्क स्थान को भरने में लॉग इन करता है, पूर्ववत बहुत अधिक पूर्ण हो रहा है, प्रतिकृति डिलीट आदि को दोहराने में बहुत व्यस्त हो रहा है

— user281377

16

मैंने पहले डीबी को लिखे गए लॉग देखे हैं (और कभी-कभी आपको लॉगिंग के लिए कॉन्फ़िगर करने योग्य विकल्प मिलते हैं, जहां ट्रेस फ़ाइल में जाता है, डीबी में त्रुटियां होती हैं, विंडोज इवेंट लॉग के लिए वसा)।

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

— gbjbaanb
स्रोत

लेकिन मुझे इसके लिए एक भ्रम है। मेरा नोटपैड, वर्डपैड, जीडिट या नोटपैड ++ या कोई भी वेब-ब्राउज़र आकार में 4GB फ़ाइल खोलने से खुश नहीं होगा। हालांकि, एक ही ब्राउज़र मुझे हजार पृष्ठों की सूची दिखा सकेगा, जिनमें से प्रत्येक में 500 रिकॉर्ड छपे होंगे। सही?

— यासिर

7

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

— नखली

6

@ यासिर: यह सच है, लेकिन आप गलत चीज को अनुकूलित करने की कोशिश कर रहे हैं। अधिकांश समय, लॉग लिखे जाते हैं और कभी नहीं पढ़े जाते हैं। इसलिए आप लॉग का निर्माण बहुत तेजी से करते हैं क्योंकि यह सामान्य मामला है।

— अनहेल्सीपामलर

5

एह, मैंने पहले ही डेटाबेस में लॉगिंग कर ली है और लॉग संदेशों को आसानी से क्वेरी करने में सक्षम होना बेहद फायदेमंद है, खासकर जब हम बग को दोहराने के लिए एक कठिन ट्रैक करने के लिए डीबग स्तर लॉगिंग चालू करते हैं।

— एंडी

2

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

— एंडी

15

गति एक कारण है; अन्य हैं:

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

— tdammers
स्रोत

3

सबसे पहले।

और वे भी विशेष परिस्थितियों में विफल हो सकते हैं यदि महान देखभाल का भुगतान नहीं किया गया था।

जब आप सावधान नहीं होते हैं तो डेटाबेस लेनदेन विफल हो सकता है?

पाठ फ़ाइल में लिखने के कई लाभ हैं, सबसे महत्वपूर्ण है

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

— unholysampler
स्रोत

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

— यासिर

1

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

— अनहेल्स्लेमर

@unholysampler आपका प्रदर्शन तर्क कमजोर है, लॉगिंग बहुत तेजी से और एक डेटाबेस के लिए एक पृष्ठभूमि थ्रेड पर किया जा सकता है, और f के लिए लॉगिंग करते हुए संभावित रूप से तेजी से अभी भी मुक्त नहीं है, खासकर अगर इसकी पृष्ठभूमि में नहीं किया गया है।

— एंडी

2

आप विशेष रूप से अपाचे को बढ़ाते हैं, इसलिए मैं इस पर विस्तार से चर्चा करूंगा।

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

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

(यह मुद्दा अब तय हो सकता है, निश्चित रूप से - यह कई साल पहले था कि मैंने ऐसा किया है)

— जूल्स
स्रोत

1

एक फाइलसिस्टम एक डेटाबेस है। यह वास्तव में एक संबंधपरक DBMS के बजाय एक सरल, श्रेणीबद्ध डेटाबेस है, लेकिन फिर भी यह एक डेटाबेस है।

फ़ाइल सिस्टम में लॉग इन करने का कारण लोकप्रिय है क्योंकि पाठ लॉग यूनिक्स दर्शन के साथ अच्छी तरह से फिट बैठता है: "पाठ सार्वभौमिक इंटरफ़ेस है।"

यूनिक्स ने बहुत सारे सामान्य उद्देश्य उपकरण विकसित किए थे जो पाठ लॉग के साथ अच्छी तरह से काम कर सकते हैं। इससे कोई फर्क नहीं पड़ता कि क्या टेक्स्ट लॉग mysql, अपाचे, आपके कस्टम एप्लिकेशन, थर्ड पार्टी सॉफ्टवेयर द्वारा समर्थित है जो लंबे समय से समर्थन से बाहर है, sysadmin grep, sed, awk, sort, uniq, cut, tail जैसे मानक यूनिक्स टूल का उपयोग कर सकता है , आदि, लॉग के माध्यम से ही सभी को पार करने के लिए।

यदि प्रत्येक ऐप अपने स्वयं के डेटाबेस में प्रवेश करता है, एक MySQL के लिए, दूसरा पोस्टग्रेज के लिए, एक और इलास्टिक्स खोज के लिए, दूसरा ELK में लॉग इन करना चाहता है, दूसरा केवल MongoDB पर लॉग इन कर सकता है, फिर आपको प्रत्येक के लॉग को ट्रॉल करने के लिए बीस विभिन्न टूल सीखना होगा। आवेदन। पाठ एक सार्वभौमिक माध्यम है जिसे हर कोई लॉग इन कर सकता है।

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

डेटाबेस में लॉग इन करना वास्तव में चीजों को व्यवहार में बहुत आसान नहीं बनाता है।

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

— झूठ बोले रेयान
स्रोत

0

आइए इसे कुछ परतों पर देखें:

मशीन की परत
ऑपरेटिंग सिस्टम परत
सेवा परत
अनुप्रयोग परत

संक्षेप में:

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

फिर हमारे पास उपयोग-मामला आधारित दृष्टिकोण है:

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

जब RDBMS को डेटाबेस में नहीं लिखा जा सकता है, तो क्या होता है?

— ojrask
स्रोत

-2

जटिलता। RDBMS को जोड़ने से खगोलीय रूप से पूरे सिस्टम की जटिलता बढ़ जाएगी। और जटिलता का प्रबंधन करने की क्षमता मुख्य चीज है जो प्रोग्रामर को स्रोत कोड उत्पादकों से अलग करती है।

— noonex
स्रोत

1

क्या आप इस बारे में विस्तार कर सकते हैं कि जटिलता के बारे में आपका क्या मतलब है क्योंकि यह डीबी बनाम फाइल सिस्टम में लॉगिंग से संबंधित है? मेरे अनुभव से, कारोबारी माहौल में जटिलता में कोई खास अंतर नहीं आया है।

— एडम जुकरमैन

वास्तव में? SqlLite जटिलता को बढ़ाता है खगोलीय? और जबकि एक वेब सर्वर को आम तौर पर डीबी की आवश्यकता नहीं होती है, कई एलओबी ऐप पहले से ही एक का उपयोग कर रहे हैं, इसलिए वहां कोई अतिरिक्त लागत नहीं है।

— एंडी

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

— noonex

@ सबसे पहले, SQLite क्लासिक शॉन में RDBMS नहीं है - यह "एम्बेडेड RDBMS" है। और हाँ - लॉगिंग के लिए SQLite की आवश्यकता से जटिलता बहुत बढ़ जाएगी।

— noonex

1

जब आप RDBMS नहीं करता है, तो आप केवल पूर्ण बनाम सर्वर के बीच अंतर कर रहे हैं। SqlLite ACID अनुपालन प्रदान करता है, जो वास्तव में RDBMS के बारे में है। और इससे जटिलता बहुत बढ़ जाती है? मैं केवल कल्पना कर सकता हूं कि आपने कुछ भी नहीं किया है, लेकिन अनुप्रयोगों का सबसे तुच्छ। अंत में, अच्छी नौकरी पूरी तरह से कई LOB अनुप्रयोगों के बारे में मेरी बात को पूरी तरह से अनदेखा कर रही है जो पहले से ही एक डेटाबेस की जरूरत थी।

— एंडी

-4

क्या यह गति या स्थिरता या कुछ और है?

स्पीड।

— S.Lott
स्रोत