Monthly Archives: November 2013

RDBMS(Postgresql)를 이용한 log 테이블 생성시 참고

로그 규칙:

일정시간간격으로 파일을 수신하는 로그를 기록하는 테이블
1일 50000개 가량의 데이터 누적
로그 보관기한 3개월
1개월 150`00000개

빠른 검색을 위한 인덱스와 키값을 지정.. 각 키값에 따라 데이터가 누적되는 성능과 검색성능비교 테스트
테스트 pc 사양 : CentOS 6.3, i5 센디브릿지, 8G Ram, 7200rpm짜리 1기가 하드..이정도?정확히 모름
하드웨어는 공용이라서 속도 측정에 오차가 발생할 가능성이 높음

– 데이터 누적 입력 테스트

1번 테이블

1회 : 27752ms
2회 : 28085
3회 : 29445
4회 : 28864
5회 : 29634
6회 : 27742

 

2번 테이블 (1번과 같은 쿼리)

1회 : 43306
2회 : 35274
3회 : 33770
4회 : 46349
5회 : 44384
6회 : 44153

3번 테이블

1회 : 21605
2회 : 22451
3회 : 22075
4회 : 20701
5회 : 24611
6회 : 25346

4번 테이블

1회 : 39211
2회 : 35934
3회 : 37053
4회 : 38488
5회 : 38954
6회 : 35096

여기까지 결론.
인덱스 두개자리는 시간이 오래 걸린다. 데이터 누적에 따라 느려지는건 별로 없다. 바이너리 인덱스라서
속도차이는 조금 있지만 신경쓸수준은 아니니 검색에 적합한 방식을 사용하면 될듯하다.

 

검색 쿼리도 확인을 해 봐야되는데.. 테스트 데이터를 만들어낸다음에 해? 보지않을 것 같다. 만약에 하게되면 해야될것. -샘플데이터 -검색쿼리

 

Postgresql FullTextSearch – 2017수정

디비에서 간단하게 문자열 검색을 할 때의 쿼리는 다음과 같다.

데이터 양 적거나/조회량이 적거나 해서 속도가 큰 문제가 되지 않을때는 이렇게 해도 충분하다.

 

like검색을 하면 무조건 full scan이 발생한다. 데이터가 늘어날수록 속도가 엄청나게 느려진다.

 

PostgreSQL Full Text Indexing

RDBMS에서도 문자열 검색이 필요할 때가 있는데
검색은 보통 루씬에 의존하는 방향으로 트렌드가 변하다 보니
FullTextSearch 쪽 기술은 싹이 트기도 전에 말라버려서…
영어쪽 기술은 충분히 지원되지만 한국어 지원은 잘 안된다.

인덱싱

인덱싱을 하면 한 문장이 형태소나 띄어쓰기 등 정해진 기준대로 단어를 분리해서 인덱스를 잡는다.

원래 문장 : ‘피자 맛있다. 햄버거는 몸에 안좋다.’

tsvector1=’피자’:1 ‘맛있다’:2 ‘햄버거는’:3 ‘ 몸에’:4:’안좋다’

tsvector2=’피자’:1 ‘맛있다’:2 ‘햄버거’:3 ‘ 몸’:4:’안좋다’ 5 ‘는’:3 ‘에’

형태소 분석기가 돌아간다면 tsvector2의 결과가 나오겠지만 별다른 설정없이 처리하면 1과같은 결과가 나오게 된다. 이 경우에는 ‘햄버거’를 검색하면 결과가 안 나올 수 있다.

‘서울특별시 종로구 흥인동’ 과 같은 원문이라면 별다른 처리 없이 인덱싱을 해도 검색에 많은 도움이 된다.

한개 컬럼만 인덱싱

gin, gist 인덱스를 두개 다 만든다.

여러컬럼 인덱싱 – tsvector 컬럼 추가

여러컬럼을 동시에 검색해야 하는 경우가 많으니.. 두번째 방법이 주로 사용된다.

검색

참고사이트