RDBMS 대신 로그에 파일 시스템이 선호되는 이유는 무엇입니까?

제목에서 질문이 명확해야합니다. 예를 들어 Apache는 규모에 관계없이 RDBMS 대신 파일에 액세스 및 오류 로그를 저장합니다.

RDMS의 경우 SQL 쿼리를 작성하기 만하면됩니다. 파일의 경우 특정 형식을 결정한 다음 정규식을 작성하거나 파서를 사용하여 조작 할 수 있습니다. 그리고 세심한주의를 기울이지 않으면 특정 상황에서 실패 할 수도 있습니다.

그러나 모두가 로그를 유지 관리하기 위해 파일 시스템을 선호하는 것 같습니다. 나는 이러한 방법들 중 어느 것에도 편견이 없지만 왜 이런 식으로 실행되는지 알고 싶습니다. 속도 또는 유지 보수성 또는 다른 것입니까?

1. 데이터베이스에 너무 많은 것들이 실패 할 수 있으며 이러한 실패를 기록하는 것도 중요합니다.

2. 자율적 트랜잭션을 허용하거나 전혀 트랜잭션을 허용하지 않는 데이터베이스 시스템이 없으면 로깅에는 별도의 연결이 필요하므로 로깅의 롤백 또는 커밋은 애플리케이션의 롤백 또는 커밋을 방해하지 않습니다.

3. 로깅 할 가치가있는 많은 것들이 시작 중, 즉 데이터베이스 연결이 설정되기 전에 발생합니다.

4. 일반적인 설정일 수있는 새로운 로그 파일이 매일 생성되고 오래된 로그 파일이 압축되어 2 주 동안 보관되어 결국 삭제됩니다. RDBMS에서 동일한 작업을 수행하는 것은 쉽지 않습니다.

이전에 DB에 기록 된 로그를 보았습니다 (때로는 추적, 파일에 대한 오류, DB에 대한 오류, Windows 이벤트 로그에 치명적인 로깅에 대한 구성 가능한 옵션이 있음).

주요 이유는 속도와 크기로, 일부 추적을 통해 방대한 양의 로깅을 생성 할 수 있습니다. 로그 파일 크기는 기가 바이트입니다. 다른 주요 이유는 로그를 읽는 것이 순차적이어야하고 특정 오류나 항목을 찾는 것 외에는 로그를 쿼리 할 필요가 없으며 파일에서 찾기가 완벽하게 작동하기 때문입니다.

속도가 한 가지 이유입니다. 다른 사람들은 :

• 실패 지점 제거. 파일 시스템은 DBMS가없는 조건에서는 거의 실패하지 않지만 데이터베이스에는 파일 시스템에 존재하지 않는 많은 오류 조건이 있습니다.
• 최첨단 접근성. 상황이 정말 나빠지면 복구 쉘로 부팅하거나 다른 시스템에 디스크를 마운트 할 수 있으며 로그 파일을 검사 할 수있는 적절한 도구를 계속 사용할 수 있습니다. 데이터베이스 인 경우 데이터베이스 서버를 실행하지 않아도됩니다.

우선.

그리고 세심한주의를 기울이지 않으면 특정 상황에서 실패 할 수도 있습니다.

조심하지 않아도 데이터베이스 트랜잭션이 실패하지 않습니까?

텍스트 파일에 쓰면 여러 가지 이점이 있습니다. 가장 중요한 것은

• 텍스트는 사람이 읽을 수 있습니다. 누구나 기본 텍스트 편집기로 로그 파일을 열고 메시지가 무엇인지 확인할 수 있습니다. 데이터베이스 구성 방법을 이해할 필요가 없습니다.
• 속도. 텍스트를 디스크에 쓰는 것은 데이터베이스 서비스가 텍스트가 데이터베이스의 어디에 들어가는 지 알아 내고 거기에 쓰고 트랜잭션이 완료되도록하는 것보다 훨씬 빠릅니다.

아파치를 구체적으로 올리면 이에 대해 자세히 설명하겠습니다.

외부 플러그인 이 필요하지만 데이터베이스에 로그인하도록 Apache를 구성 할 수 있습니다 . 이러한 플러그인을 사용하면 로그 분석 소프트웨어를 작성하려는 경우에만 로그 분석이 쉬워집니다. 표준 상용 로그 분석기는 로그가 파일에 있다고 가정하므로이 로그를 사용할 수 없습니다.

이 작업을 수행 할 때 안정성 문제도 발생했습니다. 데이터베이스 서버의 쓰기 버퍼가 가득 찬 경우 (이를 실행하는 사용자의 파일 시스템 할당량을 사용하는 경우 mysql에서 발생할 수 있음) 가능한 경우까지 쿼리 대기열을 시작합니다. 계속 진행하면 Apache가 완료되기를 기다리면서 웹 사이트에 대한 요청이 중단됩니다.

(이 문제는 이제 수정되었을 수 있습니다-몇 년 전에 내가이 일을했습니다)

파일 시스템은 데이터베이스입니다. 실제로 관계형 DBMS 대신에 더 단순하고 계층적인 데이터베이스이지만 그럼에도 불구하고 데이터베이스입니다.

파일 시스템에 로깅하는 것이 널리 사용되는 이유는 텍스트 로그가 Unix 철학에 잘 맞기 때문입니다. "텍스트는 범용 인터페이스입니다."

유닉스는 텍스트 로그와 잘 작동하는 많은 범용 도구로 개발했다. 텍스트 로그가 mysql, apache, 사용자 정의 응용 프로그램, 오래 지원되지 않는 타사 소프트웨어에 의해 생성되는지 여부는 중요하지 않습니다 .sysadmin은 grep, sed, awk, sort, uniq, cut, tail과 같은 표준 Unix 도구를 사용할 수 있습니다 등을 사용하여 로그를 모두 트롤합니다.

모든 앱이 자체 데이터베이스, 하나는 MySQL, 다른 하나는 Postgres, 다른 하나는 Elasticsearch에, 다른 하나는 ELK에 로그를 원하고 다른 하나는 MongoDB에만 로그 할 수있는 경우 각 로그를 트롤하는 20 가지 도구를 배워야합니다 신청. 텍스트는 모든 사람이 로그인 할 수있는 보편적 인 매체입니다.

MySQL과 같이 모든 로그가 단일 데이터베이스로 전달되도록 관리하더라도 각 응용 프로그램이 서로 다른 테이블 스키마를 사용하여 로그를 원할 수 있으므로 각 로그를 쿼리하는 사용자 지정 도구를 작성해야 할 수도 있습니다. 신청. 그리고 어떻게 든 모든 애플리케이션이 단일 스키마에 로그하도록 구성한 경우, 일반 스키마는 실제로 각 애플리케이션의 전체 스토리를 알려줄 수 없으므로 여전히 로그 텍스트를 구문 분석해야합니다.

데이터베이스에 로깅하는 것이 실제로 실제로 작업을 훨씬 쉽게 만들어주지는 않습니다.

데이터베이스에 로깅하면 특정 분석을 염두에 두거나 특정 감사 보존 요구 사항에 대해 유용 할 수 있습니다. 특정 감사 보존 요구 사항은 특정 데이터베이스 스키마를 설계하여 특정 목적을 위해 데이터 만 수집 할 수 있습니다. 그러나 법의학 및 디버깅 및 특정 목표를 염두에 두지 않고 로그를 수집 할 때 텍스트 로그는 일반적으로 전문 도구를 배우거나 작성하는 비용이 가치가 없을 정도로 충분합니다.

이것을 몇 개의 레이어에서 살펴 봅시다 :

1. 기계 층
2. 운영 체제 계층
3. 서비스 계층
4. 응용 계층

간단히 :

• 머신 계층에서는 실제로 일종의 덤프 이외의 로깅을 수행 할 수 없습니다.
• OS 계층에서는 로깅을 수행 할 수 있지만 실제로 파일 시스템 만 사용할 수 있습니다.
• 서비스는 파일 시스템에 로그 할 수 있지만 다른 서비스가 실행되고 있다는 것을 신뢰할 수 없으므로 로그 할 수 없습니다.
• 응용 프로그램은 서비스 및 파일 시스템에 로그 할 수 있습니다.

그런 다음 유스 케이스 기반 접근 방식이 있습니다.

한 노드의 후드를 열어서 볼 수있을 때 특정 노드의 오류를 찾기 위해 추가 작업을 수행해야하는 수평으로 확장 된 RDBMS에 노드 별 오류를 기록 하시겠습니까? 한편, 응용 프로그램 레벨 오류 및 통지를 수집하기 위해 응용 프로그램이 RDBMS에 로그인해야 할 수도 있습니다.

데이터베이스를 쓸 수 없기 때문에 RDBMS가 자체 로깅을 수행해야 할 경우 어떻게됩니까?

복잡성. RDBMS를 추가하면 전체 시스템의 복잡성이 천문학적으로 증가합니다. 그리고 복잡성을 관리하는 능력은 프로그래머를 소스 코드 제작자와 구별하는 주요 요소입니다.

속도 또는 유지 보수성 또는 다른 것입니까?

속도.