대부분의 제대로된 성능비교와 다르게 ,
음..예를 들어, 앱스토어 검색이라고 하자
앱 Data + Category 정보가 있을것이다.
이걸 한 Core에 때려넣고 카테고리 필드를 만들까?
or
카테고리 별로 여러 Core를 만들까 ?
로 테스트를 하게 되었다.
이건 누가봐도...후자가 훨씬 더 빠르다는게 뻔한 결과라
삽질에 가까운 테스트를 하였다는것이다.
<Schema>
title : String
cn : 카테고리
로 만들고, 랜덤 Data 를 n건 생성한후,
100*100번 질의 하였다.
카테고리는 2개만 생성하였다,
즉, Single Core는 2*n개의 Data가 , MultiCore 는 2개의 Core에 각각 n개 Data를 생성 하였다.
1. SingleCore 에 질의 ( q = 랜덤쿼리 AND ct:ac)
2. MultiCore에 질의 ( q = 랜덤쿼리 )
3. MultiCore에 카데고리를 AND 조건으로 질의 ( q = 랜덤쿼리 AND ct:ac)
4. DistribuedSearch ( shards=서버1,서버2&q=랜덤쿼리 AND ct:ac)
각각의 색인건수에 대하여 수행시간을 기록
삽질의 결과이다.
보시다 시피,
1.SinglCore 와 MultiCore는 약 3~4배 정도 성능차이가 남을 알 수 있다.
2.DistributedSearch는 성능 상 큰 이점이 없다(관리이슈로 보자면 아무 생각없이 Core를 나눠서 넣을 수 있어서, 상황에 따라 이점이 있을수있지만, 단순 조회성능으로 보면 이점 없음)
3.Query에 쓸데없는 조건 들어가면 성능이 확 떨어짐
3번 조건과 4번 조건에 대해선, 튜닝을 좀 해 볼 여지가 있을듯.
음..예를 들어, 앱스토어 검색이라고 하자
앱 Data + Category 정보가 있을것이다.
이걸 한 Core에 때려넣고 카테고리 필드를 만들까?
or
카테고리 별로 여러 Core를 만들까 ?
로 테스트를 하게 되었다.
이건 누가봐도...후자가 훨씬 더 빠르다는게 뻔한 결과라
삽질에 가까운 테스트를 하였다는것이다.
<Schema>
title : String
cn : 카테고리
로 만들고, 랜덤 Data 를 n건 생성한후,
100*100번 질의 하였다.
카테고리는 2개만 생성하였다,
즉, Single Core는 2*n개의 Data가 , MultiCore 는 2개의 Core에 각각 n개 Data를 생성 하였다.
1. SingleCore 에 질의 ( q = 랜덤쿼리 AND ct:ac)
2. MultiCore에 질의 ( q = 랜덤쿼리 )
3. MultiCore에 카데고리를 AND 조건으로 질의 ( q = 랜덤쿼리 AND ct:ac)
4. DistribuedSearch ( shards=서버1,서버2&q=랜덤쿼리 AND ct:ac)
각각의 색인건수에 대하여 수행시간을 기록
| 만개 | 십만개 | 5십만개 | 백만개 | 백5십만개 | |
| Single, Field 조회 | 367 | 563 | 1537 | 2778 | 4280 |
| MultiCore(title만 검색) | 347 | 498 | 562 | 788 | 1039 |
| MultiCore, Field( AND ct:ac 까지 넣어서 검색) | 309 | 488 | 1320 | 2408 | 3561 |
| DistributedSEarch | 945 | 1212 | 2055 | 3335 | 4617 |
삽질의 결과이다.
보시다 시피,
1.SinglCore 와 MultiCore는 약 3~4배 정도 성능차이가 남을 알 수 있다.
2.DistributedSearch는 성능 상 큰 이점이 없다(관리이슈로 보자면 아무 생각없이 Core를 나눠서 넣을 수 있어서, 상황에 따라 이점이 있을수있지만, 단순 조회성능으로 보면 이점 없음)
3.Query에 쓸데없는 조건 들어가면 성능이 확 떨어짐
3번 조건과 4번 조건에 대해선, 튜닝을 좀 해 볼 여지가 있을듯.
Trackback Address :: http://exif.net/trackback/98
