많은 양의 데이터로 데이터베이스를 구조화하기위한 제안

Question

Windows 서버에서 JavaScript, MySQL 및 PHP로 RIA를하고 있습니다.

데이터베이스에 넣으려는 동일하게 구조화 된 5,000 개의 데이터 세트가 있습니다. 5 개의 테이블만으로도 충분하며, 일반적인 데이터 세트에 대해 300,000 개 이상의 레코드가있는 하나의 테이블을 제외하고는 모두 합리적으로 작을 것입니다.

또한 500 명의 사용자는 해당 데이터 세트에서 컴파일 된 통계에 대한 읽기 전용 액세스 권한을 갖게됩니다. 이러한 통계는 PHP에서 제공합니다 (직접 액세스 할 수 없음). 또한 데이터에 대한 액세스가 다릅니다. 일부 사용자는 하나의 데이터 세트 만 사용할 수 있으며, 다른 사용자는 모두 일부만 사용할 수 있습니다.

사용자가 보는 결과는 비교적 작습니다. 대부분의 요청은 100 개의 행 아래로 잘 돌아오고, 가장 큰 요청은 약 700 개의 행이됩니다. 모든 요청은 Ajax를 사용하여 PHP에 연결하는 JavaScript RIA를 통해 이루어지며,이 RIA는 차례대로 데이터에 연결하고 JSON을 응답으로 출력하며 이에 따라 JavaScript가 그에 따라 제공됩니다. 이를 구성하는 방법에 대해 생각에서

은 세 가지 옵션이 자신을 소개 :

1. 가 같은 테이블에 데이터 세트를 넣습니다. 가장 큰 테이블에 1,500,000,000 개의 레코드를 쉽게 줄 수 있습니다.

2. 각 데이터 세트에 대해 별도의 표를 사용하십시오. 이는 최대 테이블 크기를 제한하지만 25,000 개의 테이블을 의미 할 수 있습니다.

3. 독점적 인 형식으로 데이터베이스를 잊어 버리십시오.

나는 몇 가지 이유로 2쪽으로 기울어 져있다.

1. 매우 큰 테이블 (예 : 쿼리 속도, 구현 제한 등) 사용시 문제가 있습니다.

2. 별도의 표가 안전합니다. 오류 및 구조 변경의 영향을 제한합니다.

3. 별도의 테이블을 사용하면 내 자신의 행 수준 보안을 구현하는 대신 MySQL의 테이블 레벨 보안을 사용할 수 있습니다. 이것은 더 적은 작업과 더 나은 보호를 의미합니다. 예를 들어, 행 수준 보안없이 쿼리가 실수로 전송 된 경우 사용자는 승인되지 않은 데이터를 가져올 수 있습니다. 데이터베이스가 질의를 거부 할 것이므로 테이블 수준 보안에서는 그렇지 않습니다.

그건 내 생각이지만, 나는 너를 원해. 이것이 올바른 선택이라고 생각합니까? 그렇지 않다면 왜 안 되겠습니까? 내가 놓친 고려 사항은 무엇입니까? 확장 성 문제가 있다면 다른 플랫폼을 고려해야합니까?

Answer 1

1) 매우 큰 테이블 (예 : 쿼리 속도, 구현 제한 등) 사용시 문제가 있습니다.

DBMS가 ... 있는지 여부한 테이블의 큰 인덱스를 통해

• 검색,
• 또는 오른쪽으로 테이블을 검색하고 그 테이블

의 작은 인덱스를 통해 검색 ... 아마하지 않습니다 성능면에서는 차이가 있습니다. 두 번째 케이스에는 문서화되지 않은 구성 요소 (올바른 테이블을 찾는 성능)가 있기 때문에 완전히 신뢰하지 않으려 고합니다.

물리적으로 데이터를 파티션하려는 경우 MySQL supports that directly 버전 5.1부터 별도의 테이블을 통해 에뮬레이션 할 필요가 없습니다.

2) 별도의 표가 안전 해 보입니다. 오류 및 구조 변경의 영향을 제한합니다.

백업용입니다.

3) 별도의 테이블을 사용하면 내 자신의 행 수준 보안을 구현하는 대신 MySQL의 테이블 레벨 보안을 사용할 수 있습니다.

사실 충분하지만 비슷한 효과는보기 또는 저장 프로 시저를 통해 얻을 수 있습니다.

모두 본질적으로 이러한 데이터 세트가 구조적으로 다른 테이블을 보증 할만큼 다른 점을 알지 못한다면 단일 테이블을 사용하는 것이 본능입니다. BTW, 잘 최적화 된 데이터베이스에 비해 독자적인 형식으로 더 잘 수행 할 수 있을지는 의문입니다.