답변:
실제 데이터베이스 크기는 중요하지 않습니다. 레코드 수는 중요하지 않습니다.
내 경험상 가장 큰 문제는 크기가 아니라 한 번에 처리 할 수있는 쿼리 수입니다. 읽기 쿼리가 슬레이브에 대해 실행될 수 있고 쓰기 쿼리가 마스터에 대해 실행될 수 있도록 마스터 / 슬레이브 구성으로 이동해야 할 가능성이 높습니다. 그러나 아직 준비가되지 않은 경우, 실행중인 쿼리에 대한 색인을 조정하여 응답 시간을 단축 할 수 있습니다. 또한 리눅스의 네트워크 스택과 커널에 도움이 될 많은 조정이 있습니다.
나는 적당한 수의 연결로 10GB를 얻었고 요청을 잘 처리했습니다.
먼저 인덱스에 중점을 둔 다음 서버 관리자에게 OS를 살펴보고 도움이되지 않으면 마스터 / 슬레이브 구성을 구현해야 할 때입니다.
일반적으로 이것은 매우 미묘한 문제이며 사소한 것이 아닙니다. mysqlperformanceblog.com 과 High Performance MySQL 을 읽어 보시기 바랍니다 . 나는 이것에 대한 일반적인 대답이 없다고 생각합니다.
거의 1TB의 데이터가있는 MySQL 데이터베이스가있는 프로젝트를 진행 중입니다. 가장 중요한 확장 성 요소는 RAM입니다. 테이블 인덱스가 메모리에 적합하고 쿼리가 고도로 최적화 된 경우 평균 시스템으로 합리적인 양의 요청을 처리 할 수 있습니다.
테이블의 모양에 따라 레코드 수가 중요합니다. varchar 필드가 많거나 int 또는 long이 몇 개인 경우 차이가 있습니다.
데이터베이스의 물리적 크기도 중요합니다. 예를 들어 백업을 고려하십시오. 엔진에 따라 실제 DB 파일은 증가하지만 innodb와 같이 축소되지는 않습니다. 따라서 많은 행을 삭제해도 실제 파일을 축소하는 데 도움이되지 않습니다.
이 문제에는 많은 것이 있으며 많은 경우 악마가 세부 사항에 있습니다.
데이터베이스 크기 는 중요 합니다. 백만 개 이상의 레코드가있는 테이블이 둘 이상 있으면 성능이 실제로 저하되기 시작합니다. 레코드 수는 물론 성능에 영향을 미칩니다. MySQL은 큰 테이블에서 느릴 수 있습니다 . 백만 개의 레코드를 기록하면 인덱스가 올바르게 설정되지 않은 경우 성능 문제가 발생합니다 (예 : 조인의 "WHERE 문"또는 "ON 조건"필드에 대한 인덱스가 없음). 천만 개의 레코드를 기록하면 모든 인덱스가 올바른 경우에도 성능 문제가 발생하기 시작합니다. 더 많은 메모리와 더 많은 프로세서 성능, 특히 메모리를 추가하는 하드웨어 업그레이드는 성능을 적어도 어느 정도 다시 높여서 가장 심각한 문제를 줄이는 데 도움이됩니다. 예를 들어Basecamp 데이터베이스 서버의 경우 37 개의 신호가 32GB RAM에서 128GB RAM으로 변경 되었습니다.
현재 160GB로 성장한 아마존의 클라우드 인프라에서 MySQL 데이터베이스를 관리하고 있습니다. 쿼리 성능이 좋습니다. 악몽이 된 것은 백업, 복원, 슬레이브 추가 또는 전체 데이터 세트를 처리하는 다른 것 또는 큰 테이블의 DDL입니다. 덤프 파일을 완전히 가져 오는 것이 문제가되었습니다. 프로세스를 자동화하기에 충분히 안정적으로 만들려면 성능보다 안정성을 우선시하기 위해 다양한 선택이 필요했습니다. SQL 백업을 사용하여 재해로부터 복구해야한다면 며칠 동안 다운되었을 것입니다.
수평 적으로 SQL을 확장하는 것은 상당히 고통스럽기 때문에 대부분의 경우 SQL에 데이터를 처음에 배치하려고 할 때 의도하지 않은 방식으로 SQL을 사용하게됩니다. 샤드, 읽기 슬레이브, 멀티 마스터 등은 모두 DB로 수행하는 모든 작업에 복잡성을 추가하는 문제이며, 그 중 하나가 문제를 해결하지는 않습니다. 몇 가지 방법으로 만 완화시킵니다. 이러한 유형의 문제가 발생하는 크기의 데이터 세트에 접근하기 시작할 때 일부 데이터를 MySQL (또는 실제로 모든 SQL)에서 옮기는 것이 좋습니다.
복잡한 조인도 조심하십시오. 거래량 외에도 거래의 복잡성이 큰 요인이 될 수 있습니다.
많은 쿼리를 리팩토링하면 성능이 크게 향상되는 경우가 있습니다.
나는 한 번 "작동을 멈춘"mysql을 보라는 요청을 받았다. DB 파일이 NFS2로 마운트되고 최대 파일 크기가 2GB 인 Network Appliance 파일러에 상주하고 있음을 발견했습니다. 그리고 트랜잭션 수락을 중단 한 테이블은 디스크에서 정확히 2GB였습니다. 그러나 성능 곡선과 관련하여 전혀 작동하지 않을 때까지 챔피언처럼 작동한다고 들었습니다! 이 경험은 항상 당신이 자연스럽게 의심하는 것의 위와 아래에 치수가 있다는 것을 상기시켜줍니다.
쿼리 성능은 주로 스캔해야하는 레코드 수에 따라 달라지며 인덱스가 그 역할을 수행하며 인덱스 데이터 크기는 행 수와 인덱스 수에 비례합니다.
전체 값과 함께 색인화 된 필드 조건이있는 쿼리는 일반적으로 1ms로 반환되지만 starts_with, IN, Between 사이에는 분명히 포함하는 조건에 더 많은 레코드를 스캔하는 데 시간이 더 걸릴 수 있습니다.
또한 ALTER와 같은 DDL의 유지 관리 문제가 많이 발생합니다. DROP은 인덱스 또는 새 열을 추가하더라도 라이브 트래픽이 많을수록 느리고 어려울 것입니다.
일반적으로 데이터베이스를 필요한만큼 많은 클러스터로 클러스터링하는 것이 좋습니다 (500GB는 일반적인 벤치 마크 일 것입니다. 다른 요소에 따르면 많은 요소에 따라 다르고 사용 사례에 따라 다를 수 있음). 클러스터 (B2B의 경우 더 적합)