로그가 데이터베이스 (SQL)가 아닌 플랫 파일에 저장되는 이유는 무엇입니까?

Question

웹 서버와 다른 기술이 SQL이나 일종의 KVS 또는 "NoSQL"솔루션에 관계없이 일종의 데이터베이스가 아닌 로깅을 위해 플랫 파일을 사용하는 이유는 무엇입니까?

플랫 파일을 사용할 때 속도, 대기 시간, 쓰기 시간 등의 이점이 있습니까? 아니면 단순히 누락 되었습니까?

Answer 1

서버에 DB가 있다고 보장 할 수는 없습니다.

DB가 문제의 일부인 경우 로그를 어떻게 봅니까?

DB가 문제의 일부가 아닌 경우 이전 텍스트 편집기로 로그를 보는 것이 더 간단합니다.

간단한 작업을 할 때 복잡하게 사용하는 이유. 아파치 (등)가 처음 개발되었을 때, 오픈 소스 (무료, 유비쿼터스) DB는 사용 가능하지 않았다.

등 기타

Answer 2

• 우선 무엇보다도, 쓰기 쉬운.
• 간단합니다 ... 파일에 쓰는 것은 잘못 될 가능성이 가장 적은 것 중 하나입니다.
• 단순성으로 인해 빠릅니다. 이는 디스크 쓰기와 작업 수행을위한 CPU 시간 모두에 적용됩니다.

많은 유산 또한 유산입니다. 테라 바이트가 아닌, 기가 바이트의 RAM이 아니라면 100 기가 바이트의 스토리지를 가진 데이터베이스 서버와 머신이 풍부하지만, 표준이 아닐지라도 대부분의 숙련 된 서버는 메모리가 훨씬 적은 부하로 시스템 리소스를 최대한 활용하는 시간부터 시작됩니다.

하지만 대부분 쉽습니다. 왜 SQLite (간단한 임베디드 SQL 서비스)에 의존하여 라이선스가 호환되는지 확인하고, 적절한 버전을 유지하며, 기본 버그 나 보안 문제가 없는지 확인하십시오. 순차적 삽입 만 수행하면 안됩니까?

키스. 로그 분석 도구는 로그 작성의 일부가 아니어야합니다.

Answer 3

적은 움직이는 부분, 뭔가 잘못 갈 수있는 적은 점을 말한다 영원한 원칙이있다. 종속성을 최소화하여 버그가 발생할 수있는 곳을 최소화합니다. 단순하기 때문에 또한 빠르며, 로깅으로 인해 시스템이 다운되는 것을 원하지 않는 고부하 서버입니다. 많은 다른, 더 큰 비행기가 그의 앞에 실패했을 때

흥미롭게 비행 찰스 린드버그의 단일 엔진 비행기가 성공적으로 만들어 같은 원리입니다 대서양을 건너 비 - 중지합니다. 계속 그것은 간단 :

Answer 4

여기에 대한 답변의 나머지 (KISS 교장, 등), 내가 로깅 서버의 하드 드라이브를 가득 프로젝트를 본 적이 그들은 청소 자동화를 구축했다 해당하는 동안 로그. 이 문제를 해결하기 위해, 하나는 롤링 백업/최대 로그 크기 기능을 구현하거나, 이동하거나 로그를 삭제하는 예약 된 작업 (크론)을 만들 수도 있습니다.

무료 점심 식사가 없습니다. 우리가 직장에서 DB 로그 사용을 중단하는 이유

Answer 5

는 여기에 있습니다.

try 
{ 
    tx.Begin(); 
    // Exception here! 
    tx.Commit(); 
} 
catch(Exception ex) 
{ 
    LogToDB(ex); 
    tx.Rollback(); 
} 

데이터베이스 연결 내에서 예외가 발생할 때마다 로깅이 롤백되고 있습니다.

(필자는 롤백 로깅 이후에 발생한 바로 그 때 ... 난 항상 말을 안 생각하지만 그것은 잠시 혼동되었다.!)