언제 데이터베이스를 파티션하고 싶지 않습니까? ( MySQL 파티셔닝 생각 )
나의 경우에는
마지막 시점에서도 조회가 병렬로 실행되지 않으므로 모든 경우에 이것이 승리 입니까? 파티셔닝의 단점은 무엇입니까? 적어도 백만 개 이상의 레코드를 볼 때 왜 모두가 기본적으로 사용하는 것이 아닌가?
업데이트-나는 zgguy의 답변을 선택했지만 나에게 매우 유용한 비슷한 질문에 대한 정말 좋은 답변에 대한 링크를 포함하여 내 연구 결과와 함께 내 자신의 답변을 추가했습니다.
답변:
성능 문제에 대한 은색 글 머리 기호가 없으며 분할도 마찬가지입니다.
모든 파티션은 본질적으로 자체 테이블입니다. 따라서 데이터베이스가 한 파티션에서만 행을 찾을 수 있도록 작성된 쿼리가 더 빨라집니다. 큰 전체 테이블을 스캔해야하지만 쿼리가 분할 된 테이블에서 하나의 파티션 만 스캔하도록 제한 할 수있는 쿼리에는 차이가 클 수 있습니다. 고유 한 키 조회의 경우 차이가 훨씬 작습니다.
그러나 데이터베이스가 모든 또는 대부분의 테이블 (인덱스) 파티션을 방문해야하는 방식으로 인덱스 조회를 사용하는 쿼리는 상당히 느리게 실행됩니다.
병렬 실행은 자체 주제입니다. 밤새 큰 일괄 처리를 실행하고 전체 작업을 수행하여 단일 작업을 수행하는 경우 병렬 처리가 좋습니다. 그러나 데이터베이스가 많은 동시 사용자의 쿼리를 지속적으로 제공하는 OLTP 시스템에서는 한 명의 사용자가 모든 리소스를 차지하지 않기를 원합니다.
여기에 대한 답변 은 잘 작성되어 있으며 zgguy의 답변 과 비슷한 주장을 합니다. 파티셔닝은 기본 키 또는 이와 유사한 것으로 인해 가장 빈번한 조회가 가정되는 단일 머신 시나리오에 도움이되지 않습니다. 색인 된 조회는 속도가 빨라야합니다).
사실, 일반적인 조언은 분할의 주된 이유가 탄젠트이며 대부분 관리와 관련된 것입니다. 예를 들어 오래된 레코드를 너무 자주 제거해야하는 경우 날짜를 기준으로 데이터를 분리하십시오. 데이터가 대부분의 모든 쿼리가 최근에 추가 된 레코드에만 적중 할 경우 조회 성능에 도움이 될 수 있습니다.
또한 MySQL이 병렬로 아무것도하지 않는다는 언급을 보았습니다 (링크에 대한 자세한 설명이나 자세한 설명은 좋을 것입니다).
글쓰기 활동이 다른 고려 사항을 추가하는지 아닌지 말하는 사람은 없습니다.
가장 먼저 염두에 두어야 할 것은 파티션 정리입니다 . 그렇지 않으면 쿼리에서 사용할 수있는 것이 아닙니다.
파티셔닝이 도움이되므로 테이블에서 많은 양의 데이터를 제거해야합니까? 오래되었지만 피터의이 게시물은 고려해야 할 몇 가지 사항이 있습니다.
그리고 생각할 수있는 또 다른 것은 간단한 테이블의 사용 편의성입니다. 파티셔닝에는 추가 작업과 유지 관리가 필요합니다.