ElasticSearch 와 Solr 을 두 가지 측면에서 비교하고 관계형 데이터베이스의 가져오기 속도와 모호한 쿼리 속도를 비교합니다.
독립 실행형 비교
1. Solr 는 4.0-알파를 발표했는데, 직접 스키마를 수정해야 한다는 것을 알게 되었는데, 이는 데이터 importer 를 가지고 있다는 장점이 있다. 자신의 컴퓨터에서 테스트한 결과, 가져오기 성능은 약 14 분 동안 3092730 개의 레코드를 가져와 약 3682 개/초 정도입니다.
2. 3 백만 개의 레코드가 있는 경우 퍼지 쿼리 및 정렬은 기본적으로 1 초 이내에
를 반환합니다3. 아까 테스트, 각 field 가 별도로 저장되었습니다. 이제 프로필을 수정하여 copyfield 를 하나 추가했습니다. 모든 field 가 text 라는 Field 에 복사했습니다. 가져오기 성능은 약 19 분 동안 3092730 개의 레코드, 약 2713 개/
4.300 만 개의 레코드의 경우 text 에 대한 퍼지 쿼리는 기본적으로 1 초 이내에 반환되지만 모든 레코드의 정렬에는 약 2~3 초
가 소요됩니다5. elasticsearch 0.19.8, 기본 구성, 단일 작업으로 가져오기, 가져오기 성능: 20 분 동안 3092730 개의 레코드 가져오기, 약 2577 개/초
6.300 만 개의 레코드의 경우 질의는 기본적으로 1 초 이내에 반환되지만 퍼지 쿼리는 비교적 느립니다. 처음에는 10 초, 나중에는 약 1~3 초가 걸립니다. 정렬을 더하면 약 5 초 정도 걸리고 전체 정렬은 기본 100ms
입니다조회 및 정렬 명령:
{
쿼리: {
"query _ string": {
쿼리: "* 999 *"
}
},
"sort": [
{
"time _ up": {
"주문": "ASC"
}
}
]
}
7. Es0.19.8, 두 가지 작업으로 가져오기 성능: 13 분 3092730 개 레코드, 약 3965 개/초
8. Solr 이 모두 인덱싱된 후 차지하는 디스크 공간은 1.2G, es 가 차지하는 디스크 공간은 4G
입니다독립 실행형 비교 2
Intel i7, 32G 메모리 시스템에서 이 두 가지의 대비를 다시 실행합니다. 하지만 한 가지 큰 차이점은 Solr 이 성능이 좋은 이 기계에서 뛰고, es 의 가져오기 프로세스는 인텔 쿼드 코어 2.5G, 4G 메모리 기계에서 달리고 있으며, 성능 차이가 있을 수 있다는 것입니다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), Northern Exposure (미국 TV 드라마) ES 버전 0.19.8, Solr 버전 4.0-알파.
1. Solr 가져오기 성능: 3400 만 개의 레코드, 62 분, 평균 9140 개/초, 12.75G
점유 공간2. *999* 와 같은 퍼지 쿼리를 사용하여 3 초 이내에 반환, 약간 긴 쿼리 조건 *00100014* 또는 2~3 초 반환
3. Es 의 가져오기 성능 (Xmx 를 10g 로 설정): 3400 만 개의 레코드, 소요 시간 40 분, 평균 14167 개/초, 설치 공간 33.26G, 클라이언트 4 개 동시.
4. *999* 와 같은 퍼지 쿼리를 사용하여 9 초 반환, 약간 긴 쿼리 조건 *00100014*, 11.8 초 반환
5. 모든 필드에 대해 질의하는 것이 아니라 특정 필드 (예: Sam _ code: * 00100014 *) 에 대해 질의하는 경우에도 1 초 이내에 반환됩니다.
6. 결론: es 의 조회 효율도 높을 수 있지만, 우리는 아직 사용하지 않을 것이다.
7. 결론 2: ES 는 모든 필드를 함께 두는 설정을 가지고 있는데, 기본값은 함께 두는 것이지만, 왜 정당한 역할을 하지 못했는지 모르겠다.
참고:
1. Solr 의 첫 번째 메모리는 기본 설정을 사용했는데, 이번에는 10G 로 바뀌었는데, 결국 가져오기 성능이 오히려 나빠졌고, 400 만 개의 레코드가 8 분, 평균 8333 개/초, 왜 그런지 모르겠다.
2. 기본 메모리 구성으로 다시 변경합니다. 가져오기 속도가 여전히 느립니다.
3. 리눅스를 다시 시작하고, 10G 메모리 구성으로, 5030 만개의 레코드, 소요 시간 92 분, 약 9112 개/초, 가져오기 속도와 메모리 구성에 큰 차이가 없음을 나타냅니다.
4. 10G 구성의 경우 검색 속도도 크게 다르지 않습니다.
5. lucene4.0 과 solr4.0 의 진보가 얼마나 큰지 파악하기 위해 solr3.6.1 을 다운로드했지만 다행히 4.0 프로필도 3.6.1 에서도 사용할 수 있어 빨리 함께 테스트해 3400 만개 레코드, 사용 쿼리 성능: *999* 첫 11.6s, *00100014* 27.3s, 4.0 알파의 결과 비교 (5 천만 결과 중 *999* 첫 2.5s, *00100014* 1 위
클러스터 비교:
동일 구성의 Centos 6.3 클러스터 4 대 (Intel i7, 32G 메모리) 를 비교.
1. 우선 es 입니다. 편리하게 클러스터 하나를 구성했습니다. 지난 3400 만개의 인더스 전체 균형 로드를 기다린 후 테스트를 해서 다른 인덕스로 가져왔습니다.
2. 가져오기 성능: 8500 만 개의 레코드, 소요 시간 72 분, 약 19676 개/초. 처음 5 천만 개의 레코드를 가져올 때의 속도는 2 만/개 이상이고 초기 속도는 2 만 2 천/개였다.
점유 공간 78.6G (중복으로 인해 실제 점유 공간은 157.2G)
3. 쿼리 성능:
*999* 첫 13.5 초, 두 번째 19.5 초, 세 번째 7.4 초, 네 번째 7.1 초, 다섯 번째 7.1 초
*00100014* 첫 17.2 초, 두 번째 16.6 초, 세 번째 17.9 초, 네 번째 16.7 초, 다섯 번째 17.1 초
Sam _ code: * 999 *, 0.8s, 1.3s, 0.02s, 0.02s, 0.02s
Sam _ code: * 00100014 *, 0.1s, 0.1s, 0.02s, 0.03s, 0.05s
4. Solr4.0-ALPHA, SolrCloud 구성은 간단합니다. ZooKeeper 를 시작한 다음 다른 3 대의 시스템이 이 주소에 액세스하면 cloud:
를 구성할 수 있습니다시스템 1: nohup Java-xms10g-xmx10g-xss256k-d jetty.port = 8983-dsolr.solr.home = "./exampp -d collection.configname = xab conf 3-dzk run-dnum shards = 4-jarstart.jaramp;
기타 시스템: nohup Java-xms10g-xmx10g-dsolr.solr.home = "./example-dih/Solr/"-dzkhost =
하지만 data import 를 수행할 때 out of memory error: unable to create new native thread 가 자주 나타납니다. 많은 자료를 조사해 Linux 의 ulimit 에서 nproc 를 10240 으로, Xss 를 256K 로 바꿔도 문제가 해결되지 않는다. 당분간 진행할 방법이 없다.
결론
1. 가져오기 성능, es 향상
2. 쿼리 성능, Solr 4.0 최고, es 는 Solr 3.6 과 동등하다. es 가 lucene4 를 채택한 후 성능이 향상될 것이라고 낙관적으로 생각할 수 있다.
3. Es 는 SAM_CODE 와 같은 쿼리 성능은 좋지만 _all 을 사용하면 성능이 매우 나쁘고 차이가 매우 크기 때문에 현재 es 상황에서는 여전히 성능 향상을 위한 공간이 있다고 생각합니다. 하지만 아직 방법을 찾지 못했습니다.