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
운영게시판
최근게시물
PostgreSQL Q&A 9575 게시물 읽기
No. 9575
커질때로 커져버린 데이터의 검색속도 향상법 문의드려요.
작성자
김현진(tokssonda)
작성일
2015-07-28 09:26
조회수
11,069

빅데이터급의 데이터는 아니지만 커져버린 테이블의 검색속도를 향상시키기 위해 어떠한

방법들을 쓰고 계신지 의견을 듣고 싶어 ^ ^ 이렇게 글을 올립니다.

뭐 여러가지 사례들의 대해서 어떻게 처리하시고 계시는지 여러의견, 조언 부탁드립니다.

 

1. 로그성 테이블 조인이 없는 대신 엄청 커져버린 테이블

( 현재 postgresql만 사용하고 있는데 조금이라도 빠르게 읽을수 있다면 mysql이나

monogo db 쪽으로 데이터를 옮겨서 insert, select 해야 하는건지 어떻게들 하고 계신가요? )

 

2. 꼭 필요한 테이블인데 데이터가 시간이 지나면 지날수록 커져버리는 테이블인데요

물론 insert가 하루에 계속 일어나며 다른 테이블과의 조인이 필요합니다.

데이터가 커진 만큼 다른 DB와 분리할수밖에 없는데 그러다 보니 해당 같은 서버의 DB table이

아니면 조인도 안된다는 단점이 있어요

( 선택한건 파티셔닝인데 날짜별로 파티셔닝을해서 검색일의 범위가 적을때 효율을

보고 있습니다. 다들 어떻게들 하고 계신가요? 조인문제 해결하신분도 의견 부탁드려요)

 

새로운 기법 이라든지 어떠한 방향성이든 의견을 듣고 싶습니다 ^ ^

 

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

1. 대부분의 RDBMS 에서 select 속도는 거의 비슷비슷합니다. 

테이블 전체를 읽어야 하는 쿼리라면, 결국 그 양만큼 디스크를 읽어야 하기 때문입니다. 

mysql 을 쓰든, mongodb를 쓰든 별반 차이는 없습니다. 

 

차이가 있다면, 첫번째 쿼리가 아니라, 똑 같은 쿼리에 똑같은 결과를 보여주는 작업이 반복되었을 경우, 그 반복되는 작업에 대한 캐쉬 처리를 어떻게 하느냐에 달렸는데, 이 부분도 요즘은 대부분 비슷비슷한 속도를 보장합니다. 

 

즉, 데이터가 많으면 느려지는 것은 어쩔 수 없다가 결론입니다. 

많은 자료를 select 하는 경우에 대해서는 미리 집계 해서 집계성 테이블 자료를 주기적으로 갱신하는 방법이 제일 일반적입니다. 

 

2. 파티션 테이블을 사용하는 것이 일반적입니다. 

 

'커질대로 커져버린' 이라는 표현을 쓸 때, 살펴보면, 대부분 로그성 insert only 테이블들인데, 이 테이블의 사용을 가만히 보면, 굳이 이런 자료를 DB 안에 넣어야 하나하는 생각을 가끔합니다. 

mp3 파일을 db에 넣어 두고 서비스 하는 것과 비슷하다는 생각을 합니다. 

 

서비스에 대한 요구사항을 분석하면서 데이터 모델링에서 '모든 자료는 RDBMS에 넣어야 한다'는 강박관념만 버리면 길을 여러가지일 것 같습니다. 

 

그럼에도 불구하고, facebook 같이 무지막지한 자료가 쌓이고, 그 자료 모두가 로그성 자료가 아니고, 무지막지하게 select 되어야 한다면, 이런 부분은 요즘 이야기하는 빅데이터로 기법으로 푸는게 맞을 듯합니다. 

거기까지 안간다면,  

절충안으로 하나의 RDBMS에 각 미들웨어와 함께 있는 캐시 서버와 캐시 서버간 동기화로 전체 구조를 다시 설계하는 방식을 사용합니다. 

PostgreSQL - jBoss (인피니스팬 활용) - apache 

이런 형태로 전체서비스의 품질이 떨어지면, 미들웨어쪽 병렬로 늘리는 방법을 사용하는 것이 일반적입니다.

 

 

김상기(ioseph)님이 2015-07-29 10:10에 작성한 댓글입니다.

상기님 조언 감사드립니다.

select 효과가 비슷하다는건 ... 절망적이군요. ㅠ_ㅠ

몇년전에 db별로 insert 하는것에 대한 처리는 확실히 속도 체감을 했었는데

캐쉬처리에 대한 부분도 기대할만큼 다르지 않다니 허허 - *

모든 자료는 RDBMS에 넣어야 한다는 강박은 ...

고객이니 ㅠ_ㅠ 어쩌지 못하고 있는 상황이긴 합니다만 ㅎㅎ

아무쪼록 의견에 영감을 얻어갑니다.

언제나 답변 감사드립니다.

김현진(tokssonda)님이 2015-07-29 13:17에 작성한 댓글입니다.
이 댓글은 2015-07-29 13:17에 마지막으로 수정되었습니다.

Mongo DB 같은 경우에는, Sharding 구성이 가능하기 때문에, Select 조회시 상당한 속도 향상을 볼 수 있습니다. 

단만, MongoDB 의 경우, 기본 구성 시, ACID 구성 중 Consistency 구성이 안되어 있기 때문에,

Replica Set의 값이 서로 다른 경우가 많이 있습니다. 

일반적으로, Write Scalability의 경우, Casandra 쪽을 선호하고, Select Scalability의 경우

MongoDB 쪽을 선호하는 편입니다.

 

아싸가오리님이 2015-07-29 17:33에 작성한 댓글입니다. Edit

감사합니다 ^ ^ 가오리님

몽고DB도 이용해봐야겠네요 ^ ^

김현진(tokssonda)님이 2015-09-21 18:44에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
9582postgres with 구문 궁금한 점이 있습니다. [5]
초보dba
2015-08-10
11140
9578DB버전 마법의 블록 문제.. [1]
철강새
2015-08-04
10076
9576update 쿼리에서 limit 사용 쿼리 질문드립니다. [1]
lyae
2015-07-29
9726
9575커질때로 커져버린 데이터의 검색속도 향상법 문의드려요. [4]
김현진
2015-07-28
11069
9574pgsql 텍스트 조합을 파라미터 변수명으로 인식 [2]
김재성
2015-07-20
9687
9573return 타입 문제점.. [2]
e도전
2015-07-14
10762
9572undefined symbol에 관해서 [5]
상록수
2015-07-13
10335
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.021초, 이곳 서비스는
	PostgreSQL v16.4로 자료를 관리합니다