질문은 ...
192 조 개의 레코드를 고려할 때 고려해야 할 사항은 무엇입니까?
나의 주요 관심사는 속도입니다.
여기 테이블이 있습니다 ...
CREATE TABLE `ref` (
`id` INTEGER(13) AUTO_INCREMENT DEFAULT NOT NULL,
`rel_id` INTEGER(13) NOT NULL,
`p1` INTEGER(13) NOT NULL,
`p2` INTEGER(13) DEFAULT NULL,
`p3` INTEGER(13) DEFAULT NULL,
`s` INTEGER(13) NOT NULL,
`p4` INTEGER(13) DEFAULT NULL,
`p5` INTEGER(13) DEFAULT NULL,
`p6` INTEGER(13) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY (`s`),
KEY (`rel_id`),
KEY (`p3`),
KEY (`p4`)
);
검색어는 다음과 같습니다.
SELECT id, s FROM ref WHERE red_id="$rel_id" AND p3="$p3" AND p4="$p4"
SELECT rel_id, p1, p2, p3, p4, p5, p6 FROM ref WHERE id="$id"
INSERT INTO rel (rel_id, p1, p2, p3, s, p4, p5, p6)
VALUES ("$rel_id", "$p1", "$p2", "$p3", "$s", "$p4", "$p5", "$p6")
여기 몇 가지 메모가 있습니다 ...
- SELECT는 INSERT보다 훨씬 자주 수행됩니다. 그러나 때때로 한 번에 수백 개의 레코드를 추가하고 싶습니다.
- 로드 방식으로 몇 시간 동안 아무 것도 없을 것입니다.
- 더 이상 정규화 할 수 없다고 생각하십시오 (p 값 조합 필요)
- 데이터베이스 전체는 매우 관계가 있습니다.
- 이것은 지금까지 가장 큰 테이블이 될 것입니다
업데이트 (08/11/2010)
흥미롭게도 나는 두 번째 옵션을 받았다.
192 조 대신에 2.6 * 10 ^ 16 (15 0, 26 조를 의미)을 저장할 수 있습니다 ...
그러나이 두 번째 옵션에서는 하나의 bigint (18) 만 테이블에 인덱스로 저장하면됩니다. 그게 다야-단 하나의 열. 그래서 나는 값의 존재를 확인하고 있습니다. 때때로 레코드를 추가하고 삭제하지는 않습니다.
그래서 단순히 숫자를 저장하는 mysql보다 더 나은 솔루션이 있어야한다고 생각하게합니다 ...
이 두 번째 옵션이 주어지면 첫 번째 옵션을 사용하거나 고수해야합니다 ...
[편집] 방금 수행 된 일부 테스트에 대한 소식을 얻었습니다.이 설정으로 1 억 개의 행이 0.0004 초 내에 쿼리를 반환합니다. [/ edit]
7
MySQL을 어떻게 사용하고 있습니까? 누군가가 확실한 주장을 제공한다면 다른 dbms로 전환하도록 확신 할 수 있습니까?
—
WheresAlice
10 ^ 12 또는 10 ^ 18에서와 같은 조?
—
andol
192 Trillion 레코드에는 토론 포럼이 아닌 MySQL 커미터에게 질문을 할 수있는 예산이 있어야합니다.
—
Remus Rusanu
이 큰 데이터베이스 (그리고 예산이 적당 한 예산)를 사용하면 큰 DB를 쉽게 처리 할 수있는 것으로 입증 된 Oracle 또는 SQL Serer 솔루션을 사용하는 것이 어떻습니까?
—
Jim B
이를 구현할 때 항상 최신 정보를 유지하십시오. 나는 확실히 관심이 있습니다. 당신은 또한 highscalability.com
—
Tom O'Connor