ทำไมไฟล์บันทึกส่วนใหญ่จึงใช้ข้อความธรรมดามากกว่ารูปแบบไบนารี่

การบันทึกเป็นสิ่งที่จำเป็น แต่ไม่ค่อยมีการใช้ (ค่อนข้าง) ด้วยเหตุนี้จึงสามารถทำให้มีขนาดเล็กลงได้มากขึ้นในแง่ของการจัดเก็บ

ตัวอย่างเช่นข้อมูลที่บันทึกบ่อยที่สุดเช่น ip, วันที่, เวลาและข้อมูลอื่น ๆ ที่สามารถแสดงเป็นจำนวนเต็มจะถูกเก็บไว้เป็นข้อความ

หากการบันทึกถูกเก็บไว้เป็นข้อมูลไบนารีพื้นที่จำนวนมากสามารถรักษาไว้ได้ดังนั้นจึงต้องใช้การหมุนน้อยลงและเพิ่มอายุการใช้งานดิสก์โดยเฉพาะกับ SSD ที่การเขียน จำกัด

บางคนอาจบอกว่ามันเป็นปัญหาเล็กน้อยที่ไม่สำคัญ แต่เมื่อคำนึงถึงความพยายามที่จำเป็นในการสร้างกลไกดังกล่าว ทุกคนสามารถทำสิ่งนี้ได้เหมือนสองวันในเวลาว่างทำไมคนไม่ทำเช่นนี้?

systemdจัดเก็บไฟล์บันทึกที่มีชื่อเสียงในรูปแบบไบนารี ประเด็นหลักที่ฉันเคยได้ยินคือ:

1. หากบันทึกเกิดความเสียหายการกู้คืนยากเนื่องจากต้องใช้เครื่องมือพิเศษ
2. พวกมันไม่ใช่มนุษย์ที่อ่านได้ดังนั้นคุณไม่สามารถใช้เครื่องมือมาตรฐานเช่นvi, grepและtailอื่น ๆ ในการวิเคราะห์ได้

เหตุผลหลักสำหรับการใช้รูปแบบไบนารี (เพื่อความรู้ของฉัน) ก็คือมันถือว่าง่ายขึ้นสำหรับการสร้างดัชนี ฯลฯ คือการรักษามันเหมือนไฟล์ฐานข้อมูล

ฉันจะยืนยันว่าประโยชน์จากพื้นที่ดิสก์มีขนาดค่อนข้างเล็ก (และลดลง) ในทางปฏิบัติ หากคุณต้องการจัดเก็บการบันทึกจำนวนมากการบันทึกการรีดซิปจะมีประสิทธิภาพมากจริงๆ

ในเรื่องของความสมดุลข้อดีของการใช้เครื่องมือและความคุ้นเคยอาจจะผิดพลาดในด้านของการบันทึกข้อความในกรณีส่วนใหญ่

ทำไมไฟล์บันทึกส่วนใหญ่จึงใช้ข้อความธรรมดามากกว่ารูปแบบไบนารี่

ค้นหาคำว่า "ข้อความ" ในบทความของปรัชญาของ Unixเช่นคุณจะพบข้อความที่ชอบ:

McIlroy จากนั้นหัวหน้า Bell Labs CSRC (ศูนย์วิจัยวิทยาศาสตร์คอมพิวเตอร์) และนักประดิษฐ์ของ Unix pipe, [9] สรุปปรัชญา Unix ดังนี้: [10]

นี่คือปรัชญา Unix: เขียนโปรแกรมที่ทำสิ่งหนึ่งและทำได้ดี เขียนโปรแกรมเพื่อทำงานร่วมกัน เขียนโปรแกรมเพื่อจัดการสตรีมข้อความเนื่องจากเป็นอินเตอร์เฟสสากล

หรือตัวอย่างเช่นจากพื้นฐานของปรัชญา Unix ,

Rule of Composition: โปรแกรมการออกแบบที่จะเชื่อมต่อกับโปรแกรมอื่น ๆ

เป็นการยากที่จะหลีกเลี่ยงการเขียนโปรแกรม monoliths ที่ซับซ้อนหากไม่มีโปรแกรมใดที่คุณสามารถพูดคุยกันได้

ประเพณี Unix สนับสนุนอย่างยิ่งให้การเขียนโปรแกรมที่อ่านและเขียนรูปแบบที่เรียบง่ายเป็นข้อความการส่งกระแสข้อมูลที่ไม่ขึ้นกับอุปกรณ์ ภายใต้ Unix แบบคลาสสิกโปรแกรมจำนวนมากที่สุดเท่าที่เป็นไปได้จะถูกเขียนเป็นตัวกรองแบบง่ายซึ่งใช้สตรีมข้อความแบบง่ายในการป้อนข้อมูล

แม้จะมีเทพนิยายที่เป็นที่นิยม แต่การปฏิบัติเช่นนี้ไม่ได้รับความนิยมเนื่องจากโปรแกรมเมอร์ Unix เกลียดส่วนต่อประสานกราฟิกผู้ใช้ เป็นเพราะถ้าคุณไม่ได้เขียนโปรแกรมที่ยอมรับและปล่อยกระแสข้อความธรรมดามันยากมากที่จะขอให้โปรแกรมเข้าด้วยกัน

สตรีมข้อความสำหรับเครื่องมือ Unix เนื่องจากข้อความเป็นวัตถุในการตั้งค่าวัตถุ ความเรียบง่ายของอินเตอร์เฟซสตรีมข้อความบังคับใช้การห่อหุ้มเครื่องมือ รูปแบบที่ซับซ้อนมากขึ้นของการสื่อสารระหว่างกระบวนการเช่นการเรียกขั้นตอนระยะไกลแสดงแนวโน้มที่จะเกี่ยวข้องกับโปรแกรมกับคนอื่น ๆ ภายในมากเกินไป

ทุกคนสามารถทำสิ่งนี้ได้เหมือนสองวันในเวลาว่างทำไมคนไม่ทำเช่นนี้?

การจัดเก็บไฟล์บันทึกในไบนารีเป็นเพียงการเริ่มต้น (และไม่สำคัญ) จากนั้นคุณต้องเขียนเครื่องมือเพื่อ:

• แสดงไฟล์บันทึกทั้งหมด ( edit)
• แสดงในตอนท้ายของการเข้าสู่ระบบโดยไม่ต้องอ่านจุดเริ่มต้นของมัน ( tail -f)
• ค้นหาเนื้อหาในไฟล์ ( grep)
• ตัวกรองเพื่อแสดงเฉพาะสิ่งที่เลือก / น่าสนใจ (ใช้นิพจน์ตัวกรองที่ซับซ้อนโดยพลการ)
• ส่งอีเมลบันทึกไปยังบุคคลอื่นที่ไม่มีไฟล์บันทึก - ถอดรหัส - ซอฟต์แวร์ของคุณ
• คัดลอกและวางส่วนของไฟล์บันทึก
• อ่านไฟล์บันทึกในขณะที่โปรแกรม (ซึ่งสร้างไฟล์บันทึก) ยังคงได้รับการพัฒนาและดีบั๊ก
• อ่านไฟล์บันทึกจากซอฟต์แวร์เวอร์ชันเก่า (ซึ่งถูกปรับใช้บนไซต์ลูกค้าและใช้งาน)

แน่นอนซอฟต์แวร์และไม่สามารถใช้รูปแบบไฟล์ไบนารีเกินไป (เช่นฐานข้อมูลเชิงสัมพันธ์) แต่มันไม่คุ้มค่า (ในYAGNIความรู้สึก) มักจะไม่คุ้มค่าทำไฟล์บันทึก

มีข้อสันนิษฐานที่ถกเถียงมากมายที่นี่

การบันทึกเป็นส่วนสำคัญของงานเกือบทุกงานที่ฉันมี มันเป็นสิ่งสำคัญหากคุณต้องการทัศนวิสัยที่ดีต่อแอพพลิเคชั่นของคุณ ฉันสงสัยว่ามันคือการใช้ "ขอบ"; องค์กรส่วนใหญ่ที่ฉันเคยเกี่ยวข้องกับบันทึกการพิจารณามีความสำคัญมาก

การจัดเก็บบันทึกเป็นแบบไบนารี่หมายความว่าคุณต้องถอดรหัสก่อนที่จะสามารถอ่านได้ บันทึกข้อความมีความเรียบง่ายและใช้งานง่าย หากคุณใคร่ครวญเส้นทางไบนารีคุณอาจเก็บบันทึกไว้ในฐานข้อมูลแทนซึ่งคุณสามารถซักถามพวกเขาและวิเคราะห์สถิติได้

SSD มีความน่าเชื่อถือมากกว่า HDD ในปัจจุบันและข้อโต้แย้งจากการเขียนจำนวนมากส่วนใหญ่มักสงสัย หากคุณเป็นกังวลเกี่ยวกับเรื่องนี้ให้จัดเก็บบันทึกของคุณบน HDD ธรรมดา

ไฟล์บันทึกเป็นส่วนสำคัญของแอปพลิเคชันที่ร้ายแรงใด ๆ : หากการบันทึกในแอพนั้นดีใด ๆ พวกเขาจะให้คุณเห็นเหตุการณ์สำคัญที่เกิดขึ้นและเมื่อใด; เกิดข้อผิดพลาดอะไรขึ้น และสุขภาพทั่วไปของแอปพลิเคชันที่เหนือกว่าการตรวจสอบใด ๆ ที่ได้รับการออกแบบมาเป็นเรื่องปกติที่จะได้ยินปัญหาตรวจสอบการวินิจฉัยในตัวของแอปพลิเคชัน (ปรากฏขึ้นเปิดเว็บคอนโซลหรือใช้เครื่องมือวินิจฉัยเช่น JMX) ล็อกไฟล์

หากคุณใช้รูปแบบที่ไม่ใช่ข้อความคุณจะต้องเผชิญกับสิ่งกีดขวางทันที: คุณจะอ่านบันทึกไบนารีได้อย่างไร ด้วยเครื่องมืออ่านบันทึกซึ่งไม่ได้อยู่ในเซิร์ฟเวอร์การผลิตของคุณ! หรือมันเป็น แต่ที่รักเราได้เพิ่มเขตข้อมูลใหม่และนี่คือผู้อ่านเก่า เราไม่ได้ทดสอบสิ่งนี้ใช่ไหม ใช่ แต่ไม่มีใครปรับใช้ที่นี่ ในขณะเดียวกันหน้าจอของคุณเริ่มสว่างขึ้นกับผู้ใช้ที่ส่งเสียงคุณ

หรือบางทีนี่อาจไม่ใช่แอปของคุณ แต่คุณสนับสนุนและคิดว่าคุณรู้ว่านี่เป็นระบบอื่นและ WTF หรือไม่ บันทึกอยู่ในรูปแบบไบนารีหรือไม่ ตกลงเริ่มอ่านหน้า wiki และคุณเริ่มต้นที่ไหน ตอนนี้ฉันได้คัดลอกมันไปยังเครื่องท้องถิ่นของฉันแล้ว แต่ - พวกมันเสียหายหรือไม่ ฉันได้ทำการถ่ายโอนที่ไม่ใช่ไบนารีแล้วหรือยัง? หรือเครื่องมืออ่านบันทึกทำผิดพลาดหรือไม่

กล่าวโดยย่อเครื่องมืออ่านข้อความเป็นแบบข้ามแพลตฟอร์มและแพร่หลายและบันทึกมักมีอายุการใช้งานยาวนานและบางครั้งจำเป็นต้องอ่านอย่างรวดเร็ว หากคุณคิดค้นรูปแบบไบนารี่คุณก็จะถูกตัดขาดจากโลกที่เต็มไปด้วยเครื่องมือที่เข้าใจและใช้งานง่าย การสูญเสียการทำงานอย่างจริงจังเมื่อคุณต้องการ

สภาพแวดล้อมการบันทึกส่วนใหญ่มีการประนีประนอม: ทำให้บันทึกปัจจุบันสามารถอ่านได้และนำเสนอและบีบอัดบันทึกที่เก่ากว่า นั่นหมายความว่าคุณได้รับประโยชน์จากการบีบอัด - ยิ่งกว่านั้นจริงๆแล้วเนื่องจากรูปแบบไบนารีจะไม่ลดขนาดข้อความบันทึก ในเวลาเดียวกันคุณสามารถใช้งานน้อยลงและgrepและอื่น ๆ

ดังนั้นสิ่งที่เป็นไปได้ผลประโยชน์ที่อาจเกิดขึ้นจากการใช้ไบนารี? ประสิทธิภาพพื้นที่เพียงเล็กน้อย - ไม่สำคัญมากขึ้น เขียนน้อยลง (หรือเล็กกว่า)? ที่จริงแล้วจำนวนของการเขียนจะเกี่ยวข้องกับจำนวนของดิสก์ที่คอมมิตดังนั้นหากเส้นบันทึกมีขนาดเล็กกว่าดิสก์บล็อคขนาดใหญ่อย่างมีนัยสำคัญ SSD จะกำหนดบล็อกใหม่ซ้ำแล้วซ้ำอีก ดังนั้นไบนารีเป็นตัวเลือกที่เหมาะสมหาก:

• คุณกำลังเขียนข้อมูลที่มีโครงสร้างจำนวนมาก
• ต้องสร้างบันทึกอย่างรวดเร็วเป็นพิเศษ
• คุณไม่จำเป็นต้องวิเคราะห์พวกเขาภายใต้ "เงื่อนไขการสนับสนุน"

แต่นี่จะฟังดูน้อยลงเช่นการบันทึกแอปพลิเคชัน นี่คือไฟล์เอาต์พุตหรือบันทึกกิจกรรม การวางไว้ในไฟล์อาจเป็นเพียงขั้นตอนเดียวจากการเขียนลงในฐานข้อมูล

แก้ไข

ฉันคิดว่ามีความสับสนทั่วไปที่นี่ระหว่าง "บันทึกโปรแกรม" (ตามกรอบการบันทึก) เทียบกับ "บันทึก" (เช่นในบันทึกการเข้าถึงบันทึกการเข้าสู่ระบบและอื่น ๆ ) ฉันสงสัยว่าคำถามนั้นเกี่ยวข้องอย่างใกล้ชิดที่สุดกับเรื่องหลังและในกรณีนี้ปัญหาก็มีความชัดเจนน้อยกว่ามาก เป็นที่ยอมรับอย่างสมบูรณ์สำหรับบันทึกข้อความหรือบันทึกกิจกรรมในรูปแบบกะทัดรัดโดยเฉพาะอย่างยิ่งเนื่องจากมีแนวโน้มที่จะได้รับการกำหนดและใช้ในการวิเคราะห์มากกว่าการแก้ไขปัญหา เครื่องมือที่ทำนี้รวมและระบบตรวจสอบระบบปฏิบัติการยูนิกซ์tcpdump sarโปรแกรมบันทึกในทางกลับกันมักจะมีมากขึ้นเฉพาะกิจ

ตัวอย่างของการบันทึกไบนารีค่อนข้างกว้าง: บันทึกเหตุการณ์ของ Windows ในด้านมืออาชีพสิ่งนี้จะช่วยให้ข้อความบันทึกค่อนข้างใช้คำ (และหวังว่าจะเป็นประโยชน์) โดยแทบไม่มีค่าใช้จ่าย

คำเตือน: คิวของ foobars ที่ต้องเพิ่มขึ้น 517 รายการใน 90 วินาทีที่ผ่านมา หากเกิดขึ้นประมาณวันละครั้งก็ไม่มีอะไรต้องกังวล หากมันเกิดขึ้นบ่อยครั้งหรืออย่างต่อเนื่องคุณอาจต้องการตรวจสอบจำนวน RAM ที่มีให้กับแอพพลิเคชั่น foobar หากเกิดขึ้นพร้อมกับเหตุการณ์ 12345 ดูเหมือนว่าคุณกำลังใช้ฐานข้อมูลที่ล้าสมัยและคุณควรโทรติดต่อฝ่ายสนับสนุนที่ + 1-555-12345 เพื่อป้องกันข้อมูลสูญหาย

ส่วนหลักของข้อความนี้มีอยู่เพียงครั้งเดียวเป็นทรัพยากรที่ติดตั้งกับแอปพลิเคชัน อย่างไรก็ตามหากทรัพยากรนี้ไม่ได้รับการติดตั้งอย่างถูกต้อง (เช่นเนื่องจากมีการติดตั้งเวอร์ชันที่ใหม่กว่าซึ่งไม่รองรับข้อความล้าสมัยนี้) สิ่งที่คุณเห็นในบันทึกเหตุการณ์คือข้อความมาตรฐานที่เป็นเพียงถ้อยคำที่แฟนซี

Dunno บางอย่างด้วย "517" และ "90"

และไม่มีประโยชน์อีกต่อไป แต่อย่างใด

คำถามหลักสองข้อที่คุณต้องการถามก่อนเลือกระหว่างข้อความและไบนารีคือ:

• ผู้ชมของฉันคือใคร
• ฉันต้องการถ่ายทอดเนื้อหาอะไรบ้าง

ความคิดเห็นทั่วไปคือผู้ชมข้อความบันทึกเป็นมนุษย์ เห็นได้ชัดว่าไม่ใช่ข้อสันนิษฐานที่สมบูรณ์แบบเพราะมีสคริปต์การตระเวนบันทึกจำนวนมากอยู่ที่นั่น แต่เป็นเรื่องธรรมดา ในกรณีนี้มันเหมาะสมที่จะสื่อข้อมูลในสื่อที่มนุษย์รู้สึกสบายใจ ข้อความมีประเพณีอันยาวนานของการเป็นสื่อนี้

สำหรับเนื้อหาพิจารณาว่าไฟล์บันทึกไบนารีต้องมีรูปแบบที่กำหนดไว้อย่างดี รูปแบบต้องถูกกำหนดไว้อย่างดีพอที่คนอื่นจะเขียนซอฟต์แวร์ที่ทำงานบนบันทึกเหล่านั้น บันทึกบางส่วนมีโครงสร้างค่อนข้างดี (คำถามของคุณมีหลายรายการ) บันทึกอื่น ๆ ต้องการความสามารถในการถ่ายทอดเนื้อหาในรูปแบบภาษาธรรมชาติที่กำหนดไว้ไม่ดี กรณีภาษาธรรมชาติดังกล่าวมีการจับคู่ที่ไม่ดีสำหรับรูปแบบไบนารี

สำหรับบันทึกที่สามารถอธิบายได้ดีในไบนารีคุณต้องเลือก เนื่องจากข้อความใช้งานได้กับทุกคนจึงมักถูกมองว่าเป็นตัวเลือกเริ่มต้น หากคุณบันทึกผลลัพธ์เป็นข้อความผู้อื่นสามารถทำงานกับบันทึกของคุณได้ มันได้รับการพิสูจน์แล้วหลายพันครั้ง ไฟล์ไบนารีมีเล่ห์เหลี่ยม ดังนั้นอาจเป็นเพราะนักพัฒนาส่งข้อความออกมาเพียงเพราะทุกคนรู้ว่าสิ่งที่กำลังทำอยู่นั้นเป็นเช่นไร

TL; DR: ขนาดไม่สำคัญจริงๆ แต่ใช้งานได้สะดวก

ก่อนอื่นในขณะที่การเปรียบเทียบข้อได้เปรียบของข้อความและรูปแบบไบนารีสำหรับการจัดเก็บบันทึกระยะสั้นเป็นคำถามที่สำคัญขนาดไม่สำคัญจริงๆ เหตุผลสองประการคือ:

1. บันทึกเป็นข้อมูลซ้ำซ้อนสูงที่จะบีบอัดได้ดีมาก: จากประสบการณ์ของฉันมันไม่ยากที่จะเห็นไฟล์บันทึกที่ถูกบีบอัดซึ่งมีขนาด 5% หรือน้อยกว่าขนาดของไฟล์ต้นฉบับ ดังนั้นการใช้ข้อความหรือรูปแบบไบนารีไม่ควรมีผลกระทบใด ๆ ที่วัดได้ในการจัดเก็บบันทึกเป็นเวลานาน

2. รูปแบบใดก็ตามที่เราเลือกบันทึกจะเติมดิสก์เซิร์ฟเวอร์อย่างรวดเร็วหากเราไม่ใช้“ ล็อกไฟล์เก็บข้อมูล” ที่บีบอัดและส่งไฟล์บันทึกไปยังแพลตฟอร์มจัดเก็บข้อมูลระยะยาว การใช้รูปแบบไบนารี่อาจทำให้บิตช้าลง แต่ถึงแม้การเปลี่ยนแปลงโดยปัจจัย 10 จะไม่สำคัญเท่าไร

ข้อความเทียบกับรูปแบบบันทึกไบนารี

คำสัญญาของระบบ Unix คือถ้าเราเรียนรู้การใช้ชุดเครื่องมือมาตรฐานที่ทำงานกับไฟล์ข้อความที่มีโครงสร้างในบรรทัดเช่นgrep , sort , join , sed , awkและawk - เราจะสามารถใช้พวกมันประกอบต้นแบบอย่างรวดเร็วในการทำงานใด ๆ เราต้องการแม้ว่าจะช้าและหยาบ เมื่อต้นแบบได้แสดงให้เห็นถึงประโยชน์ของมันแล้วเราสามารถเลือกที่จะทำให้มันเป็นซอฟต์แวร์ที่ออกแบบมาเพื่อเพิ่มประสิทธิภาพหรือเพิ่มคุณสมบัติที่มีประโยชน์อื่น ๆ อย่างน้อยที่สุดในความเข้าใจของฉันนี่คือสาระสำคัญของปรัชญา Unix

ถ้าหากเราต้องทำการรักษาและวิเคราะห์เราไม่สามารถคิดออกได้ในวันนี้ถ้าเราไม่รู้ว่าใครควรนำการวิเคราะห์นี้ไปใช้เป็นต้นเราก็อยู่ในขั้นที่จะใช้ต้นแบบและรูปแบบข้อความสำหรับ บันทึกอาจเหมาะสมที่สุด หากเราจำเป็นต้องทำการรักษาที่ได้รับการระบุเป็นอย่างดีซ้ำ ๆ กันเราอยู่ในสถานการณ์ที่เราควรสร้างระบบซอฟต์แวร์ตลอดกาลเพื่อดำเนินการวิเคราะห์และรูปแบบไบนารีหรือโครงสร้างสำหรับบันทึกเช่นฐานข้อมูลเชิงสัมพันธ์ซึ่งน่าจะเป็น ดีที่สุด

(บางเวลาที่ผ่านมาฉันเขียนบล็อกโพสต์เกี่ยวกับเรื่องนี้)

ไฟล์บันทึกอยู่ในรูปแบบข้อความเนื่องจากสามารถอ่านได้ง่ายโดยใช้โปรแกรมแก้ไขข้อความชนิดใดก็ได้หรือแสดงเนื้อหาผ่านคำสั่งคอนโซล

อย่างไรก็ตามไฟล์บันทึกบางไฟล์อยู่ในรูปแบบไบนารีหากมีข้อมูลจำนวนมาก ตัวอย่างเช่นผลิตภัณฑ์ที่ฉันใช้ในการจัดเก็บสูงสุด 15,000 บันทึก ในการจัดเก็บระเบียนในจำนวนห้องที่น้อยที่สุดจะถูกเก็บไว้ในรูปแบบไบนารี อย่างไรก็ตามต้องเขียนแอปพลิเคชันพิเศษเพื่อดูบันทึกหรือแปลงเป็นรูปแบบที่สามารถใช้งานได้ (เช่นสเปรดชีต)

โดยสรุปไฟล์บันทึกไม่ได้อยู่ในรูปแบบข้อความ รูปแบบข้อความมีข้อได้เปรียบที่ไม่จำเป็นต้องใช้เครื่องมือที่กำหนดเองเพื่อดูเนื้อหา หากมีข้อมูลจำนวนมากไฟล์อาจอยู่ในรูปแบบไบนารี รูปแบบไบนารีจะต้องมีแอปพลิเคชัน (กำหนดเอง) เพื่ออ่านข้อมูลและแสดงผลในรูปแบบที่มนุษย์สามารถอ่านได้ ข้อมูลเพิ่มเติมสามารถบรรจุในรูปแบบไบนารี ไม่ว่าจะใช้รูปแบบข้อความหรือรูปแบบไบนารีเป็นการตัดสินใจตามปริมาณข้อมูลและความสะดวกในการดูเนื้อหา

ในระบบฝังตัวที่ฉันอาจไม่มีช่องสัญญาณออกในระหว่างใช้งานแอปพลิเคชันไม่สามารถจ่ายความเร็วที่กำหนดโดยการบันทึกหรือการบันทึกจะเปลี่ยนหรือปิดบังเอฟเฟกต์ที่ฉันพยายามบันทึกฉันมักจะ หันไปบรรจุข้อมูลไบนารีลงในอาร์เรย์หรือบัฟเฟอร์แหวนและทั้ง printf () ไอเอ็นจีในตอนท้ายของการทดสอบการทำงานหรือทิ้งมันดิบและการเขียนล่ามเพื่อพิมพ์เป็นอ่านได้ ฉันต้องการจบด้วยข้อมูลที่อ่านได้

ในระบบที่มีทรัพยากรมากขึ้นเหตุใดจึงคิดค้นแผนการเพิ่มประสิทธิภาพสิ่งที่ไม่ต้องการเพิ่มประสิทธิภาพ

ไฟล์บันทึกมีวัตถุประสงค์เพื่อช่วยในการแก้ไขข้อบกพร่องของปัญหา โดยปกติแล้วพื้นที่ฮาร์ดไดรฟ์จะถูกกว่าเวลาทางวิศวกรรมมาก ไฟล์บันทึกใช้ข้อความเพราะมีเครื่องมือมากมายสำหรับการทำงานกับข้อความ (เช่นtail -f) แม้แต่ HTTP ก็ใช้ข้อความล้วน (ดูทำไมเราไม่ส่งเลขฐานสองรอบแทนข้อความใน http )

นอกจากนี้ยังมีราคาถูกกว่าในการพัฒนาระบบการบันทึกข้อความธรรมดาและตรวจสอบว่ามันทำงานได้ดีขึ้นและง่ายต่อการตรวจแก้จุดบกพร่องถ้ามันผิดและง่ายต่อการกู้คืนข้อมูลที่เป็นประโยชน์ในกรณีที่ระบบล้มเหลวและเสียหายส่วนหนึ่งของบันทึก

ไฟล์ข้อความที่เสียหายยังคงสามารถอ่านได้รอบส่วนที่เสียหาย ไฟล์ไบนารีที่เสียหายอาจถูกเรียกคืนได้ แต่ก็อาจไม่ได้เช่นกัน ถึงแม้ว่ามันจะ restorable มันจะต้องทำงานอีกเล็กน้อย อีกเหตุผลหนึ่งคือรูปแบบการบันทึกแบบไบนารีทำให้มีความเป็นไปได้น้อยที่ในระหว่างการสร้าง "การแก้ไขชั่วคราว" (aka "ถาวรที่สุดของการแก้ไขทั้งหมด") โซลูชันการบันทึกจะถูกนำมาใช้แทนสิ่งที่สามารถสร้างได้เร็วขึ้น

เราวางใจในการทดสอบหน่วยเพื่อให้บรรลุและรักษาความแข็งแกร่งของซอฟต์แวร์ของเรา (โค้ดส่วนใหญ่ของเราทำงานในเซิร์ฟเวอร์โดยไม่มีการวิเคราะห์การวิเคราะห์หลังการทำงานของไฟล์บันทึกเป็นกลยุทธ์หลัก) เกือบทุกคลาสในการใช้งานของเราทำการบันทึกบางอย่าง ส่วนที่สำคัญของการทดสอบหน่วยของเราคือการใช้ตัวบันทึก 'จำลอง' ที่ใช้เมื่อทำการทดสอบหน่วย การทดสอบหน่วยสร้างตัวลอกเลียนแบบและมอบให้กับรายการที่กำลังทดสอบ จากนั้น (เมื่อมีประโยชน์ / เหมาะสม) จะวิเคราะห์สิ่งที่บันทึกไว้ (โดยเฉพาะข้อผิดพลาดและคำเตือน) การใช้รูปแบบบันทึกข้อความจะทำให้ง่ายขึ้นด้วยเหตุผลเดียวกันกับการวิเคราะห์ที่ทำในบันทึก 'จริง': มีเครื่องมือมากมายในการกำจัดของคุณที่ใช้งานและปรับเปลี่ยนได้อย่างรวดเร็ว

ประวัติศาสตร์บันทึกเป็นทางการบันทึกเหตุการณ์ที่เขียนด้วยมือและต่อเนื่อง เมื่อเครื่องจักรสามารถบันทึกเหตุการณ์ได้สิ่งเหล่านี้ถูกเขียนลงในอุปกรณ์ส่งออกที่ถ่ายสำเนาอย่างหนักเช่นเครื่องพิมพ์โทรพิมพ์ซึ่งผลิตบันทึกต่อเนื่องแบบถาวร

ย้อนกลับไปในวันที่เมนเฟรมของเราเราใช้รูปแบบบันทึกแบบไบนารีที่กำหนดเอง เหตุผลหลักคือไม่ต้องประหยัดพื้นที่มันเป็นเพราะเราต้องการให้บันทึกครอบครองพื้นที่ จำกัด โดยเขียนทับรายการเก่ากับรายการใหม่ สิ่งสุดท้ายที่เราต้องการคือไม่สามารถวินิจฉัยปัญหาที่เกิดจากดิสก์เต็ม (ในปี 1980 พื้นที่ดิสก์เคยราคา $ 1,000 / Mb ดังนั้นผู้คนจึงไม่ซื้อมากกว่าที่ต้องการ)

ตอนนี้ฉันยังคงชอบแนวคิดของล็อกไฟล์แบบวงกลมและหากระบบปฏิบัติการมีสัตว์ร้ายตัวนี้ฉันก็จะใช้มันโดยไม่ลังเล แต่ไบนารีเป็นความคิดที่ไม่ดี คุณไม่ต้องการเสียเวลาค้นหาคำสั่งที่เหมาะสมสำหรับการถอดรหัสไฟล์บันทึกเมื่อคุณมีปัญหาร้ายแรงในการแก้ปัญหา