MySQL : 많은 테이블 또는 많은 데이터베이스?

MySQL : 많은 테이블 또는 많은 데이터베이스?

---

프로젝트의 경우 항상 동일한 구조를 가지며 서로 연결되지 않은 데이터 묶음이 있습니다. 데이터를 저장하는 방법에는 두 가지가 있습니다.

• 모든 풀에 대해 새 데이터베이스 만들기 (약 15-25 개 테이블)
• 하나의 데이터베이스에 모든 테이블을 만들고 테이블 이름에 따라 풀을 다릅니다.

어느 것이 MySQL을 처리하기 쉽고 빠릅니까?

편집 : 나는 데이터베이스 디자인 문제에 관심이 없으며 두 가지 가능성 중 어느 것이 더 빠른지 관심이 있습니다.

편집 2 : 나는 그것을 더 명확하게 만들려고 노력할 것입니다. 말했듯이 일부 날짜가 다른 풀에 거의 속하지 않는 데이터가 있습니다. 한 테이블에 한 유형의 모든 데이터를 넣고 풀 ID와 연결하는 것은 좋은 생각이 아닙니다.

• 특정 풀을 백업 / 삭제하기가 어렵습니다 (그리고 잠시 후 (big int를 사용하는 경우에도) 기본 키가 부족해질 것으로 예상합니다)

따라서 아이디어는 모든 풀에 대한 데이터베이스를 만들거나 하나의 데이터베이스에 많은 테이블을 만드는 것입니다. 데이터베이스에 대한 쿼리의 50 %는 간단 inserts합니다. 49 %는 selects기본 키에 대해 간단 합니다.

문제는 무엇을 처리하는 것이 더 빠릅 MySQL니까? 많은 테이블 또는 많은 데이터베이스?

---

단일 데이터베이스의 여러 테이블과 별도의 데이터베이스에있는 여러 테이블간에 큰 성능 차이가 없어야합니다.

MySQL에서 데이터베이스 (표준 SQL은 "스키마"라는 용어를 사용함)는 주로 테이블의 네임 스페이스 역할을합니다. 데이터베이스에는 기본 문자 집합 및 데이터 정렬과 같은 몇 가지 속성 만 있습니다. 그리고를 사용 GRANT하면 데이터베이스 당 액세스 권한을 편리하게 제어 할 수 있지만 성능과는 관련이 없습니다.

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

SELECT * FROM database17.accounts_table;

이것은 순전히 구문상의 차이입니다. 성능에 영향을주지 않아야합니다.

스토리지와 관련하여 @Chris가 추측하는 것처럼 테이블을 데이터베이스 당 파일로 구성 할 수 없습니다. MyISAM 스토리지 엔진을 사용하면 항상 테이블 당 파일이 있습니다. InnoDB 스토리지 엔진을 사용하면 모든 테이블을 통합하는 단일 스토리지 파일 세트가 있거나 테이블 당 파일이 있습니다 (데이터베이스가 아닌 전체 MySQL 서버에 대해 구성됨). 두 경우 모두 단일 데이터베이스에 테이블을 만드는 것이 여러 데이터베이스에 비해 성능 이점이나 단점이 없습니다.

데이터베이스 당 작동하는 MySQL 구성 매개 변수는 많지 않습니다. 서버 성능에 영향을 미치는 대부분의 매개 변수는 서버 전체 범위입니다.

백업과 관련하여 테이블의 하위 집합을 mysqldump명령 에 대한 인수로 지정할 수 있습니다 . 명령 줄에서 모든 테이블의 이름을 지정할 필요없이 데이터베이스 당 논리적 테이블 집합을 백업하는 것이 더 편리 할 수 ​​있습니다. 그러나 성능에는 차이가 없으며 백업 명령을 입력 할 때 편리 할뿐입니다.

---

풀을 추적하기 위해 단일 테이블을 만들고 (PoolID 및 PoolName을 열로 사용하고, 추적하려는 다른 항목을 사용하여) 15-25 개의 테이블에서 모든 테이블에 열을 추가하면됩니다. 특정 레코드가 속한 풀을 알 수 있도록 외래 키를 풀 테이블에 반환합니다.

이와 같은 데이터를 혼합하고 싶지 않다면 여러 데이터베이스를 만드는 것이 좋습니다. 동일한 기능을 위해 여러 테이블을 모두 생성하면 스파이더가 따끔 거립니다.

---

TheTXI가 제안한대로 poolID poolname이있는 하나의 테이블 세트를 원하지 않는 경우 모두 동일한 작업을 수행하는 여러 테이블 대신 별도의 데이터베이스를 사용하십시오.

이렇게하면 초기 "데이터베이스 사용"문에 대한 다른 풀 액세스 간의 차이를 제한하고 매번 SELECT를 다시 코딩하거나 동적 SQL을 사용할 필요가 없습니다.

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

• 간편한 백업 / 복원
• 데이터베이스 인스턴스를 쉽게 시작 / 중지합니다.

단점은 다음과 같습니다.

• 관리 작업이 조금 더 많지만 많지는 않습니다.

나는 당신의 응용 프로그램이 무엇인지 모르겠지만 하나의 데이터베이스에 모든 테이블을 만들기 전에 실제로 신중하게 생각하십시오. 그런 식으로 광기가 놓여 있습니다.

편집 : 성능이 유일한 문제라면이를 측정해야합니다. 대표적인 쿼리 집합을 가져와 성능을 측정합니다.

편집 2 : 많은 테이블 / 많은 데이터베이스 모델 간의 단일 쿼리에 대한 성능 차이는 무시할 수 있습니다. 데이터베이스가 하나만 있으면이를 조정할 수 있습니다. 데이터베이스가 많으면 모든 데이터베이스를 조정할 수 있습니다.

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

나에게 가장 좋은 옵션은 TheTXI가 제안한 것처럼 여전히 poolId가있는 하나의 데이터베이스이고, 그다음에 (대부분 관리) 요구 사항에 따라 여러 데이터베이스입니다. 두 옵션 간의 성능 차이를 정확히 알아야하는 경우에는 그 답을 드릴 수 없습니다. 이를 설정하고 테스트해야합니다.

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

---

설명하신 상황에서 경험을 통해 많은 수의 풀이있을 때 별도의 데이터베이스가 더 빨라질 것이라고 믿게되었습니다.

하지만 여기서 지켜야 할 매우 중요한 일반 원칙이 있습니다. 얼마나 빠를 지 생각하지 말고 프로파일 링하십시오.

---

나는 당신의 시나리오를 완전히 이해했는지 잘 모르겠습니다. 모든 풀이 동일한 테이블을 사용하지만 구별 키만 다른 것을 원하십니까? 아니면 풀을 구별하기 위해 각 테이블에 접미사가있는 하나의 데이터베이스 내에 별도의 테이블 풀을 원하십니까?

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

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

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

이러한 모든 작업은 별도의 데이터베이스 없이도 수행 할 수 있습니다. 그러나 분리를 통해이 모든 작업을 더 쉽게 수행 할 수 있고 작업 할 테이블을 정신적으로 추적해야하는 복잡성이 줄어 듭니다.

---

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

다른 사람들이 언급했듯이 별도의 데이터베이스를 사용하면 상황을 전환하고 특정 풀 (예 : 압축 된 테이블)에 특정한 최적화를 만들 수 있습니다. 추가 관리 오버 헤드이지만 훨씬 더 많은 유연성이 있습니다.

Additionally, you can always "pool" the tables that are in separate databases by using federated or merge tables to simplify querying if needed.

As for running out of primary keys, you could always use a compound primary key if you are using MyISAM tables. For example, if you have a field called groupCode (any type) and another called sequenceId (auto increment) and create your primary key as groupCode+sequenceId. The sequenceId will increment based on the next unique ID within the group code set. For example: AAA 1 AAA 2 BBB 1 AAA 3 CCC 1 AAA 4 BBB 2 ...

Although with large tables you have to be careful about caching and make sure the file system you are using handles large files.

---

I don't know mysql very well, but I think I'll have to give the standard performance answer -- "It depends".

Some thoughts (dealing only with performance/maintenance, not database design):

• Creating a new database means a separate file (or files) in the file system. These files could then be put on different filesystems if performance of one needs to be separate from the others, etc.
• A new database will probably handle caching differently; eg. All tables in one DB is going to mean a shared cache for the DB, whereas splitting the tables into separate databases means each database can have a separate cache [obviously all databases will share the same physical memory for cache, but there may be a limit per database, etc].
• Related to the separate files, this means that if one of your datasets becomes more important than the others, it can easily be pulled off to a new server.
• Separating the databases has an added benefit of allowing you to deploy updates one-at-a-time more easily than with the single database.

However, to contrast, having multiple databases means the server will probably be using more memory (since it has multiple caches). I'm sure there are more "cons" for the multi-database approach, but I am drawing a blank now.

So I suppose I would recommend the multi-database approach. Obviously this is only with the understanding that there may very well be a better "database-designy" way of handling whatever you are actually doing.

---

Given the restrictions you've placed on it, I'd rather spin up more tables in the existing database, rather than having to connect to multiple databases. Managing connection strings TEND to be harder, in addition to managing the different database optimizations you may have.

---

FTR, in normal circumstances I'd take the approach described by TheTXI.

In answer to your specific question though, I have found it to be dependant on usage. (Cop out I know, but hear me out.)

A single database is probably easier. You'll have to worry about just one connection and would still have to specify tables. Multiple databases could, under certain conditions, be faster though.

If I were you I'd try both. There's no way we'll be able to give you a useful answer.

참고URL : https://stackoverflow.com/questions/696682/mysql-many-tables-or-many-databases