'분류 전체보기'에 해당되는 글 82건

ElasticSearch를 도입하기전, ElasticSearch에대해 공부하기 위해 레퍼런스를 읽으면서 번역&정리한 글입니다.

문서 전체를 번역한 것이 아니라 개인적으로 정리가 필요하다 싶은 내용만 정리하였습니다.

본문: ElasticSearch 공식레퍼런스

Mapping은 document와 document의 field가 어떻게 저장되고 인덱싱되는지를 정하는 것이다.

Field Datatypes:

- Simple types like text, keyword, date, long, double, boolean, ip

- JSON형식을 띄는 object, nested

- 특수한 경우에 사용되는 geo_point, geo_shape, completion

잘모르는 타입들 정리:

Keyword datatype:

- 주로 이메일주소, 우편번호 등 형식을 갖춘 데이터들을 저장하기 위해 사용된다.

- 주로 필터링, 정렬, 종합을 위해 사용된다.

- 정확한 값으로면 검색이 가능하다

Text datatype:

- text로 지정된 field는 anlayzer를 통해 변환된다.(한글은 anlayzer-nori 플러그인을 별도로 깔아야됨)

- 변환된 후에는 ES가 하나의 단어를 전체 내용중에서 찾을 수 있게 해준다.

Nested datatype:

- nested타입은 object타입의 특수한 형태로써 쉽게 말하자면 object의 list라고 생각하면된다.

- 그리고 ES는 inner object라는 형식을 지원하지 않기때문에 이 list를 flatten하여 처리한다.

PUT my_index/_doc/1
{
  "group" : "fans",
  "user" : [ 
    {
      "first" : "John",
      "last" :  "Smith"
    },
    {
      "first" : "Alice",
      "last" :  "White"
    }
  ]
}

위의 코드블럭이 처리될때는 아래로 변환되어 처리된다.

{
  "group" :        "fans",
  "user.first" : [ "alice", "john" ],
  "user.last" :  [ "smith", "white" ]
}

ElasticSearch를 도입하기전, ElasticSearch에대해 공부하기 위해 레퍼런스를 읽으면서 번역&정리한 글입니다.

문서 전체를 번역한 것이 아니라 개인적으로 정리가 필요하다 싶은 내용만 정리하였습니다.

본문: ElasticSearch 공식레퍼런스

PUT /...customer/_doc/1
{
  "name": "John Doe",
  "characteristics": "he is tall, fat and wearing blue jacket"
}

위의 예시에서

PUT /<index>/<mapping type>/<id>

순이다.

그래서 실제로 쿼리를 보내보면:

{
  "_index" : "...customer",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 1,
  "result" : "created",
  "_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
  },
  "_seq_no" : 0,
  "_primary_term" : 1
}

 이렇게 _type에 _doc이 뜨는 것을 볼 수 있다.

mapping type이 7.x버전부터는 없어졌다고 하는데 무엇인지 알아둘겸 읽어보았다.

---여기서부터 원문---

처음 ElasticSeach(이하 ES)가 출시했을때부터, 각각의 document는 하나의 index와 하나의 mapping type으로 저장되었다. Mapping Type은 document의 타입을 나타내는데 사용되었는데, 예를 들자면 twitter라는 index는 user 타입과 tweet 타입을 가질 수 있다.

각각의 mapping type은 고유의 field를 가지고 있다. 그래서 user 타입은 full_name, user_name 필드를 가지고 있고, tweet 타입은 content, tweeted_at 필드를 가질 수 있다.

document는 _type 메타 필드를 가지고 있었기 때문에 타입으로 필터링하여 검색을 할 수 있었다.

GET twitter/user,tweet/_search
{
  "query": {
    "match": {
      "user_name": "kimchy"
    }
  }
}

_type필드는 document의 _id와 합쳐져 _uid필드를 만들어낸다. 따라서 다른 타입에 속하는 document들은 같은 _id를 가질 수 있다.

그렇다면 왜 mapping type을 없애는 걸까?

처음에 ES에서 소개할때 index는 SQL database의 데이터베이스와 유사하고, type은 테이블과 유사하다고 하였다.

하지만 이것은 유저들이 잘못된 방향으로 사용하도록 유도하였다. 

ES의 index에서는 같은 이름을 가졌지만 서로 다른 type에 속하는 field들이 있을때, 2 field는 같은 Lucene field에 속하게 된다. 따라서 A라는 type에 속하는 ABC라는 field과 B라는 type에 속하는 ABC라는 field는 같은 lucene field세 속하고, 따라서 같은 mapping을 가져야한다.

대체방안

1. document의 종류별로 각기 다른 index를 만든다. index들은 상호간에 독립적이기 때문에 위에서 언급한 문제가 없다.

2. Custom type field를 사용한다. 이를 적용하면:

PUT twitter/user/kimchy
{
  "name": "Shay Banon",
  "user_name": "kimchy",
  "email": "shay@kimchy.com"
}

PUT twitter/tweet/1
{
  "user_name": "kimchy",
  "tweeted_at": "2017-10-24T09:00:00Z",
  "content": "Types are going away"
}

가 이렇게 바뀐다:

PUT twitter/_doc/user-kimchy
{
  "type": "user", 
  "name": "Shay Banon",
  "user_name": "kimchy",
  "email": "shay@kimchy.com"
}

PUT twitter/_doc/tweet-1
{
  "type": "tweet", 
  "user_name": "kimchy",
  "tweeted_at": "2017-10-24T09:00:00Z",
  "content": "Types are going away"
}

매핑도 이를 반영하기위에 좀 바뀌는데

원래는:

PUT twitter
{
  "mappings": {
    "user": {
      "properties": {
        "name": { "type": "text" },
        "user_name": { "type": "keyword" },
        "email": { "type": "keyword" }
      }
    },
    "tweet": {
      "properties": {
        "content": { "type": "text" },
        "user_name": { "type": "keyword" },
        "tweeted_at": { "type": "date" }
      }
    }
  }
}

이후에는:

PUT twitter
{
  "mappings": {
    "_doc": {
      "properties": {
        "type": { "type": "keyword" }, 
        "name": { "type": "text" },
        "user_name": { "type": "keyword" },
        "email": { "type": "keyword" },
        "content": { "type": "text" },
        "tweeted_at": { "type": "date" }
      }
    }
  }
}

ElasticSearch를 도입하기전, ElasticSearch에대해 공부하기 위해 레퍼런스를 읽으면서 번역&정리한 글입니다.

문서 전체를 번역한 것이 아니라 개인적으로 정리가 필요하다 싶은 내용만 정리하였습니다.

본문: ElasticSearch 공식레퍼런스

ElasticSearch(이하 ES)는 항상 접근 가능하고 필요에 따라 확장이 가능하도록 설계되었다. 서버(node)를 클러스터에 추가하기만 하면 ES가 자동으로 데이터와 쿼리 로드를 사용가능한 노드들로 분산하여 준다.

Shard는 Primary와 Replica 두가지 종류가 있다. Index에 포함된 각각의 document는 1개의 primary shard에 포함된다. replica shard는 primary shard의 복제이다. Replica는 하드웨어 문제에 대응할 수 있도록 해주고 searching이나 document를 불러오는 작업을 처리하는 capacity를 늘려준다.

ElasticSearch를 도입하기전, ElasticSearch에대해 공부하기 위해 레퍼런스를 읽으면서 번역&정리한 글입니다.

문서 전체를 번역한 것이 아니라 개인적으로 정리가 필요하다 싶은 내용만 정리하였습니다.

본문: ElasticSearch 공식레퍼런스

ElasticSearch(이하 ES)는 클러스터 매니징, 인덱싱, 데이터 검색을 위한 사용이 간단한 REST API를 제공한다. 그리고 테스트 목적으로 Command Line이나 Kibana의 개발자 콘솔에서 직접 request를 보낼 수도 있다.

ES의 REST API는 구조화된 쿼리, 텍스트 쿼리, 두개가 혼합된 쿼리를 지원한다. 만약 gender와 age field를 employee index에서 검색하고 hire_date에 따라 정렬한다면 Full-text 쿼리는 query string과 매치되는 모든 document를 찾고, 연관도에 따라 정렬한다.

ElasticSearch를 도입하기전, ElasticSearch에대해 공부하기 위해 레퍼런스를 읽으면서 번역&정리한 글입니다.

문서 전체를 번역한 것이 아니라 개인적으로 정리가 필요하다 싶은 내용만 정리하였습니다.

본문: ElasticSearch 공식레퍼런스

ElasticSearch(이하 ES)는 데이터를 분산 저장한다. 그리고 테이블에 행과 열의 방식으로 데이터를 저장하는 것이 아니라 JSON으로 직렬화하여 저장한다. 만약 클러스터가 여러개의 ES 노드로 구성되어 있다면 저장된 document들은 클러스터에 분산 저장되어 어떤 노드에서든 접근이 가능하다.

Document가 저장되면 index가 되어 1초안에 거의 실시간으로 검색이 가능하다. ES는 Inverted Index라는 자료구조를 사용하여 매우 빠른 Full-Text-Search(이하 FTS)가 가능하다. Inverted Index는 document안에 존재하는 모든 유니크한 단어들을 정리하여 그 단어가 포함된  document들을 찾아낸다.

Index는 최적화된 document들의 모음이라고 할수있다. 그리고 각각의 document들은 key-value로 구성된 데이터들을 저장하는 field들로 구성된다. ES는 기본적으로 모든 field들을 인덱싱(앞의 index와는 조금 다름)하며 각각의 인덱싱된 field들은 최적화된 자료구조를 가지고 있다. 텍스트로 구성될 field들은 inverted indices 자료구조로 저장되고, 숫자와 위치정보 field들은 BKD 트리 구조로 저장된다. 이렇게 각각의 필드에 맞춤 자료구조를 사용하는 것이 ES가 매우 빠른 이유이다.

가끔은 하나의 field를 여러가지 방법으로 인덱싱하는 것이 유용할때가 있다. 예를 들면 문자열 field를 Full-Text-Search를 위하여 text field로 인덱싱하고, 데이터 정렬과 수집을 위해서 keyword field로도 인덱싱할 수 있다. 아니면 하나 이상의 language analyzer를 사용하여 인덱싱할 수도 있다.

1. 와디즈의 셀링포인트를 정리해보자
-성장하는 회사
-이야기에 귀 기울인다
-올바른 회사도 성장할 수 있다

---------------------------------------------
2. 적합한 채용 프로세스를 설계해보자
프로세스 A: 
- 채용배경, 와디즈에서 어떤역할을 해주길 바라는지 자세히 명시(실제 일을 하고 있는 사람들의 사례를 곁들임)
- 왜 와디즈를 선택했는지
프로세스 B:
- 채용위원회 ( 평가를 구조화 + 객관적으로 지원자를 보기위해서 )
             - 실무진들이 면접을 하지만 실제 결정권은 없다
                    - 급한 실무진들이 이정도면 괜찮지않을까해서 뽑는 경우를 막기위함
             - 면접관 가이드라인

채용 전형 안내엽서 + Thank you card + 굿즈
면접 만족도 조사

---------------------------------------------
3. 온보딩
- 웰컴메일:  조직장이 작성
- 오프라인 미팅
- 입사자 맞이를 준비하기 위해 입사 1주일 전 부서에 알림 메일
- 웰컴 팩 (가이드북, 텀블러, 굿즈 등등)
- 필수/주요 이벤트 구글캘린더 작성 후 공유
- 입사로부터 1개월후 : 체크인 교육 (법률 및 윤리/비용정산 가이드/와디즈 브랜드)
- 입사로부터 2개월후 : 자기 평가, 다면 평가, 팀장 평가, 최종 의사결정, 평가 면담

---------------------------------------------
Q&A:
채용 리소스를 줄이는 방법: 
- 수동적 > 능동적으로 채용
- LinkedIn, 잡코리아 등 직접 찾아본다
- 인터뷰할 때 정말 솔직하게 얘기한다

스타트업 환경에 맞는 효율적인 팀 구성방법:
- 이거는 내가 할 일이 아닌데 왜 나에게 시키냐가 되면 안됨(스타트업X)
- 조직원들이 되는데까지 커버하다가 전문성이 필요해지면 전문가를 채용
- 스타트업의 반대는 공장(해야될일만 하면 운영이됨)
- 자신이 능동적으로 목표지향적으로 나서서하려고 하는 사람을 뽑자
      - 스타트업은 대기업과 달리 자신이 여러가지일을 할 수 있는 여지가 있다. 이 기회를 잡고자 하는 사람을 뽑자!

협업툴로 잘 이전하는 방법:
- 협업툴과 개인용메신저의 차이점은 데이터를 정보화(Archiving)할 수 있다는 점

자율성을 부여함
- 노마드 데이: 자신이 원하는 장소에서 일할 수 있는날(월1회)
- 점심시간도 상관없음: 자신의 TASK를 다 한다면 시간, 장소 크게 중요하지 않다

중간관리자에게 책임감 부여
- 문제가 생겼다면 어떻게해서 왜 생겼고 앞으로 재발한다면 어떻게 대응하겠다라는 책임

본문: https://www.postgresql.org/docs/10/textsearch-intro.html

[ 이 글은 본문의 전체를 번역한 글은 아닙니다. 본인이 중요하다고 생각되는 부분만 정리하였습니다 ]

Introduction

Textual search operator들은 예전부터 데이터베이스에 있었다. PostgreSQL은 ~, ~*,LIKE, ILIKE같은 operator들을 사용할 수 있었는데 이들은 현대의 정보 시스템에서 필수적인 여러 요소들이 고려되어있지 않다.

정규표현식은 단어들이 조금이라도 변형되면 찾지 못한다. 예를 들면 satisfy와 satisfies가 있다. satisfy로 검색하였을 때, satisfies로 쓰인 데이터를 놓치게된다. OR을 사용하여 여러개의 변형된 형태를 추가할 수 있겠지만, 매우 지루하고 에러가 생길 여지가 많다(어떤 단어들은 수천가지의 형태로 변형될 수 있다).

Full Text Indexing은 document를 전처리하여 빠르게 검색될 수 있도록 한다.

- Document를 Token으로 해체한다. document을 token으로 해체하고 token들을 숫자, 단어, 이메일 주소 등의 class로 파악한다. Document란 Full Text Search에서의 단위이다. 뉴스 기사나 이메일 내용같은 것들이 될 수 있다.

- Token을 Lexem으로 변환한다. lexem이란 token과 같이 문자열로 되어있지만 '정규화'되어 다양한 형태로 표현된 하나의 단어라면 같은 단어로 만들어져있다. 예를 들자면 대문자로 되어있다면 소문자로 바꾸고, 단어뒤에 붙는 -s, -es들을 제거하는 것 등이 있다.

- 전처리된 Docment를 검색하기 좋은 형태로 저장한다. 각각의 document는 정렬되고 정규화된 lexem들의 배열로 표현할 수 있다.

tsvector타입을 사용하면 전처리된 document를 저장하고, tsquery를 사용하여 검색할 수 있다.

Basic Text Matching

PostgreSQL의 Full Text Searching은 @@연산자를 사용한다. @@연산자는 tsvector가 tsquery와 매칭이 될 경우 true를 반환한다.

SELECT 'a fat cat sat on a mat and ate a fat rat'::tsvector @@ 'cat & rat'::tsquery;
 ?column?
----------
 t

SELECT 'fat & cow'::tsquery @@ 'a fat cat sat on a mat and ate a fat rat'::tsvector;
 ?column?
----------
 f

tsquery는 이미 정규화된 상태의 lexem들을 검색어로 가지고 있어야하며 AND, OR, NOT, FOLLOWED BY와 같은 연산자와 같이 사용될 수 있다.

SELECT to_tsvector('fat cats ate fat rats') @@ to_tsquery('fat & rat');
 ?column? 
----------
 t
 

SELECT 'fat cats ate fat rats'::tsvector @@ to_tsquery('fat & rat');
 ?column? 
----------
 f

위의 코드에서 to_tsvector가 document string을 정규화시켜주므로 true가 반환되지만 밑의 예제는 이미 정규화된 것으로 판단하여 처리하므로 rats 와 rat은 다르기때문에 false를 반환한다.

갤럭시 탭S3를 구입하고 노트필기를 하는데 쓰다보면 선이 끊기는 경우가 있습니다.

이 현상이 잦다면 펜촉에 문제가 있을 수 있습니다.

1. 일단 동봉된 펜촉 리무버로 펜촉을 당겨서 뽑고 휴지/물티슈로 깨끗하게 닦은 후 다시 넣어줍니다.

이 방법이 안된다면(저는 좀 나아지긴 했지만 완전히 해결이 안됐었습니다)

2. 갤럭시 노트 시리즈에 동봉되어 있는 펜촉으로 교체한다.

저는 갤럭시 노트9을 사용하고 있는데요, 갤럭시 노트9 펜촉으로 교체한 이후에는 약 1~2주일동안 펜 끊김 현상이 일어난 적이 없는 걸로 보아 괜찮아진 듯 합니다!