볼랜드포럼: 대용량 DB의 경우 어떻게 처리하나요?

	C++Builder \| Delphi \| FireMonkey \| C/C++ \| Free Pascal \| Firebird

경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지

분야별 포럼

볼랜드포럼 홈

회원 메뉴

자유게시판		세상 살아가는 이야기들을 나누는 사랑방입니다.

[13191] 대용량 DB의 경우 어떻게 처리하나요?
홍만식 []	11768 읽음 2007-07-20 12:01

안녕하세요 ^^
DB를 공부하는 중인데요... 궁금한게 있어서 질문드립니다 ^-^

제가 MS SQL SERVER를 공부하다가 문득 생각이 난건데요.

예를 들어 택배회사의 경우 (잘나가는 택배의 경우)
하루 물량도 엄청날꺼고...
그게 주문테이블(편의상 order라고 이름을 지었다치구요)에 들어갈건데....
그게 하루 이틀도 아니고 계속 쌓이게 되면 엄청나게 양이 많아져서 속도자체가 굉장히 느려질것 같은데요.

그렇다면 (그냥 제 생각입니다) 위의 주문테이블을 월단위로 쪼개면 될것 같은데요.
(물론 월단위도 많다면 주단위..)
이를테면 order200701, order200702, order200703 이런식으로요 <-- 주문테이블 2007년01월분, 2월분, 3월분
구분을 위해 같은 구조의 테이블을 저렇게 나눈다는 이야기에요

저렇게 나눠 넣는거는 create table할때 조건을 걸어서 넣어두면 될것 같은데...

나중에 조회할때 즉...제가 이제껏 이 택배회사에다가 주문한 내역을 다 보고 싶다고 했을때
전부 다 나와야 할텐데요..

그럴려면 쪼개진테이블 하나하나를 다 뒤져서 찾아야 하잖아요.
루프를 돌려서 찾는 방법이 있을것 같긴한데...이것도 쉬운일이 아닐것 같구요..

특히 기간을 정해서..즉 제가 2007년 3월부터 2007년 7월사이에 택배 발송한것을 다 보고 싶다고 했을때
개월수 계산해서 맞는 테이블 찾아서 조회하고....어휴.. 생각만해도 복잡할것 같아요..

실제 실무에서는 어떤식으로 처리를 하게 되나요????
그게 궁금합니다...

Trackback : http://www.borlandforum.com/impboard/impboard.dll/trackback?sn=97651

[cppbuilder] 2007-07-20 12:17 X

안쪼개도 됩니다.
용량이 매우 커져도 인덱스만 잘 걸어주민 검색 속도는 그다지 떨어지지 않습니다.

[cppbuilder] 2007-07-20 12:17 X

옛날 DB에서는 쪼개는 편법이 동원되기도 했는데, 요즘 것은 그럴 필요가 없습니다.

WARSHIP [warship] 2007-07-20 13:33 X

음 안나누어도 될거 같지만, 혹 나눠야 된다고 해도
union 을 활용하면 될거 같군요 ^^;

박진훈 [jhoony73] 2007-07-20 13:44 X

대용량 데이터베이스의 경우 말씀하신것 처럼 파티션을 하기도 합니다.
오라클에서는 테이블 파티션의 기능이 제공됩니다만,
MS-SQL의 경우는 월단위나 년단위 테이블을 만들고 뷰를 사용했던 기억이 나네요..

이현진 [cyberpd] 2007-07-20 15:58 X

아래 사이트에 DB 관련 정보, 설계 예제 등을 찾아보실 수 있을겁니다.

http://www.dbguide.net

곽상현 [catbus] 2007-07-20 22:15 X

3억건 5억건 디비도 조회하면 1초안에 나옵니다..그게 튜닝이죠...
국내에도 이런 테이블 많습니다..

이홍석 [lhs0806] 2007-07-21 18:20 X

관계형 데이터베이스의 핵심은 데이터를 테이블형태로 구성하는것이죠..
그래서 님이 말씀한내용 즉 데이터가 무한대(!)로 늘어날경우
인덱스같은 것도 답은 되겠지만
아애 파티셔닝하는것도 근본적 답이될 수있읍니다..
그러나 문제는 어떤룰로 쪼갤것인가 이고요
이는 업무에따라 다를수 있읍니다.
ms는 2005버젼부터 본격(!)적인 파티션을 지원하다고 합니다..
광고보니 건물에다 건전지 넣는 그림이나오더군요..
꺼꾸로말하면 이전버젼은 그리 좋은 성능은 아니였다는 애기도 됩니다.ㅎㅎ
이제 오라클은 그리드로 갑니다.. 데이터를 머쉰단위로도 쪼개서 관리할수 있도록
하겠다... 뭐 이거죠..
결론적으로 쪼개는 것에 한표!!

아제나 [azena] 2007-07-23 08:01 X

인덱스에 서브쿼리를 응용하면 수십억 디비라도 0.1초 안에 결과를 낼 수 있습니다.
order00001 처럼 의미없이 order라는 영문자를 붙여서 검색 결과를 떨어뜨릴 필요는 없죠.
검색 속도는 숫자를 따라올게 없으므로 그냥 숫자로 하는게 최고 입니다.
PK를 (날짜*100000000+시퀸스)로 잡고 2007년 07월 23일자 검색한다면 2007072300000000~2007072399999999 까지 검색하면 되겠죠.
이때 최신 정보가 아래쪽에 위치하므로 맨 위로 올린다고 order by desc 쓰면 쿼리 속도가 엄청나게 저하됩니다. 그러므로 실제 디비에 저장되는 값은 NOT 연산을 해주거나 9999999999999999 에서 빼기를 한 결과값을 저장하면 최신 자료가 숫자가 더 낮아지기 때문에 알아서 소트가 됩니다. 대충 이런 식으로 디비 퍼포먼스를 끌어올릴 수 있죠. 엔터프라이즈급 RDBMS는 1억건의 디비는 큰 편도 아닙니다. 대신 그만큼 설계의 중요성이... -_-;;