큰 테이블 구성 및 최적화

Question

나는 속도가 중요한 예측 다이얼러를 구축하고 있습니다. 번호를 다이얼하려면 테이블에서 고객 정보를 가져오고 pbx가 작동하도록 호출 파일을 작성하십시오.

현재 각 지역 번호에 대한 표가 있으며 한 번에 하나의 지역 번호로 전화를 걸지만 여러 우편 번호로 연결된 지역을 기반으로 전화를 걸 모델로 전환하고 있습니다. 일부 지역 코드는 여러 우편 번호로 존재합니다. 각 테이블에는 매월 추가 된 새로운 번호가 있으며, 수백만 개의 전화 번호 목록과 비교하여 제거됩니다.

내 질문에, 어떻게이 데이터를 가장 효율적으로 구성해야합니까?

큰 테이블 하나는 생산성이 떨어지는 것처럼 보입니다. 우리는 수백만 건의 문질러 쓴 데이터를 기록하고 있습니다.

현재 나의 추론 방법은 가져 오기 및 스크러빙을 위해 지역 코드 테이블을 유지 한 다음 지역의 우편 번호에 대한 지역 코드 테이블을 검색하여 작성된 영역 테이블로 스크럽 된 레코드를 복사하는 것입니다.

현재 auto_incremented INT 기본 키, 고유 전화 번호 및 이미 호출되었거나 do-not-call 목록에있는 번호를 추적하는 상태로 테이블을 인덱싱합니다. 호출 파일을 작성할 때 레코드를 대기 상태로 표시 한 다음 호출이 완료되면 호출 방법에 따라 표시합니다. 따라서 각 호출에 대해 검색과 두 가지 업데이트가 있습니다.

검색은 지역 코드 표에서 특정 상태를 찾습니다. 업데이트는 레코드 ID를 기반으로 발생합니다.

질문의 성토는 다음과 같습니다. 우편 번호로 정리하고 상태로 검색하거나 지역 번호별로 정렬하고 상태 및 우편 번호로 검색하는 것이 더 빠릅니까? 아니면 지역 코드 테이블에서 지어진 지역을 설정할 때마다 새 테이블을 만드는 것이 더 나은 방법일까요?

어리석은 질문 인 것처럼 여겨지면 용서해주십시오. 저는 이것을 구축하면서 SQL을 가르쳐 왔으며, 데이터베이스 설계 및 성능의 미묘한 차이는 제 능력을 뛰어 넘었습니다.

테이블의 총 크기는 2 백만 행으로 늘어납니다.

Answer 1

질문의 성토는 다음과 같습니다. 우편 번호로 정리하고 상태로 검색하거나 지역 번호별로 정렬하고 상태 및 우편 번호로 검색하는 것이 더 빠릅니까? 아니면 지역 코드 테이블에서 지어진 지역을 설정할 때마다 새 테이블을 만드는 것이 더 나은 방법일까요?

답변 : 당신이하고있는 일을 실제로 알지 못한다면 아무 것도하지 마십시오. 대신 엔티티의 모든 행을 보유 할 테이블을 하나 만들고 컬럼 값을 사용하여 다양한 우편 번호와 지역을 구별하십시오. 가능하면 zipcodes 및 territory 테이블을 만들고이를 참조하는 외래 키를 추가하십시오.속성 값에 따라 별도의 테이블을 생성

는 일반적인 해결책이 아니라, 많은 추가적인 어려움을 소개합니다 (당신이 모든 우편 번호를 통해 영토로 검색 어떻게 우편 번호에 의해 테이블로 구성 할 경우, 예를 들면?)

보다 일반적인 솔루션과 데이터베이스 성능이 뛰어날수록 인덱스를 사용하는 것이 좋습니다. 데이터베이스는 여러 인덱스를 사용하여 여러 다른 열의 검색을 위해 테이블에 빠르게 액세스 할 수 있습니다.

따라서 기본 전략은 내가 추천 :

이

1. 이
   • explain <query>이 매우 편리 성능을 분석 구현하는 물리적 데이터 모델
   • 을 논리적 데이터 모델
   • 을 만들
   • 이 있다면 충분하지 않다. 더 많은 인덱스 추가, 기존 인덱스 사용 개선 (클러스터 된 인덱스 및 커버 레이션 읽기) 또는 선택적 비정규 화
   • 선택과 삽입 사이의 균형은 무엇입니까? 인덱스는 삽입
   그것은 이백 만 행이 MySQL을위한 엄청난 양의 (물론,이 부하에 따라 달라집니다 있지만) 아니라는 것을주의하는 것도 중요

을 늦출 수 있습니다. 최종선은 최적화가 당신의 특정한 상황에 의존하는 아주 까다로운 주제라는 것입니다.

Answer 2

TaoNonnanes area code table에 매번 territory 테이블을 만들 필요가 없습니다.

외래 키가 area code table 인 영토 테이블을 하나만 만들면 영토와 지역 코드 테이블의 색인을 만들고 적어도 3NF까지 전체 데이터베이스를 표준화하려고 시도하십시오. 나는 전체 데이터베이스 정규화가 무엇인지 알지 못한다.

Answer 3

속도를 원하면 데이터를 정상화하지 않습니다. 데이터가 커지면 속도 성능이 떨어집니다.

이 경우 성능은하는 SSD는 성능을 많이 향상 수있는 하드 디스크의 속도에 넥타이 될 것입니다하지만 당신은 공간 문제를 가지고

는 무역 오프 사용 회전하는 디스크가 될 수 더 비싼 것 데이터를 표준화하지 마십시오. 검색을 수행하는 데 사용하는 필드의 색인을 생성합니다.

다른 전략 (더 영리한)은 데이터 세트를 반복하여 사용할 수있는 정수 코드를 사용할 수 있으며 memcache에서 우편 번호, 도시 등의 실제 값을 사용할 수 있습니다 (우편 번호, 국가 이름, 도시는 변경 불가능한 데이터)이 접근법은 문제에 새로운 의존성을 추가합니다.

2 억 5 천만 행의 표가 있으며이 정보에는 국가, 도시, 우편 번호 및 ISP 태그가 지정됩니다. 내가 ssd의 주요 데이터를 저장하고 지리적 데이터 memcached에 저장됩니다, 내가 검색을 할 필요가있을 때, 나는 논리적 인 레이어를 조회하고 데이터베이스에 코드를 번역 할 수 있습니다.