Tag: Test

Docker Volume 중첩해서 셋팅하는 경우 발생하는 문제 확인

초기 디렉토리 구조 생성

➜  $ tree
 .
 ├── test1
 │   ├── test1
 └── test2
     └── test2
$ cat test1/test1
test1 file
$ cat test2/test2
test2 file

도커에서 볼륨을 셋팅하고 실행

$ docker run --rm -it \
-v $(pwd)/test1:/test \
-v $(pwd)/test2:/test/kkk \
-v $(pwd)/test2/test2:/test/test2file \
-v $(pwd)/test1/test1:/test/test1file \
-v $(pwd)/test2:/test/kkk1 \
alpine sh

도커 실행 후 HOST에서 봤을 때 변경된 파일구조

$ tree
 .
 ├── test1
 │   ├── kkk
 │   ├── kkk1
 │   ├── test1
 │   ├── test1file
 │   └── test2file
 └── test2
     └── test2

도커 실행 후 Container 내부에서 변경된 파일구조

# tree
 .
 ├── kkk
 │   └── test2
 ├── kkk1
 │   └── test2
 ├── test1
 ├── test1file
 └── test2file

volume 마운트 시켰는데 파일이 복사돼버림

중복된 마운트를 할 경우 생각과 다르게 동작할 가능성

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

로그 규칙:

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

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

CREATE TABLE log_upload1
(
  regdate timestamp without time zone NOT NULL,
  filename character varying(100) NOT NULL,
  filenamepath character varying(255),
  logmessage character varying(255),
  PRIMARY KEY (regdate, filename)
);

CREATE TABLE log_upload2
(
  regdate timestamp without time zone NOT NULL,
  filename character varying(100) NOT NULL,
  logmessage character varying(255),
  filenamepath character varying(255),
  CONSTRAINT log_upload2_pkey PRIMARY KEY (filename)
);
CREATE INDEX log_upload2_idx
  ON log_upload2
  USING btree
  (regdate);

CREATE TABLE log_upload3
(
  id bigserial NOT NULL,
  regdate timestamp without time zone NOT NULL,
  filename character varying(100) NOT NULL,
  logmessage character varying(255),
  filenamepath character varying(255),
  PRIMARY KEY (id)
);
CREATE INDEX log_upload3_idx
  ON log_upload3
  USING btree
  (regdate);

CREATE TABLE log_upload4
(
  id bigserial NOT NULL,
  regdate timestamp without time zone NOT NULL,
  filename character varying(100) NOT NULL,
  logmessage character varying(255),
  filenamepath character varying(255),
  PRIMARY KEY (id)
);
CREATE INDEX log_upload4_idx
  ON log_upload4
  USING btree
  (regdate, filename);

– 데이터 누적 입력 테스트

1번 테이블

INSERT INTO log_upload1
(regdate, filename, filenamepath, logmessage)
select 
now(),
md5(random()::text)||nextval('test1'),
md5(random()::text)||currval('test1'),
'no message'
FROM generate_series(1,1500000);

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번 테이블

INSERT INTO log_upload3
(regdate, filename, filenamepath, logmessage)
select 
now(),
md5(random()::text)||nextval('test3'),
md5(random()::text)||currval('test3'),
'no message'
FROM generate_series(1,1500000);

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

4번 테이블

INSERT INTO log_upload4
(regdate, filename, filenamepath, logmessage)
select 
now(),
md5(random()::text)||nextval('test4'),
md5(random()::text)||currval('test4'),
'no message'
FROM generate_series(1,1500000);

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

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

 

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