MySQL 및 1억 개 이상의 행이 있는 테이블

MySQL 및 1억 개 이상의 행이 있는 테이블

저는 1억 개 이상의 행이 있는 테이블을 몇 개 가지고 있습니다.저는 매달 2천만에서 4천만 줄의 줄을 받습니다.

지금은 모든 것이 괜찮은 것 같습니다. - 모든 삽입이 빠릅니다. - 모든 선택이 빠릅니다. (인덱스를 사용하고 복잡한 집계를 사용하지 않습니다.)

그러나 저는 두 가지가 걱정됩니다. - 테이블에 수억 개의 행이 있을 경우 인덱스(바이너리 트리)를 다시 조정하는 데 시간이 오래 걸릴 수 있기 때문에 느린 삽입이 있을 수 있습니다. - 인덱스가 메모리에 맞지 않으면 디스크의 여러 부분에서 인덱스를 읽는 데 시간이 걸릴 수 있습니다.

어떤 의견이라도 주시면 대단히 감사하겠습니다.문제가 발생할 경우 이를 방지하거나 문제를 해결/완화할 수 있는 방법을 제안해 주시면 대단히 감사하겠습니다.

(언젠가 샤딩을 시작해야 한다는 것을 알고 있습니다)

미리 감사드립니다.

오늘은 100MM 행을 사용하고 있고 매달 ~30MM을 사용할 경우 3개월 안에 그 크기를 두 배로 늘릴 수 있으며, 올해가 가기 전에 다시 두 배로 늘릴 수도 있기 때문에 분할 또는 분할에 대해 생각해봐야 할 날입니다.

어느 시점에서 데이터베이스가 너무 커서 마이그레이션할 수 없는 이벤트 지평선에 도달하게 됩니다.디스크에 작업 공간이 충분하지 않아 대체 스키마로 전환할 수 없거나, 마이그레이션을 다시 실행하기 전에 마이그레이션을 수행할 다운타임이 부족합니다.그러면 여러분은 점점 더 느려지면서 그것을 영원히 간직하게 될 것입니다.

표에 대한 쓰기 작업의 성능은 주로 지수를 유지하기가 얼마나 어려운지에 따라 결정됩니다.데이터를 더 많이 색인화할수록 쓰기 작업이 더 까다로워질 수 있습니다.인덱스 유형은 모두 관련성이 있으며, 일부는 다른 인덱스보다 더 압축적입니다.데이터가 약간 인덱싱되어 있는 경우 일반적으로 작업 속도가 급격히 느려지기 전에 더 많은 레코드를 저장할 수 있지만, 시스템 구성, 하드웨어 및 IO 용량에 따라 성능 저하 요인이 크게 좌우됩니다.

사용해야 할 엔진인 InnoDB에는 수많은 튜닝 파라미터가 있으며 많은 사람들이 이를 매우 끔찍한 기본값으로 설정한다는 것을 기억하십시오.여기에 할당된 메모리를 보고 제대로 하고 있는지 확인합니다.

데이터를 월별, 고객별로 분할할 수 있는 방법이나 비즈니스 논리에 따라 변경되지 않는 다른 요소가 있다면 데이터는 본질적으로 관련이 없는 단순한 옵션을 많이 선택할 수 있을 것입니다.그렇지 않다면, 여러분은 어려운 결정을 내려야 할 것입니다.

여러분이 지금 하고 싶은 한 가지는 1G 행으로 테이블의 성능이 어떤지 시뮬레이션하는 것입니다.충분히 크고 적절하게 다양한 양의 테스트 데이터를 생성한 다음 로드 상태에서 얼마나 잘 수행되는지 확인합니다.문제가 아니라는 것을 알게 될 수도 있습니다. 그런 경우에는 몇 년 더 걱정할 필요가 없습니다.그렇지 않다면 데이터가 너무 커서 분할할 수 없게 되기 전에 지금 바로 당황하여 솔루션을 구축해야 합니다.

데이터베이스 성능은 일반적으로 상당히 선형적인 방식으로 저하되며, 어느 시점에서 벼랑 끝으로 떨어집니다.이 절벽이 어디에 있는지 알아야 부딪히기 전에 시간이 얼마나 남았는지 알 수 있습니다.성능이 급격히 저하되는 경우는 대개 인덱스가 메모리에 맞지 않을 때와 디스크 버퍼가 너무 얇아 유용하지 않을 때입니다.

OP와 다른 응답자들이 만들고 있는 요점을 해결하기 위해 노력하겠습니다.질문은 표면에만 닿으며, 이 답변은 그 뒤를 따릅니다.좀 더 초점을 맞춘 질문에 대해 자세히 알아볼 수 있습니다.

• 1조 줄은 주사위를 던집니다.100M이 꼭 문제가 되는 것은 아닙니다.
• 파티셔닝은 성능 향상을 위한 수단이 아닙니다.유용한 방법으로 사용할 수 있는 주요한 경우는 "오래된" 데이터를 삭제해야 할 때입니다. (DROP PARTITION다보다 .DELETEing000,000,000 줄의 행
• INSERTs의 소리와 함께AUTO_INCREMENT PRIMARY KEY절대로 속도를 줄이지 않을 겁니다 이는 키 됩니다.이는 모든 시간적 키 및/또는 작은 "핫 스팟" 집합에 적용됩니다.ePRIMARY KEY(stock_id, date)재고가 있는 만큼의 핫스팟으로 제한됩니다.
• INSERTsPRIMARY KEY점점 더 느려질 겁니다 됩니다.그러나 이는 임의의 "랜덤" 키에 적용됩니다.
• 보조 인덱스는 나중에 PK와 동일한 문제가 발생합니다.BTree의 크기에 따라 달라지기 때문입니다. (PK가 주문한 데이터의 BTree는 대개 각 보조 키보다 큽니다.)
• 인덱스(PK 포함)가 "메모리에 적합"한지 여부는 삽입값이 '랜덤'인 경우(UUID와 같이)에만 중요합니다.
• Data Warehouse 애플리케이션의 경우, 일반적으로 'Fact' 테이블에 추가 인덱스 대신 Summary Table을 제공하는 것이 좋습니다.이렇게 하면 최대 10배 빠른 "보고" 쿼리가 생성됩니다.
• 맹목적으로 사용함AUTO_INCREMENT 최적보다 작을 수 있습니다.
• 백만 행 테이블의 데이터 또는 인덱스에 대한 B트리는 약 3단계 깊이입니다.1조 행, 6단계.이러한 "레벨 수"는 성능에 어느 정도 영향을 미칩니다.
• 이진 트리는 사용되지 않으며 대신 BT 트리(실제로 B+Tree)는 InnoDB에서 사용됩니다.
• InnoDB는 많은 노력을 들이지 않고도 대부분 BT트리의 균형을 유지합니다.걱정하지 마세요. (그리고 사용하지 마세요.OPTIMIZE TABLE.)
• 모든 작업은 16KB 블록(데이터 또는 인덱스)에서 수행되며 RAM(buffer_pool)에서 수행됩니다.테이블이나 인덱스 모두 RAM에 "로딩"되지 않으며, 적어도 전체 단위로는 명시적이지 않습니다.
• 복제는 읽기 확장에 유용합니다. (MySQL에서도 쉽게 사용할 수 있습니다.)
• 샤딩은 쓰기 스케일링에 유용합니다.(이것은 DYI 작업입니다.)
• 경험칙에 따라 디스크의 절반을 사용 가능한 상태로 유지하여 커다란 테이블에 다양한 관리 목적으로 사용할 수 있습니다.
• 테이블이 여러 GB 크기 범위에 들어가기 전에 데이터 유형과 정규화를 다시 생각해 보는 것이 좋습니다.
• InnoDB(요즘)에서 주요 조정 가능한 것입니다.innodb_buffer_pool_size, (우선) 사용 가능한 RAM의 약 70%가 되어야 합니다.
• Row_format= compressed는 사용할 가치가 없는 경우가 많습니다.
• 유튜브, 페이스북, 구글 등은 이번 Q&A에서 논의되는 것은 무엇이든 '넘어' 있습니다.수천 대의 서버, 맞춤형 소프트웨어 등을 사용합니다.

특정 애플리케이션에 대해 논의하고 싶다면 자세한 내용을 확인해 보겠습니다.서로 다른 앱은 서로 다른 기술을 필요로 합니다.

위의 많은 주제에 대해 더 자세한 정보를 제공하는 내 블로그: http://mysql.rjweb.org

언급URL : https://stackoverflow.com/questions/38346613/mysql-and-a-table-with-100-millions-of-rows