Tại sao hệ thống tệp được ưa thích cho các bản ghi thay vì RDBMS?

Câu hỏi nên rõ ràng từ tiêu đề của nó. Ví dụ, Apache lưu truy cập và nhật ký lỗi trong các tệp thay vì RDBMS cho dù quy mô lớn hay nhỏ đang được sử dụng.

Đối với RDMS, chúng ta chỉ cần viết các truy vấn SQL và nó sẽ thực hiện công việc trong khi đối với các tệp, chúng ta phải quyết định một định dạng cụ thể và sau đó viết regex hoặc có thể là các trình phân tích cú pháp để thao tác chúng. Và những người thậm chí có thể thất bại trong những trường hợp cụ thể nếu không được chăm sóc cẩn thận.

Tuy nhiên, mọi người dường như thích hệ thống tập tin để duy trì nhật ký. Tôi không thiên vị đối với bất kỳ phương pháp nào trong số này nhưng tôi muốn biết tại sao nó được thực hành như thế này. Đó là tốc độ hoặc khả năng bảo trì hoặc cái gì khác?

1. Quá nhiều thứ có thể thất bại với cơ sở dữ liệu và ghi lại những thất bại này cũng quan trọng.

2. Trừ khi bạn có một hệ thống cơ sở dữ liệu cho phép các giao dịch tự trị (hoặc hoàn toàn không có giao dịch), việc ghi nhật ký sẽ yêu cầu một kết nối riêng để việc khôi phục hoặc cam kết trong việc ghi nhật ký không can thiệp vào rollback hoặc cam kết trong ứng dụng.

3. Nhiều điều đáng ghi lại xảy ra trong quá trình khởi động, tức là có thể trước khi kết nối cơ sở dữ liệu được thiết lập.

4. Trong những gì có thể là một thiết lập điển hình, một logfile mới được tạo ra mỗi ngày, các tệp nhật ký cũ được nén và giữ trong 2 tuần, trước khi cuối cùng bị xóa. Không dễ để làm điều tương tự trong RDBMS.

Tôi đã thấy các bản ghi được ghi vào DB trước đó (và đôi khi bạn nhận được các tùy chọn có thể định cấu hình để ghi nhật ký, trong đó dấu vết đi đến tệp, lỗi đối với DB, các lỗi nghiêm trọng đối với nhật ký Sự kiện của Windows).

Lý do chính là tốc độ và kích thước, cho phép một số dấu vết có thể tạo ra chất lượng lớn, ghi nhật ký lớn - Tôi đã truy tìm các tệp nhật ký có kích thước gigabyte. Lý do chính khác là việc đọc nhật ký cần phải tuần tự, không cần thực sự truy vấn nhật ký, ngoại trừ tìm một lỗi hoặc mục nhất định - và find-in-file hoạt động hoàn toàn tốt cho việc đó.

Tốc độ là một lý do; những kẻ khác là:

• Loại bỏ các điểm thất bại. Một hệ thống tệp hiếm khi thất bại trong các điều kiện trong đó DBMS sẽ không, nhưng có rất nhiều điều kiện lỗi trong cơ sở dữ liệu đơn giản không tồn tại trong các hệ thống tệp.
• Khả năng tiếp cận công nghệ thấp. Nếu mọi thứ thực sự tồi tệ, bạn có thể khởi động vào vỏ cứu hộ hoặc gắn đĩa vào một hệ thống khác và vẫn có sẵn các công cụ đầy đủ để kiểm tra tệp nhật ký. Nếu đó là cơ sở dữ liệu, bạn sẽ không có máy chủ cơ sở dữ liệu nào đang chạy.

Trước hết.

Và những người thậm chí có thể thất bại trong những trường hợp cụ thể nếu không được chăm sóc cẩn thận.

Giao dịch cơ sở dữ liệu không thể thất bại khi bạn không cẩn thận?

Viết vào một tệp văn bản có một số lợi ích, quan trọng nhất là

• Văn bản là con người có thể đọc được. Bất cứ ai cũng có thể mở một tệp nhật ký với trình soạn thảo văn bản cơ bản và xem các tin nhắn là gì. Bạn không cần phải hiểu cách tổ chức cơ sở dữ liệu.
• Tốc độ. Viết văn bản vào đĩa nhanh hơn nhiều so với dịch vụ cơ sở dữ liệu tìm ra văn bản đi vào cơ sở dữ liệu, viết nó ở đó và đảm bảo giao dịch được hoàn thành.

Bạn đặc biệt nâng cao Apache, vì vậy tôi sẽ thảo luận chi tiết về vấn đề này.

Apache có thể được cấu hình để đăng nhập vào cơ sở dữ liệu, mặc dù nó yêu cầu một plugin bên ngoài để làm như vậy. Sử dụng một plugin như vậy có thể làm cho phân tích nhật ký dễ dàng hơn, nhưng chỉ khi bạn có ý định viết phần mềm phân tích nhật ký của riêng bạn. Các máy phân tích nhật ký ngoài giá trị giả định rằng nhật ký của bạn nằm trong các tệp, vì vậy bạn sẽ không thể sử dụng các phân tích này.

Khi tôi đang làm điều này, tôi cũng gặp phải các vấn đề về độ tin cậy: nếu bộ đệm ghi của máy chủ cơ sở dữ liệu bị đầy (điều này có thể xảy ra với mysql nếu bạn sử dụng hết hạn ngạch hệ thống tệp của mình cho người dùng thì nó sẽ chạy theo truy vấn cho đến khi họ có thể để tiếp tục, tại thời điểm đó Apache bắt đầu chờ đợi nó kết thúc, dẫn đến các yêu cầu treo đối với trang web của bạn.

(Tất nhiên vấn đề này có thể được khắc phục - dĩ nhiên là nhiều năm trước tôi đã làm điều này)

Một hệ thống tập tin là một cơ sở dữ liệu. Đây thực sự là một cơ sở dữ liệu phân cấp đơn giản hơn thay vì DBMS quan hệ, tuy nhiên nó vẫn là một cơ sở dữ liệu.

Lý do tại sao việc đăng nhập vào hệ thống tệp là phổ biến là vì nhật ký văn bản phù hợp với triết lý Unix: "Văn bản là giao diện phổ quát".

Unix đã phát triển với rất nhiều công cụ có mục đích chung có thể hoạt động tốt với nhật ký văn bản. Không quan trọng liệu nhật ký văn bản có được tạo bởi mysql, apache, ứng dụng tùy chỉnh của bạn, phần mềm bên thứ ba không hỗ trợ hay không, sysadmin có thể sử dụng các công cụ Unix tiêu chuẩn như grep, sed, awk, sort, uniq, cut, tail , v.v., để truy tìm tất cả các bản ghi giống nhau.

Nếu mọi ứng dụng đăng nhập vào cơ sở dữ liệu của riêng nó, một cho MySQL, một cho Postgres, một cho Elaticsearch, một ứng dụng khác muốn đăng nhập vào ELK, một ứng dụng khác chỉ có thể đăng nhập vào MongoDB, thì bạn sẽ phải học hai mươi công cụ khác nhau để truy tìm nhật ký của mỗi ứng dụng. Văn bản là một phương tiện phổ quát mà tất cả mọi người có thể đăng nhập.

Ngay cả khi bạn quản lý để làm cho nó sao cho tất cả các bản ghi vào một cơ sở dữ liệu, giả sử MySQL, bạn có thể thấy rằng mỗi ứng dụng sẽ muốn đăng nhập với các lược đồ bảng khác nhau, do đó bạn vẫn phải viết công cụ tùy chỉnh để truy vấn nhật ký cho từng bản ghi ứng dụng. Và nếu bạn bằng cách nào đó nhồi nhét mọi ứng dụng để đăng nhập vào một lược đồ duy nhất, bạn có thể sẽ thấy rằng lược đồ chung đó thực sự không thể cho bạn biết toàn bộ câu chuyện của mỗi ứng dụng, vì vậy dù sao bạn vẫn phải phân tích các văn bản nhật ký.

Đăng nhập vào cơ sở dữ liệu thường không thực sự làm cho mọi thứ dễ dàng hơn trong thực tế.

Đăng nhập vào cơ sở dữ liệu có thể hữu ích khi bạn có một phân tích cụ thể mà bạn có trong đầu hoặc cho yêu cầu lưu giữ kiểm toán cụ thể, để bạn có thể thiết kế một lược đồ cơ sở dữ liệu cụ thể để chỉ thu thập dữ liệu cho các mục đích cụ thể đó. Nhưng đối với pháp y và gỡ lỗi và khi bạn thu thập nhật ký mà không có mục tiêu cụ thể, nhật ký văn bản thường đủ tốt để chi phí học tập hoặc tạo các công cụ chuyên dụng thường không xứng đáng.

Chúng ta hãy xem xét điều này trên một vài lớp:

1. Lớp máy
2. Lớp hệ điều hành
3. Lớp dịch vụ
4. Lớp ứng dụng

Tóm lại:

• Trên lớp máy, bạn thực sự không thể thực hiện đăng nhập ngoài một số loại bãi.
• Trên lớp hệ điều hành, bạn có thể đăng nhập nhưng bạn thực sự chỉ có sẵn hệ thống tệp.
• Các dịch vụ có thể đăng nhập vào hệ thống tệp, nhưng họ không thể tin tưởng các dịch vụ khác đang chạy để họ không thể đăng nhập vào đó.
• Các ứng dụng có thể đăng nhập vào các dịch vụ và hệ thống tập tin.

Sau đó, chúng ta có cách tiếp cận dựa trên trường hợp sử dụng:

Bạn có muốn ghi lại các lỗi cụ thể của nút vào RDBMS theo chiều ngang mà bạn cần thực hiện thêm công việc để tìm lỗi của một nút cụ thể khi bạn có thể bật nắp mở cho một nút và xem nó ở đó không? Mặt khác, ứng dụng của bạn có thể nên đăng nhập vào RDBMS để thu thập các thông báo và lỗi cấp độ ứng dụng.

Điều gì xảy ra khi RDBMS cần tự ghi nhật ký vì cơ sở dữ liệu không thể được ghi vào?

Phức tạp. Thêm RDBMS sẽ tăng độ phức tạp của toàn bộ hệ thống. Và khả năng quản lý sự phức tạp là điều chính giúp phân biệt các lập trình viên với các nhà sản xuất mã nguồn.

Đó là tốc độ hoặc khả năng bảo trì hoặc cái gì khác?

Tốc độ.