세상의 모든 Software 지식을 정리

앨리어스가 하나의 색인을 가리키고 있을 경우, 라우팅과 함께 사용한다면 쿼리 요청이나 색인 시점에 자동으로 라우팅 값을 적용시키는 효과를 얻을 수도 있다. 예) POST /_aliases {   "actions" : [     {       "add" : {         "index" : "get-together",         "alias" : "denver-events",         "filter" : {           "term" : {             "name" : "denver"           }         },         "routing" : "denver"       }     }   ] } * denver-events 앨리어스를 사용하여 모든 문서를 조회 POST /denver-events/_search?pretty {   "query" : {     "match_all" : {}   },   "fields" : [     "name"   ] }

search shards API를 통해 검색 요청이 어느 샤드에서 수행될지 확인할 수 있다. 예) GET get-together/_search_shards?pretty GET get-together/_search_shards?pretty&routing=denver 위와같이 routing값이 denver인 녀석만 조회할 경우 특정 샤드에서만 수행하게 된다 이처럼, 한 색이네 두개의 샤드가 존재하고, 라우팅 값으로 denver를 입력한 경우, 샤드 1에서만 검색은 수행되는 것을 알 수 있다. 즉, 검색이 수행되어야 할 대상이 되는 데이터를 절반으로 줄인것이라고 볼 수 있다. 라우팅은 샤드 수가 많은 색인을 다룰 떄 유용하다. 하지만 라우팅이 항상 필요한 것은 아니다. 떄로는 이를 통해 더 효과적으로 확장성을 활용할 수 있다고 생각할 수 있으며 언제나 테스트를 통해 검증해보아야 한다.

자식 문서가 부모 문서와 같은 샤드에 있는 것이, 다른 샤드에 있을 때 보다 검색 성능이 더 좋을 것이다. 라우팅이란 이처럼 문서를 특정 샤드에 위치시킬 수 있는 역할을 한다. 보통 색인시 문서의 ID값을 해싱하여 해당 문서를 샤드에 색인하게 된다. 하지만 라우팅 값을 이용하면 해당 routing값을 해싱하여 샤드에 색인하게 된다. 1. 왜 라우팅을 사용해야 하는가? 라우팅을 사용하지 않을 경우, 엘라스틱서치는 문서를 여러 샤드들에 균등하게 분포시킬 것이다. 그렇다면 왜 라우팅을 사용해야 할까? 그 이유는 커스텀 라우팅은 같은 라우팅 값을 공유하는 문서들을 한 샤드에 저장할 수 있도록 하기 때문이다. 이 문서들이 같은 색인에 존재할 경우, 쿼리에 라우팅 값을 지정하여 요청이 색인의 특정 샤드들에 대해서만 수행되도록 할 수 있다. 1-1. 라우팅 전략 라우팅은 두 가지 영역에서의 고민이 필요하다. 먼저 문서를 색인하는 시점에 좋은 적절한 라우팅 값을 선택해야 하고, 쿼리 시점에 이를 재활용 할 수 있어야 한다. 만약 적은 분포를 가지는 다른 값을 라우팅 값으로 선택하고자 했다면, 색인 내의 샤드 간에 불균등한 분포를 이루게 될수 있다. 만약 라우팅 값의 경우의 수가 세 가지뿐이라면, 모든 문서들은 최대 세개의 샤드에 걸쳐 분포하게 될 것이다. 색인 내의 여러 샤드에 걸쳐 데이터를 분포 시키기 위해서는 충분히 많은 카디널리티를 가지는 값을 라우팅 필드로 선택하는 것이 상당히 중요하다고 볼 수 있다. 예) POST get-together/group/10?routing=denver {   "name" : "Denver Ruby",   "description" : "The Denver Ruby Meetup" } POST get-together/group/11?routing...

Partial Index를 만들기 위해서는 db.collection.createIndex()메소드를 사용한 후, partialFilterExpression을 옵션으로 사용할 수 있다. equality expressions (i.e. field: value)또는 $eq $exists: true expression $gt, $gte, $lt, $lte expressions $type expressions $and operator at the top-level only 예) db.restaurants.createIndex(    { cuisine: 1, name: 1 },    { partialFilterExpression: { rating: { $gt: 5 } } } ) 다음 인덱스는 rating이 5보다 클 경우만 인덱스가 생성된다. db.restaurants.find( { cuisine: "Italian", rating: { $gte: 8 } } ) 위 쿼리는 8 이상인것만 조회를 시도하므로 생성된 인덱스를 사용할 것이다. 그러나 db.restaurants.find( { cuisine: "Italian", rating: { $lt: 8 } } ) 이 쿼리는 8미만인것을 조회하므로 인덱스 조건인 5보다 큰 경우에 위배되는 상황이 발생하므로 인덱스를 사용하지 않을것이다. db.restaurants.find( { cuisine: "Italian" } ) 그저 filter조건에만 해당하는 위 쿼리도 인덱스를 사용하지 못한다. 주의사항 :  _id필드는 partialIndex가 될 수 없다. Shard key indexes cannot be partial indexes.

기존 filtered의 쿼리 작동은  {   "query" : {     "filtered" : {       "filter" : {         "term" : {           "location" : "denver"         }       }     }   } } 위 쿼리 조회를 위한 또 다른 방식은  {   "post_filter" : {     "term" : {       "location" : "denver"     }   } } 성능 : Post Filter는 query수행 후 실행된다. 먼저 쿼리는 모든 도큐먼트에 대해 실행되고 일치된 녀석들이 Post Filter가 적용된다. 전체적인 request 선응은 filterd 쿼리보다 느릴것이다. Document set processed by aggregations : 만약 Post filter 가 적용되지 않으면 aggregations적용된 결과가 나타날 것이다.

In some cases, however, scoring can be more resource-intensive: Scoring with a script runs a script to calculate the score for each document in the index Doing a  phrase  query searches for words within a certain distance from each other, with a large slop To address this, elasticsearch use rescoring POST get-together/_search?pretty {   "query" : {     "match" : {       "title" : "elasticsearch"     }   },   "rescore" : {     "window_size" : 20,     "query" : {       "rescore_query" : {         "match" : {           "title" : {             "type" : "phrase",             "query" : "elasticsearch hadoop",             "slop" : 5           }         }     ...

1. 필드 매핑에서 유사도 파라미터 수정 { "mappings" : { "get-together" : { "properties" : { "title" : { "type" : "string", "similarity" : "BM25" //BM25로 변경 } } } } } 2. 필드 매핑에 추가 점수 방법을 사용하는 방법 <BM25 유사도 고급설정> curl -XPOST 'localhost:9200/myIndex' { "settings" : { "index" : { "analysis" : {...}, "similarity" : { "my_custom_similarity" : { "type" : "BM25", "k1" : 1.2, "b" : 0.75, "discount_overlaps" : false //k1, b 유사도 변수 설정 그리고 중복 토큰을 계산하지 않도록 설정 } } } }, "mappings" : { "mytype" : { "properties" : { "title" : { "type" : "text", "similarity" : ""my_custom_similarity ...

https://thinkwarelab.wordpress.com/2016/11/14/ir-tf-idf-%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B4%85%EC%8B%9C%EB%8B%A4/

여러 문자열들을 트라이에 집어넣는 대신 한 문자열의 S의 모든 접미사를 트라이에 집어넣는 것입니다. 이것을 접미사 트라이(suffix trie)라고 부릅니다. "BANANAS"로 만든 접미사 다음은  접미사 트라이를 보여줍니다.

1. Ngram Ngram은 토큰의 각 단어 부분을 다중 서브 토큰으로 분해하는 방식이다. Ngram과 Edge ngram둘다 min_gram과 max_gram설정이 필요하다. 이들 설정은 단어로부터 분해된 토큰의 크기를 제어한다. 예를들어, Ngram 분석길로 "spaghetti"단어를 분석한다고 가정해보자. 가장 단순한 1-grams(unigram)부터 시작하자. 1-1. 1-gram "spaghetti"의 1-gram은 s, p, a, g, h, e, t, t, i 가 된다. ngram의 크기에 따라 문자열을 작은 토큰으로 분해한다. 1-1. Bigram bigram(크기가 2인 문자열)로 분해한다면 sp, pa, ag, gh, he, et, tt, ti와 같은 작은 토큰을 얻을 것이다. 1-3. Trigram spa, pag, agh, ghe, het, ett, tti토큰을 얻을 것이다. 2. min_gram과 max_gram의 설정 이 분석기를 이용할 때 두 개의 서로 다른 크기를 설정해야 한다. 하나는 생성하려는 가장 작은 ngram(min_gram설정), 다른하나는 가장 긴 ngram을 지정한다. 앞의 예제 "spaghetti"에서 min_gram을 2,  max_gram을 3으로 설정하면 다음과 같다. sp, spa, pa, pag, ag, agh, gh, ghe, he, het, et, ett, tt, tti, ti 이 런 방식으로 텍스트를 분석 하는 것에 흥미를 끌 만한 점이 있는데, 텍스트를 쿼리할 떄 텍스트를 동일한 방식으로 분해할 텐데, 그래서 철자가 틀린 "spaghety"단어도 찾을수 있는 것이다. 이를 검색하는 한가지 방법은 일치를 확인하기 위해 단어의 편집거리를 지정하는 퍼지(fuzzy)쿼리를 실행하는 것이다. "spag...

생각해둔 분석기가 있어서 어떻게 텍스트를 다루는지 확인하고 싶다면, 분석기의 이름을 analyzer파라미터로 설정하면 된다. elasticsearch.yml 파일에 분석기를 설정한다면, analyzer파라미터에 있는 names로 이를 지정할 수 있다. POST get-together/_analyze?analyzer=myCustomAnalyzer 'share your experiance' 가끔은 내장 분석기만 사용하고 싶지 않을 떄도 있다. 그 대신 토크나이저와 토큰 필터의 조합으로 시도를 해보고 싶을 것이다. 예를들어, 공백으로 텍스트를 분해하기 위해 화이트스페이스 토크나이저와 그 후에 소문자화 및 역토큰 필터(reverse token filter)를 사용하고 싶다면 다음과 같이하면 된다. POST get-together/_analyze?tokenizer=whitespace?filters=lowercase, reverse 'share your experience * 텀 벡터 API를 사용하여 색인된 텀 실행하기 curl 'localhost:9200/get-together/_doc/1/_termvector?pretty=true'

엘라스틱 서치는 도큐먼트가 색인에 추가되기 전에 모든 분석된 필드를 위해 다음과 같은 단계를 거친다. 문자 필터링 - 문자 필터를 이용해서 문자들을 변환한다. 텍스트를 토큰으로 분해 - 텍스트를 한 개 이상의 토큰의 집합으로 분해한다. 토큰 필터링 - 토큰 필터를 사용해서 개별 토큰을 변환한다. 토큰 색인 - 토큰을 색인에 저장한다. 1.  문자 필터링 "share your experiance with NoSql & big data technologies" 여기서  & => and로 변환한다. "share your experiance with NoSql and big data technologies" 2. 토큰으로 분해하기 루씬 자체는 데이터의 큰 문자열에 작용하지 않는대신 토큰으로 알려져 있는 것에 작동한다. 예를들어, 영문에서 사용하는 일반적인 토크나이저는 표준 토크나이저인데, 공백과 개행같은 화이트스페이스 뿐만 아니라 대시(dash)같은 문자를 기반으로 텍스트를 토큰으로 분해한다. share, your, experiance, with, NoSql, and, big, data, technologies, 3. 토큰 필터링 4. 토큰 색인 * 색인 생성시 분석기 추가하기 색인을 위한 주 샤드와 레플리카 샤드 개수를 위한 settings는 다음과 같다. POST get-together { "settings" : { "number_of_shards" : 2, "number_of_replica" : 1 }, "mappings" : { .... } } 사용자 지정 분석키를 추가하는 것은 index키 아래에 있는 settings 설정에 별도의 맵으로 지정한다. 이...

세가지 케이스가 존재 1.   db.students.createIndex({student_id: 1, class_id: 1}) db.students.find({student_id:{$gt:500000}, class_id:54}) .sort({student_id:1}) .explain("executionStats") 위 인덱스를 태워 쿼리를 조회 할 떄와 db.students.createIndex({class_id:1, student_id:1}) 이 인덱스와 성능을 비교하면 참고로 class_id의 분류 갯수는 800 여개 아래 인덱스를 탈 때 더 좋은 성능을 보여준다. 즉, 먼저 필터역할을 하여 스캔해야할 document를 줄인다. 만약 db.students.find({student_id:{$gt:500000}, class_id:54}) .sort({final_grade:1}) .explain("executionStats") final_grade로 정렬할 필요가 있다면, 현재 인덱스로 쿼리를 타게되면 몽고디비 메모리 상에서 위 인덱스를 sort하게 되어 더 나쁜 현상을 보인다. 즉, db.students.createIndex({class_id:1, final_grade:1, student_id:1}) 이 인덱스로 해당 쿼리를 조회해주면 된다. 결과적으로 compoundedIndex는 Keys for equality filters should appear first. Keys used for sorting should appear before multi-value fields . Keys for multi-value filters should appear last. 다음과같이 디자인하는것이좋다.

How MongoDB Selects an Index Now let’s take a look at how MongoDB chooses an index to satisfy a query. Let’s imagine we have five indexes. When a query comes in, MongoDB looks at the query’s shape. The shape has to do with what fields are being searched on and additional information, such as whether or not there a sort. Based on that information, the system identifies a set of candidate indexes that it might be able to use in satisfying the query. Let’s assume we have a query come in, and three of our five indexes are identified as candidates for this query. MongoDB will then create three query plans, one each for these indexes. In three parallel threads, MongoDB will run the query such that each one will use a different index. The objective here is to see which one is able to return results the fastest. Visually, we can think of this as a race, something like in the graphic below. The idea here is that the first query plan to reach a goal state is the winner. But more important...

bool쿼리 * must (query1 AND query2 AND query3)가 반드시 일치해야함 * should (query1 OR query2 OR query3)가 반드시 일치해야함 * must_not 반드시 일치하지 않아야함 GET get-together/_search { "query" : { "bool" : { "must" : [ { "term" : { "attendees" :"david" } } ], "should" : [ { "term" : { "attendees" : "client" } }, { "term" : { "attendees" : "andy" } } ], "must_not" : [ { "range" : { "date" : { "lt" : "2013-06-30T00:00" } } } ], "minimum_should_match" : 1 } } }

1. MATCH_ALL 쿼리 모든 도큐먼트를 일치하게 된다. 쿼리 대신 필터 사용이 필요할 때, match_all쿼리가 상당히 유용하다 (점수에 관해 신경쓰지 않을 떄) 또는 검색하는 색인과 타입 사이에서 모든 도큐먼트를 반환하고 싶을 때 유용하다. 예) GET get-together/_search { "query" : { "match_all" : {} } } 검색에 쿼리 부분대신 필터를 사용하면 쿼리는 이와 같다. GET get-together/_search { "query" : { "match_all" : {} }, "filter" : { .... } } 2. QUERY_STRING 쿼리 다른 대체제로 하는 것을 추천 3. 텀 쿼리와 텀 필터 텀 쿼리와 필터는 실행 가능한 가장 단순한 쿼리인데, 필드와 텀을 지정해서 도큐먼트 내에서 검색할 수 있다. 검색한 텀이 분석되지 않았기 때문에 완전히 일치하는 도큐먼트 결과만 찾는다는 것을 알아두자. 예) GET get-together/_search { "query" : { "term" : { "tags" : "elasticsearch" } }, "_source" : ["name", "tags"] } 결과값 { "hits" : [ { "_id" : "3", "_index" : "get-together", "_score"...

* filtered query는 5.0버전부터 deprecated 되었습니다. 일반적으로 query는 일치하는 도큐먼트와 얼마나 근접한지 점수를 반환한다. 반면에 filter는 단순히 도큐먼트가 일치하는지 예, 아니오만 판단한다. 다음과 같다.               텀 필터 :             tags=lucene    도큐먼트는 tags=lucene를 가지는가? 1 . Yes : 캐시 일치 - >도큐먼트 반환. 2. No : 캐시 불일치 -> 도큐먼트 제외          텀 쿼리:       tags=lucene    도큐먼트는 tags=lucene를 가지는가? 1. Yes : 점수 계산 -> 도큐먼트 반환 2. No : 다음 도큐먼트로 이동하므로 신경쓰지말자. filtered : query + filter 필터드 쿼리는 쿼리와 필터 둘다 포함한다. 예는 다음과 같다. GET get-together/_search { "query" : { "filtered" : { "query" : { "match" : { "title" : "hadoop" } }, "filter" : { "term" : { "host" : "andy" } } } } } GET get-together/_search { "query" : { "bool" : { "must" : { "match" : { "title" : "hadoop" } }, "...

엘라스틱 서치는 일치한 도큐먼트를 _score값의 내림차순으로 정렬해서 가장 적합성이 높은 도큐먼트 순서로 반환한다. 오름차순 또는 내림차순으로 필드를 정렬하려면 필드를 나열한 배열 대신 다음처럼 맵을 가진 배열을 지정한다. GET get-together/_search { "query" : { "match_all" : {} }, "sort" : [ {"created_on" : "asc"}, {"name" : "desc"}, "_score" ] }

검색 요청의 일부분을 차지하는 또 다른 요소는 엘라스틱 서치로 하여금 일치하는 개별 도큐먼트에서 반환할 필드 목록을 어떻게 지정하는가인데, 검색요청에 _source 구성 요소에서 이를 지정하면 된다. 요청에 _source를 지정하지 않는다면, 엘라스틱서치는 기본적으로 도큐먼트의 _source 전체를 반환하거나 저장된 _source가 없다면 일치하는 _id, _type, _index, _score와 같은 도큐먼트에 관한 메타데이터만 반환한다. 일치하는 각 그룹의 name과 date필드를 반환하는 쿼리는 다음과 같다. GET get-together/_search { "query" : { "match_all" : {} }, "_source" : ["name", "date"] } _SOURCE로 반환한 필드에서 와일드 카드 필드목록을 각각 지정해서 반환하는 것 외에도 와일드 카드를 사용할 수 있다. 예를들어, "name" , "nation"필드 둘다 반환하려면 "_source" : "na*"를 지정한다. _source["name.*", "address.*"] 와 같이 와일드 카드 문자열을 배열처럼 사용해서 다수개 와일드 카드를 지정할 수 있다. 어떤 필드를 포함할지 지정할 수 있을 뿐만아니라 반환하지 않을 필드도 제외시킬 수 있다. 예) GET get-together/_search { "query" : { "match_all" : {} }, "_source" : { "include" :["location.*", "date"], "exclude...

_source는 모든 것을 저장하고, _all은 모든것을 색인한다. _all로 검색할 때, 엘라스틱 서치는 어떤 필드가 일치하는지와 무관하게 검색결과를 반환한다. 이는 사용자가 보려는 것이 어디에 있는지 몰라도 그저 무언가를 찾을 때 유용하다. 항상 특정 필드만 검색하려면 _all의 enable옵션으로 false를 설정해서 비활성화 할 수 있다. 이렇게 하면 색인 전체 크기가 줄어들고 더 빠르게 색인을 만든다.. 기본적으로 _all은 include_in_all옵션 값으로 true를 가진 개별 필드를 암묵적으로 포함한다.  include_in_all옵션을 사용해서 _all은 무엇이 포함되고 무엇이 그렇지 않을지 제어할 수도 있다.

_source는 원본 도큐먼트를 저장할지 또는 그렇지 않을지를 true 또는 false로 지정할 수 있다. 기본값은 true인데 대부분의 경우 그대로 사용하는 것이 좋다. 왜냐하면 변경 API를 이용한다던지 하이라이트 (Highlighting)구현 역시 _source가필요하다 원본 도큐먼트의 특정 필드만 반환하기 GET get-together/_doc/1?pretty?fields=name fields파라미터로 제공할 수 있다. _source를 저장할 떄, 엘라스틱 서치는 여기에서 필수 필드를 가져온다. Store옵션을 yes로 설정한 개별필드만 저장할 수 있다. 예를들어 name필드만 저장하려면 매핑은 다음과 같다. _source전제를 조회해서 특정 필드를 추출하는 것보다 단일 저장 필드를 조회하는 것이 더 빠르므로, 특히 큰 도큐먼트를 갖고 있을 때, 엘라스틱서치에게 특정 필드만 요청하는 것이 더 유용할 수 있다. * _source의 기능을 false할 시 문제점 update, update_by_query그리고 reindex API를 사용할 수 없다. highlighting 기능을 사용할 수 없음 reindex및 mapping, analysis 바꾸기 불가, major버전으로 인덱스 업그레이드 불가 쿼리 또는 aggregation의 디버그 불가 만약 디스크 공간이 문제라면 _source를 false하기 보다는 compression level을 고려해보자

일반적으로, 사전 정의된 필드는 사용자가 정의하지 않고 일래스틱 서치가 제공한다. 도큐멘트를 색인할 때 날짜를 기록하는 _timestamp 필드를 사용할 수 있다. 사전 정의된 필드는 필드에 따라 특수 기능을 갖고 있다. 예를들어, ttl필드는 일래스틱서치에 의해 특정 시간 이후에 도큐멘트를 자동 삭제하는 기능을 갖고 있다. 사전 정의된 필드 이름은 모두 언더스코어(_)로 시작한다. 이들 필드가 도큐먼트에 새 메타데이터를 추가하면, 원본 도큐먼트에 새 메타데이터를 추가하면, 원본 도큐먼트를 저장하는 것에서부터 자동 만료를 위해 타임스탬프를 저장하는 것에 이르기 까지 일래스틱서치는 이 메타데이터를 다양한 기능에 사용한다. 도큐먼트를 어떻게 저장하고 검색하는지에 관한 제어 : _source는 색인할 때 원래의 Json도큐먼트를 저장하도록한다. _all은 모든 필드를 색인한다. 도큐먼트의 아이덴티티(Identity) : 도큐먼트가 색인된 곳에 관한 데이터가 포함된 _uid, _id, _type, _index가 있다. 도큐먼트에 새 속성 추가 : _size로 원본 JSON크기 값을 색인 할 수 있다. 같은 방법으로 _timestamp를 이용해서 색인 시점의 시간값을 별도로 색인 할 수 있으며, _ttl을 이용해서 특정 시간 이후에 자동으로 삭제되도록 할수 있따.

첫번쨰는 tags필드에 ["first", "second"]가 들어간 경우이고 두번째는 tags필드에 "third four"가 들어가있다. 이때, default조건에 의해 둘다 analyzed되어 있지만, 다른 조건인 not_analyzed를 걸고 싶다면 다음과 같이한다. { "properties" : { "tags" : { "type" : "text", "index" : "analyzed", "fields" : { "verbatim" : { "type" : "text", "index" : "not_analyzed" } } } } } 그저 아무 문자열을 실행하면 태그필드의 analyzed버전에서 검색한다. 그러나 원래의 태그에서 정확하게 일치하는 것을 가져오기 위해 not_analyzed버전에서 검색하려면 tags.verbatim이라는 전체 경로를 지정해서 검색한다.

다음과 같이 new-events 타입을 인덱스한다고 해보자 PUT get-together/_mapping/new-events {   "properties" : {     "name" : {       "type" : "text",        "index" : "analyzed"      }    } } index의 기본값은 analyzed인데, 만약 해당 필드에 있는 값이 "Last night with ElasticSearch"라고 하면 analyzed인 경우는 해당 문장을 단일 텀으로 변경하여 색인 한다. 즉, "last" , "night", "with", "elastisearch"이다. 만약 not_analyzed인 경우는 단일 텀으로 만들지 않고, 전체 문자열을 단일 텀으로 색인한다. 태그 검색 처럼 정확히 일치하는 경우 사용한다. 예를 들어, "big data"인 경우는 "big data"자체가 색인된다. 만약 index 가 no인 경우는 색인을 생략하고 어떠한 텀도 만들지 않아서 특정 필드의 검색이 불가능 할 것이다. 검색할 필요가 없는 경우는 이 옵션을 사용하면 공간의 절약과 색인 및 검색에 필요한 시간도 절약할 수 있을 것이다. 예를들어, 이벤트의 리뷰를 저장한다고 하자. 비록 이 리뷰를 저장하고 보여주는 것이 가치가 있어도 검색할 필요까지는 없을 것이다. 이 경우 그 필드의 색인을 비활성화 함으로써 색인 과정을 더 빠르게 만들고 저장 공간도 절약할 것이다.

1. 하이퍼 스레딩 사용중지 2. autoscaling사용 3. C-상태 / P- 상태제어 4. Timekeeping작업 <네트워크 관점> <OS적관점> 1. RHEL6 vs RHEL ebizzy로 성능비교시 34배 향상됨 최신 OS를 사용하라

* Edge Location (cache 역할) * Amazon CloudFront 엣지에 캐쉬된 컨텐츠로 빠른전달 * 주위로 부하 이동하기 기존에는 로그를 웹서버에 저장하는 방식 -> 정적, 동적 콘텐츠 Amazon S3로 이전 * 자주사용되는 세션/상태정보는 ElasticCache와 Dynamo DB에 저장 <오토 스케일링> 사용영역이 50만 이상일 떄는 ,가용영역1과 2를 묶어서 하는 것을 추천

Largest Sum of Averages 동적 계획법으로 첫번째 인덱스는,  i 번째 부터 시작하는 수 두번 째 인덱스는, K 번 그룹을 지칭 즉, d[i][k]는 K번째 그룹일 때, i번째 부터 시작하는 수. d[i][k] = max(d[i][k], search(i, k-1) + curr/ (n-i)); --> n-i는 끝에서 부터 i 번째 까지 --> curr 은 i번째 부터 n번째 까지의 합(그때가 K번째 그룹)

* Query vs Filter 1. Query는 스코어 값에 영향을 미치고, Filter는 스코어 값에 영향을 미치지 않는다. 2. Query는 캐싱되지 않고, Filter는 캐싱되므로 Filter가 성능면에서 유리하다. 한마디로, 스코어 값이 필요할 경우는 Query를 이용하고, 스코어 값이 필요하지 않은 경우에는 Filter를 이용하면 된다. 간단히 정리하자면 Filter : RDBMS를 이용할 때 사용했던 WHERE절 구문은 ElasticSearch의 Filter에 해당한다. 일반적으로 ElasticSearch를 처음 이용할 때 , 내가 원하는 결과를 추려내기 위해서 Query문을 이용하는 경우가 많다. 하지만 RDBMS의 where절 조건은 filter에 해당한다. 왜냐하면 , 전체결과에서 원하는 결과를 추려내는 작업이라는 점에서 개념이 동일하고, 성능 면에서도 유리하며, 예상치 못한결과를 얻게되는 일이 없기 때문이다. * Query 엘라스틱 서치에서 말하는 Query는 일반적인 SQL query의 개념과 다소 차이가 있다. 검색이라는 것은 단ㄴ순히 '이러한 조건을 만족하는 레코드를 찾아라' 라는 개념을 넘어서  ' 가장 적합하고 유사성(스코어)이 높은  결과를 찾아라 '라는 개념이 포함되어 있다. 이미 tokenizing, analyzing과정을 거쳐서 인덱싱 되어있는 데이터로 부터 검색 문자열에 해당하는 가장 유사성 높은 결과를 반환 하는 것은 기존 SQL 문으로는 한계가 있었던 점이고, 이를 해결하기 위한 것이 바로 루씬 검색엔진을 기반으로 한 것이다.