2011-08-28 8 views
4

MySQL 테이블에서 페이지의 모든보기에 대한 로그를 유지해야하는 시스템에서 작업하고 있습니다. 방문자가 지난 24 시간 동안 이전에 해당 페이지를 방문하지 않은 경우에만보기가 기록됩니다. 이렇게하면 성능 및 데이터베이스 크기 측면에서 많은 문제가 될지 궁금하네요.모든 페이지보기에 데이터베이스 행 삽입

이 작업을 수행해야하는 사이트는 하루에 약 60,000 개의 고유 한 페이지 뷰를 평균적으로 가지므로 하루에 약 60,000 개의 새 행이 추가됩니다 (2 초마다 1 개 미만). 이 표는 i_id, ip_address, timestamp의 3 열입니다. i_id은 다른 테이블에 대한 외래 키입니다.

테이블은 CRON 스크립트를 사용하여 매일 끝날 때 지워집니다.

이렇게하면 데이터베이스에 즉각적인 부담이 있습니까? 예를 들어 사이트에서 트래픽이 급증하면 (매우 규칙적으로) 하루에 200,000 개 이상의 페이지 뷰를 기록 할 수 있습니다. 이는 초당 2 회의 쿼리를 의미합니다.

답변

6

일반 규칙은 감사 테이블에 제약 조건 (기본, 외부 등)이 없으며 인덱스가 아니라는 점입니다. 위의 경우 모두 삽입 속도가 느려집니다.

벌크 삽입은 데이터베이스에 필요한 연결 수를 줄이기 위해 삽입을 일괄 적으로 고려하여 작업에 소요되는 시간 (한 대 다수)을 고려해야합니다. 또한 트랜잭션 로그가 이에 대해 작성된 경우 - 특정 시점에 데이터베이스를 부활시킬 수 있기를 원하면 IO에 쓰기를 요구함으로써 데이터베이스가 영향을받을 수 있기 때문에 쓰기 작업을 최소화하십시오.

하루가 끝날 때 기록을 삭제할 시점이 없습니다. 2 일 동안 발생한 트래픽은 어떻게됩니까? MySQL partitioning would likely be a better idea.

+0

레코드 지우기의 요점은 그들은 보고서에 제출 될 것이고 이후에 그들에 대한 필요성은 없을 것입니다. – John

+2

@ 존 : 귀하의 시스템이지만, 월, 연도, 시간을 합산하면 시스템에 더 많은 가치를 제공 할 수 있습니다. –

+0

글쎄, 그건 내가 가정 한 시스템에 달려있다 : P 그러나이 경우 실제로 하루 후에 데이터를 보관할 필요가 없다. 감사! – John

2

문제는 하루에 페이지 뷰가 아닙니다. 피크 시간대에 얼마나 많은 페이지 뷰를 초당 제공해야하는지 생각해야합니다. 페이지 뷰가 균등하게 퍼져 있고 초당 페이지 뷰 수가 2 개인 경우 평균 비공유 서버에서는 문제가되지 않습니다.

하지만 어떤 하드웨어는 등, 실제 페이지로드 분배,

+2

초당 +1 개의 쿼리는 전혀 중요하지 않습니다. –

+1

데이터베이스가 웹 사이트의 컨텐트도 제공한다고 가정하면, 두 번째/등의 통계에 대한 이러한 삽입보다 훨씬 많은로드가 발생합니다. –

-1

를 사용하는 것처럼 당신이해야한다고 생각, 더 많은 데이터없이 결정할 불가능 :

  1. 외래 키를 제거합니다. 이 경우에는 중복 된 것 같습니다. 각 INSERT/UPDATE/DELETE db에서 FK를 사용하면 db는 테이블 데이터 무결성을 검사하기위한 추가 자원을 소비합니다. 로깅을 위해 필요하지 않습니다. 성능과 빠른 응답이 필요합니다.
  2. myisam을 사용하십시오. MyIsam 엔진은 더 간단합니다. Innodb에서와 같이 트랜잭션 로깅, 저널링 등과 같은 여러 가지 추가 리소스에 리소스를 사용하지 않습니다.
  3. 한 행이 아닌 일괄 처리에 대한 인덱스 삽입 및 플러시에는 INSERT DELAYED를 사용하십시오. 자세한 내용은 http://dev.mysql.com/doc/refman/5.5/en/insert-delayed.html을 참조하십시오. 각 삽입 쿼리 db에서 일부 작업을 수행하고 그 중 하나는 플러시 인덱스입니다. 20 개의 쿼리를 실행하면 20 회의 플러시가 수행됩니다. INSERT DELAYED는 쿼리를 일괄 처리하여 하나의 쿼리처럼 실행합니다. 그래서 당신은 한 번만 홍조를 얻습니다.
+0

'INSERT DELAYED'는 여기에 로깅하기에는 좋지 않을 수 있습니다. 삽입 된 행을 다른 세션에서 즉시 볼 수 있어야 다음 삽입을 방지 할 수 있습니다 - 지연된 INSERT는 시간을 보장하지 않습니다 – Crack

+0

고유 키와 INSERT DELAYED IGNORE로이를 수정해야합니다 문제. –

+1

왜 My ISAM을 사용합니까? 도달 범위 삽입을 위해 전체 테이블을 잠급니다. 이는 삽입이 동시에 발생할 수 없음을 의미합니다. InnoDB는 행 레벨 잠금을 사용합니다. –

0

테이블에 적절한 색인이 있는지 확인하십시오. 데이터베이스 관리 시스템은 그 이상을 견딜 수 있도록 만들어졌습니다.

+0

감사 테이블은 일반적으로 무거운 삽입/etc, 낮은 읽기 때문에 인덱스에 값이 거의 없거나 거의 없습니다. 색인이 삽입 속도를 늦추므로 ... –

+0

John은 특정 사용자가 최근에 자신의 웹 사이트를 방문했는지 여부를 확인하려는 경우 필요하며 쿠키를 통해 수행된다는 표시가 나타나지 않습니다. – Crack

-2

아마 당신의 mysql 클러스터가 최적화되어 있는지 확인하고 변형이있을 수 있습니다. 그런 식으로 맞을 준비가되어 있는지 확인하십시오.

2

몇 가지 의견 :

  • 이이 InnoDB의 테이블에 있는지 확인합니다. MyISAM은 모든 삽입 또는 업데이트에 대해 전체 테이블을 잠그는 반면 InnoDB는 행 수준 잠금을 사용합니다.
  • 각 열에 적합한 가장 작은 숫자 데이터 형식을 사용하십시오.
  • 초당 두 개의 쿼리가 필요합니까? MySQL은 아침 식사 전에 초당 두 개의 쿼리를받습니다. 진심으로, 당신은 수백을 견딜 수 있어야합니다.
  • 여전히 걱정이된다면 InnoDB 테이블에서 훨씬 더 나은 동시성이 가능하므로 MySQL 5.1 이상을 사용하고 있는지 확인하십시오.
  • 'foreign'키는 코드 및 규칙을 통해서만 적용되며 엄격한 제약 조건으로 적용되지 않아야합니다. 이렇게하면 삽입 속도가 느려질 수 있습니다.