Elastic Search 학습 노트 의 9 가지 복잡 한 데이터 형식 과 끼 워 넣 기 대상
앞에서 말 한 간단 한 데이터 형식 을 제외 하고 Elasticsearch 는 JSON 의 null, 배열, 대상 도 지원 합 니 다.
공역
필드 의 값 을 비 울 수 있 습 니 다. 물론 배열 도 비 울 수 있 습 니 다.그러나 Lucene 에 서 는 null 값 을 저장 할 수 없 기 때문에 null 값 이 존재 하 는 도 메 인 은 공역 이 라 고 생각 합 니 다.
다음 세 가지 도 메 인 은 비어 있 는 것 으로 여 겨 집 니 다. 색인 되 지 않 습 니 다.
"null_value": null,
"empty_array": [],
"array_with_null_value": [ null ]
배열 영역
많은 경우, 우 리 는 tag 역 에 여러 개의 라벨 이 포함 되 기 를 희망 합 니 다.우 리 는 배열 의 형식 으로 라벨 을 색인 할 수 있 습 니 다.
{ "tag": [ "search", "nosql" ]}
배열 에 대해 서 는 특별한 맵 수요 가 없습니다.모든 도 메 인 은 0, 1 또는 여러 개의 값 을 포함 할 수 있 습 니 다. 마치 전문 도 메 인 에서 여러 개의 단 어 를 분석 하 는 것 과 같 습 니 다.
이것 은 배열 의 모든 값 이 같은 데이터 형식 이 어야 한 다 는 것 을 암시 한다.너 는 날짜 와 문자열 을 한데 섞 을 수 없다.색인 배열 을 통 해 새로운 도 메 인 을 만 들 면 Elasticsearch 는 배열 의 첫 번 째 값 의 데이터 형식 을 이 도 메 인 형식 으로 사용 합 니 다.
메모: Elasticsearch 에서 문 서 를 얻 었 을 때 각 배열 의 순 서 는 처음에 문 서 를 색인 할 때 와 같 습 니 다.네가 얻 은source 필드, 색인 과 똑 같은 JSON 문 서 를 포함 합 니 다.
그러나 배열 은 다 중 값 영역 색인 으로 검색 할 수 있 지만 무질서 합 니 다.검색 할 때 '첫 번 째' 나 '마지막' 을 지정 할 수 없습니다.더 정확히 말 하면 수 조 를 자루 에 담 은 값 으로 상상 해 보 자.
다단 계 대상
내부 대상 은 항상 하나의 실체 나 대상 을 다른 대상 에 삽입 하 는 데 사용 된다.예 를 들 어 트 위 터 문서 에 user 를 포함 하 는 것 보다name 과 userid 필드, 우리 도 이렇게 쓸 수 있 습 니 다:
{
"tweet": "Elasticsearch is very flexible",
"user": {
"id": "@johnsmith",
"gender": "male",
"age": 26,
"name": {
"full": "John Smith",
"first": "John",
"last": "Smith"
}
}
}
내부 개체 맵
Elasticsearch 는 새로운 대상 도 메 인 을 동적 으로 모니터링 하고 매 핑 합 니 다. Elasticsearch 6 이전 properties 속성 은 다음 과 같 습 니 다.
{
"gb": {
"tweet":
"properties": {
"tweet": { "type": "string" },
"user": {
"type": "object",
"properties": {
"id": { "type": "string" },
"gender": { "type": "string" },
"age": { "type": "long" },
"name": {
"type": "object",
"properties": {
"full": { "type": "string" },
"first": { "type": "string" },
"last": { "type": "string" }
}
}
}
}
}
}
}
}
user 와 nam e 역 의 매 핑 구 조 는 트 위 터 형식 과 같 습 니 다.사실 type 맵 은 특수 한 대상 맵 일 뿐 뿌리 대상 이 라 고 합 니 다.이 를 제외 하고 일부 문서 메타 데이터 의 특수 한 최상 위 도 메 인 이 있 습 니 다. 예 를 들 어source 와all 도 메 인, 다른 대상 과 같 습 니 다.
주: elasticsearch 6 이후 object 형식 이 없습니다. 기본 내장 처리 되 었 습 니 다.elasticsearch 6 이후 맵 조회 결 과 는 다음 과 같 습 니 다.
{
"test": {
"mappings": {
"test": {
"properties": {
"tweet": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"user": {
"properties": {
"age": {
"type": "long"
},
"gender": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"id": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"name": {
"properties": {
"first": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"full": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"last": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
}
}
}
}
}
}
}
}
}
}
내부 개체 인덱스
Lucene 은 내부 대상 을 지원 하지 않 습 니 다.Lucene 문 서 는 목록 에 대한 키 값 으로 구성 되 어 있 습 니 다.Elasticsearch 가 내부 클래스 를 효과적으로 색인 할 수 있 도록 문 서 를 이렇게 바 꿉 니 다.
{
"tweet": [elasticsearch, flexible, very],
"user.id": [@johnsmith],
"user.gender": [male],
"user.age": [26],
"user.name.full": [john, smith],
"user.name.first": [john],
"user.name.last": [smith]
}
내부 도 메 인 은 이름 으로 참조 할 수 있 습 니 다 (예 를 들 어 first).같은 이름 의 두 도 메 인 을 구분 하기 위해 서 는 전체 경로 (예 를 들 어 user. name. first) 나 type 이름 추가 경로 (tweet. user. name. first) 를 사용 할 수 있 습 니 다.
앞의 간단 하고 납작한 문서 에는 user 와 user. name 필드 가 없습니다.Lucene 색인 은 스칼라 와 단순 값 만 있 고 복잡 한 데이터 구조 가 없습니다.
내부 개체 배열
만약 에 우리 가 followers 내부 대상 배열 이 있다 고 가정 하면:
{
"followers": [
{ "age": 35, "name": "Mary White"},
{ "age": 26, "name": "Alex Jones"},
{ "age": 19, "name": "Lisa Smith"}
]
}
이 문 서 는 우리 가 이전에 설명 한 것 처럼 평면 적 으로 처 리 될 것 입 니 다. 결 과 는 다음 과 같 습 니 다.
{
"followers.age": [19, 26, 35],
"followers.name": [alex, jones, lisa, smith, mary, white]
}
그러나 여기 서 한 가지 문제 가 있 습 니 다.
{age: 35}
와 {name: Mary White}
간 의 상관 성 은 이미 잃 어 버 렸 습 니 다. 모든 다 중 값 역 은 질서 있 는 배열 이 아니 라 무질서 한 값 이기 때 문 입 니 다.이것 은 우리 로 하여 금 "26 세의 추종자 가 있 습 니까?" 라 고 물 어보 게 하기에 충분 하 다.그러나 우 리 는 "26 살 짜 리 알 렉 스 존 스 라 는 추종자 가 있 습 니까?" 라 는 정확 한 답 을 얻 지 못 했다.
소켓 개체
위의 내부 대상 배열 의 문 제 를 고려 하여 우 리 는 아래 의 예 를 보 자.
Elasticsearch 에서 단일 문서 의 삭제 와 수정 은 모두 원자 적 인 작업 이기 때문에 관련 실체 데 이 터 를 같은 문서 에 저장 하 는 것 도 당연 하 다.예 를 들 어 우 리 는 주문서 와 명세 데 이 터 를 문서 에 저장 할 수 있다.또한, 우 리 는 블 로그 글 의 댓 글 을 하나의 comments 배열 의 형식 으로 블 로그 글 과 함께 놓 을 수 있다.
PUT /my_index/blogpost/1
{
"title": "Nest eggs",
"body": "Making your money work...",
"tags": [ "cash", "shares" ],
"comments": [
{
"name": "John Smith",
"comment": "Great article",
"age": 28,
"stars": 4,
"date": "2014-09-01"
},
{
"name": "Alice White",
"comment": "More like this please",
"age": 31,
"stars": 5,
"date": "2014-10-22"
}
]
}
필드 에 의존 하면 comments 필드 는 자동 으로 object 형식 으로 매 핑 됩 니 다.
모든 정보 가 하나의 문서 에 있 기 때문에 우리 가 조회 할 때 문장 과 평론 문 서 를 연합 할 필요 가 없 기 때문에 조회 효율 이 매우 높다.
그러나 우리 가 다음 과 같은 조 회 를 사용 할 때 위의 문서 도 조건 에 부합 되 는 결과 로 여 겨 진다.
GET /my_index/blogpost/_search
{
"query": {
"bool": {
"must": [
{ "match": { "name": "Alice" }},
{ "match": { "age": 28 }}
]
}
}
}
앨 리 스 는 실제로 31 살 이지 28 이 아니다!주의: elasticsearch 6 이후 버 전 은 전체 문제 가 없 었 고 해결 되 었 습 니 다. 6 이후 의 조회 결 과 는 명중 되 지 않 았 습 니 다. 결 과 는 다음 과 같 습 니 다.
{
"took": 0,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 0,
"max_score": null,
"hits": []
}
}
우리 가 대상 배열 에서 토론 한 것 처럼 위 와 같은 문제 가 발생 한 이 유 는 JSON 형식의 문서 가 다음 과 같은 평면 키 쌍 의 구조 로 처리 되 었 기 때문이다.
{
"title": [ eggs, nest ],
"body": [ making, money, work, your ],
"tags": [ cash, shares ],
"comments.name": [ alice, john, smith, white ],
"comments.comment": [ article, great, like, more, please, this ],
"comments.age": [ 28, 31 ],
"comments.stars": [ 4, 5 ],
"comments.date": [ 2014-09-01, 2014-10-22 ]
}
Alice 와 31, John 과 2014 - 09 - 01 사이 의 관련 성 정 보 는 더 이상 존재 하지 않 는 다.object 형식 (내부 대상 참조) 은 단일 대상 을 저장 할 때 유용 하지만 대상 배열 의 검색 에 서 는 소 용이 없습니다.
포 함 된 대상 은 바로 이 문 제 를 해결 하 러 온 것 이다.comments 필드 형식 을 object 가 아 닌 nested 로 설정 한 후, 모든 끼 워 넣 은 대상 은 숨겨 진 독립 된 문서 로 인 덱 싱 됩 니 다. 예 를 들 어 다음 과 같 습 니 다.
{ #
"comments.name": [ john, smith ],
"comments.comment": [ article, great ],
"comments.age": [ 28 ],
"comments.stars": [ 4 ],
"comments.date": [ 2014-09-01 ]
}
{ #
"comments.name": [ alice, white ],
"comments.comment": [ like, more, please, this ],
"comments.age": [ 31 ],
"comments.stars": [ 5 ],
"comments.date": [ 2014-10-22 ]
}
{ #
"title": [ eggs, nest ],
"body": [ making, money, work, your ],
"tags": [ cash, shares ]
}
모든 포 함 된 대상 을 독립 적 으로 색인 한 후 대상 필드 의 상관 성 을 유지 할 수 있 습 니 다.우리 가 조회 할 때 도 진정 으로 조건 에 맞 는 문서 만 되 돌려 준다.
뿐만 아니 라 포 함 된 문 서 는 문서 내부 에 직접 저장 되 어 있 기 때문에 조회 할 때 포 함 된 문서 와 루트 문서 의 결합 비용 이 낮 고 속도 가 단독 저장 과 거의 같 습 니 다.
새 겨 진 문 서 는 숨겨 진 저장 소 입 니 다. 직접 가 져 올 수 없습니다.새 겨 진 대상 을 추가 삭제 하려 면 전체 문 서 를 다시 색인 해 야 합 니 다.주의해 야 할 것 은 조회 할 때 전체 문 서 를 되 돌려 주 는 것 이지, 문서 자 체 를 끼 워 넣 는 것 이 아니다.
포 함 된 개체 맵
필드 를 nested 로 설정 하 는 것 은 간단 합 니 다.
PUT /my_index
{
"mappings": {
"blogpost": {
"properties": {
"comments": {
"type": "nested",
"properties": {
"name": { "type": "string" },
"comment": { "type": "string" },
"age": { "type": "short" },
"stars": { "type": "short" },
"date": { "type": "date" }
}
}
}
}
}
}
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
다양한 언어의 JSONJSON은 Javascript 표기법을 사용하여 데이터 구조를 레이아웃하는 데이터 형식입니다. 그러나 Javascript가 코드에서 이러한 구조를 나타낼 수 있는 유일한 언어는 아닙니다. 저는 일반적으로 '객체'{}...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.