디텍티브 슬라임 2장: 슈거플래닛의 첫 만남

 

디텍티브 슬라임

제2장: 슈거플래닛의 첫 만남

사탕 마을로의 여정

디텍티브 슬라임, 로임, 호야는 신비한 포탈을 통해 슈거플래닛에 도착한 후, 그 주변을 둘러보기 시작했습니다. 온 세상이 달콤한 사탕과 캔디로 가득 차 있었고, 향긋한 냄새가 그들의 코끝을 자극했습니다.

"저기 마을이 보여!" 호야가 손가락으로 멀리 보이는 작은 마을을 가리키며 외쳤습니다.

그들은 천천히 마을로 이동했습니다. 마을의 집들은 사탕 지팡이와 젤리빈으로 지어져 있었고, 길은 초콜릿 타일로 포장되어 있었습니다. 마을 사람들은 모두 다양한 사탕과 과자로 이루어져 있었는데, 그들은 일행을 보고 반갑게 인사했습니다.

마시멜로와의 만남

마을 중앙 광장에 도착하자, 커다란 마시멜로 모양의 인물이 그들을 반겼습니다. "안녕하세요! 저는 마시멜로에요. 이곳은 슈거플래닛의 사탕 마을입니다. 당신들은 누구신가요?"

디텍티브 슬라임이 앞서 나와 인사했습니다. "안녕하세요, 우리는 디텍티브 슬라임과 그의 친구들, 로임과 호야입니다. 우리는 이상한 포탈을 통해 이곳에 오게 되었어요."

마시멜로는 친절하게 웃으며 말했다. "이곳에 오신 것을 환영합니다! 이곳은 매우 신비한 곳이지만, 가끔 예상치 못한 일이 일어나곤 하죠. 혹시 도움이 필요하신가요?"

로임이 고개를 끄덕이며 말했다. "네, 저희가 이곳에 왜 오게 되었는지 잘 모르겠어요. 혹시 도움을 줄 수 있는 분이 있을까요?"

마시멜로는 잠시 생각하다가 말했다. "저 언덕 너머에 큰 성이 있어요. 성에 사는 마법사가 여러분을 도와줄 수 있을 거예요. 그는 이 행성에 대해 많은 지식을 가지고 있답니다."

성으로의 여정

디텍티브 슬라임 일행은 마시멜로의 안내를 따라 큰 언덕을 향해 걸어갔습니다. 언덕을 오르는 길은 가파르고 힘들었지만, 그들은 포기하지 않고 계속해서 걸어갔습니다.

드디어 언덕 꼭대기에 다다르자, 거대한 성이 눈앞에 나타났습니다. 성은 거대한 캔디 지팡이와 초콜릿 벽돌로 지어져 있었고, 곳곳에 달콤한 향기가 풍겨 나왔습니다.

그 순간, 큰 목소리가 성에서 울려 퍼졌습니다. "거기 누구냐~!"

디텍티브 슬라임과 그의 친구들은 깜짝 놀라며 주위를 둘러보았습니다. 성의 문이 천천히 열리기 시작했고, 그들은 긴장 속에서 다음 상황을 기다렸습니다.

디텍티브 슬라임 1장 신비한 포탈

 

디텍티브 슬라임

제1장: 신비한 포탈

평화로운 날

디텍티브 슬라임과 그의 친구들, 계란이 들어간 슬라임 로임, 그리고 호랑이 귀와 꼬리를 가진 주황색 머리카락의 호야는 평화로운 날을 보내고 있었습니다. 그들은 작은 마을의 숲 속에 있는 아늑한 집에서 함께 살고 있었습니다. 디텍티브 슬라임은 사건이 없을 때는 주로 책을 읽거나 친구들과 함께 시간을 보내며 지냈습니다.

이상한 소리

어느 날 오후, 그들은 집 근처에서 놀고 있었습니다. 로임은 큰 나무 그늘 아래에서 휴식을 취하고 있었고, 호야는 나무 위에 올라가 햇빛을 즐기고 있었습니다. 디텍티브 슬라임은 새로운 탐정 소설을 읽고 있었습니다. 그러던 중, 갑자기 옆 창고에서 이상한 소리가 들려왔습니다.

"윙윙윙~" 하는 소리가 점점 커져갔습니다.

"이게 무슨 소리지?" 디텍티브 슬라임이 책에서 눈을 떼고 물었습니다.

호야는 나무에서 뛰어내려와 창고 쪽으로 걸어갔습니다. "뭔가 이상해 보여. 한 번 가보자."

로임도 호기심을 참지 못하고 따라갔습니다. 그들은 조심스럽게 창고 문을 열어보았습니다.

포탈

창고 안에는 커다란 포탈이 반짝이고 있었습니다. 파란색과 보라색 빛이 소용돌이치며 아름답게 빛나고 있었습니다.

"이거 정말 신기하네," 로임이 말했습니다. "하지만 어떻게 생긴 거지?"

디텍티브 슬라임은 신중하게 포탈을 살펴보았습니다. "모르겠어. 하지만 한 가지는 확실해. 이 포탈은 우리를 어디론가 데려가려는 것 같아."

그 순간, 포탈이 갑자기 강력한 힘으로 그들을 빨아들이기 시작했습니다. "조심해!" 호야가 소리쳤지만 이미 늦었습니다. 디텍티브 슬라임과 그의 친구들은 포탈 속으로 빨려들어갔습니다.

슈거플래닛

그들은 눈을 뜨고 주변을 둘러보았습니다. 그들이 도착한 곳은 눈부시게 아름다운 행성이었습니다. 모든 것이 설탕으로 만들어진 것처럼 보였습니다. 나무는 캔디로 이루어져 있었고, 강은 달콤한 시럽으로 흘러가고 있었습니다.

"여긴 대체 어디지?" 로임이 놀란 표정으로 물었습니다.

디텍티브 슬라임은 주변을 살펴보며 말했다. "이곳은 아마도 슈거플래닛이라는 행성일 거야. 모험이 시작된 것 같군."

호야는 웃으며 말했다. "그럼 이제 탐정 모드로 전환해야겠네! 우린 이곳에서 무슨 일이 일어나고 있는지 조사해야 해."

Elasticsearch search type

분산된 검색(distributed search)를 실행할 때 여러가지 실행 방법이 있을 수 있다.

분산된 검색 operation은 모든 relevant한 shard들로 흩어지고 다시 그 결과들을 모아오는 것이 필요하다. 

특히, 검색엔진에서는 뿌리고(scatter)/모으는(gather) 실행에 있어 여러가지 방법이 있다. 

분산 검색을 실행할 때 문제는 각 shard들에서 어느 정도의 result들을 받아 올 것인가라는 문제가 있다. 예를 들어 우리에게 10개의 shard가 있다고 가정했을 때, 첫번째 shard에 가장 relevant한 0부터 10까지의 결과가 있고, 나머지 shard들에 그 이하 ranking의 0부터 10까지의 문서들이 있다고 하자. 

이런 이유로 request를 실행할 때 정확한 결과를 얻고자 한다면, 전체 shard에서 각 0부터 10까지의 결과를 가져와서 sorting하고 그 결과를 리턴한다. 

또 검색엔진과 관련된 문제로 term frequency들을 구하는 문제에서 하나의 shard는 다른 shard들의 결과를 고려하지 못한다. 정확한 ranking을 위해서 우리는 global term frequency를 구하기 위해 먼저 전체 shard의 term frequency들을 다 모아야하고, 그 global frequency를 사용해서 각 shard에서 query를 수행해야한다. 

큰 document set에 대해 result들을 sort하거나 scrolling할 필요가 있기 때문에 올바른 sorting을 실행하는데 들어가는 비용이 상당하다.  큰 result set에 대해서 sorting 없이 scrolling하기위해서는 scan search type을 사용하면 된다. 

Elasticsearch에서는 개별 search 단위로 search_type 파라메터를 지원하여 유연한 검색 type을 사용할 수 있도록 해준다. 

Query Then Fetch 

parameter value: query_then_fetch

request가 두가지 단계로 실행된다. 첫번째로, query들이 과련된 모든 shard로 보내진다. 

각 shard들은 search(검색)을 진행하고 sorting된 결과 리스트를 생성한다. 

각 shard들은 적당한 정도의 정보(just enough information)을 coordinating node로 전달하여 shard level의 result들을 merge하고 resort하여 maximum length size만큼의 global한 sorting된 result들을 만들게 한다. 

이게 search_type이 정해지지 않은 request의 default setting이다. 

Dfs, Query Then Fetch

Parameter value : dfs_query_then_fetch

"Query Then Fetch"와 동일한데, initial scatter 단계에서 더 나은 정확도를 위해 distributed term frequency를 계산하는 것만 다르다. 

Count 

Parameter value : count

특별한 search type으로 document를 제외하고 search request에 matche된 count만 return한다. (total_hits로 표현됨)

그리고 facets 결과도 같이 포함 될 수 있다. 보통 count API가 더 많은 옵션을 가지기 때문에 더 좋다. 

Scan

Parameter value:scan

scan search type은 ordering을 하지 않도록 하여 large result sets을 사용할 때에 더 효과적으로 scrolling할 수 있도록 한다. 

추가적인 내용을 위해서는 Efficient scrolling with Scroll-Scan문서를 확인하면 된다. 

Query And Fetch

Parameter value : query_and_fetch

qeury and fetch mode는 ES내(internal)의 optimization으로 query_then_fetch request가 하나의 shard로만 targeting되는 경우에 저동으로 선택된다. 

query_then_fetch가 single pass로 실행된다. 이 mode는 사용자에 의해서 지정되지않아야 한다. 

Dfs, Query And Fetch

Parameter value : dfs_query_and_fetch

initial scatter 단계에서 distributed  term frequency를 더 적확하게 scoring하는 것을 제외하고는 query_and_fetch와 동일하다. 이 모드는 사용자에 의해서 지정되지 않아야한다. 

Nodejs memory limit configuration

While I trying to change memory configuration of node application, I found some documents related..

https://nodejs.org/api/v8.html
The document says "The V8 options available for a version of node.js".
We can find list of options from below link.
https://github.com/thlorenz/v8-flags/blob/master/flags-0.11.md

By change old_space_size option

1 2 3 4 5 6 7 8

node --max-old-space-size=1024 my-node-script.js #increase to 1gb node --max-old-space-size=2048 my-node-script.js #increase to 2gb node --max-old-space-size=3072 my-node-script.js #increase to 3gb node --max-old-space-size=4096 my-node-script.js #increase to 4gb node --max-old-space-size=5120 my-node-script.js #increase to 5gb node --max-old-space-size=6144 my-node-script.js #increase to 6gb node --max-old-space-size=7168 my-node-script.js #increase to 7gb node --max-old-space-size=8192 my-node-script.js #increase to 8gb

elasticsearch on docker

먼저 docker가 필요하므로 아직 설치되어있지 않다면 docker부터 설치하자.

docker install : http://docs.docker.com/mac/started/

docker가 설치되었다면 docker hub로 부터 우리가 원하는 image를 다운로드 받아야한다. 

docker image : https://hub.docker.com/_/elasticsearch/