MySQL 데이터베이스는 어떤 시점에서 성능을 잃기 시작합니까?
- 실제 데이터베이스 크기가 중요합니까?
- 많은 레코드가 중요합니까?
- 성능 저하가 선형 또는 지수입니까?
나는 거의 2GB를 차지하는 약 15M의 레코드를 가진 큰 데이터베이스라고 생각합니다. 이 수치를 기준으로 데이터를 정리할 인센티브가 있습니까? 아니면 몇 년 동안 데이터를 계속 확장 할 수 있습니까?
답변
실제 데이터베이스 크기는 중요하지 않습니다. 레코드 수는 중요하지 않습니다.
내 경험상 가장 큰 문제는 크기가 아니라 한 번에 처리 할 수있는 쿼리 수입니다. 읽기 쿼리가 슬레이브에 대해 실행될 수 있고 쓰기 쿼리가 마스터에 대해 실행될 수 있도록 마스터 / 슬레이브 구성으로 이동해야 할 가능성이 높습니다. 그러나 아직 준비가되지 않은 경우, 실행중인 쿼리에 대한 색인을 조정하여 응답 시간을 단축 할 수 있습니다. 또한 리눅스의 네트워크 스택과 커널에 도움이 될 많은 조정이 있습니다.
나는 적당한 수의 연결로 10GB를 얻었고 요청을 잘 처리했습니다.
먼저 인덱스에 중점을 둔 다음 서버 관리자에게 OS를 살펴보고 도움이되지 않으면 마스터 / 슬레이브 구성을 구현해야 할 때입니다.
답변
일반적으로 이것은 매우 미묘한 문제이며 사소한 것이 아닙니다. mysqlperformanceblog.com 과 High Performance MySQL 을 읽어 보시기 바랍니다 . 나는 이것에 대한 일반적인 대답이 없다고 생각합니다.
거의 1TB의 데이터가있는 MySQL 데이터베이스가있는 프로젝트를 진행 중입니다. 가장 중요한 확장 성 요소는 RAM입니다. 테이블 인덱스가 메모리에 적합하고 쿼리가 고도로 최적화 된 경우 평균 시스템으로 합리적인 양의 요청을 처리 할 수 있습니다.
테이블의 모양에 따라 레코드 수가 중요합니다. varchar 필드가 많거나 int 또는 long이 몇 개인 경우 차이가 있습니다.
데이터베이스의 물리적 크기도 중요합니다. 예를 들어 백업을 고려하십시오. 엔진에 따라 실제 DB 파일은 증가하지만 innodb와 같이 축소되지는 않습니다. 따라서 많은 행을 삭제해도 실제 파일을 축소하는 데 도움이되지 않습니다.
이 문제에는 많은 것이 있으며 많은 경우 악마가 세부 사항에 있습니다.
답변
데이터베이스 크기 는 중요 합니다. 백만 개 이상의 레코드가있는 테이블이 둘 이상 있으면 성능이 실제로 저하되기 시작합니다. 레코드 수는 물론 성능에 영향을 미칩니다. MySQL은 큰 테이블에서 느릴 수 있습니다 . 백만 개의 레코드를 기록하면 인덱스가 올바르게 설정되지 않은 경우 성능 문제가 발생합니다 (예 : 조인의 “WHERE 문”또는 “ON 조건”필드에 대한 인덱스가 없음). 천만 개의 레코드를 기록하면 모든 인덱스가 올바른 경우에도 성능 문제가 발생하기 시작합니다. 더 많은 메모리와 더 많은 프로세서 성능, 특히 메모리를 추가하는 하드웨어 업그레이드는 성능을 적어도 어느 정도 다시 높여서 가장 심각한 문제를 줄이는 데 도움이됩니다. 예를 들어Basecamp 데이터베이스 서버의 경우 37 개의 신호가 32GB RAM에서 128GB RAM으로 변경 되었습니다.
답변
서버 관리자가 OS를 살펴 보는 것보다 먼저 인덱스에 중점을 둘 것이며, 도움이되지 않는 경우 마스터 / 슬레이브 구성을위한 시간 일 수 있습니다.
사실입니다. 일반적으로 작동하는 또 다른 것은 반복적으로 작업하는 데이터의 양을 줄이는 것입니다. “이전 데이터”와 “새 데이터”가 있고 쿼리의 99 %가 새 데이터와 함께 작동하는 경우 모든 이전 데이터를 다른 테이블로 이동하십시오.
-> 파티셔닝을 살펴보십시오 .
답변
2GB 및 약 15M 레코드는 매우 작은 데이터베이스입니다. 펜티엄 III (!)에서 훨씬 더 큰 데이터베이스를 실행했지만 모든 것이 여전히 빠르게 실행됩니다. 느린 경우 mysql이 아닌 데이터베이스 / 애플리케이션 디자인 문제입니다. 하나.
답변
“데이터베이스 성능”, “쿼리 성능”은 여기서 더 나은 용어입니다. 대답은 쿼리, 쿼리가 작동하는 데이터, 인덱스, 하드웨어 등에 따라 달라집니다. 스캔 할 행 수와 EXPLAIN 구문과 함께 사용할 인덱스에 대한 아이디어를 얻을 수 있습니다.
2GB는 실제로 “큰”데이터베이스로 계산되지 않습니다. 중간 크기에 가깝습니다.
답변
현재 160GB로 성장한 아마존의 클라우드 인프라에서 MySQL 데이터베이스를 관리하고 있습니다. 쿼리 성능이 좋습니다. 악몽이 된 것은 백업, 복원, 슬레이브 추가 또는 전체 데이터 세트를 처리하는 다른 것 또는 큰 테이블의 DDL입니다. 덤프 파일을 완전히 가져 오는 것이 문제가되었습니다. 프로세스를 자동화하기에 충분히 안정적으로 만들려면 성능보다 안정성을 우선시하기 위해 다양한 선택이 필요했습니다. SQL 백업을 사용하여 재해로부터 복구해야한다면 며칠 동안 다운되었을 것입니다.
수평 적으로 SQL을 확장하는 것은 상당히 고통스럽기 때문에 대부분의 경우 SQL에 데이터를 처음에 배치하려고 할 때 의도하지 않은 방식으로 SQL을 사용하게됩니다. 샤드, 읽기 슬레이브, 멀티 마스터 등은 모두 DB로 수행하는 모든 작업에 복잡성을 추가하는 문제이며, 그 중 하나가 문제를 해결하지는 않습니다. 몇 가지 방법으로 만 완화시킵니다. 이러한 유형의 문제가 발생하는 크기의 데이터 세트에 접근하기 시작할 때 일부 데이터를 MySQL (또는 실제로 모든 SQL)에서 옮기는 것이 좋습니다.
