Tính năng lưu trữ nhật ký trong cơ sở dữ liệu hoặc tệp sql hiệu quả hơn là gì?

Question

Tôi có vài tập lệnh được tải bởi cron khá thường xuyên. Ngay bây giờ tôi không lưu trữ bất kỳ nhật ký nào, vì vậy nếu bất kỳ tập lệnh nào không tải được, tôi sẽ không biết nó cho đến khi tôi thấy kết quả - và ngay cả khi tôi nhận thấy kết quả là không chính xác, tôi không thể làm bất cứ điều gì vì tôi don ' t biết tập lệnh nào bị lỗi.

Tôi đã quyết định lưu trữ nhật ký, nhưng tôi vẫn không chắc chắn cách thực hiện. Vì vậy, câu hỏi của tôi là - những gì hiệu quả hơn - lưu trữ các bản ghi trong cơ sở dữ liệu sql hoặc các tập tin?

Tôi có thể tạo bảng 'nhật ký' trong cơ sở dữ liệu mysql của mình và lưu trữ mỗi nhật ký trong hàng riêng biệt hoặc tôi chỉ có thể sử dụng tệp file_put_contents hoặc fopen/fwrite của php để lưu trữ nhật ký trong các tệp riêng biệt.

Tập lệnh của tôi sẽ thêm khoảng 5 nhật ký (trong tổng số) mỗi phút khi làm việc. Tôi đã thực hiện vài bài kiểm tra để xác định những gì nhanh hơn - fopen/fwrite hoặc chèn mysql. Tôi lặp lại một tuyên bố "chèn" 3000 lần để tạo 3000 hàng và lặp fopen/fwrite 3000 lần để tạo 3000 tệp với văn bản mẫu. Fwrite thực hiện nhanh hơn 4-5 lần so với chèn của sql. Tôi đã thực hiện một vòng lặp thứ hai - Tôi lặp một tuyên bố 'chọn' và gán nó cho một chuỗi 3000 lần - Tôi cũng đã mở 3000 tệp bằng cách sử dụng 'fopen' và gán kết quả cho chuỗi. Kết quả là như nhau - fopen/fwrite hoàn thành nhiệm vụ nhanh hơn 4-5 lần.

Vì vậy, với tất cả những người lập trình có kinh nghiệm - trải nghiệm của bạn về lưu trữ nhật ký là gì? Lời khuyên nào?

// 04.09.2011 EDIT - Cảm ơn tất cả vì câu trả lời của bạn, họ đã giúp đỡ rất nhiều. Mỗi bài đăng có giá trị, do đó, rất khó để chỉ chấp nhận một câu trả lời ;-)

Answer 1

Bạn có thể sử dụng một thành phần như Zend_Log vốn hỗ trợ khái niệm các nhà văn được gắn vào cùng một cá thể nhật ký. Bằng cách đó, bạn có thể đăng nhập cùng một thư đến một hoặc nhiều địa điểm khác nhau mà không cần phải thay đổi mã đăng nhập của mình. Và bạn luôn có thể thay đổi mã của mình để thay thế hệ thống nhật ký hoặc thêm mã mới theo cách đơn giản.

Đối với câu hỏi của bạn, tôi cho rằng việc đăng nhập vào tệp đơn giản và phù hợp hơn nếu bạn (nhà phát triển) là người duy nhất cần đọc thông điệp tường trình.

Đăng nhập vào db thay vào đó nếu bạn cần người khác cần đọc nhật ký trong giao diện web hoặc nếu bạn cần khả năng tìm kiếm thông qua nhật ký. Vì ai đó đã chỉ ra các vấn đề đồng thời, nếu bạn có nhiều người dùng đăng nhập vào db có thể mở rộng quy mô tốt hơn.

Cuối cùng, tần suất đăng nhập 5 tin nhắn mỗi phút yêu cầu hầu như không có CPU cho ứng dụng của bạn, vì vậy bạn không cần phải lo lắng về buổi biểu diễn. Trong trường hợp của bạn, tôi sẽ bắt đầu với logfiles và sau đó thay đổi (hoặc thêm nhiều người viết) nếu các điều kiện tiên quyết của bạn sẽ thay đổi.

Answer 2

Nhật ký sử dụng tệp hiệu quả hơn, tuy nhiên các nhật ký được lưu trữ trong cơ sở dữ liệu dễ đọc hơn, thậm chí từ xa (bạn có thể viết lối vào web) yêu cầu, ví dụ). Tuy nhiên, lưu ý rằng việc kết nối và chèn hàng vào cơ sở dữ liệu là dễ xảy ra lỗi (máy chủ cơ sở dữ liệu, sai mật khẩu, không có tài nguyên), vậy bạn sẽ đăng nhập những lỗi đó ở đâu nếu bạn quyết định sử dụng cơ sở dữ liệu? Không có thông tin?

Answer 3

Viết hệ thống tệp phải luôn nhanh hơn.

Tuy nhiên đó là mối quan tâm của bạn. Cả hai thực hiện một chèn đơn giản và ghi vào một hệ thống tập tin được hoạt động nhanh chóng. Những gì bạn cần phải lo lắng là những gì sẽ xảy ra khi cơ sở dữ liệu của bạn bị hỏng. Tôi personaly muốn viết cho cả hai vì vậy luôn luôn có một bản ghi nếu bất cứ điều gì đi sai nhưng bạn cũng có dễ dàng tìm kiếm từ một cơ sở dữ liệu.

Answer 4

Lỗi ghi nhật ký được giới hạn tốt nhất đối với tệp theo ý kiến ​​của tôi, bởi vì nếu có sự cố với cơ sở dữ liệu, bạn vẫn có thể ghi nhật ký đó. Rõ ràng đó không phải là một tùy chọn nếu việc ghi nhật ký lỗi của bạn yêu cầu kết nối tới cơ sở dữ liệu!

Những gì tôi cũng sẽ nói tuy nhiên, đó là khai thác gỗ nói chung là cái gì đó tôi rời trong cơ sở dữ liệu, tuy nhiên điều này chỉ áp dụng nếu bạn đang làm rất nhiều khai thác gỗ cho những con đường mòn kiểm toán, vv

Answer 5

Tùy thuộc vào kích thước của nhật ký và mức đồng thời. Vì mới nhất, kiểm tra của bạn hoàn toàn không hợp lệ - nếu có 100 người dùng trên trang web và bạn cho phép nói 10 chuỗi ghi vào cùng một tệp, fwrite sẽ không nhanh hơn. Một trong những điều RDBMS cung cấp là kiểm soát đồng thời.

Tùy thuộc vào yêu cầu và rất nhiều phân tích bạn muốn thực hiện. Chỉ cần đọc hồ sơ là dễ dàng, nhưng những gì về tập hợp một số dữ liệu trong một khoảng thời gian xác định.

Trang web có quy mô lớn sử dụng các hệ thống như Scribe để ghi nhật ký của chúng.

Nếu bạn đang nói về 5 bản ghi mỗi phút tuy nhiên, đây thực sự là tải thấp, do đó, câu hỏi chính là cách bạn sẽ đọc chúng. Nếu tệp phù hợp với nhu cầu của bạn, hãy đi với tệp. Nói chung, viết thêm chỉ ghi (thông thường cho các bản ghi) là rất nhanh.

Answer 6

Tốc độ không phải là tất cả. Có, nó nhanh hơn để ghi vào các tập tin nhưng nó nhanh hơn nhiều để bạn có thể tìm thấy những gì bạn cần trong nhật ký nếu chúng ở trong cơ sở dữ liệu. Vài năm trước, tôi đã chuyển đổi CMS của mình từ nhật ký dựa trên tệp thành bảng Mysql. Bảng là tốt hơn.

Answer 7

Nhận xét về những phát hiện của bạn.

Về việc ghi vào tệp bạn có thể đúng.
Về việc đọc bạn đã chết sai.

Viết đến một cơ sở dữ liệu:

1. MyISAM khóa điện toàn bộ bảng trên chèn, gây ra một tranh cãi khóa. Sử dụng InnoDB, có khóa hàng.
2. Trái với 1. Nếu bạn muốn thực hiện tìm kiếm toàn văn trên nhật ký. Sử dụng MyISAM, nó hỗ trợ các chỉ mục toàn văn.
3. Nếu bạn muốn thực sự nhanh chóng, bạn có thể sử dụng động cơ memory, điều này ghi bảng trong RAM. Chuyển dữ liệu sang bảng dựa trên đĩa khi tải CPU thấp.

Đọc từ cơ sở dữ liệu

Đây là nơi các cơ sở dữ liệu thực sự tỏa sáng.
Bạn có thể kết hợp tất cả các loại thông tin từ các mục khác nhau, nhanh hơn nhiều và dễ dàng hơn bao giờ bạn có thể làm từ một tệp phẳng.

SELECT logdate, username, action FROM log WHERE userid = '1' /*root*/ AND error = 10; 

Nếu bạn có chỉ số trên các lĩnh vực được sử dụng trong where khoản kết quả sẽ trở lại gần như ngay lập tức, hãy thử làm điều đó trên một tập tin phẳng.

SELECT username, count(*) as error_count 
FROM log 
WHERE error <> 0 
GROUP BY user_id WITH ROLLUP 

Đừng bận tâm đến việc bảng không được chuẩn hóa, điều này sẽ chậm hơn nhiều và khó thực hiện hơn với tệp phẳng.
Nó thực sự không có trí tuệ.

Answer 8

Cá nhân, tôi thích các file log vì vậy tôi đã tạo hai chức năng:

<?php 
function logMessage($message=null, $filename=null) 
{ 
    if (!is_null($filename)) 
    { 
     $logMsg=date('Y/m/d H:i:s').": $message\n"; 
     error_log($logMsg, 3, $filename); 
    } 
} 

function logError($message=null, $filename=null) 
{ 
    if (!is_null($message)) 
    { 
     logMessage("***ERROR*** {$message}", $filename); 
    } 
} 
?> 

tôi xác định một hằng số hoặc hai (Tôi sử dụng ACTIVITY_LOG và error_log cả các thiết lập để cùng một tập tin do đó bạn không cần phải tham khảo hai tập tin cạnh nhau để có cái nhìn tổng thể về hoạt động) và gọi khi thích hợp. Tôi cũng đã tạo một thư mục chuyên dụng (/ var/log/phplogs) và mỗi ứng dụng mà tôi viết có tệp nhật ký riêng của nó. Cuối cùng, tôi xoay các bản ghi để tôi có một số lịch sử để tham khảo lại cho khách hàng.

Tự do sử dụng các chức năng ở trên có nghĩa là tôi có thể theo dõi việc thực hiện các ứng dụng khá dễ dàng.

Answer 9

Tôi nghĩ rằng việc lưu trữ nhật ký trong cơ sở dữ liệu không phải là một ý tưởng hay. Ưu điểm của việc lưu trữ nhật ký vào cơ sở dữ liệu trên các tệp là bạn có thể phân tích nhật ký của mình dễ dàng hơn với sức mạnh của SQL, nhược điểm là bạn phải trả nhiều thời gian hơn để duy trì cơ sở dữ liệu. Bạn nên thiết lập một máy chủ cơ sở dữ liệu riêng biệt để lưu trữ nhật ký của mình hoặc bạn có thể nhận quá nhiều nhật ký INSERT, điều này sẽ làm giảm hiệu suất cơ sở dữ liệu của bạn để sử dụng sản xuất; cũng không dễ dàng di chuyển, lưu trữ nhật ký trong cơ sở dữ liệu, so với các tệp (logrotate, v.v.). Ngày nay, bạn nên sử dụng một số hệ thống ghi nhật ký giàu tính năng đặc biệt để xử lý nhật ký, ví dụ: logstash (http://logstash.net/) có bộ thu thập, bộ lọc và lưu trữ nhật ký trong các hệ thống bên ngoài như elasticsearch, kết hợp với lối vào đẹp để hiển thị và phân tích nhật ký của bạn.

Ref:

• http://www.revsys.com/blog/2012/may/01/three-things-you-should-never-put-your-database/