편해지기 위한 도전

100만 row가 있는 테이블에 컬럼 추가는 어떻게 할까

깔롱지기 — Tue, 28 Mar 2023 10:17:24 +0900

테이블을 설계하고 서비스를 운영하다보면 자연스럽게 많은 데이터가 쌓이게 되는 테이블들이 존재하게 됩니다.

또한 부득이한 경우 테이블에

컬럼 추가, 변경, 인덱스 추가 등 여러 가지 해당 테이블에 값을 변경해야 되는 상황이 생기게 되는데요.

초기에 데이터가 얼마 존재하지 않을 때는 문제가 되지 않지만 데이터가 많이 쌓이게 된 경우에는 문제가 발생할 수 도 있습니다.

일반적으로 컬럼을 추가한다고 할 때 사용할 수 있는 쿼리는

ALTER TABLE `테이블명` ADD `컬럼명` 자료형

ex) 'USER' 라는 테이블에 'name' 10글자 컬럼 추가

ALTER TABLE `USER` ADD `name` VARCHAR(10)

와 같이 사용할 수 있습니다.

하지만, MySQL/MariaDB 는 전통적으로 ALTER 명령어에 대해서 해당 명령어가 실행하는 도중에는 해당 테이블을 LOCK 을 잡고 있게 되기 때문에 쓰기 기능이 활발한 테이블에서는 굉장히 불편한 상황일 수 밖에 없었습니다.

그런데 MySQL 5.6 버전 이상부터는 Online DDL 기능이 활성화되었습니다. Online DDL은 테이블의 구조를 변경(스키마 변경)을 실행하는 도중에도, INSERT나 UPDATE와 같은 DML들을 실행할 수 있도록 해주는 기능입니다.

저는 MySQL 5.7 문서를 참고해서 작성하였습니다.

https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html

MySQL :: MySQL 5.7 Reference Manual :: 14.13.1 Online DDL Operations

14.13.1 Online DDL Operations Online support details, syntax examples, and usage notes for DDL operations are provided under the following topics in this section. The following table provides an overview of online DDL support for index operations. An aste

dev.mysql.com

Online DDL 사용 시에는 테이블 LOCK 을 최소화 하기 위해 ALGORITHM, LOCK 이라는 2가지 요소를 활용할 수 있습니다.

위에 예시를 들었던 컬럼 추가 쿼리를 2가지 요소를 추가하면

ALTER TABLE tbl_name ADD COLUMN column_name column_definition, ALGORITHM=INPLACE, LOCK=NONE;

와 같이 활용할 수 있습니다.

물론 컬럼 추가 외에도 추가, 삭제, 이름 변경, 자료형 변경 등등 다양하게 활용할 수 있습니다.

다만 컬럼 추가 시에 유의해야될 점은 컬럼을 추가하는 위치를 특정하면 ALGORITHM=COPY 와 동일하게 동작한다는 점입니다.

ALTER TABLE 'table_name'
ADD COLUMN 'add_column' column_definition AFTER 'exist_column',
ALGORITHM=INPLACE, LOCK=NONE;

위와 같이 AFTER 를 활용하여 특정 컬럼 뒤에 컬럼을 추가할 경우 사실상 테이블을 COPY 하고 추가되기 때문에 ALGORITHM, LOCK 을 제대로 활용하지 못한다고 할 수 있습니다. 때문에 컬럼을 추가할 경우에는 반드시 AFTER 문법을 사용하지 않도록 하여야 합니다.

2022년 회고

깔롱지기 — Mon, 30 Jan 2023 00:35:25 +0900

처음으로 회고록을 작성해보고자 합니다.

정리하는 느낌으로 간단하게 목차만 나눠서 업무적인 내용과 개인적인 내용들을 정리해보겠습니다.

블로그

2022년도는 블로그 글 작성을 거의 하지 않은 년도였던거 같네요. 사실 상 21년, 22년은 블로그를 작성하지 않고 다른 사람들의 블로그나 유튜브를 더 많이 보는 시간이었던거 같습니다. 또한 회사 생활 등으로 신경을 못쓴 년도였던거도 같은데 핑계인거 같긴하네요. 블로그를 쓰는 목적성을 많이 잃어버렸다고 생각했습니다.

23년도가 되어서 지금까지 제가 해왔던 일들을 쭉 정리를 해보고 있는데 기록을 남기는게 중요하다는 생각을 다시 하게 되어서 블로그 글들을 다시 열심히 써보려고 합니다.

블로그를 쓰는 목적성에 대해서 고민을 하다가 결론이 난 거지만 다른 사람들이 많이 읽을거 같은 내용을 쓰는게 아니라 내가 기억하고 싶은 것들을 기록하는데에 더 초점을 맞추는 식으로 운영을 해야 동기부여도 되고 나중에 내가 다시 읽었을 때 도움도 많이 될거 같다고 생각하게 되네요.

그와 별개로 블로그 운영을 하지는 않았지만 22년도의 간단한 통계를 확인해보면 재밌을 거 같아서 오랜만에 블로그 관리 페이지에 들어갔는데 해당 내용들만 정리해 보자면

2022년 월간 평균적으로 1000명 정도는 제 블로그의 글들을 읽어주시는 분들이 있었습니다. 글을 자주 작성하는 편이 아닌데도 제 생각보다는 많은 분들이 블로그를 방문해주시고 있어서 조금 놀랐습니다.

많이 읽어주신 글들의 트렌드도 있었는데

1,2,3 월까지는 제가 작성했던 여러 후기들의 글들이 조회수가 높았습니다.

대표적인 글들은

2020.02.20 - [내가 관심있는 IT 이슈/지식 정리] - ICT 인턴십 소개 및 합격 후기

2019.12.01 - [내가 관심있는 IT 이슈/지식 정리] - 정부지원 IT 대외활동 총정리(SW마에스트로, BOB, 42Seoul)

2019.12.11 - [내가 관심있는 IT 이슈/지식 정리] - SW마에스트로 10기 합격 후기

2019.12.02 - [내가 관심있는 IT 이슈/지식 정리] - 정보보호병 가기 전에 이건 꼭 알고 가자!!

이런 글들이 있었네요

또 제일 조회수가 높은 글이 있는데요

2020.03.21 - [내가 공부하고 싶은 IT/웹] - ax5ui-grid 활용하기 - 01

ax5ui 에 관련된 글이었습니다. 해당 글은 KCC정보통신에서 인턴 생활을 하는 동안 처음으로 사용했던 오픈 소스였는데 jquery 기반으로 활용되는 오픈 소스로 생각보다 개선할 점들이 많아서 정리하면서 수정도 해보던 거였습니다. 아무래도 정보가 적어서 그런지 블로그 글에 대한 유입이 많은 것 같다고 생각이 되네요

회사 생활

21년 12월 말 - 새로운 회사로 이직하였습니다.

22년 3월 - 신규 서비스 런칭을 위해서 처음부터 서비스를 개발해보는 경험을 했습니다. CTO님이 "너 경력에 처음부터 서비스를 주도적으로 개발하는 경험을 한 사람은 거의 없을거다. 그러니 많은 것을 배우고 경험할 수 있을 거고 실력적으로도 많이 성장할거다" 라고 이야기 해주셨던게 아직도 기억이 나네요.

DB설계부터 개발, 인프라까지 모두 세팅하는 경험을 해봤는데 지금 생각해도 어떻게 했나.. 싶네요. 짧은 개발 경력동안 가장 많이 야근하고 공부했던 시간이었지 않나 싶습니다.

또 신기했던게 서비스 초창기에는 버그가 굉장히 많이 발생할거라고 예상했는데 생각보다 버그가 발생하지 않아서 개발팀에서 굉장히 놀랐었던게 기억에 남습니다.

22년 6월 - 개발팀의 규모가 본격적으로 커지기 시작한 시점이었습니다. 제가 입사할 때까지만 해도 개발팀 규모가 작았는데 해당 시점부터는 프론트 3명, 백엔드 3명, 퍼블리셔 1명으로 개발팀 인원이 늘어나면서 조금씩은 여유가 생기는 시점이었습니다.

또한 개발적으로 기능 개선을 할 때 고민했던 것들이 기술적으로 해결되는 경험을 많이 하면서 개발자를 함으로써의 뿌듯함이나 O2O 서비스에 대한 도메인 지식이 점점 늘고 적응해간다는 점에서 만족감을 느끼는 시기였습니다.

22년 7월 - 개발 팀장님이 퇴사하였습니다.

팀장이 공석이 되면서 테크 리드 포지션을 담당하게 되었습니다. 다른 팀의 팀장 분들은 연차가 10년이 넘는데 3년차인 제가 팀의 리드를 맡는다는게 굉장히 부담되기도 하고 많은 책임감이 다가오던 시기이지 않았나 생각됩니다. 실질적인 업무의 일정 조율이나 개발 방향성과 더불어 실제 개발까지 신경써야될게 굉장히 많아지는 시기였습니다. 이렇게 작은 조직에서도 신경 쓸게 굉장히 많은데 더 큰 조직에서 리드 포지션을 담당하는 분들은 더 대단하다고 생각을 많이 했습니다.

22년 11월 - 연도가 끝나는 시점이 다가오면서 서비스의 1년간의 성장세에 대한 자체적인 평가를 하는 시점이 다가왔습니다.

회사에서는 열심히 투자를 받으러 다녔지만 결과적으로 투자에 실패하였고 한동안은 투자 받을려고 노력하지는 않을거라는 사실을 공유받았습니다. 회사 지표가 점점 안 좋아지고 있다는 것을 개발팀에서는 거의 매일 데이터를 확인하니 미리 알고 있었지만 리더들 입에서 해당 사실이 나오니 조금씩 불안해지던 시점이지 않나 생각됩니다.

개발팀 적으로는 팀장님이 퇴사한 이후로는 팀장급 채용을 하지 않는다는 결정이 내려졌습니다. 좋게 생각하면 리드로써 제가 일을 잘하고 있다고 생각될 수도 있지만 개인적으로는 CTO님이 이미 현재 시스템에서 편함을 느끼기도 했고 다른 팀 분들도 제가 리드로써 판단하거나 결정하는 사항들을 인정해주고 있다는 느낌을 받긴했습니다. 감사하긴 하지만 제 연차에서 부족한 점이 많은데 실무적으로 저를 도와줄 사람이 없다는 것은 언제나 아쉽기도하고 외로운 자리라는 것을 느끼던 시점입니다.

22년 12월 - 회사 구조조정으로 50%의 인원을 희망퇴직한다는 통보가 내려왔습니다. 구조조정의 사유는 투자 실패, 서비스 매출 감소 등이 원인이었습니다. 그 결과 개발팀도 반토막이 나서 백엔드 개발자가 저 혼자 남게 되고 기존의 서비스도 유지만 하는 형태로 의사 결정이 내려졌습니다.

뭔가 서비스의 처음부터 함께하기도 했고 현재 회사에 오래 근속하고 싶은 마음으로 입사했는데 리더들의 아쉬운 판단들이 스노우볼이 되어서 지금의 결과가 나온거 같아서 굉장히 슬픈 상황이었습니다. 남는다는 결정을 해도 내가 할 수 있는게 뭘까.. 라는 생각도 많이하고 떠난다면 나를 받아줄 다른 회사는 있을까.. 라는 생각이 공존하면서 좋은 회사, 좋은 서비스, 좋은 동료 들은 어떤거일까.. 라는 생각도 많이 했습니다. 개발에 집중하고 많은 사람들이 좋아해줄 수 있는 서비스나 기능을 만든다는게 이렇게 어려운걸까.. 라는 생각도 하면서 22년도가 마무리 되었습니다.

개인적인 일들

22년도는 많은 취미를 가지게 된 연도가 아닌가 생각됩니다. 또한 많은 친구들을 사귀게 된거 같기도합니다.

코로나 시기에 자취를 하면서 한동안은 밖에 나가지 않았었는데 점점 상황이 괜찮아지면서 다시 활동적인 일들을 많이 할 수 있었던거 같습니다.

한가지 아쉬운 것은 해외 여행을 못간건데 23년도에는 꼭 이루고 싶습니다.

또 23년도에는 단순히 혼자 취미를 즐기는게 아니라 취미를 공유하면서 지내고 싶다는 생각을 하게 되네요.

마무리

23년도는 도전하는 한 해가 될 거 같습니다.

회사나 개발적으로 앞으로 나아갈 방향성을 찾아가야할 시기인거 같습니다.

CTO님은 3~5년차 개발자가 기술적으로 가장 뛰어난 시기라고 이야기해주시는데 업무를 하다보면 저도 그 사실에 공감이 될 때가 있습니다. 이 시기에 기술적으로 많이 성장 할 수 있는 환경과 노력을 병행해야된다고 생각합니다. 또한 가장 자만하기 쉬운 시기이기도 하다고 생각이 됩니다. 그렇기 때문에 방향성을 명확히 하고 노력을 해야되는데 그렇기 위한 좋은 선택들이 기다리는 한 해가 되면 좋겠습니다.

또한 나 스스로를 가꾸는 한 해가 되면 좋을거 같습니다.

이제 20대의 마무리를 향해 달려가고 있고 젊을 때 신체적이든 정신적이든 건강하게 가꾸어야 그게 꾸준히 30대까지 유지될 수 있는 원동력이 될거 같습니다.

Elasticsearch term & match

깔롱지기 — Sun, 1 Jan 2023 21:01:57 +0900

테스트용 index 생성

schema 를 가진 인덱스 생성 (nori 형태소 분석기 사용)

PUT /cn-test-idx
{
  "settings": {
    "index": {
      "number_of_replicas": 1,
      "number_of_shards": 1,
      "analysis": {
        "analyzer": {
          "korean_analyzer": {
            "type": "custom",
            "tokenizer": "korean_tokenizer",
            "filter": [
              "nori_readingform",
              "lowercase",
              "nori_posfilter"
            ]
          }
        },
        "tokenizer": {
          "korean_tokenizer": {
            "type": "nori_tokenizer",
            "decompound_mode": "mixed"
          }
        },
        "filter": {
          "nori_posfilter": {
            "type": "nori_part_of_speech",
            "stoptags": [
              "E",
              "IC",
              "J",
              "MAG",
              "MAJ",
              "SP",
              "SSC",
              "SSO",
              "SC",
              "SE",
              "XPN",
              "XSA",
              "XSN",
              "XSV",
              "UNA",
              "NA",
              "VCP",
              "VSV",
              "VX",
              "VV"
            ]
          }
        }
      }
    }
  },
  "mappings": {
    "_doc": {
      "properties": {
        "keyword_field": {
          "type": "keyword"
        },
        "kor_contents": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "analyzer": "korean_analyzer"
        },
        "contents": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          }
        }
      }
    }
  }
}

테스트용 document 등록

PUT /cn-test-idx/_doc/1
{
  "contents" : "여러개의 물건들",
  "kor_contents" : "여러개의 물건들",
  "keyword_field": "여러개의 물건들"
}

테스트용 텍스트

GET /cn-test-idx/_analyze?pretty
{
  "analyzer": "korean_analyzer",
  "text": "여러개의 물건들"
}

{
  "tokens" : [
    {
      "token" : "여러",
      "start_offset" : 0,
      "end_offset" : 2,
      "type" : "word",
      "position" : 0
    },
    {
      "token" : "개",
      "start_offset" : 2,
      "end_offset" : 3,
      "type" : "word",
      "position" : 1
    },
    {
      "token" : "물건",
      "start_offset" : 5,
      "end_offset" : 7,
      "type" : "word",
      "position" : 3
    }
  ]
}

테스트용 text가 “여러개의 물건들” 이고 nori 분석기로 analyze 하면 위와 같이 tokenize 된다.

토큰들: 여러, 개, 물건

term 쿼리

해당 필드(여기서는 kor_contents)의 inverted index 에 저장되는 token 들 중에서 쿼리의 키워드와 일치하는 document가 있는지 찾아준다.
보통 filter 용도로 사용한다.
아래와 같이 3가지 쿼리가 가능하다.

sql 쿼리의 where 문의 field = 'token' 과 유사하다고 보면 된다.

GET /cn-test-idx/_search
{
  "query": {
    "term": {
      "kor_contents": "여러"
    }
  }
}

GET /cn-test-idx/_search
{
  "query": {
    "term": {
      "kor_contents": "개"
    }
  }
}

GET /cn-test-idx/_search
{
  "query": {
    "term": {
      "kor_contents": "물건"
    }
  }
}

terms 쿼리

term의 경우, 질의문이 1개만 가능하지만 terms 는 여려 개의 질의문을 사용할 수 있다.

GET /cn-test-idx/_search
{
  "query": {
    "terms": {
      "kor_contents": [
        "여러",
        "개"
      ]
    }
  }
}

match 쿼리

term과 마찬가지로 inverted index 에 저장되는 token 들 중에서 일치하는 document가 있는지 찾아주는데, 차이점은 바로 검색하는 키워드를 analyze 한다는 것이다. 이 analyze 한 결과의 token 들 중에서 하나라도 일치하면 결과에 포함된다.

GET /cn-test-idx/_search
{
  "query": {
    "match": {
      "kor_contents": "여러가지"
    }
  }
}

검색하는 키워드는 ‘여러’, ‘가지’ 두개의 토큰으로 분석되고 이중에 ‘여러’ 가 일치하기 때문에 조회 결과에 테스트 document 가 나온다.

GET /cn-test-idx/_analyze?pretty
{
  "analyzer": "korean_analyzer",
  "text": "여러가지"
}

{
  "tokens" : [
    {
      "token" : "여러",
      "start_offset" : 0,
      "end_offset" : 2,
      "type" : "word",
      "position" : 0
    },
    {
      "token" : "가지",
      "start_offset" : 2,
      "end_offset" : 4,
      "type" : "word",
      "position" : 1
    }
  ]
}

multi_match 쿼리

여러필드에 단일 질의문을 검색할 때 사용합니다.

GET /cn-test-idx/_search
{
  "query": {
    "multi_match": {
      "fields": [
        "kor_contents",
        "contents"
      ],
      "query": "여러가지"
    }
  }
}

match_phrase 쿼리

phrase: 둘 또는 그 이상의 어절로 이루어져 한 덩어리
match 와 다른 점은 검색 키워드의 분석된 토큰이 모두 존재해야 하고 순서도 순차적으로 동일한 document를 결과에 포함한다.

가능 쿼리

GET /cn-test-idx/_search
{
  "query": {
    "match_phrase": {
      "kor_contents": "여러개"
    }
  }
}

GET /cn-test-idx/_search
{
  "query": {
    "match_phrase": {
      "kor_contents": "여러개의 물건들"
    }
  }
}

불가능 쿼리

GET /cn-test-idx/_search
{
  "query": {
    "match_phrase": {
      "kor_contents": "물건들 여러개"
    }
  }
}

match 와 match_phrase 중 서비스에 적용시에는 match_phrase 를 써야될 거 같긴 한데 위 예의 순서도 맞아야 하는 부분이 걸림돌이다.

그래서 실제 검색에서는 아래와 같이 사용 예정이다.

GET /cn-test-idx/_search
{
  "query": {
    "match": {
      "kor_contents": {
        "query": "물건들 여러개",
        "operator": "and",
        "boost": 1
      }
    }
  }
}

match 와 operator의 and 조건을 써서 검색 키워드의 모든 토큰이 존재하나 순서는 상관없는 쿼리를 작성할 수 있다.

Elasticsearch bool 쿼리

깔롱지기 — Sun, 1 Jan 2023 20:55:25 +0900

bool 쿼리 다른 쿼리들을 조합하여 결과와 score 들을 결합하거나 동작을 변경함. 즉 bool 하위의 여러 쿼리들을 결합하여 결과를 낼때 사용함
bool 은 query 와 filter 에서의 동작이 상이함. query로 사용할 때는 score 가 결합되어 일치하는 절일 많을 수록 더 좋음

bool의 기본 쿼리

must: 모든 필터가 매치되어야 함(and)
filter: 이전 포스팅에서 설명한 filter 와 동작은 동일. score를 무시하고 결과가 캐싱됨
should: minimum_should_match 개의 필터에 매치되어야 함 (or)
- minimum_should_match
  must 또는 filter 같이 사용되면 기본값이 0, score에 영향만 줌
  단독으로 사용시 기본값이 1
must_not: 문서가 필터에 매치되지 않아야 함(not). filter 절에서 실행되며 filter 와 같이 score를 무시하고 결과가 캐싱됨

예)

GET /cn-test-idx/_search
{
  "query": {
    "bool": {
      "should": [
        {
          "match": {
            "kor_contents": "자비스"
          }
        },
        {
          "match": {
            "kor_contents": "여러"
          }
        }
      ],
      "minimum_should_match": 1,
      "filter": [
        {
          "term": {
            "keyword_field": "1번"
          }
        }
      ]
    }
  }
}

위 쿼리는 아래의 쿼리와 결과가 같다.

GET /cn-test-idx/_search
{
  "query": {
    "bool": {
      "must": {
        "bool": {
          "should": [
            {
              "match": {
                "kor_contents": "자비스"
              }
            },
            {
              "match": {
                "kor_contents": "여러"
              }
            }
          ]
        }
      },
      "filter": [
        {
          "term": {
            "keyword_field": "1번"
          }
        }
      ]
    }
  }
}

Elasticsearch DSL 기본

깔롱지기 — Sun, 1 Jan 2023 20:52:19 +0900

DSL이란 Domain Specific Language 으로 JSON 에 기반한 질의 언어

DB의 SQL 과 비슷한 언어로 사용자가 원하는 데이터를 추출하기 위한 질의 언어

DSL 예시

GET /조회할 인덱스명/_search
{
  "query": {
    ...
  }
}

예) 실제 가장 기본적인 match 쿼리

GET /cn-test-idx/_search
{
  "query": {
    "match": {
      "kor_contents": "여러"
    }
  }
}

Query VS Filter

DSL 설명에 앞서 query 와 filter 간의 차이점을 이해해야 함

기본적으로 Elasticsearch 는 일치하는 검색 결과의 관련성을 점수 별로 정렬하여 각 문서와 쿼리와 얼마나 잘 일하는지 측정함

관련성 점수는 소수점 숫장이며 검색 API의 _score 메터 필드에 반한됨
_score 가 높을수록 문서의 관련성이 높다도 볼수 있음

각 쿼리의 유형은 관 관련성 점수를 다르게 계산할 수 있지만 _score 계산은 query 나 filter 문에서 실행되는 것에 따라 달라짐

query
query 문은 “이 문서가 이 쿼리 절과 얼마나 잘 일치합니까?” 라는 질문에 대답함. 문서가 일치하는지 여부를 결정하는 것 외에도 query 문은 _score 메타 필드에 관련성 점수를 계산함
캐싱되지 않음
filter
filter 문은 query 문과 같이 “이 문서가 이 쿼리 절과 얼마나 잘 일치합니까?” 라는 질문에 대답함. 차이점은 score를 계산하지 않고 간단하게 예 또는 아니오 로 계산함
filter 문은 주로 구조화된 데이터를 필터링하는 데 사용됨. 예를 들어 “등록 시간이 2020년에서 2021년 사이의 데이터나 데이터의 상태 값이 삭제가 안 된 데이터” 와 같이 문서의 score 가 필요없는 데이터 형태를 필터링하는데 사용
filter 문은 자동으로 캐싱하여 성능을 향상시킴

query 와 filter 비교표

	Query	Filter
검색 결과	관련성	Yes or No
검색 범위	전문 검색	주어진 질의에 해당하는 정확한 값
캐시 여부	No	Yes
관련성 점수 계산	Yes	No

예)

GET /cn-test-idx/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "kor_contents": "자비스"
          }
        },
        {
          "match": {
            "kor_contents": "엔진"
          }
        }
      ],
      "filter": [
        {
          "term": {
            "keyword_field": "2번"
          }
        },
        {
          "range": {
            "created_date": {
              "gte": "2020-12-01 00:00:00"
            }
          }
        }
      ]
    }
  }
}

GET /cn-test-idx/_search
{
  "query": {
    "bool": {
      "should": [
        {
          "match": {
            "kor_contents": "자비스"
          }
        },
        {
          "match": {
            "kor_contents": "여러"
          }
        }
      ],
      "minimum_should_match": 1, 
      "filter": [
        {
          "term": {
            "keyword_field": "1번"
          }
        },
        {
          "range": {
            "created_date": {
              "gte": "2020-12-01 00:00:00"
            }
          }
        }
      ]
    }
  }
}

bool 하위 두 개의 match 절은 query 문을 사용하므로 각 문서가 얼마나 잘 알치하는 score 를 매기는 데 사용됨
filter 하위의 term 과 range 절은 filter 문에서 사용되므로 위 조건에 일치하는 문서는 score 에 영향을 미치지 않고 결과를 반환함

Elasticsearch Inverted Index 의 이해

깔롱지기 — Sun, 25 Dec 2022 20:42:14 +0900

Elasticsearch는 Open Source Project인 Apache Lucene을 기반으로 만들어진 Search Engine 임

이 Apache Lucene에서의 Index는 Inverted Index를 사용하기 때문에, Elasticsearch도 그러함

Index 란

Key-Value 구조를 가지는 테이블을 말한다.

Key	Value
1	1번
2	2번
3	3번
4	4번

위와 같은 Key-Value 구조를 가지는 테이블은 HashMap 이라는 자료구조와도 관련이 있다, 특히 대용량 데이터에서 빠르게 데이터를 탐색할 때에 매우 유용한 자료구조로 알려져 있다.

Forward Index

보통 Index 라고 말하는 것은 forward index 를 의미한다. 어떠한 주어진 Document 들로 index를 생성하면 아래와 같이 된다. 즉 Document가 Key에 해당하고 Document에 존재하는 Word들이 Value에 해당한다.

Document	Words
Document1	apple, toy
Document2	bit, box, toy
Document3	tool,tag, fund, box

Inverted Index (역색인)

위에 나온 forward index와는 달리, inverted index는 Word가 Key가 되고, 그 Word가 존재하는 Document들이 Value가 된다. 즉, 아래의 예시에서 처럼 toy라는 key로 검색해서 toy라는 단어가 있는 Document들을 찾을 수 있다.

Word	Documents
toy	Document1, Document2
box	Document2, Document3
fund	Document3

예제로 설명

원본 데이터

key : 1
value : 자비스가 필요해의 본문 글입니다 역색인에 대해서 설명합니다.

key : 2
value : 자비스가 필요해, 검색엔진과 역색인의 원리

key : 3
value : 자비스가 필요해, 엘라스틱 서치와 루씬의 비교

형태소 분석 확인 (nori 형태소 분석기)

“자비스가 필요해의 본문 글입니다 역색인에 대해서 설명합니다.” 형태소 분석 결과

GET /cn-place/_analyze?pretty
{
  "analyzer": "korean_analyzer",
  "text": "자비스가 필요해의 본문 글입니다 역색인에 대해서 설명합니다."
}

{
  "tokens" : [
    {
      "token" : "자비스",
      "start_offset" : 0,
      "end_offset" : 3,
      "type" : "word",
      "position" : 0
    },
    {
      "token" : "필요",
      "start_offset" : 5,
      "end_offset" : 7,
      "type" : "word",
      "position" : 2
    },
    {
      "token" : "해",
      "start_offset" : 7,
      "end_offset" : 8,
      "type" : "word",
      "position" : 3
    },
    {
      "token" : "본문",
      "start_offset" : 10,
      "end_offset" : 12,
      "type" : "word",
      "position" : 5
    },
    {
      "token" : "글",
      "start_offset" : 13,
      "end_offset" : 14,
      "type" : "word",
      "position" : 6
    },
    {
      "token" : "역색인",
      "start_offset" : 18,
      "end_offset" : 21,
      "type" : "word",
      "position" : 9,
      "positionLength" : 2
    },
    {
      "token" : "역",
      "start_offset" : 18,
      "end_offset" : 19,
      "type" : "word",
      "position" : 9
    },
    {
      "token" : "색인",
      "start_offset" : 19,
      "end_offset" : 21,
      "type" : "word",
      "position" : 10
    },
    {
      "token" : "설명",
      "start_offset" : 27,
      "end_offset" : 29,
      "type" : "word",
      "position" : 14
    }
  ]
}

“자비스가 필요해, 검색엔진과 역색인의 원리” 형태소 분석 결과

GET /cn-place/_analyze?pretty
{
  "analyzer": "korean_analyzer",
  "text": "자비스가 필요해, 검색엔진과 역색인의 원리"
}

{
  "tokens" : [
    {
      "token" : "자비스",
      "start_offset" : 0,
      "end_offset" : 3,
      "type" : "word",
      "position" : 0
    },
    {
      "token" : "필요",
      "start_offset" : 5,
      "end_offset" : 7,
      "type" : "word",
      "position" : 2
    },
    {
      "token" : "검색",
      "start_offset" : 10,
      "end_offset" : 12,
      "type" : "word",
      "position" : 5
    },
    {
      "token" : "엔진",
      "start_offset" : 12,
      "end_offset" : 14,
      "type" : "word",
      "position" : 6
    },
    {
      "token" : "역색인",
      "start_offset" : 16,
      "end_offset" : 19,
      "type" : "word",
      "position" : 8,
      "positionLength" : 2
    },
    {
      "token" : "역",
      "start_offset" : 16,
      "end_offset" : 17,
      "type" : "word",
      "position" : 8
    },
    {
      "token" : "색인",
      "start_offset" : 17,
      "end_offset" : 19,
      "type" : "word",
      "position" : 9
    },
    {
      "token" : "원리",
      "start_offset" : 21,
      "end_offset" : 23,
      "type" : "word",
      "position" : 11
    }
  ]
}

“자비스가 필요해, 엘라스틱 서치와 루씬의 비교” 형태소 분석 결과

GET /cn-place/_analyze?pretty
{
  "analyzer": "korean_analyzer",
  "text": "자비스가 필요해, 엘라스틱 서치와 루씬의 비교"
}

{
  "tokens" : [
    {
      "token" : "자비스",
      "start_offset" : 0,
      "end_offset" : 3,
      "type" : "word",
      "position" : 0
    },
    {
      "token" : "필요",
      "start_offset" : 5,
      "end_offset" : 7,
      "type" : "word",
      "position" : 2
    },
    {
      "token" : "엘라스틱",
      "start_offset" : 10,
      "end_offset" : 14,
      "type" : "word",
      "position" : 5
    },
    {
      "token" : "서치",
      "start_offset" : 15,
      "end_offset" : 17,
      "type" : "word",
      "position" : 6
    },
    {
      "token" : "루씬",
      "start_offset" : 19,
      "end_offset" : 21,
      "type" : "word",
      "position" : 8
    },
    {
      "token" : "비교",
      "start_offset" : 23,
      "end_offset" : 25,
      "type" : "word",
      "position" : 10
    }
  ]
}

3가지 문장의 형태소 분석으로 추출된 단어들

자비스가 필요해의 본문 글입니다. 역색인에 대해서 설명합니다.
자비스,필요,해,본문,글,역색인,역,색인,설명

자비스가 필요해, 검색엔진과 역색인의 원리
자비스,필요,검색,엔진,역색인,역,색인,원리

자비스가 필요해, 엘라스틱 서치와 루씬의 비교
자비스,필요,엘라,스틱,서치,루씬,비교

형태소 분석이 끝나면 검색엔진은 역색인 작업을 하게 되는데 그 결과는 다음과 같다.

키워드	문서번호
자비스	1,2,3
필요	1,2,3
해	1
본문	1
글	1
역색인	1,2
역	1,2
색인	1,2
설명	1
검색	2
엔진	2
원리	2
엘라	3
스틱	3
서치	3
루씬	3
비교	3

위의 표를 보다시피 역색인은 키워드에 문서들의 Primary Key(혹은 주소, 파일명 등)와 같은 값등을 매핑하여 저장하는 기술이다. 역색인 작업을 하게 될때의 장점은 매우 빨리 찾을 수 있다는 것이다. 기존보다 추가적인 작업과 메모리가 필요하게 되지만, 검색은 매우 빠른 속도로 처리가 된다.

그리고, 키워드가 여러개 있어도 속도에 큰 영향을 주지 않게 되며 된다. 예를 들어 검색 키워드가 “자비스 역색인"이라고 입력 했을 경우 자비스에 속한 문서 번호 1,2,3을 갖고 오고, 역색인에 속한 문서 번호 1,2를 갖고 온 후, 교집합인 1,2를 출력해주면 되는 간단한 작업만 필요하다.

만약 위와 같이 키워드에 AND처리를 하는게 아니라 OR처리가 필요하다고 한다면, 다음과 같이 처리를 하면 된다.

1번 문서 2번
2번 문서 2번
3번 문서 1번

위와 같이 문서별 등장 빈도수를 책정 한 후, 빈도가 많은 순으로 정렬(여기선 1,2,3 순서)을 하면 된다.

검색엔진은 위의 원리에서 크게 벗어나지 않으며. 여기에서 얼만큼 보다 효율적으로 구현을 하냐의 싸움이기 때문에 솔루션을 만드는 것은 다른 차원의 문제이지만, 보다 시피 간단한 검색엔진을 만드는 것은 요구사항에 따라서 하루만에도 만들 수 있는 간단한 알고리즘 집합이다.

Inverted indexing 이 되는 과정

용어정리

Postings List
Indexing하는 과정에서 생성하게 되는 (Document별 Unique한 식별값인) Document ID들을 모은 List이다.
정렬은 Document ID별로 하여, List를 생성한다.
Vocabulary
각 Field별로 추출한 Term들의 집합
Field
Term들을 묶은 집합 (Term들을 대표하는 개념이라기 보다는 document별로 공통으로 구분하는 데이터집합)
Term
Field에서 (tokenization에 의해) 추출한 word 또는 token
Doc Freq
해당 Term이 몇개의 Document에 존재하는가에 대한 빈도
Term Freq
해당 Term이 각 Document내에 몇번 나타나는가에 대한 빈도
position
해당 Term이 Field내에 몇번째 Term인지에 대한 값으로, 맨 앞에 존재하면 0
offset
해당 Term이 Field내의 문자열 시작점부터 끝점까지의 값

Inverted Indexing 과정설명

먼저 Field들을 분류한다.
각 Field들에 맞는 Term들을 추출한다.
추출한 Term별로 DocFreq를 계산한다.
추출한 Term이 존재하는 Document별로 TermFreq를 계산하고 각 Document내 position을 구한다.
(offset은 언제 구하는지 정확히 모르겠지만, Term추출 또는 DocFreq를 계산할 때 구하는 듯 합니다.)
Term이 Key이고 Value가 Postings List(Document ID List)인 Inverted Index가 생성된다.

Elasticsearch 분석기 테스트

깔롱지기 — Sun, 25 Dec 2022 20:34:08 +0900

Tokenizer 확인

주어진 문장(text)이 어떻게 형태소 분리되는지 확인
분석하려는 index 를 지정함
여기서는 cn-place
Tokenizer 지정
여기서는 korean_tokenizer

GET cn-place/_analyze?pretty
{
   "tokenizer":"korean_tokenizer",
   "text":"운동장"
}

결과

{
  "tokens" : [
    {
      "token" : "운동장",
      "start_offset" : 0,
      "end_offset" : 3,
      "type" : "word",
      "position" : 0,
      "positionLength" : 2
    },
    {
      "token" : "운동",
      "start_offset" : 0,
      "end_offset" : 2,
      "type" : "word",
      "position" : 0
    },
    {
      "token" : "장",
      "start_offset" : 2,
      "end_offset" : 3,
      "type" : "word",
      "position" : 1
    }
  ]
}

사용자 정의 Analyzer 확인

Tokenizer + filter 의 조합
주어진 문장(text)이 어떻게 형태소 분리가 되는지 그리고 필터링이 되는지 확인
분석하려는 index 를 지정함
여기서는 cn-place
Analyzer 지정
여기서는 korean_tokenizer

GET cn-place/_analyze?pretty
{
   "analyzer":"korean_analyzer",
   "text":"운동장"
}

결과

{
  "tokens" : [
    {
      "token" : "운동장",
      "start_offset" : 0,
      "end_offset" : 3,
      "type" : "word",
      "position" : 0,
      "positionLength" : 2
    },
    {
      "token" : "플레이",
      "start_offset" : 0,
      "end_offset" : 3,
      "type" : "SYNONYM",
      "position" : 2
    },
    {
      "token" : "놀이터",
      "start_offset" : 0,
      "end_offset" : 3,
      "type" : "SYNONYM",
      "position" : 2,
      "positionLength" : 3
    },
    {
      "token" : "운동",
      "start_offset" : 0,
      "end_offset" : 2,
      "type" : "word",
      "position" : 2,
      "positionLength" : 2
    },
    {
      "token" : "그라운드",
      "start_offset" : 0,
      "end_offset" : 3,
      "type" : "SYNONYM",
      "position" : 3,
      "positionLength" : 2
    },
    {
      "token" : "장",
      "start_offset" : 2,
      "end_offset" : 3,
      "type" : "word",
      "position" : 4
    }
  ]
}

Elasticsearch 분석기

깔롱지기 — Sun, 25 Dec 2022 20:31:04 +0900

Elasticsearch 의 분석기는

토크나이저 (Tokenizer)
토큰 필터 (Token Filter)

로 구성되어 있음

분석기 동작 프로세스

문장을 특정한 규칙에 의해 수정
- 전처리 필터 (CHARACTER FILTER; char_filter)
- 문장 분석 전 replaceAll()같은 패턴 처리나, 태그 제거 등의 역할
- 토크나이저 내부에서도 전처리가 가능하기 때문에 활용도는 떨어짐
- 대표적인 전처리 필터 : html_strip
  기본적으로 html 태그를 모두 삭제하지만 escaped_tags 파라미터를 통해 특정 태그만 예외처리 가능
수정한 문장을 개별 토큰으로 분리
- 토크나이저 필터 (TOKENIZER FILTER)
- 분석기의 핵심 구성요소로, 텍스트를 어떻게 나눌 것인지 정의
- 언어 및 특징에 따라 다른 종류의 Tokenizer를 사용하며 하나의 분석기만 사용 가능
  기본 토크나이저 필터 아래 참고
개별 토큰을 특정한 규칙에 의해 변경
- 토큰 필터 (TOKEN FILTER)
- 토큰화된 단어를 하나씩 필터링하여 사용자가 원하는 형태로 변환
- 불필요한 단어 제거, 동의어 처리, 영문의 소문자 변환 작업 등
- 토크나이저에 의해 토큰이 모두 분리되어야 동작하므로 독립 사용 불가
  기본 토큰 필터 아래 참고

기본 분석기 종류

ElasticSearch 는 기본적으로 아래와 같이 3개의 분석기를 제공

분석기	적용 토크나이저	적용 토큰 필터
Standard Analyzer	Standard Tokenizer	Lowercase Token Filter
Whitespace Analyzer	Whitespace Tokenizer	-
Keyword Analyzer	Keyword Tokenizer	-

포인트(Point) 테이블 설계

깔롱지기 — Sun, 20 Nov 2022 21:35:08 +0900

포인트 설계 시 고민했던 부분들과 해결하는 과정 정리

초반 설계 시에 정확한 요구사항 전에 관련 레퍼런스를 찾아보다가 제일 잘 정리되어 있고 거의 비슷하게 설계가 가능했던 좋은 레퍼런스가 있었다.

https://techblog.woowahan.com/2587/

신규 포인트 시스템 전환기 #1 – 개발 단계 | 우아한형제들 기술블로그

{{item.name}} 포인트 시스템 개편기 #1 – 개발 안녕하세요? 우아한 형제들에서 결제/정산 (+포인트와 비즈머니) 시스템을 개발하고 있는 이동욱입니다. ‘사내 블로그에 글을 더 쓸 일이 있을줄이

techblog.woowahan.com

해당 글에서 좋은 DB 설계 방식에 모티브를 얻고 요구사항에 맞는 조건들을 정리했다.

요구사항

1. 포인트의 상태는 적립(Save), 사용(Use), 사용취소(Use cancel), 적립취소(Save cancel), 만료(Expire) 5 종류의 상태가 발생할 수 있다.

2. 적립 자체는 여러 상황에서 발생할 수 있다.(ex. 리뷰작성, CS, 마케팅 등등) 또한 적립이 발생한 액션을 알 수 있어야 한다.

3. 적립된 포인트를 한번에 사용할 수 있다.

시나리오 예시

1) 1000원 적립

2) 2000원 적립

3) 2500원 사용

4) 500원 남음

4. 유효기간 종료 될 경우 자동으로 만료가 되어야 한다.

설계

point_master(포인트 적립 정책), point_member(회원별 포인트), point_member_detail(회원별 포인트 상세) 3가지의 테이블을 설계 했다.

point_master 는 어드민에서 사용자에게 발급하는 포인트에 대한 정책이기 때문에 별도로 설명하지 않고 넘어가고 포인트 관련의 핵심인 point_member, point_member_detail 에 관련해서만 정리하겠다.

ERD 정리

create table point_member
(
    point_member_id          bigint auto_increment comment '포인트 회원 아이디'
        primary key,
    member_id                bigint        not null comment '회원 아이디',
    point_master_id          bigint        null comment '포인트 마스터 아이디',
    point_status_code        varchar(1)    not null comment '포인트 액션 형태',
    point                    int default 0 not null comment '포인트',
    issue_date               varchar(8)    not null comment '발급 일자 yyyymmdd',
    expiry_date              varchar(8)    not null comment '만료 일자 yyyymmdd',
    point_type_code          varchar(2)    null comment '포인트 포인트 구분 코드',
    ref_unique_id            bigint        null comment '각 테이블의 아이디',
    reason                   varchar(100)  null comment '사유',
    memo                     varchar(100)  null comment '메모'
)

create table point_member_detail
(
    point_member_detail_id   bigint auto_increment comment '포인트 회원 상세 아이디'
        primary key,
    point_member_id          bigint        not null comment '포인트 회원 상세 아이디',
    member_id                bigint        not null comment '회원 아이디',
    point_status_code        varchar(1)    not null comment '포인트 액션 형태',
    point                    int default 0 not null comment '포인트',
    save_point_member_id     bigint        null comment '적립 원본 아이디'
)

시나오리오 별 상황

1. 적립

point_member 에 100 적립

point_member_detail 에 100 적립

적립 상황 시에는 point_member 와 point_member_detail 에 테이블에 각각 하나의 row 가 추가된다.

save_point_member_id 에는 point_member의 id 를 그대로 저장한다.

2. 사용

point_member 에 500 사용

point_member_detail 에 500 사용되는 과정 예시

사용 시에는 먼저 100, 200, 300 씩 순차적으로 적립이 된 상황에서 (총 600 포인트)

500포인트를 사용 할 경우 먼저 적립된 포인트 부터 순차적으로 차감되는 과정을 point_member_detail 에서 확인 할 수 있다.

이런식으로 포인트 관련 테이블을 설계 할 경우 포인트의 적립과 차감에 관련된 히스토리를 쌓으면서 사용자에게는 요약된 정보를 보여 줄 수 있어서 쿼리를 할 때도 유용하다고 생각한다.

[Pinpoint] quickstart Windows(윈도우) 환경 실행하기

깔롱지기 — Sun, 9 Aug 2020 21:05:37 +0900

안녕하세요, 이번에 '오픈소스 컨트리뷰톤'에 참여하게 되어 pinpoint에 대한 간단한 설명과 빠르게 세팅하는 법을 포스팅하려고 합니다.

그 중에서도 윈도우 환경에 대한 설명이 조금은 부족하고 네이버에서 만든 오픈소스이지만 설명은 영어로 대부분 되어 있어 한국어로 정리하는 느낌으로 하려고 합니다.

1. pinpoint

naver/pinpoint

APM, (Application Performance Management) tool for large-scale distributed systems. - naver/pinpoint

github.com

pinpoint github 주소입니다. 최신 코드 및 설명을 확인할 수 있습니다.

Pinpoint | Leading Open-Source APM

Tweets by Pinpoint_APM Is your application created with PHP? Pinpoint has started to support application written in PHP. Check-out our php-agent repository. Looking for place to ask questions? Questions and FAQ Introduction Pinpoint is an APM (Application

naver.github.io

pinpoint에 대한 설명 페이지입니다. 조금 더 자세히 설명이 되어 있습니다.

2. 설치파일 다운 받기

1) github으로 갑니다.

평소라면 git clone을 하거나 다운 받겠지만 오픈소스의 경우 최신 master branch의 소스들은 안전한 버전이 아닐 가능성이 높습니다.

2) stable 버전

검증이 된 버전인 v2.0.3 링크로 갑니다. 물론 시간에 따라 업데이트가 되니 추후에는 달라질 수도 있습니다.

과거의 stable version 또한 branch를 통해서 가져올 수 있습니다. 물론 저는 2.0.3 버전으로 진행하겠습니다.

2.0.3 release notes 페이지 제일 하단으로 이동합니다.

Souce code라는 zip 파일을 다운받습니다. 이것만 있으면 됩니다.

3. 설치하기 전 준비

1) JDK 설치

pinpoint를 설치하기 전에 JAVA_HOME을 설정하여야 합니다.

jdk 6, 7, 8, 9 모두가 필요합니다. 하나라면 없으면 maven build가 실패합니다.

jdk 6, 7은 recommended 링크를 통해서 접속해 다운로드 합니다. 다운로드 위치는 크게 상관은 없지만 하나의 폴더에 위치 시켜주는게 좋습니다.

저는 C드라이브에 java라는 폴더를 생성 후 다운로드 받았습니다.

2) 환경변수 설정

[내 PC] 우클릭 -> [속성] -> [고급 시스템 설정] -> [환경 변수] 에서 설정 가능합니다.

이런식으로 JAVA_HOME부터 JAVA_9_HOME까지 생성해줍니다.

그럼 설치 준비가 끝납니다.

4. 설치하기

1) maven build

'mvnw.cmd' 파일이 존재하는 위치에서 cmd를 열은 후

mvnw.cmd install -DskipTests=true

라고 입력합니다. 빌드가 진행되는 시간은 사양에 따라 다르지만 JAVA_HOME 설정 등이 잘못되면 초반에 에러가 발생하고 그렇지 않다면 대부분 정상적으로 빌드가 됩니다.

2) Hbase 설치 및 세팅

hbase를 설치합니다. 설치위치는 'pinpoint\quickstart' 에 압축파일 다운 및 압출 풀기를 진행합니다.

그리고 위의 파일을 다운 받을 경우 폴더명이 'hbase-1.3.6.bin' 과 같이 되어 있을 텐데 폴더 명을 'hbase'로 수정합니다. 'hbase' 안에 폴더도 동일하게 'hbase'로 수정합니다.

그럼 최종적으로 'pinpoint\quickstart\hbase\hbase' 라는 경로가 완성됩니다.

3) Hbase 시작 및 초기화하기

cmd를 pinpoint 위치로 이동한 후 명령어를 쳐야합니다.

quickstart\bin\start-hbase.cmd

hbase를 시작하는 명령어입니다. cmd 창이 뜨면서 쭉 진행이 되고 중간에 오류 메시지가 뜰 수도 있는데 일단 무시합니다. 그 상태로 cmd 창을 닫지 말고 초기화 시키는 명령어를 입력해줍니다.

quickstart\bin\init-hbase.cmd

hbase를 초기화하면서 테이블을 생성합니다.

4) collector, testapp, web 시작

quickstart\bin\start-collector.cmd

quickstart\bin\start-testapp.cmd

quickstart\bin\start-web.cmd

차라대로 입력하면 끝입니다.