기록 감사 테이블 만들기

-2

현재 우리는 11M 개 이상의 기록을 보유하고있는 AuditLog 테이블을 보유하고 있습니다. 인덱스 및 통계에 관계없이이 테이블을 참조하는 쿼리는 시간이 오래 걸립니다. 대부분의 보고서는 1 년이 지난 감사 기록을 확인하지 않지만이 기록을 유지하려고합니다. 이것을 처리하는 가장 좋은 방법은 무엇입니까?기록 감사 테이블 만들기

나는 AuditLog 테이블을 1 년 미만의 모든 레코드를 보유하도록 유지하려고 생각했습니다. 그런 다음 1 년이 넘은 레코드를 AuditLogHistory 테이블로 옮깁니다. 매일 밤 배치 파일을 실행하여이 레코드를 이동 한 다음 AuditLog 테이블의 인덱스와 통계를 업데이트하면됩니다. 이 작업을 완료하는 데 좋은 방법입니까? 아니면 이전 기록을 다른 방법으로 저장해야합니까?

AuditLog 테이블에서 가져온 레코드는 연결된 서버에 도달하고 6 개의 다른 db를 체크인하여 조건에 따라 특정 멤버가 존재하는지 확인합니다. 나는 연결된 서버 db에 대한 변경을 할 수있는 권한이 없으므로 Auditlog 만 최적화 할 수 있습니다. 연결된 서버를 사용하면 쿼리 비용의 90 % 이상을 사용합니다. 그래서 나는 단지 내가 할 수있는 일을 제한하려하고있다.

출처

2017-02-10 user3199317

솔루션을 시험해보고 전문가와 죄수의 목록을 만드십시오. – dfundako

무엇이든 시도하기 전에 나는 이것이 최선의 방법이라면 의견을 얻고 싶었습니다. – user3199317

첫째, 1,100 만 개의 레코드가있는 테이블에서 쿼리를 최적화 할 수 없다고 생각합니다. 자주 실행되는 쿼리와 관련된 인덱스를 조사해야합니다.

어쨌든 귀하의 질문에 대한 답변은 "파티셔닝"입니다. 날짜 열을 기준으로 분할하고 모든 조건에이 조건을 포함해야합니다. 그러면 데이터 양이 줄어들고 처리 속도가 빨라집니다.

documentation은 파티셔닝을 배우기에 좋은 출발점입니다.

출처

2017-02-10 18:58:30

나는 파티셔닝이 대답이라는 데 동의합니다. 한 가지만 추가하고 싶었습니다. OP는 자신의 AuditLog 테이블에 대한 색인을 생성합니다. 인덱싱을 사용하면 읽기가 빨라지지만 삽입 속도가 느려집니다. 로그 테이블은 아마도 많은 삽입과 상대적으로 적은 읽기를 가질 것입니다. 따라서 실제로 필요하지 않으면 색인을 추가해서는 안됩니다. 보고서를 전혀 손상시키지 않지만 로그를 느리게 만드는 프로세스를 만들 수 있습니다. –

두 개의 연결된 감사 테이블이 있는데, 하나는 약 100M 행이고 다른 하나는 오래된 레코드를 유지할 필요가 없다는 점만 제외하면 거의 동일한 시나리오가 있습니다. 특정 시간보다 오래된 감사 레코드를 삭제하는 것은 고통스럽게 느려졌습니다. 테이블을 auditlog_history로 이름을 바꾸고, 감사 로그 테이블을 다시 만들고, 이름이 바뀐 테이블에서 다시 삽입 한 다음 auditlog_history 테이블을 잘라내는 것이 약 80 배 더 빠릅니다. 귀하의 경우에는 잘라내기를 건너 뛸 수 있습니다. 물론 외래 키나 인덱스를 삭제하고 다시 작성해야합니다. –

AuditLog 테이블에서 가져온 레코드는 연결된 서버에 충돌하여 6 개의 다른 db를 체크인하여 조건에 따라 특정 멤버가 있는지 확인합니다. 나는 연결된 서버 db에 대한 변경을 할 수있는 권한이 없으므로 Auditlog 만 최적화 할 수 있습니다. 연결된 서버를 사용하면 쿼리 비용의 90 % 이상을 사용합니다. 그래서 나는 단지 내가 할 수있는 일을 제한하려했다. 감사합니다. 파티셔닝을 살펴 보겠습니다. – user3199317

답변

관련 문제