ElasticSearch 문서란?문서 인덱스

문서란?

프로그램의 대부분 실체나 대상은 키 값 쌍을 포함하는 JSON 대상으로 서열화될 수 있으며 키 (키) 는 필드 (field) 또는 속성 (property) 의 이름이며, 값 (value) 은 문자열, 숫자, 볼 유형, 다른 대상, 값 그룹 또는 다른 특수한 유형, 예를 들어 날짜를 나타내는 문자열, 지리적 위치를 나타내는 대상이 될 수 있다.
1

{
    "name":         "John Smith",
    "age":          42,
    "confirmed":    true,
    "join_date":    "2014-06-01",
    "home": {
        "lat":      51.5,
        "lon":      0.1
    },
    "accounts": [
        {
            "type": "facebook",
            "id":   "johnsmith"
        },
        {
            "type": "twitter",
            "id":   "johnsmith"
        }
    ]
}

일반적으로, 우리는 대상 (object) 과 문서 (document) 가 등가가 서로 통한다고 생각할 수 있다.그러나 그들은 차이점이 있다. 대상(Object)은 해시, hashmap, 사전 또는 관련 수조와 유사한 JSON 구조체이다.객체(Object)에 다른 객체(Object)도 포함될 수 있습니다.Elasticsearch에서 문서(document)라는 용어는 특수한 의미를 가지고 있다.이것은 최상위 구조나 루트 객체(root object)가 시퀀스화된 JSON 데이터(고유 ID로 식별되어 Elasticsearch에 저장됨)를 의미합니다.
1

문서 메타데이터

하나의 문서는 데이터만 있는 것이 아니다.문서에 대한 정보도 메타데이터 (metadata) 를 포함한다.세 개의 필수 메타데이터 노드는 다음과 같습니다.
노트
설명_index
문서가 저장된 곳_type
문서가 대표하는 대상의 클래스_id
문서의 고유한 식별

_index

인덱스 (index) 는 관계형 데이터베이스에 있는 '데이터베이스'와 유사하다. 인덱스와 관련된 데이터를 저장하는 곳이다.
팁:
사실상, 우리의 데이터는 섹션 (shards) 에 저장되고 인덱스는 한 개 이상의 섹션을 한데 묶는 논리적 공간일 뿐이다.그러나 이것은 단지 내부 세부 사항일 뿐이다. 우리의 프로그램은 분리에 전혀 관심이 없다.프로그램의 경우, 문서는 인덱스 (index) 에 저장됩니다.나머지 디테일은 Elasticsearch가 관심을 가져도 된다.
1
색인 관리 섹션에서 색인을 만들고 관리하는 방법을 연구하지만, 지금은 Elasticsearch에서 색인을 만들 것입니다.우리가 유일하게 해야 할 일은 단지 색인 이름을 선택하는 것이다.이 이름은 모두 소문자여야 하며 밑줄로 시작할 수 없고 쉼표를 포함할 수 없습니다.색인 이름으로 website을 사용하겠습니다.
1

_type

응용 프로그램에서 우리는 대상을 사용하여 특정한'사물'을 나타낸다. 예를 들어 한 사용자, 한 블로그, 한 평론, 또는 한 통의 메일이다.모든 대상은 하나의 클래스 (class) 에 속하는데, 이 클래스는 속성이나 대상과 관련된 데이터를 정의합니다.user 클래스의 객체에는 이름, 성별, 나이 및 이메일 주소가 포함될 수 있습니다.
1
관계형 데이터베이스에서 우리는 항상 같은 종류의 대상을 하나의 표에 저장한다. 왜냐하면 그들은 같은 구조를 가지고 있기 때문이다.같은 이치로 Elasticsearch에서 우리는 같은 유형(type)의 문서를 사용하여 같은'사물'을 나타낸다. 왜냐하면 그들의 데이터 구조도 같기 때문이다.
모든 유형(type)은 자신의 맵(mapping)이나 구조 정의를 가지고 있으며 전통적인 데이터베이스 테이블의 열과 같다.모든 종류의 문서는 같은 인덱스에 저장되지만, 형식의 매핑 (mapping) 은 Elasticsearch의 다른 문서가 어떻게 인덱스되는지 알려 줍니다.우리는 에서 맵을 어떻게 정의하고 관리하는지 연구할 것이지만, 지금은 Elasticsearch에 의존하여 데이터 구조를 자동으로 처리할 것이다._type의 이름은 대문자나 소문자일 수 있으며 밑줄이나 쉼표를 포함할 수 없습니다.우리는 blog을 유형명으로 사용할 것이다.

_id

id는 단지 하나의 문자열로 _index과 _type을 조합할 때 Elasticsearch에서 유일하게 문서를 표시할 수 있습니다.문서를 만들면 _id을 사용자 정의할 수도 있고, Elasticsearch가 자동으로 생성할 수도 있습니다.

기타 메타데이터

또 일부 다른 메타데이터가 있는데, 우리는 에서 연구할 것이다.위에서 언급한 요소를 사용하면 우리는 이미 Elasticsearch에 문서를 저장하고 ID 검색을 통해 Elasticsearch를 문서 저장소로 사용할 수 있다.

문서 인덱스

문서는 index API를 통해 인덱스되므로 데이터를 저장하고 검색할 수 있습니다.하지만 우선 문서의 소재를 결정해야 한다.논의한 바와 같이 문서는 _index, _type, _id을 통해 유일하게 확정되었다._id을 직접 제공하거나 index API를 사용하여 생성할 수 있습니다.
1

자신의 ID 사용

만약 당신의 문서에 자연스러운 표지부호(예를 들어 user_account 필드나 다른 값으로 문서를 표시)가 있다면 당신은 자신의 _id을 제공할 수 있습니다. 이런 형식의 index API를 사용할 수 있습니다.

PUT /{index}/{type}/{id}
{
  "field": "value",
  ...
}

예를 들어 우리의 인덱스는 “website”, 유형은 “blog”이고 우리가 선택한 ID는 “123”이다. 그러면 이 인덱스 요청은 다음과 같다.

PUT /website/blog/123
{
  "title": "My first blog entry",
  "text":  "Just trying this out...",
  "date":  "2014/01/01"
}

Elasticsearch 응답:

{
   "_index":    "website",
   "_type":     "blog",
   "_id":       "123",
   "_version":  1,
   "created":   true
}

요청에 응답하는 인덱스가 성공적으로 만들어졌습니다. 이 인덱스에는 _index, _type, _id 메타데이터와 새로운 요소가 포함되어 있습니다: _version.
2
Elasticsearch에는 문서마다 버전 번호가 있으며, 문서가 바뀔 때마다 (삭제 포함) _version이 증가합니다.버전 제어에서 우리는 _version호를 사용하여 프로그램의 일부분이 다른 부분의 변경 사항을 덮어쓰지 않도록 하는 방법을 연구할 것이다.

자체 ID 증가

만약 우리의 데이터가 자연 ID가 없다면, 우리는 Elasticsearch가 자동으로 우리를 위해 생성할 수 있다.요청 구조에 변화가 생겼다. PUT 방법인 “ URL ”이 POST 방법인 " "으로 바뀌었다.(역자주: 원래는 문서를 어떤 ID에 대응하는 공간에 저장한 것이었는데, 지금은 이 문서를 어느 _type에 추가한 것이다).
이제 URL에는 _index과 _type 두 필드만 포함됩니다.

POST /website/blog/
{
  "title": "My second blog entry",
  "text":  "Still trying this out...",
  "date":  "2014/01/01"
}

응답 내용은 아까와 유사하며 _id 필드만 자동으로 생성된 값으로 변경됩니다.
2

{
   "_index":    "website",
   "_type":     "blog",
   "_id":       "wM0OSFhDQXGZAWDf0-drSA",
   "_version":  1,
   "created":   true
}

자동으로 생성되는 ID는 22자 길이, URL-safe, Base64-encoded string universally unique identifiers 또는 UUIDs입니다.

문서 검색

Elasticsearch에서 문서를 얻으려면 우리는 같은 _index, _type, _id을 사용하지만 HTTP 방법은 GET으로 변경합니다.

GET /website/blog/123?pretty

응답은 현재 익숙한 메타데이터 노드를 포함하고 _source 필드를 추가했습니다. 색인을 만들 때 Elasticsearch에 보내는 원본 문서를 포함합니다.

{
  "_index" :   "website",
  "_type" :    "blog",
  "_id" :      "123",
  "_version" : 1,
  "found" :    true,
  "_source" :  {
      "title": "My first blog entry",
      "text":  "Just trying this out...",
      "date":  "2014/01/01"
  }
}

pretty

임의의 검색 문자열에 pretty 인자를 추가합니다. 위의 예와 유사합니다.Elasticsearch 미화 출력 (pretty-print) JSON 응답을 쉽게 읽을 수 있도록 합니다._source 필드는 미화되지 않고 우리가 입력한 것과 일치합니다.
GET 요청에 대한 응답은 {"found": true}으로 구성됩니다.이것은 문서가 이미 찾았다는 것을 의미한다.만약 우리가 존재하지 않는 문서를 요청한다면 여전히 JSON을 얻을 수 있지만 found의 값은 false으로 바뀌었다.
이 밖에 HTTP 응답 상태 코드도 '404 Not Found'으로 '200 OK'을 대체한다.우리는 curl 이후에 -i 매개 변수를 추가하여 응답 헤더를 얻을 수 있다.

curl -i -XGET http://localhost:9200/website/blog/124?pretty

현재 응답은 다음과 같습니다.

HTTP/1.1 404 Not Found
Content-Type: application/json; charset=UTF-8
Content-Length: 83

{
  "_index" : "website",
  "_type" :  "blog",
  "_id" :    "124",
  "found" :  false
}

문서의 일부 읽어들이기

일반적으로 GET 요청은 문서의 모든 것을 되돌려 _source 매개 변수에 저장합니다.하지만 관심 있는 필드는 title에 불과할 수도 있습니다.요청된 개별 필드에는 _source 매개 변수를 사용할 수 있습니다.여러 필드는 쉼표로 구분할 수 있습니다.

GET /website/blog/123?_source=title,text

_source 필드는 이제 요청한 필드만 포함하고 date 필드를 필터링합니다.

{
  "_index" :   "website",
  "_type" :    "blog",
  "_id" :      "123",
  "_version" : 1,
  "exists" :   true,
  "_source" : {
      "title": "My first blog entry" ,
      "text":  "Just trying this out..."
  }
}

또는 _source 필드를 원하고 다른 메타데이터를 원하지 않는다면 다음과 같이 요청할 수 있습니다.

GET /website/blog/123/_source

그것은 단지 되돌아갈 뿐이다.

{
   "title": "My first blog entry",
   "text":  "Just trying this out...",
   "date":  "2014/01/01"
}

문서가 있는지 확인

만약 당신이 하고 싶은 일이 문서가 존재하는지 확인하는 것뿐이라면, 내용에 전혀 관심이 없다. HEAD 방법으로 GET을 대체해라.HEAD 요청은 응답체로 돌아가지 않으며 HTTP 헤더만 표시됩니다.

curl -i -XHEAD http://localhost:9200/website/blog/123

Elasticsearch는 문서가 있는 경우 200 OK 상태로 돌아갑니다.

HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Content-Length: 0

404 Not Found이 없는 경우

curl -i -XHEAD http://localhost:9200/website/blog/124

HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=UTF-8
Content-Length: 0

물론, 이것은 당신이 조회하는 순간 문서가 존재하지 않는다는 것을 나타낼 뿐, 몇 밀리초 후에도 존재하지 않는다는 것을 의미하지는 않는다.다른 프로세스는 이 기간 동안 새 문서를 만들 수 있습니다.

전체 문서 업데이트

문서는 Elasticsearch에서 변할 수 없습니다. 우리는 그들을 수정할 수 없습니다.존재하는 문서를 업데이트하려면 색인 문서 섹션에서 설명한 index API를 사용하여 색인(reindex)을 재구성하거나 교체할 수 있습니다.

PUT /website/blog/123
{
  "title": "My first blog entry",
  "text":  "I am starting to get the hang of this...",
  "date":  "2014/01/02"
}

응답에서 우리는 Elasticsearch가 _version을 증가시켰다는 것을 볼 수 있다.
1

{
  "_index" :   "website",
  "_type" :    "blog",
  "_id" :      "123",
  "_version" : 2,
  "created":   false <1>
}

<1> created 표지는 false이다. 같은 인덱스, 같은 유형에 같은 ID의 문서가 존재하기 때문이다.
내부에서, Elasticsearch는 오래된 문서를 삭제하고 완전한 새 문서를 추가하기 위해 표시했습니다.이전 버전의 문서는 즉시 사라지지 않지만, 방문할 수도 없습니다.Elasticsearch는 더 많은 데이터를 인덱스할 때 삭제된 문서를 정리합니다.
이 장의 뒷부분에서 update API를 살펴보겠습니다.이 API는 문서의 일부를 수정할 수 있는 것처럼 보이지만 사실 Elasticsearch는 이전에 말한 것과 똑같은 과정을 따릅니다. 이 과정은 다음과 같습니다.
이전 문서에서 JSON 검색
수정 사항 이전 문서 삭제 인덱스 새 문서 유일한 차이점은 update API에서 이 프로세스를 완료하려면 하나의 클라이언트 요청만 있으면 되고 get 및 index 요청은 더 이상 필요하지 않다는 점입니다.
from: https://es.xiaoleilu.com/030_Data/05_Document.html