MySQL: 테이블이 많습니까, 아니면 데이터베이스가 많습니까?

MySQL: 테이블이 많습니까, 아니면 데이터베이스가 많습니까?

프로젝트에는 항상 같은 구조를 가지며 서로 연결되어 있지 않은 데이터가 많이 있습니다.데이터를 저장하는 방법에는 다음 두 가지가 있습니다.

• 모든 풀에 대해 새 데이터베이스 생성(약 15-25 테이블)
• 1개의 데이터베이스에 모든 테이블을 만들고 테이블 이름에 따라 풀을 달리합니다.

MySQL에서 더 쉽고 빠른 것은 무엇입니까?

편집: 데이터베이스 설계에는 관심이 없습니다.두 가지 가능성 중 어느 것이 더 빠른지 궁금할 뿐입니다.

EDIT 2: 좀 더 명확하게 설명하겠습니다.앞서 말한 바와 같이 데이터의 일부는 서로 다른 풀에 속하지 않습니다.한 유형의 모든 데이터를 한 테이블에 넣고 풀 ID로 링크하는 것은 좋지 않습니다.

• 특정 풀을 백업/삭제하는 것은 어렵다(또한 프라이머리 키는 시간이 지나면 고갈될 것으로 예상됨(대규모 int를 사용하는 경우에도 마찬가지)

%는 단순합니다.inserts 49%입니다.selects라라프프

는 어떤 이 더 처리되느냐는 것입니다.MySQL테이블이 많습니까, 데이터베이스가 많습니까?

단일 데이터베이스 내의 여러 테이블과 개별 데이터베이스 내의 여러 테이블 간에 성능 차이가 크지 않아야 합니다.

MySQL에서 데이터베이스(표준 SQL은 "schema"라는 용어를 사용)는 주로 테이블의 네임스페이스 역할을 합니다.데이터베이스에는 기본 문자 집합 및 대조와 같은 몇 가지 속성만 있습니다.그리고 그 사용법은GRANT를 사용하면 데이터베이스별 접근 권한을 쉽게 제어할 수 있지만 성능과는 무관합니다.

단일 연결을 통해 데이터베이스의 모든 테이블에 액세스할 수 있습니다(MySQL Server의 동일한 인스턴스에서 테이블을 관리하는 경우).테이블 이름만 수식하면 됩니다.

SELECT * FROM database17.accounts_table;

이것은 순전히 구문상의 차이입니다.퍼포먼스에 영향을 주지 않습니다.

스토리지에 관해서는 @Chris가 지정하는 대로 데이터베이스별로 테이블을 구성할 수 없습니다.MyISAM 스토리지 엔진에서는 테이블마다 항상 파일이 있습니다.InnoDB 스토리지 엔진에서는 모든 테이블을 통합하는 단일 스토리지 파일 세트가 있거나 테이블당 파일이 있습니다(이 설정은 데이터베이스가 아닌 MySQL 서버 전체에 대해 구성됨).어느 경우든 여러 데이터베이스에 비해 단일 데이터베이스에 테이블을 작성해도 성능상의 이점이나 단점은 없습니다.

데이터베이스당 작동하는 MySQL 구성 매개 변수가 많지 않습니다.서버 퍼포먼스에 영향을 주는 파라미터의 대부분은 서버 전체에 적용됩니다.

할 수 .mysqldump명령어를 입력합니다.명령줄의 모든 테이블에 이름을 붙일 필요 없이 데이터베이스별로 논리 테이블세트를 백업하는 것이 편리할 수 있습니다.그러나 성능에는 차이가 없습니다.백업 명령어를 입력할 때 편리할 뿐입니다.

풀(풀 포함)을 추적하기 위해 단일 테이블을 만드는 것은 어떨까요?ID 및 PoolName을 컬럼으로 하고 추적하는 다른 모든 테이블에 열을 추가하여 해당 레코드가 속한 풀을 알 수 있도록 풀테이블에 외부 키를 되돌립니다.

그렇게 데이터를 혼재시키고 싶지 않다면 여러 데이터베이스를 만드는 것이 좋습니다.같은 기능을 위해 여러 개의 테이블을 만들면 거미 느낌이 따끔거립니다.

수영장이 있는 테이블 세트를 원하지 않는 경우TXI가 제안한 ID 풀명은 동일한 작업을 수행하는 여러 테이블이 아닌 별도의 데이터베이스를 사용합니다.

이렇게 하면 서로 다른 풀에 대한 액세스 간의 변화를 첫 번째 "데이터베이스 사용" 문으로 제한할 수 있으므로 SELECT를 매번 재코딩하거나 동적 SQL을 사용할 필요가 없습니다.

이 접근방식의 다른 장점은 다음과 같습니다.

• 간단한 백업/복원
• 데이터베이스 인스턴스의 간단한 시작/중지

단점은 다음과 같습니다.

• 관리 업무는 조금 더 하지만, 많지는 않아요.

어떤 어플리케이션인지 모르겠지만 1개의 데이터베이스에 모든 테이블을 작성하기 전에 신중하게 생각해 주십시오.그런 식으로 광기가 거짓말이다.

편집: 퍼포먼스만 신경 쓴다면 퍼포먼스를 측정해야 합니다.대표적인 쿼리 세트를 취하여 성능을 측정합니다.

편집 2: 여러 테이블/많은 데이터베이스 모델 간의 단일 쿼리에 대한 성능 차이는 거의 없습니다.데이터베이스가 1개만 있으면 튜닝할 수 있습니다.데이터베이스가 많으면 모든 데이터베이스를 튜닝할 수 있습니다.

내 (다른 사용자를 위해 말할 수 없음) 요점은 잘 조정된 데이터베이스의 경우 세 가지 옵션(테이블 풀ID, 여러 테이블, 여러 데이터베이스) 간에 성능 차이가 거의 없기 때문에 단기적으로나 장기적으로나 가장 쉬운 옵션을 선택할 수 있다는 것입니다.

최적의 옵션은 여전히 TXI에서 권장한 바와 같이 poolId를 가진 데이터베이스 1개, 그리고 (대부분의 관리 요구에 따라) 여러 데이터베이스를 사용하는 것입니다.두 옵션의 성능 차이가 정확히 무엇인지 알아야 하는 경우에는 답변을 드릴 수 없습니다.셋업하고 테스트해야 합니다.

여러 데이터베이스를 사용하면 하드웨어를 쉽게 사용하여 성능을 향상시킬 수 있습니다.

당신이 설명한 상황에서는 많은 수의 풀이 있을 때 개별 데이터베이스가 더 빠를 것이라고 저는 믿게 되었습니다.

여기서 지켜야 할 중요한 일반적인 원칙이 있습니다.얼마나 빠를지 생각하지 말고 프로파일링 해

제가 당신의 시나리오를 완전히 이해했는지 잘 모르겠습니다.모든 풀을 동일한 테이블을 사용하여 구분 키만 다르게 설정하시겠습니까?또는 1개의 데이터베이스 내에 별도의 테이블 풀을 배치하고 각 테이블에 서픽스를 붙여 풀을 구별하시겠습니까?

그러나 어느 쪽이든 두 가지 주요 이유로 여러 데이터베이스를 사용해야 합니다.첫 번째는 한 풀의 스키마를 변경해야 하는 경우 다른 풀에는 영향을 주지 않습니다.

둘째, 부하가 증가했을 경우(또는 다른 이유로) 새로운 데이터베이스 서버가 있는 별도의 물리 머신으로 풀을 이동할 수 있습니다.

또한 데이터베이스 서버에 대한 보안 액세스를 더욱 엄격하게 잠글 수 있습니다.

이 모든 작업은 별도의 데이터베이스를 필요로 하지 않아도 수행할 수 있지만, 분리를 통해 이 모든 작업이 쉬워지고 어떤 테이블에서 작업해야 하는지 암기적으로 추적해야 하는 복잡성을 줄일 수 있습니다.

테이블 이름별로 풀을 달리하거나 별도의 데이터베이스에 저장하는 것은 거의 동일합니다.그러나 하나의 데이터베이스에 많은 테이블이 있는 경우 MySQL은 로그인/연결 시 테이블 정보를 로드하고 모든 테이블에 대한 보안 검사를 수행해야 합니다.

다른 사람들이 언급했듯이, 개별 데이터베이스를 사용하면 특정 풀(즉, 압축된 테이블)에 고유한 최적화 기능을 만들 수 있습니다.추가 관리 오버헤드가 발생하지만 유연성이 대폭 향상됩니다.

또한 필요에 따라 페더레이션테이블 또는 머지테이블을 사용하여 별도의 데이터베이스에 있는 테이블을 항상 "풀링"하여 쿼리를 간소화할 수 있습니다.

프라이머리 키의 부족에 대해서는 MyISAM 테이블을 사용하고 있는 경우는, 항상 복합 프라이머리 키를 사용할 수 있습니다.예를 들어 groupCode(임의의 유형)라는 필드와 sequenceId(자동 증분)라는 다른 필드가 있으며 프라이머리 키를 groupCode+sequenceId로 작성하는 경우.sequenceId는 그룹 코드 세트 내의 다음 고유 ID에 따라 증가합니다.예를 들어 AAA 1 AAA 2 BBB 1 AAA 3 CCC 1 AAA 4 BBB 2 ...

큰 테이블에서는 캐시에 주의해야 하지만 사용하는 파일 시스템에서 큰 파일을 처리해야 합니다.

mysql은 잘 모르지만, 표준 퍼포먼스인 「에 따라 다릅니다」라고 대답하지 않으면 안 될 것 같습니다.

몇 가지 생각(데이터베이스 설계가 아닌 성능/유지보수만 고려):

• 새 데이터베이스 작성은 파일 시스템에 별도의 파일이 있음을 의미합니다.한 파일의 성능을 다른 파일 시스템과 분리해야 하는 경우 등에 이러한 파일을 다른 파일 시스템에 저장할 수 있습니다.
• 새 데이터베이스에서는 캐시를 다르게 처리할 수 있습니다.하나의 DB에 있는 모든 테이블은 DB에 대한 공유 캐시를 의미하지만, 테이블을 별도의 데이터베이스로 분할하면 각 데이터베이스가 별도의 캐시를 가질 수 있습니다(모든 데이터베이스가 캐시에 대해 동일한 물리적 메모리를 공유하지만 데이터베이스별로 제한이 있을 수 있음 등).
• 즉, 개별 파일과 관련하여 데이터셋 중 하나가 다른 데이터셋보다 중요해진 경우 새 서버로 쉽게 풀 수 있습니다.
• 데이터베이스를 분리하면 단일 데이터베이스를 사용할 때보다 업데이트를 한 번에 한 개씩 더 쉽게 배포할 수 있다는 추가적인 이점이 있습니다.

그러나 반대로 데이터베이스가 여러 개 있으면 서버가 더 많은 메모리를 사용하게 됩니다(여러 캐시를 가지고 있기 때문에).다중 데이터베이스 접근법에 대한 "단점"이 더 많을 것이라고 확신하지만, 지금은 공백입니다.

따라서 멀티 데이터베이스 접근방식을 권장합니다.이것은, 실제로 무엇을 하고 있는가에 대해서, 보다 「데이터베이스 설계」의 방법이 있을 가능성이 있는 것을 이해하고 있는 것 뿐입니다.

여러 데이터베이스에 연결할 필요 없이 기존 데이터베이스에서 더 많은 테이블을 스핀업하는 것이 좋습니다.다양한 데이터베이스 최적화 관리뿐만 아니라 연결 문자열 관리가 더 어려워지는 경향이 있습니다.

FTR, 보통 상황에서는 TXI가 설명한 방식을 택할 것입니다.

그러나 구체적인 질문에 대한 답변으로 사용법에 따라 다르다는 것을 알았습니다.(알아, 하지만 끝까지 들어줘)

단일 데이터베이스가 더 쉬울 수 있습니다.접속은 1개뿐이지만 테이블을 지정해야 합니다.그러나 특정 상황에서는 여러 데이터베이스가 더 빠를 수 있습니다.

내가 너라면 둘 다 시도해 볼 거야.우리가 당신에게 유용한 답을 줄 수 있는 방법은 없습니다.

언급URL : https://stackoverflow.com/questions/696682/mysql-many-tables-or-many-databases