[질문] mysql 레코드 수가 1000 만개 정도일때...
글쓴이: hurryon / 작성시간: 수, 2003/05/21 - 10:43오전
안녕하세요. mysql 의 레코드 수가 약 1000만개 정도가 된다면
안정성이라고 해야 하나? 아니면 검색 능력과 같은것이 어떨지요?
테이블 구조는 다음과 같습니다.
mysql> desc iif; +---------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------+-------------+------+-----+---------+----------------+ | id | bigint(20) | | PRI | NULL | auto_increment | | keyword | varchar(18) | | | | | | did | int(11) | YES | | NULL | | | weight | float | YES | | NULL | | +---------+-------------+------+-----+---------+----------------+ 4 rows in set (0.03 sec)
물론 다른 몇개의 테이블도 더 있습니다만...아마도 위의 iif 테이블의
레코드 수가 가장 많을거 같습니다. 안정성은 어떨지?
C API로 접근하고 있습니다.
Forums:
테이블을 나누시는게 좋을듯...
MySQL에 1000만건의 레코드를 한 테이블에 저장을 해보지는 않았지만
일반적인 경험으로 보면 테이블을 나누시는게 좋은 방법 같습니다.
예를들어 등록되는 레코드의 월별로 나눈다던지 아니면 Primary Key를
몇개의 그룹으로 나누어서 테이블을 별도로 가지고 가는거죠..
1000만건을 한 테이블에 저장한다면 물론 PK로 잡혀있는 필드에 대한
검색은 어느정도 속도가 나오겠지만 그 외의 필드는 검색을 할때
속도를 전혀 보장할수 없습니다.
더군다나 key 외의 조건으로 update나 delete가 발생을 한다면
하나의 Query가 하나의 트랜잭션이기 때문에 너무 많은 레코드가
하나의 트랙잭션에 대한 결과로 발생을 하면서 최악의 경우에
트랜잭션 로그가 깨지면서 DB가 recovery 되지 않는 경우도
발생 가능합니다.
물론 code table처럼 조회만 하는 테이블이라면 이러한 문제는
없겠지만 1000만건의 데이터를 하나의 테이블로 가지고 가는것은
잠재적으로 문제를 발생할 소지가 많으므로 가능하면 테이블을 나누는
방향으로 설계를 하시길..
저의 개인적인 의견이었습니다.. ^^
[quote]MySQL에 1000만건의 레코드를 한 테이블에 저장을 해보
좀 더 구체적인 예를 들어서 설명해 주시면 안 될까요?
저도 관심이 많은 주제라... 좀 더 자세하게 듣고 싶습니다.
답변 부탁드립니다.
어찌나 졸린지..~~
cannes 님의 말씀은 이런거 같네요.
발 담갔다. 이제 익숙해 지는길만이..
1천만건 정도의 데이터이고 mysql이라면 id 를 unsigned in
1천만건 정도의 데이터이고 mysql이라면 id 를 unsigned int 로 하셔도 될거 같습니다.
일단 이 테이블에서 인덱스는 id 컬럼에만 걸려 있는거 같으니 id 로 표시할수 있는 최대 범위를 추측해야 할 거 같습니다.
1천만건 정도라면 unsigned int 로도 충분히!! 표현 할 수 있으며 이렇게 바꾸게 되면 테이블의 크기는 약 10% 정도 줄어드나 인덱스의 크기는 절반으로 줄어 드는 이점이 있습니다. 혹시 다른 컬럼들도 쓸데없이 크게 잡힌건 아닌지 확인 해 보시구요..
인덱스가 절반으로 된다는 것은 mysql의 BTREE 인덱스의 효율이 2배가 된다는 것은 아니지만 분명한 향상이 있습니다.
간단하게 그 한 테이블만 놓고 계산해 보자면
4 (int) * 1천만 하면 4천만 바이트 입니다. 약 40메가 정도의 인덱스가 생성이 되고 이는 효율이나 속도를 크게 걱정 할 정도의 크기는 아닙니다.
단.. 검색은 항상 id 컬럼에서만 일어나야 하겠죠..
select 와 id 컬럼을 제외한 update 만 빈번하다면 크게 걱정 할 부분은 없을 거 같습니다.
안정성은......
mysql 이잖습니까? -_-;;;;;;;;
위에서 Primary 키로 잡고 select 한다면 빠른속도로 수행이 가
위에서 Primary 키로 잡고 select 한다면 빠른속도로 수행이 가능합니다..
Primary 키가 char 형이면 상당히 복잡해 지겠지만요..
구조상 별로 큰 문제는 없다고 보여 집니다..
그리고 update 와 write 시 문제점은 InnoDB가 기본으로 배포는 요즘 Mysql 에서는 별 상관이 업습니다..
(사실 Insert 와 Delete가 조금 문제지요..)
low level locking 지원되기 떄문입니다.
그래서 DB가 크면 클수록 InnoDB로 가시는게 좋습니다..
=================================
:: how about a cup of tea ? ::
=================================
댓글 달기