不爲也 比不能也

Elasticsearch is a different kind of beast, especially if you come from the world of SQL. It comes with many benefits: performance, scale, near real-time search, and analytics across massive amounts of data. And it is easy to get going! Just download and start using it.그 동안 SQL을 다뤄왔다면, Elasticsearch는 그것과 전혀 다르다. 방대한 양의 데이터에 대한 성능, 확장, 실시간에 가까운 검색과 분석 등 많은 이점이 있다. 그리고 시작하기가 쉽다. 단순히 내려 받고, 그것을 사용하..

In the real world, relationships matter: blog posts have comments, bank accounts have transactions, customers have bank accounts, orders have order lines, and directories have files and subdirectories.현실 세계에서, 관계는 중요하다. 블로그 포스트는 댓글을 가지고 있고, 은행 계좌는 거래 내역을 가지고 있고, 고객은 은행 계좌를 가지고 있고, 명령은 명령 체계를 가지고 있고, 디렉토리는 파일과 하위 디렉토리를 가지고 있다.Relational databases are specifically designed—and this will not come a..

We can (partly) emulate a relational database by implementing joins in our application. For instance, let’s say we are indexing users and their blog posts. In the relational world, we would do something like this:응용프로그램에서 join을 구현하여, 관계형 데이터베이스를 (부분적으로) 따라 할 수 있다. 사용자와 그들의 블로그 포스트를 색인해 보자. 관계의 세계에서는, 다음과 같이 할 것이다.PUT /my_index/user/1 { "name": "John Smith", "email": "john@smith.com", "dob": "197..

The way to get the best search performance out of Elasticsearch is to use it as it is intended, by denormalizing your data at index time. Having redundant copies of data in each document that requires access to it removes the need for joins. Elasticsearch로부터 가장 좋은 검색 성능을 얻을 수 있는 방법은, 색인 시에 데이터를 비정규화 하여, 데이터를 의도했던 그대로 사용하는 것이다. 데이터에 액세스하기 위해 필요한 각 document에, 데이터의 중복 복사본을 가지는 것은, join의 필요성을 제거하는 것..

A common requirement is the need to present search results grouped by a particular field. We might want to return the most relevant blog posts grouped by the user’s name. Grouping by name implies the need for a terms aggregation. To be able to group on the user’s whole name, the name field should be available in its original not_analyzed form, as explained in Aggregations and Analysis: 특정 field로..

Of course, data denormalization has downsides too. The first disadvantage is that the index will be bigger because the _source document for every blog post is bigger, and there are more indexed fields. This usually isn’t a huge problem. The data written to disk is highly compressed, and disk space is cheap. Elasticsearch can happily cope with the extra data.물론, 데이터 비정규화도 단점이 있다. 첫 번째 단점은 모든 블로그 ..

The problem comes when we want to allow more than one person to rename files or directories at the same time. Imagine that you rename the /clinton directory, which contains hundreds of thousands of files. Meanwhile, another user renames the single file /clinton/projects/elasticsearch/README.txt. That user’s change, although it started after yours, will probably finish more quickly.한 명 이상이, 동시에, ..

Given the fact that creating, deleting, and updating a single document in Elasticsearch is atomic, it makes sense to store closely related entities within the same document. For instance, we could store an order and all of its order lines in one document, or we could store a blog post and all of its comments together, by passing an array of comments: Elasticsearch에서 단일 document를 생성, 수정, 삭제하는 것은 ..

Setting up a nested field is simple—where you would normally specify type object, make it type nested instead: nested field를 설정하는 것은 간단하다. 일반적으로 object type을 지정하는 곳에, type을 nested 로 대신 지정하면 된다.PUT /my_index { "mappings": { "blogpost": { "properties": { "comments": { "type": "nested", "properties": { "name": { "type": "string" }, "comment": { "type": "string" }, "age": { "type": "short" }, "stars..

Because nested objects are indexed as separate hidden documents, we can’t query them directly.Instead, we have to use the nested query to access them: nested object는 숨겨진 개별 document로 색인되기 때문에, 그들을 직접 query할 수 없다. 대신에, 그들을 nested query를 사용하여 액세스해야 한다.GET /my_index/blogpost/_search { "query": { "bool": { "must": [ { "match": { "title": "eggs" } }, { "nested": { "path": "comments", "query": { "bool..