1-03-03. Indexing a Document

Documents are indexed—stored and made searchable—by using the index API. But first, we need to decide where the document lives. As we just discussed, a document’s _index, _type, and _iduniquely identify the document. We can either provide our own _id value or let the index API generate one for us.

document는 index API에 의해 색인된 (저장되고 검색 가능하도록 만들어진)다. 그러나 먼저, document를 어디에 저장할지를 결정해야 한다. 방금 이야기했듯이, document의 _index, _type, _id 는 document를 유일하게 식별한다. 사용자가 자신의 _id 값을 제공하거나, index API가 생성하도록 할 수 있다.

Using Our Own IDedit

If your document has a natural identifier (for example, a user_account field or some other value that identifies the document), you should provide your own _id, using this form of the index API:

document가 고유의 식별자(예: user_account field나 document를 식별할 수 있는 어떤 다른 값)를 가지고 있다면, 아래 형태의 index API로, 자기 자신만의 _id 를 제공할 수 있다.

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

For example, if our index is called website, our type is called blog, and we choose the ID 123, then the index request looks like this:

예를 들자면, website 라는 index에, blog 라는 type에, 123 이라는 ID라면, index request는 아래와 같다.

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

COPY AS CURLVIEW IN SENSE 

Elasticsearch responds as follows:

Elasticsearch의 response는 아래와 같다.

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

The response indicates that the document has been successfully created and includes the _index, _type, and _id metadata, and a new element: _version.

response는 document가 성공적으로 생성되었다는 것을 보여주고, _index, _type, _id metadata와 새로운 요소 _version 을 포함한다.

Every document in Elasticsearch has a version number. Every time a change is made to a document (including deleting it), the _version number is incremented. In Dealing with Conflicts, we discuss how to use the _version number to ensure that one part of your application doesn’t overwrite changes made by another part.

Elasticsearch에 있는 모든 document는 버전을 가지고 있다. document에 변화(삭제시에도)가 있을 때 마다, _version 은 증가한다. Dealing with Conflicts에서, 응용프로그램의 어떤 부분이, 다른 부분에 의해 만들어진 변화를 덮어쓰지 않는다는 것을 보장하기 위해, _version 을 사용하는 방법에 대해 이야기할 것이다.

Autogenerating IDsedit

If our data doesn’t have a natural ID, we can let Elasticsearch autogenerate one for us. The structure of the request changes: instead of using the PUT verb ("store this document at this URL"), we use the POST verb ("store this document under this URL").

데이터에 고유의 ID가 없다면, Elasticsearch가 자동으로 식별자를 생성하도록 할 수 있다. request 구조에 변화가 있다. PUT ("해당 URL에 이 document를 저장해라")이 아닌, POST ("해당 URL 아래 에 이 document를 저장해라")를 사용한다.

The URL now contains just the _index and the _type:

이제 URL은 _index 와 _type 만을 가지고 있다.

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

COPY AS CURLVIEW IN SENSE 

The response is similar to what we saw before, except that the _id field has been generated for us:

response는 _id field가 생성되었다는 점을 제외하면, 좀 전에 보았던 것과 유사하다.

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

Autogenerated IDs are 20 character long, URL-safe, Base64-encoded GUID strings. These GUIDs are generated from a modified FlakeID scheme which allows multiple nodes to be generating unique IDs in parallel with essentially zero chance of collision.

자동으로 생성되는 ID는 20자리 character로, URL-safe하고, Base64로 encoding된 GUID 문자열이다. 이들 GUID 문자열은, 기본적으로 충돌의 위험이 없는, 다수의 node에서 동시에 유일한 ID를 생성할 수 있는, 변형된 FlakeID scheme에서 생성된다.