elasticsearch 다섯 번 째 편 (문서 조작 인터페이스)
예시:
1
2
3
4
5
PUT /test/user/1
{
"name": "silence",
"age": 27
}
설명: 1. 색인 문 서 는 PUT 방법 을 사용 합 니 다. index (test), type (user), 문서 번 호 를 지정 하고 json 형식 으로 문서 의 내용 을 제출 해 야 합 니 다. 2. 색인 문서 에 있 을 때 index 와 type 이 존재 하 는 지 자동 으로 검사 합 니 다. 존재 하지 않 으 면 자동 으로 생 성 됩 니 다. type 에 대해 서 는 putmapping 방법 을 type 으로 자동 으로 호출 하여 mapping 을 만 듭 니 다.제출 한 json 데이터 가 필드 를 추가 할 때 type 에 자동 으로 puutmapping 방법 을 호출 하여 mapping 에 새로운 필드 형식 을 추가 합 니 다. elasticsearch. yml 에 설정 을 추가 하면 index 와 type 을 자동 으로 만 들 지 않 습 니 다.
1
2
action.auto_create_index: false
index.mapper.dynamic: false
어떤 경우 에는 특정한 유형의 index 를 자동 으로 만 들 거나 사용 하지 않 으 면 일치 하 는 모드 와 흑백 명단 형식 으로 설정 할 수 있 습 니 다.
1
action.auto_create_index: +test*,+temp*,+tmp* # test,temp,tmp index
설명: action. autocreate_index 는 true 로 설정 되 어 있 거나 일부 index 를 실행 할 수 있 습 니 다. index. mapper. dynamic 은 false 로 설정 되 어 있 으 며, 첫 번 째 시 index 는 자동 으로 type 을 만 들 수 있 습 니 다. 나중에 새로운 type 을 따로 만 들 수 없습니다.
3. 문서 의 version 속성 es 는 모든 문서 에 자동 으로 version 속성 을 설정 합 니 다. version 은 1 부터 문서 가 업데이트 되 고 삭제 작업 이 발생 할 때 version 은 1 이 증가 합 니 다. version 은 범위 [1, 9.2e + 18] 의 정수 입 니 다.문 서 를 가 져 오 거나 조회 하 는 것 은 version 이 문서 의 일부분 으로 version 속성 을 되 돌려 주 는 것 입 니 다. 주로 낙관적 인 잠 금 기 를 사용 하여 데 이 터 를 읽 은 후에 업데이트 동작 을 할 때의 데이터 일치 성 문 제 를 보증 합 니 다. 요청 을 제출 할 때 지정 한 version 매개 변 수 를 통 해 저 장 된 버 전이 항목 에 부합 되 어야 성공 할 수 있 음 을 표시 합 니 다. 기본 조건 은 둘 이 일치 합 니 다.version 을 제출 하지 않 으 면 검사 사용 방법 을 표시 하지 않 습 니 다. 예 를 들 어 번호 가 1 인 문서 version 은 7 입 니 다.
1
2
3
4
5
6
7
8
9
10
11
{
"_index": "test",
"_type": "user",
"_id": "1",
"_version": 7,
"found": true,
"_source": {
"name": "silence",
"age": 27
}
}
다음 과 같은 업데이트 요청 동작 을 사용 하면 실행 성공 을 볼 수 있 습 니 다. 또한 version 은 1 을 증가 하고 결 과 를 되 돌려 줍 니 다. 8: 입력:
1
2
3
4
5
PUT /test/user/1?version=7
{
"name": "silence",
"age": 28
}
출력:
1
2
3
4
5
6
7
{
"_index": "test",
"_type": "user",
"_id": "1",
"_version": 8,
"created": false
}
우리 가 다시 version = 7 의 요청 을 보 낼 때 받 은 응답 은:
1
2
3
4
{
"error": "VersionConflictEngineException[[test][2] [user][1]: version conflict, current [8], provided [7]]",
"status": 409
}
자신 이 version > 8 의 요청 을 테스트 하 는 데 실 패 했 습 니 다. 이 때 높 은 병행 상황 에서 이러한 효율 이 낮은 지 생각 할 수 있 습 니 다. 메모리 에 version + 1 의 사본 을 설치 하고 메모리 에서 사본 을 증가 시 킨 다음 에 비동기 방식 으로 병행 을 높 일 수 있 습 니 다. 이 때 실행 성 공률 이 떨 어 지고 데이터 가 손실 될 수 있 습 니 다.이러한 상황 에서 지정 한 version 이 저장 되 어 있 는 버 전 번호 보다 크 면 됩 니 다. 이 문 제 를 해결 하기 위해 es 는 version 을 제공 합 니 다.type 에서 사용 할 비교 정책 을 지정 할 수 있 습 니 다:
version_type 값
설명 하 다.
internal
기본 값 은 지정 한 version 이 저 장 된 version 과 일치 해 야 한 다 는 것 을 의미 합 니 다. 성공 하면 version 이 자동 으로 증가 합 니 다.
external/external_gt
지정 값 은 저 장 된 version 보다 커 야 합 니 다. version 을 제출 한 version 으로 성공 적 으로 저장 하면
external_gte
지정 값 은 저 장 된 version 보다 커 야 합 니 다. version 을 제출 한 version 으로 성공 적 으로 저장 하면
force
강제로 업데이트 하고 저장 version 을 제출 한 version 으로 설정 합 니 다.
4.op_type: 요청 을 제출 할 때 op 을 지정 합 니 다.type = create, id 가 존재 하지 않 을 때 만 들 지 않 으 면 입력 에 실패 함 을 표시 합 니 다.
1
2
3
4
5
PUT /test/user/1?op_type=create
{
"name": "silence",
"age": 28
}
출력:
1
2
3
4
{
"error": "DocumentAlreadyExistsException[[test][2] [user][1]: document already exists]",
"status": 409
}
op_type = create 의 다른 표현 방법 은:
1
2
3
4
5
PUT user/1/_create
{
"name": "silence",
"age": 28
}
5. ID 생 성기: 대부분의 경우 문서 의 id 가 무엇 인지 유지 할 필요 도 없고 관심 도 없습니다. es 에 서 는 문서 에 자동 으로 id 를 생 성 할 수 있 습 니 다. post 방식 으로 파 라 메 터 를 제출 할 수 있 고 요청 에 서 는 id 값 을 지정 하지 않 습 니 다. (지정 하면 지정 한 id 값 을 사용 합 니 다) 6. routing 길 은 분 배 됩 니 다. index 를 만 들 때 보통 index 데 이 터 를 다른 shard 에 저장 합 니 다. es 기본 값 은 hash (id) 를 통 해 저 장 됩 니 다. % shard_num 은 문 서 를 어느 shard 에 저장 할 지 결정 합 니 다. 이 때 routing 의 역할 을 생각해 야 합 니 다. 맞습니다. 부하 가 hash 인 입력 매개 변 수 를 지정 하 는 것 입 니 다. 입력:
1
2
3
4
5
POST user/?routing=name
{
"name": "silence",
"age": 28
}
색인 문서 에 지정 한 routing 을 표시 하려 면 제출 문서 에 지정 한 routing 에 대응 하 는 값 이 있어 야 합 니 다. 그렇지 않 으 면 실행 에 실패 합 니 다.
7. 분산 실행 색인 작업 은 shard 로 이동 하고 이 shard 를 포함 하 는 node 에서 실 행 됩 니 다. shard 를 복사 하 는 것 이 존재 하면 모든 복사 노드 가 주 shard 에서 실 행 된 후에 결 과 를 되 돌려 줍 니 다.
8. 일치 성 은 일부 네트워크 노드 의 오 류 를 방지 하기 위해 기본 적 인 상황 에서 색인 성공 수량 > = 중재 (replicas / 2 + 1) 시 작업 이 성공 했다 고 생각 합 니 다. 복사 수량 이 1 일 때 데 이 터 는 모두 두 부 (주 shard 와 복사 shard) 가 저 장 됩 니 다. 이때 주 shard 가 성공 하면 실행 성공 은 elasticsearch. yml 에서 action. writeconsistency 는 원, all, quorum 수정 판단 근거 로 설정 합 니 다.
9. shard 새로 고침 은 색인 문서 가 성공 한 후에 바로 문 서 를 조회 하기 위해 (shard 가 새로 고침 되 어야 검색 할 수 있 습 니 다) refresh = true 를 설정 하여 색인 문서 가 성공 한 후에 이 데 이 터 를 저장 하 는 shard 의 새로 고침 동작 을 즉시 실행 할 수 있 습 니 다. 설정 하기 전에 색인 과 조회 에 대해 성능 테스트 를 해 야 합 니 다. get 인터페이스 에서 문 서 를 가 져 오 는 것 은 완전히 실시 간 입 니 다.
자신 이 지나 간 구덩이 하 나 를 다시 공유 합 니 다: 배경: 로그 에 존재 하 는 모든 원본 IP 를 통계 해 야 합 니 다. 로 그 를 하루 에 저장 해 야 합 니 다. 코드 구 조 는 다음 과 같 습 니 다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
def get_all_store_hosts():
'''
es ip
doc refresh
'''
return _all_
def get_distinct_hosts_from_logs(day):
'''
ip
'''
return _hosts_
def store_hosts(hosts)
'''
ip es
'''
def stat(day):
_all_ = get_all_store_hosts()
_hosts_ = get_distinct_hosts_from_logs:
_hosts_ = [_host for _host in _hosts_ if _host not in _all_]
if len(_hosts_):
store_hosts(_hosts_)
if __name__ == '__main__':
for day in xrange(1, 30):
stat(day)
여러분, 문제 있어 요?좋 습 니 다. 문제 가 없 는 것 같 습 니 다. 하지만 실행 이 완료 되면 es 에서 당신 의 통계 데이터 에 중복 되 는 ip 이 대량으로 저장 되 어 있 는 것 을 놀 라 게 할 것 입 니 다. 문제 의 원인 은 모두 가 이미 알 고 있 겠 죠?
해결 방법: 저 는 메모리 에 캐 시 를 만 들 었 습 니 다. 캐 시 를 통 해 다시 하고 캐 시 에 존재 하지 않 을 때 캐 시 에 넣 고 es 에 저장 합 니 다.
예제: 입력:
GET /test/user/1 입력:1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
"_index": "test",
"_type": "user",
"_id": "1",
"_version": 3,
"found": true,
"_source": {
"name": "silence",
"age": 28,
"book": {
"name": " "
}
}
}
설명: 1. GET 방법 으로 문서 의 ID 에 따라 문서 내용 을 읽 을 수 있 습 니 다index,_type,_id 3 원 그룹 은 색인, 유형, 문서 id 를 표시 하 는 유일한 문 서 를 표시 합 니 다.version 은 문서 의 버 전 found 는 결 과 를 조회 할 지 여 부 를 표시 합 니 다. true 는 존재 합 니 다. false 는 존재 하지 않 습 니 다source 는 진정한 문서 내용 입 니 다.
2. HEAD 방법 을 통 해 reponse header 정보 에 따라 문서 의 입력 여 부 를 판단 할 수 있 습 니 다.
curl -XHEAD -i "http://localhost:9200/test/user/1"1
2
3
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Content-Length: 0`
입력:
curl -XHEAD -i "http://localhost:9200/test/user/1 출력:1
2
3
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=UTF-8
Content-Length: 0
문서 에 HEAD 방법 이 존재 하면 상태 코드 를 200 으로 되 돌려 줍 니 다. 그렇지 않 으 면 상태 코드 는 404 입 니 다.
3. GET 작업 은 기본적으로 실시 간 입 니 다. 즉, 문서 색인 후 바로 읽 을 수 있 습 니 다. Search 가 shard 새로 고침 을 기다 리 는 것 은 아니 지만 GET 요청 에서 인자 realime = false 또는 elasticsearch. yml 설정 action. get. realime: false 를 통 해 4 를 사용 하지 않 습 니 다. GET 데이터 에서 사용 할 수 있 습 니 다. "all "검색 할 대신type, 이 때 모든 type 에서 첫 번 째 로 일치 하 는 document 5 를 되 돌려 줍 니 다. GET 데이터 에서source, _source_include & _source_exclude 설정 은 문서 에 포 함 된 속성 입력 을 되 돌려 줍 니 다:
GET /test/user/1?_source=false 어떤 도 되 돌아 오지 않 음소스 내용 입력: GET /test/user/1?_source=name 돌아 오기 만source 의 name 입력: GET /test/user/1?_source_include=*.name&_source_exclude=name _source 는 한두 필드 를 되 돌려 야 하 는 경우 에 자주 사용 되 며, 내용 이 많은 문서 속성 값 을 선별 할 때 조합 할 수 있 습 니 다source_include 와source_exclude 6. 돌아 가 고 싶 으 면source 의 내용 을 사용 할 수 있 습 니 다:
GET /test/user/1/_source 7. 색인 문서 에 routing 을 지정 하면key 문 서 를 정확하게 GET 할 수 있 도록 GET 요청 에 routing 을 추가 하여 올 바른 routing 을 지정 해 야 합 니 다.key 8. 기본 GET 문 서 는 shard 를 복사 하 는 데 실 행 됩 니 다. preference 를 로 설정 할 수 있 습 니 다.primary 혹은local, _primary 는 주 shard 에서 실행 하 는 것 을 표시 합 니 다.local 은 할당 되 고 사용 가능 한 shard 에서 9. GET 요청 을 수행 할 때 refresh = true 인 자 를 추가 하여 문서 와 관련 된 shard 를 강제로 새로 고침 할 수 있 음 을 표시 합 니 다. 이 는 search 에서 10. GET 요청 이 발 송 된 후,필요 에 따라 문서 id 를 가 져 와 서 복사 노드 에 요청 을 전송 하고 결 과 를 되 돌려 줍 니 다. 11. GET 요청 에서 version 속성 을 지정 하여 규칙 에 맞 는 문 서 를 가 져 올 수 있 습 니 다.DELETE API
예제: 입력
DELETE /test/user/1설명: 1. DELETE 방법 으로 제출 한 매개 변수 에서 version 속성 을 설정 하여 규칙 에 맞 는 version 문 서 를 삭제 할 수 있 습 니 다. 2. index 문서 에 routing 을 설정 할 때key, 문 서 를 삭제 할 때 도 routing 을 사용 하여 올 바른 routing 을 설정 해 야 합 니 다.key 3. 문 서 를 삭제 하 는 것 이 index 가 존재 하지 않 으 면 es 는 자동 으로 생 성 됩 니 다. 4. 문서 삭제 요청 은 주 shard 에 전 달 됩 니 다. 주 shard 작업 이 완료 되면 각 복사 shard 는 주 shard 에서 동기 화 됩 니 다.from: http://imsilence.github.io/2015/09/17/elasticsearch/elasticsearch_05/
좋은 웹페이지 즐겨찾기
