'검색'에 해당되는 글 41건

  1. 2019.08.28 [Elasticsearch] Node Topology 7.x
  2. 2019.01.15 [Elasticsearch] 문서 모델링 펼치기
  3. 2018.10.05 [검색일반] stop token filter 와 char filter
  4. 2018.10.04 [Elasticsearch] _analyze 예제 - 특수문자 제거
  5. 2018.06.28 [Elasticsearch] HighLevelRestClient 를 이용한 Bulk Indexing 로컬 테스트 결과
  6. 2018.06.27 [Elasticsearch] Move TransportClient to High Level REST Client
  7. 2018.06.27 [Elasticsearch] 6.3 설치 변경 내용
  8. 2018.04.06 [Elasticsearch] Split Index 기능 맛보기
  9. 2018.04.06 [Elasticsearch] Elasticsearch Case Study 1) Data 노드에 Index/Shard 구성 시작 해보기
  10. 2017.12.27 [링크] 검색 Trend

[Elasticsearch] Node Topology 7.x

Elastic/Elasticsearch 2019. 8. 28. 10:54

사용성에서 정확한 정의가 없어서 많이들 헷갈려 하셨던 Node 가 정리가 된 것 같아 기록해 봅니다.

 

원문 링크)

https://www.elastic.co/guide/en/elasticsearch/reference/7.3/modules-node.html

 

Master Eligible Node

- node.master

마스터 노드는 전용으로 구성 하는 것을 추천 하며, 최소한의 작업을 수행 하도록 하는 것이 좋습니다.

 

Data Node

- node.data

CPU-, Memory-, I/O 성능 영향을 많이 받기 때문에 좋은 장비로 구성 하시길 추천 드립니다.

또한 Network 사용량에 대한 고려도 해야 합니다.

 

Ingest Node

- node.ingest

 

Machine Learning Node (x-pack)

- node.ml

 

Coordinating Node

node.master: false

node.data: false

node.ingest: false

node.ml: false

이 노드의 수를 너무 많이 늘리지 않도록 주의 하는게 좋습니다.

이유는 마스터 노드가 선출 되었을 때 모든 노드의 승인을 기다리게 되어 오히려 성능적으로 손해를 볼 수도 있습니다.

 

Voting Only Node (x-pack)

- node.voting_only

:

[Elasticsearch] 문서 모델링 펼치기

Elastic/Elasticsearch 2019. 1. 15. 19:13

상품 모델링을 하다 보니 부득이 flat 하게 펼쳐야 하는 이슈가 생겼습니다.

field 수만 수천개 ㅡ.ㅡ;

사실 C사에 있을 때 봤던 field 수가 1만개 이상 되었던 걸로 기억 하는데 어쩔 수 없이 저도 다르지만 비슷한 구조를 만들게 되었내요.


[원문]

https://www.elastic.co/guide/en/elasticsearch/reference/master/mapping.html#mapping-limit-settings


Elasticsearch 에서 기본 제약 사항은 아래와 같습니다.


index.mapping.total_fields.limit

The maximum number of fields in an index. Field and object mappings, as well as field aliases count towards this limit. The default value is 1000.


index.mapping.depth.limit

The maximum depth for a field, which is measured as the number of inner objects. For instance, if all fields are defined at the root object level, then the depth is 1. If there is one object mapping, then the depth is 2, etc. The default is 20.


index.mapping.nested_fields.limit

The maximum number of nested fields in an index, defaults to 50. Indexing 1 document with 100 nested fields actually indexes 101 documents as each nested document is indexed as a separate hidden document.


index.mapping.nested_objects.limit

The maximum number of nested json objects within a single document across all nested fields, defaults to 10000. Indexing one document with an array of 100 objects within a nested field, will actually create 101 documents, as each nested object will be indexed as a separate hidden document.


혹시라도 문서 모델링 하시다가 field limit 에 대한 정보가 궁금 할 것 같아 일단 북마킹 합니다.

모델링을 flat 하게 펼치게 된 이유는 시간에 대한 다양한 요구사항이 발생을 하다 보니 부득이 이와 같이 펼치게 되었습니다.

:

[검색일반] stop token filter 와 char filter

ITWeb/검색일반 2018. 10. 5. 14:43

가끔 착각하게 되는 내용이라 기술해 봅니다.


우리가 흔히 이야기 하는 불용어라고 하는 것은 추출된 색인어에 대해서 색인어 처리를 하지 않도록 하는 것입니다.

이것이 stopwords 라고 부르는 것이고 stop token filter 하고 합니다.


analyze 과정에서 char filter 이후 tokenizer 단계에서 사용되는 filter 기능이 되는 것입니다.

다시 말해 색인어 추출 후 적용하는 filter 기능이라고 보시면 됩니다.


그럼 char filter 는 언제 동작 하게 될까요?

이 filter 기능은 색인어 추출 전 그러니까 tokenizer 로 text 가 전달 되기 전에 text 내 불필요한 문자들을 제거 하기 위해 사용을 합니다.

이것이 char filter 가 되겠습니다.


그냥 저 혼자 복습 차원에서 기술해 봤습니다.


https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-stop-tokenfilter.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-charfilters.html


:

[Elasticsearch] _analyze 예제 - 특수문자 제거

Elastic/Elasticsearch 2018. 10. 4. 08:02

색인 시점에 text 에 포함된 특수 문자를 제거 하기 위한 예시 입니다.


[실행]

curl -X POST \

  http://localhost:9200/_analyze \

  -H 'cache-control: no-cache' \

  -H 'content-type: application/json' \

  -d '{

  "tokenizer": "arirang_tokenizer",

  "filter":[

              "lowercase",

              "trim",

              "arirang_filter"

            ],

  "char_filter" : [{

          "type": "pattern_replace",

          "pattern": "\\p{Punct}|\\d",

          "replacement": " "

        }],

  "text": "애플(&<>,./^!@+=;:%)파이"

}'



[결과]

{

    "tokens": [

        {

            "token": "애플",

            "start_offset": 0,

            "end_offset": 2,

            "type": "korean",

            "position": 0

        },

        {

            "token": "파이",

            "start_offset": 18,

            "end_offset": 20,

            "type": "korean",

            "position": 1

        }

    ]

}


:

[Elasticsearch] HighLevelRestClient 를 이용한 Bulk Indexing 로컬 테스트 결과

Elastic/Elasticsearch 2018. 6. 28. 11:35


arirang plug 을 적용해서 돌려본 실행 속도 입니다.


[DEBUG] 2018-07-02 13:12:18.407 [main] MainIndexer - Bulk operation elapsed time [811.0869750976562] sec

[DEBUG] 2018-07-02 13:14:16.595 [main] MainIndexer - Force merge operation elapsed time [118.18800354003906] sec


[Settings]

"settings":{
"number_of_shards":1,
"number_of_replicas":0,
"index.refresh_interval":"1h",
"index.routing.allocation.require.box_type":"indexing",
"index.similarity.default.type":"BM25",
"index":{
"analysis":{
"analyzer":{
"arirang_custom_analyzer":{
"tokenizer":"arirang_tokenizer",
"filter":[
"lowercase",
"trim",
"custom_synonym",
"arirang_filter"
]
}
},
"filter":{
"custom_synonym":{
"type":"synonym_graph",
"synonyms":[]
}
}
}
}
}


[Mappings]

"mappings" : {
"_doc": {
"_source": {
"enabled": true
},
"dynamic_templates": [
{
"strings": {
"match_mapping_type": "string",
"mapping": {
"type": "text",
"analyzer": "arirang_custom_analyzer",
"fields": {
"raw": {
"type": "keyword",
"ignore_above": 50
}
}
}
}
}
]
}
}





얼마전 밋업에서 김종민님이 공유해 주신 위키피디아 문서를 가지고 테스트한 결과 입니다.

그냥 제가 만든 Indexer 모듈에 대한 성능 테스트용도로 한번 실험 삼아 돌려 본거라 별 도움이 안될 수 있습니다.


아래 문서는 언제까지 올라가 있을지 모르겠습니다.

빨리 받으시면 될 듯 하내요.


문서 다운로드 링크)

https://s3.ap-northeast-2.amazonaws.com/kr.elastic.co/sample-data/kr-wikipedia-dump.json.tar.gz


위키피디아 문서 색인 테스트 결과)

MacBook Pro

CPU 2.8G i7

MEM 16GB

API : HighLevelRestClient

REST API : _bulk

Settings

primary shard : 1

replica shard : 0

refresh_interval : 1h

similarity : BM25

default analyzer (standard)

Mappings

dynamic mapping

Indexing File Source Size 

3.6GB

Indexing Segment File Size (force merge 전)

11 GB

Indexing Segment File Size (force merge 후)

4.28 GB

Bulk Request Thread Size

5

Bulk Request Document Size (per thread)

500

Bulk Indexing / Force Merge Time

[DEBUG] 2018-06-28 11:06:13.780 [main] MainIndexer - Bulk operation elapsed time [366.6780090332031] sec

[DEBUG] 2018-06-28 11:08:22.254 [main] MainIndexer - Force merge operation elapsed time [128.47300720214844] sec

Indexing Documents

Total indexed document are 1020662


결과적으로 튜닝한 내용은 전혀 없고 그냥 색인기 기능 테스트 정도로 보셔도 될 것 같습니다.


:

[Elasticsearch] Move TransportClient to High Level REST Client

Elastic/Elasticsearch 2018. 6. 27. 11:46

이번에 새로 Indexer 모듈을 만들다 보니 아래 문서의 내용을 확인하게 되었습니다.


Reference)

https://www.elastic.co/guide/en/elasticsearch/client/java-api/current/client.html

https://github.com/elastic/elasticsearch/tree/master/client/rest/src/test/java/org/elasticsearch/client


원문발췌)

We plan on deprecating the TransportClient in Elasticsearch 7.0 and removing it completely in 8.0. Instead, you should be using the Java High Level REST Client, which executes HTTP requests rather than serialized Java requests. The migration guidedescribes all the steps needed to migrate.

The Java High Level REST Client currently has support for the more commonly used APIs, but there are a lot more that still need to be added. You can help us prioritise by telling us which missing APIs you need for your application by adding a comment to this issue: Java high-level REST client completeness.

Any missing APIs can always be implemented today by using the low level Java REST Client with JSON request and response bodies.


사실 저도 TransportClient 를 사용하면 version 때문에 고민을 하긴했었는데요.

이 참에 그냥 REST Client 로 넘어 가야 겠다고 생각해서 새로 작성 하였습니다.


기본적인 예제 코드는 아래 내용 참고 하시면 됩니다.


public static void main(String[] args) {
requestRestClient();
}

public static void requestRestClient() {
int numNodes = 5; //randomIntBetween(1, 5);
HttpHost[] hosts = new HttpHost[numNodes];
for (int i = 0; i < numNodes; i++) {
hosts[i] = new HttpHost("localhost", 9200);
}
RestClientBuilder builder = RestClient.builder(hosts);
RestClient restClient = builder.build();

builder.setMaxRetryTimeoutMillis(10000);

builder.setFailureListener(new RestClient.FailureListener() {
@Override
public void onFailure(HttpHost host) {
System.out.println("onFailure");
}
});

builder.setRequestConfigCallback(new RestClientBuilder.RequestConfigCallback() {
@Override
public RequestConfig.Builder customizeRequestConfig(
RequestConfig.Builder requestConfigBuilder) {
return requestConfigBuilder.setSocketTimeout(10000);
}
});

Map<String, String> params = new HashMap<>();
params.put("preference", "_shards:0,1,2,3");

HttpAsyncResponseConsumerFactory.HeapBufferedResponseConsumerFactory consumerFactory =
new HttpAsyncResponseConsumerFactory.HeapBufferedResponseConsumerFactory(
30 * 1024 * 1024);
try {
Response response = restClient
.performRequest("GET", "/hello/_search", params, null, consumerFactory);

System.out.println(response.toString());

// Read Case 1
RequestLine requestLine = response.getRequestLine();
HttpHost host = response.getHost();
int statusCode = response.getStatusLine().getStatusCode();
Header[] headers = response.getHeaders();
String responseBody = EntityUtils.toString(response.getEntity());

System.out.println(requestLine);
System.out.println(host);
System.out.println(statusCode);
System.out.println(headers);
System.out.println(responseBody);

// Read Case 2 - old fashion
BufferedReader reader = new BufferedReader(new InputStreamReader(
response.getEntity().getContent()));

String inputLine;
StringBuffer buffer = new StringBuffer();

while ((inputLine = reader.readLine()) != null) {
buffer.append(inputLine);
}

reader.close();

// System.out.println(buffer.toString());
} catch (IOException e) {
e.printStackTrace();
}

try {
restClient.close();
} catch (IOException e) {
e.printStackTrace();
}
}

public static int randomIntBetween(int min, int max) {
return RandomNumbers.randomIntBetween(random(), min, max);
}

public static Random random() {
return RandomizedContext.current().getRandom();
}




:

[Elasticsearch] 6.3 설치 변경 내용

Elastic/Elasticsearch 2018. 6. 27. 07:54

Elasticsearch 6.3 이 릴리즈 되면서 가장 큰 변화는 Elastic 용과 OSS 용 이렇게 두개로 설치 패키지가 나뉜것입니다.

즉, Elastic 사의 license 를 기반으로 동작하는 x-pack 들을 사용하기 위해서는 Elastic 버전을 설치 하셔야 한다는 이야기 입니다.


Basic  라이센스의 경우 free 이기 때문에 OSS 버전을 설치 하고 사용할 수 있겠다 생각 하시면 안되는 걸 경험 하실 수 있습니다. (제가 그랬습니다 ^^;)


전에는 x-pack 을 elasticsearch-plugin 으로 설치가 가능 했지만 6.3 에서는 지원을 하고 있지 않습니다.

또한 x-pack 을 쓰기 위해서는 default system index 생성이 필요 한데 아래 설정이 되어 있으면 오류가 발생을 하게 됩니다.


action.auto_create_index: false


이 설정은 잘 아시겠지만 index 가 없을 때 자동으로 생성을 하게 해주는 설정인데요.

저는 보안이랑 관리적인 부분에서 disable 하고 사용했었는데 basic 버전을 사용하기 위해서 이 설정을 과감히 포기 했습니다.


몇 가지 removed 된 설정들이 있는데요.

5.x 올라 오면서 변경된 내용과 일부 비슷한 것들이 있어서 링크 겁니다.


[Elasticsearch] 2.4.x to 5.2.x 으로의 elasticsearch.yml

그리고 Elastic 에서 제공하는 Breaking Changes 를 보시는 것도 도움이 됩니다.



정리하면)

1. x-pack 버전과 oss 버전이 있으니 용도와 목적에 맞게 설치 하시면 됩니다.

- basic license 를 사용하기 위해서는 x-pack  버전을 사용하셔야 합니다.


2. x-pack 버전 사용 시 action.auto_create_index: true 로 설정 하셔야 합니다.

- default system index 를 생성 해야 하기 때문입니다.


:

[Elasticsearch] Split Index 기능 맛보기

Elastic/ElasticsearchReferences 2018. 4. 6. 14:24

Split index 기능에 대해서 공식 문서에 나와 있는 내용을 그대로 테스트 해봤습니다.

(Shrink 와 Split 은 모두 Resize Action 에 해당 합니다.)


Reference)

https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-split-index.html


이 split index API 는 기존에 존재하는 또는 생성된 index 의 primary shard 를 신규 index 로 기존 primary shard 크기 보다 크게 split 해서 생성해 주는 역할을 합니다.


RESTful endpoint 는 _split 입니다.


근데 7.0 에서는 삭제 된다고 하니 제가 이걸 왜 쓰고 있는지 모르겠습니다.

하지만 늘 그렇듯이 Elasticsearch 에서는 기능이 없어지게 되면 대체 가능한 기능을 추가로 제공해 줍니다. :)


이 API 사용시 제일 중요한 부분은 IMPORTANT 에 잘 나와 있습니다.


The _split API requires the source index to be created with a specific number_of_routing_shards in order to be split in the future. This requirement has been removed in Elasticsearch 7.0.


※ Source index 를 생성 할때 설정을 해줘야 한다는 이야기 입니다.


그럼 문서에 나와 있는 데로 한번 돌려 보겠습니다.

하지 전에, elasticsearch 하나 띄워 놓으시고 kibana 도 띄워 놓으세요. 그래야 편하게 dev tool 이용해서 request 할 수 있겠죠.


Step 1) Preparing an index for splitting

Source index 를 생성 하는 과정이며 이 과정에서 반드시 routing shard 정보를 설정 하셔야 합니다.


PUT my_source_index

{

    "settings": {

        "index.number_of_shards" : 1,

        "index.number_of_replicas" : 0,

        "index.number_of_routing_shards" : 2

    }

}


Step 2) Set read-only mode

Split 하기 전에 반드시 읽기 전용으로 반드시 설정을 하셔야 합니다. 안하시면 에러 납니다.

그럼 왜 해야 할까요?

보통 DB 마이그레이션 작업 하실때 생각을 해보시면 됩니다. :)


PUT /my_source_index/_settings

{

  "settings": {

    "index.blocks.write": true 

  }

}


문서를 자세히 보기 전까지 저 설정이 block 단위로 write 할 수 있도록 해주는 설정인 줄 알았습니다. ^^;


Step 3) Splitting an idex

이제 primary shard 를 2 개로 늘려 보겠습니다.


POST my_source_index/_split/my_target_index

{

  "settings": {

    "index.number_of_shards": 2,

    "index.number_of_replicas" : 0

  }

}


이 단계 작업을 하면서 주의 할 점은 당연한 내용이지만, 

1. target index 가 없어야 겠죠.

2. source index 의 primary shard 보다 커야 겠죠.

3. factor 조건을 만족 해야 합니다.


routingNumShards % numTargetShards != 0 이면 안되구요.


if (sourceNumberOfShards < targetNumberOfShards) { // split

factor = targetNumberOfShards / sourceNumberOfShards;

if (factor * sourceNumberOfShards != targetNumberOfShards || factor <= 1) { 이면 안되구요. }

}


즉,

- 나눠서 나머지가 없어야 합니다.

- target shard 는 routing shard 보다 작거나 같아야 합니다.


아래는 factor 조건을 만족하지 않는 예시 입니다.


PUT my_source_index

{

    "settings": {

        "index.number_of_shards" : 1,

        "index.number_of_replicas" : 0,

        "index.number_of_routing_shards" : 4

    }

}


PUT /my_source_index/_settings

{

  "settings": {

    "index.blocks.write": true 

  }

}


POST my_source_index/_split/my_target_index

{

  "settings": {

    "index.number_of_shards": 3,

    "index.number_of_replicas" : 0

  }

}


조건 1) 

4 % 3 => 1 // 0 이 되어야 합니다.


조건 2) 

assert getRoutingFactor(3, 4) >= 0


if ( 3 < 4 ) {

    factor = 4 / 3; // factor = 1

    if ( factor * 3 != 4 || factor <= 1) {

        throw new IllegalArgumentException(.....);

    }

}



혹시라도 사용하셔야 하는 분들이 계시다면 참고 하시면 되겠습니다.

:

[Elasticsearch] Elasticsearch Case Study 1) Data 노드에 Index/Shard 구성 시작 해보기

Elastic/Elasticsearch 2018. 4. 6. 10:13

Elasticsearch Case Study 1) Data 노드에 Index/Shard 구성 시작 해보기

- Data Node 3개, Active Index 1개

- Data Node Spec)

CPU : 16 cores

- 지속적인 Read/Write operaiton 이 발생 하는 경우로 가정 하겠습니다.


Primary/Replica Shard Sizing)

- Shard 구성을 하실 때 가장 쉽게 접근 할 수 있는 방법은 CPU 코어 크기를 가지고 판단 하시면 됩니다.

- Data 노드 하나당 active shard 로 배치 할 수 있는 가장 기본은 코어 크기와 똑같이 구성 하시는 것입니다.


위에 16 코어로 가정했기 때문에 Data 노드에는 16개의 Shard 를 할당 할 수 있습니다.


Elasticsearch Settings 정보)

curl -XPUT http://localhost:9200/case-study-1/_settings '{

    "settings" : {

        "index" : {

            "number_of_shards" : 15,

            "number_of_replicas" : 2

        }

    }

}'


이와 같이 Index 를 생성 하게 되면 아래와 같이 shard 가 배치 됩니다.


Data node 1 : 

Primary Shards : 0, 1, 2, 3, 4

Replica Shards : 5, 6, 7, 8, 9, 10, 11, 12, 13, 14

Data node 2 :

Primary Shards : 5, 6, 7, 8, 9

Replica Shards : 0, 1, 2, 3, 4, 10, 11, 12, 13, 14

Data node 3 :

Primary Shards : 10, 11, 12, 13, 14

Replica Shards : 5, 6, 7, 8, 9, 0, 1, 2, 3, 4


보시게 되면 모든 Data 노드에 Shard 가 15개씩 할당 되어 있는 것을 확인 하실 수 있습니다.

여기까지 확인 하셨으면 이제 부터가 시작 입니다.


Data 노드에 Index, Shard에 대한 기본 설정은 했지만 이게 최적화 된 것인지는 알수 없습니다.

그래서 사용환경에 맞춰서 성능 테스트를 해 보셔야 합니다.


아래 질문에 답변을 해보세요.


1. 내가 사용하고자 하는 클러스터는 질의 및 분석에 최적화 되어야 한다.

2. 내가 사용하고자 하는 클러스터는 색인에 최적화 되어야 한다.

3. 내가 사용하고자 하는 클러스터는 질의, 분석 그리고 색인 모두 최적화 되어야 한다.


1번을 원하신다면 아래 항목들에 대해서 검토를 해보시면 좋습니다.

질의 와 분석은 CPU 와 Memory 를 많이 사용하기 때문에 충분한 자원이 준비 되어 있어야 합니다.

그리고 Document 에 대한 mapping 정보 최적화가 필요 합니다.

1. Match query 종류를 사용해야 하는가? (주로 Full text query를 의미 합니다.)

- Elastic 사에서는 Full text queries 라고 합니다.

2. Term query 종류를 사용해야 하는가? (주로 Exact match query를 의미 합니다.)

- Elastic 사에서는 Term level queries 라고 합니다.

3. Aggregation 질의가 많은가?

4. Nested 유형의 Aggregation 질의가 많은가?


2번을 원하신다면 아래 항목들에 대해서 검토를 해보시면 좋습니다.

색인 작업은 CPU 와 Disk I/O 성능에 영향을 많이 받습니다.

또한 사용하는 형태소 분석기에 따른 성능 변화도 확인을 하셔야 합니다.


사실 색인에 최적화 라는건 Bulk Indexing 이 아니고서는 다른 주제 인것 같습니다.

로그 데이터의 경우 보통은 Data 노드의 처리량을 고려해서 앞단에 Queue 를 사용하고,

여기서 Beats 나 Logstash 와 같은 Shipper 를 이용해서 Elasticsearch 로 색인하도록 구성을 합니다.

결과적으로 Queue + Beats/Logstash + Elasticsearch 에 대한 최적화 작업 없이는 어려운 작업 입니다.


Elasticsearch 관점에서 바라보면:Bulk Indexing)

1. Dynamic mapping 사용을 피하는게 좋습니다.

2. 불필요한 Analyzed 과정을 제거 하는게 좋습니다.

3. Bulk 요청 시 Replica 와 Refresh 를 사용하지 않는게 좋습니다.

4. _all Field 사용을 피하는게 좋습니다.

5. _id 는 가능 하면 임의 설정을 하지 않는게 좋습니다.

6. Index Buffer Size 를 512MB 정도까지 크게 설정 하는게 좋습니다.

7. 기타 등등 사소한 튜닝 팁들이 많습니다.


3번을 원하신다면 아래 항목들에 대해서 검토를 해보시면 좋습니다.

가장 어려운 요구사항 입니다.

이런 경우 클러스터의 노드와 인덱스 구성을 분리해서 사용하시는게 좋습니다.

1. Cross Cluster Search(Tribe Node) 에 대해서 검토해 봅니다.

2. Hot-Warm Architecture 에 대해서 검토해 봅니다.

3. Index Alias 기능에 대해서 검토해 봅니다.

4. Shrink, Split, Reindex, Rollover, Rollup 기능에 대해서 검토해 봅니다.

5. Snapshot 과 Restore 기능에 대해서 검토해 봅니다.


이번 Case Study 는 아주 단순 합니다.

요구사항은 알수 없고 단순히 Data 노드 규모와 스펙만으로 Index/Shard 배치를 설정 하는 것이였습니다.

"왜 이렇게/저렇게 해야 하지?" 라는 궁금증이 드시는 부분은 이해를 돕기 위해 추가적인 설명이 들어가야 하는데 과감히 생략 했습니다. (커뮤니티에 질문 주시거나 저를 만나시면 물어보세요. 친절히 설명해 드리겠습니다.)


항상 반복 되는 이야기지만,

사용 환경에 맞게 테스트 하시고 최적화 하는게 정답입니다.

시작 하기 전에 조금이나마 도움이 될 수 있는 내용을 작성한 것이지 이대로 하면 된다는 것은 아닙니다.

알아야 할 것도 많고 검증 해야 할 것도 많습니다.

시간과 인력이 부족 하시다면 Elastic 사에서 지원하는 좋은 프로그램들이 있으니 참고 하셔도 좋을 것 같습니다.


궁금 하신 것들이 있으시면 Facebook 유저 커뮤니티에 질문으로 올려 주세요.

제가 할 수 있다면 도움 드릴 수 있도록 하겠습니다.

:

[링크] 검색 Trend

ITWeb/스크랩 2017. 12. 27. 09:58

검색 Trend 를 알아보기 위한 대표 링크.


[네이버]

https://datalab.naver.com/


[구글]

https://trends.google.co.kr/trends/explore

: