database.sarang.net
UserID
Passwd
Database
DBMS
ㆍMySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
MySQL Q&A 31105 게시물 읽기
No. 31105
키와 파티셔닝과의 관계 및 키설정에 대한 조언 부탁드립니다.
작성자
권순환(soonani82)
작성일
2017-08-16 18:03ⓒ
2017-08-16 18:05ⓜ
조회수
5,136

키와 파티셔닝과의 관계 및 키설정에 대한 조언 부탁드립니다.

 

안녕하세요. 저는 ERP10년 개발및 PL/PM을 하다가 새로운 회사에서 새로운 일을 하게되었습니다.

런칭이 될지 모르겠지만 소셜+특정기능이 들어간 시스템을 기획,설계중에 있습니다.

대용량 디비의 경험이 부족하여 몇가지 질문이 있습니다.

어떤방식으로 설계를 해야 가장 적합한 구조를 갖은 디비가 될까요? 지금 생각에는 3번이 제일유력한대...

혹시나 더좋은 방법이 있을가요?

 

-----------------------------------------------------------------

게시물 테이블 : 사람키, 게시물키, 년월(6자리)

-----------------------------------------------------------------

 

■방법1. 게시물만 자동증가로 키를 사용한다.

문제점 : 인트11자리 이상의 게시물이 들어올경우 문제발생

 

■방법2. 사람키 생성, 게시물은 max값을 구하여 +1 증가방식

사람별 파티션(천만명이 사용할경우 파티션이 1천개)

문제점 : 1천만개의 파티션의 가능여부와 데이터 조회시의 부하문제가 있을것같음.

 

■방법3. 년월(6자리), 게시물은 max값을 구하여 +1 증가방식

년월(6자리)별 파티션(데이터를 년월로 조회단위로 사용), 인덱스(사람) 조건추가

문제점 : 사람별로 모든데이터를 조회시 월단위로 조회되고, 월을 클릭해서 다음 데이터를 조회해야함.

 

 

 

끝까지 읽어주셔서 감사합니다. 많은 조언부탁드립니다.

아직 mysql적응이 안되는데 좋은 싸이트 몇개만 추천해주세요..

이 글에 대한 댓글이 총 5건 있습니다.

게시글키(일련번호)를 사용하지 마세요.
(사람키, 등록일시(datetime)) 로 키를 잡으세요.
필요에 따라 게시판 구분이 키에 포함될 수도 있구요.

마농(manon94)님이 2017-08-16 18:17에 작성한 댓글입니다.
이 댓글은 2017-08-16 18:18에 마지막으로 수정되었습니다.

마농님 답변 감사합니다.

 

질문하나만 더 드릴께요. 데이터가 천만건이상 들어온다고 가정하고 설계를 하고 싶은데요.(잘되서 많은 사람이 사용한다고 가정, 1달에 100만건 가정)

 

키설정을 (사람키, 등록일시(datetime)) 게 잡으면, 키생성에서 드물게작성하는 중복키문제도 해결될것같고, 게시물에대한 인공키를 생성하지 않는 장점도 있는거 같습니다.

쇼셜네트워크이다보니 관련된 사람의 데이터를 조회하는 경우가 많을것같은데 사람이 키이다보니 새로운 인덱스를 생성하지 않아도되는 장점도 있는거같네요.

 

질문1. (사람키[1번], 등록일시(datetime)[2번])로 생성시 데이터가 인서트될때 느리지 않을까요? 혹시나 사람키에대한 저장공간이 다차서 저장공간이 이동되거나, 인덱스를 다시 잡는경우가 발생하는지 여쭙고 싶어요.

 

질문2. 혹시나 너무많은 데이터가 들어온다고 가정하고, 테이블을 파티셔닝(테이블명1개, 물리적공간 n개)한다고 하면 사람별로 하는게 좋을까요? 등록일시(datetime)에 해당하는 6자리 년월을 따로 컬럼(year_month)을 두어서 year_month기준으로 파티셔닝을 하는게 좋을까요? 아니면 파티셔닝을 아에 안하는게 좋을까요?(조회는 항상 1달단위로 처리)

 

현재생각으로는 6자리 년월을 파티셔닝을 하고 (사람키[1번], 등록일시(datetime)[2번])으로 잡는게 좋다고 생각이 됩니다.

 

처리루틴 : 일반저장소(저장 및 year_month 생성) -> 트리거(데이터복사) -> 실제저장소(파티셔닝 되어있는) 이런방식을 생각하고 있습니다.

 

끝까지 읽어주셔서 감사합니다.

좋은 조언좀 부탁들입니다.

권순환(soonani82)님이 2017-08-17 09:02에 작성한 댓글입니다.
이 댓글은 2017-08-17 09:04에 마지막으로 수정되었습니다.

질문1.
 - 자동증가나 max + 1 처리를 안하니 오히려 빠를 듯 한데요.
질문2.
 - 년월 컬럼을 따로 둘 필요가 없죠.
 - 날짜컬럼을 이용해 파티셔닝 가능 할 듯.
질문3. 처리루틴
 - 왜 그렇게 하려고 하나요?
 - 그렇게 하고자 하는 목적의식이 분명해야 합니다.
 - 굳이 저장소를 나누고 트리거까지 쓸 필요가 있는지?
 - 트리거 쓰면 느려집니다. 오류 발생의 소지도 많구요.
4. 기타
 - 꼭 RDBMS 여야 하는지?


-- 참고 --
빅데이터 시장이 주목받으면서 관계형 DMBM(RDBMS) 중심의 오픈소스 DBMS가 아닌,
다양한 오픈소스 DB도 나오는 추세다.
이들은 RDBMS 제품군처럼 테이블 형태의 데이터 저장 방식이나
SQL 접근 방식을 갖지 않는, RDBMS와 다른 형태의 데이터 저장 구조를 갖는다.
대표적으로 noSQL 기반 오픈소스 DB인 ‘몽고DB’와 ‘카산드라’가 있다.
최근에는 모바일 서비스가 확산되면서 모바일 DB인 SQLite에 대한 관심도 늘고 있다.
출처 : [네이버 지식백과] 오픈소스 DBMS - DB계에 부는 오픈소스 바람 (용어로 보는 IT)
http://terms.naver.com/entry.nhn?docId=3579404&cid=59088&categoryId=59096

마농(manon94)님이 2017-08-17 09:25에 작성한 댓글입니다.

마농님 친절한 답변에 매우 감사드립니다.

좋은하루되세요~~

권순환님이 2017-08-17 09:49에 작성한 댓글입니다. Edit

 1번 문제점은 bigint로 잡으시면 됩니다.

박인호(paerae)님이 2017-08-17 17:40에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
31108쿼리 문의 드립니다. [4]
김진호
2017-08-22
4581
31107mysql 점검 문의 드립니다.
goblin
2017-08-22
4442
31106MariaDB 서버연동.. 질문할게요.. [1]
김민호
2017-08-20
4424
31105키와 파티셔닝과의 관계 및 키설정에 대한 조언 부탁드립니다. [5]
권순환
2017-08-16
5136
31104mysql 버전에 의해서 with 문 사용 불가능 한경우 있나요? [2]
권순환
2017-08-16
4958
31103사람별 AUTO_INCREMENT증가 테이블 생성 질문 [2]
권순환
2017-08-16
4540
31102데이터 모델링 중 테이블의 건수에 관한 궁금증 [1]
우코아
2017-08-09
4505
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.017초, 이곳 서비스는
	PostgreSQL v16.4로 자료를 관리합니다