0

저희 회사는 최근 고객에게 POS (금전 등록기) 애플리케이션을 제공하기 위해 프랜차이즈에 가입하여 매주 3-5 건의 신규 가입을 진행하고 있습니다. 현재 우리는 모든 신규 고객에 대해 응용 프로그램 데이터베이스의 사본을 작성하지만,이 접근법으로 인해 우리를 분쇄 할 수 있다고 이미 말할 수 있습니다. 각 테이블에서 클라이언트 ID의 형식으로 식별되는 모든 클리닉에 대해 하나의 데이터베이스를 사용하는 것이 가장 좋을지도 모른다고 생각했습니다.많은 레코드 집합을 가진 데이터베이스가 읽기 속도에 영향을 줍니까? (MySQL)

이제 우리는 그 주제에 대해 약간의 논쟁을 벌였습니다. 한 동료는 50,000 개의 대형 테이블을 사용하면 작업 속도가 느려지고 응용 프로그램 전체를 최적화해야한다고 말하고있었습니다. 또 다른 동료는 MySQL이 대용량 데이터베이스를 처리하도록 설계되었다고 말하면서, 각 쿼리 WHERE 절에 클라이언트 ID를 지정하면 사실상 속도 변화가없는 데이터의 하위 집합을 받게됩니다.

대형 테이블 (100,000+)에서 데이터의 하위 집합을 선택하면 더 작은 테이블에서 동일한 수의 행을 선택하는 것과 큰 차이가 있습니까?

또한 데이터베이스 디자인을 위해 어떤 방향으로 나아갈 지에 대한 모든 권장 사항을 높이 평가할 것입니다.

+0

아니요, 100k 레코드는 상대적으로 작은 테이블입니다. 데이터베이스 서버가 충분하면 성능에 미치는 영향은 미미합니다. 모든 것과 마찬가지로 먼저 테스트해야합니다. 그러나 고객은 경쟁사의 데이터와 데이터를 병합하고 싶지 않을 수도 있음을 명심해야합니다. – Ben

답변

1

데이터 크기가 일 때은 성능에 영향을 미치지 만 적절한 색인 생성을 수행하면 50-100k 레코드의 조회가 문제가되어서는 안됩니다. 작업하는 프로덕션 데이터베이스 (~ 125 만 레코드)는 기본 키로 레코드를 조회 할 때 무시할 수있는 시간 (0.005 초 미만)이 소요됩니다.

여전히 실제 사용에 따라 다릅니다. 일부 쿼리를 최적화하고 추가 인덱스를 추가해야 할 수도 있습니다.

0

저는 하나의 길고 큰 테이블 대신 여러 개의 작은 테이블로 나눠 보았습니다. 디자인되고 올바르게 색인 된 경우, 장기적으로는 더 빠를 것입니다.

+2

귀하의 진술에 대한 귀하의 이유는 무엇입니까? – Ben

0

선택 (읽기) 쿼리의 속도를 높이려면 쿼리 할 열에 인덱스를 추가 할 수 있습니다.

예를 들어 일종의 클리닉 식별자로 쿼리하면 해당 열에 인덱스를 넣을 수 있습니다. 이렇게하면 데이터베이스가 데이터를 트래버스하고 데이터베이스의 모든 레코드를 보지 않고 조건에 맞는 레코드를 찾을 수 있습니다 (속도 저하가 발생하는 곳입니다). 미래에 다른 기준 (날짜를 말하자)으로 쿼리하면 해당 열에도 인덱스를 추가 할 수 있습니다.

인덱스를 추가하면 런타임 성능이 향상되지만 데이터를 저장하는 데 필요한 실제 디스크 크기가 늘어납니다.

+0

나는 색인이 그 질문에 함축되어 있다고 생각한다. – Ben

+0

질문에 상황에 대한 단서가 내 답변의 세부 수준에 영향을주었습니다. – rynmrtn

관련 문제