Efficient PostgreSQL Index 생성을 위한 몇가지 참고점

-
  • B-Tree
    • MySQL 과 마찬가지로, CREATE INDEX 를 하게 되면 B-Tree 를 사용한다. 
    • B-Tree 는 별도로 공부해야하지만,  it tries to remain balanced. 가 핵심이다. 각 tree의 branch 들에 속한 값의 양들이 거의 동일하게된다. 

  • INDEX  Case by case 
      • select * from foo where bar = 1
      • select * from foo where bar = 2
    • bar=2 인 경우가 굉장히 많으면, 오히려 안타게 된다. sequential scan 이 index scan 보다 훨씬 빠르기 때문이다.

  • Partial Index
    • Index 는 Index 인데, where 조건이 포함된 Index 이다
    • Index size 를 줄임으로써 Index에 대한 효율성을 높일 수 있다
    • 아래와 같은 경우, comments 중 flag 가 true 인 것들에 대해서만 created_at에 Index 를 걸 수 있다. 
    • CREATE INDEX idx_comments_flagged_created_at ON comments(created_at) WHERE flag IS TRUE;

  • Expression Index
    • data 를 function 에 넣은 결과값에 대해 Index를 걸 수 있다.  
    • 예를들어, 사용자의 email 계정을 저장하는  column  이 있다고 할때,  사용자가 입력한대로 값은 저장하되 로그인등 인증시에는 아래처럼 소문자로 처리하고 싶으면,
      •  WHERE lower(account) = '{lowercased_email}'
    •  Index 는 아래와 같이 걸수 있다. 
    • CREATE INDEX idx_users_account_email ON users(lower(account)); 
    • 혹은 Timestamp Column 에 대해 날짜에 대해서만 검색을 하는 경우, 
      •  WHERE date(posts.published_at) = date('2020-07-07')
    • 다음과 같이 할 수도 있다.
    • CREATE INDEX idx_posts_day ON posts (date(published_at));

  • Unique Index
    • UK  는, data integrity 측면과 성능 측면에서 중요한 역할을 한다.
    • UK 와  Unique Constraints 에 는 차이가 있는데, Unique Constraints 는 위의 Partial, Expression Index 를 사용할 수 없다.

  • Multi-column Index
    • Postgres query planner 는 기본적으로 Multiple single-column indexes 들을 잘 조합해서 사용하는 능력이 있다.  multi-column query 시에 말이다.
    • 따라서, query  조건에 들어오는  column 들에 대해 각각  single-column index  들만 잘 걸어두면, Postgres 에서 알아서 잘 선택해준다.
    • 그럼에도 multi-column index 를 생성한다면, order 가 중요하므로 반드시 column 순서를 고려해야 하고, 항상 index 에는 cost 가 따른다는점을 생각해서 benchmark 테스트를 해야한다.
    • 아래와 같은 index 가 있다고 ㅎ
    • CREATE INDEX idx_posts_like_dislike ON posts (like,dislike);
    • 아래와 같은 두 경우는 index 를 사용한다
      •  WHERE like=n and dislike=m;
      •  WHERE like=n;
    • 하지만 아래의 경우에는 사용되지 않는다.
      •  WHERE dislike=m;
    • 이 경우, column like 에만 따로 또 index 를 거는것은 중복에 해당한다.

  • B-Trees and Index
    • B-Tree Index  는 기본적으로 ascending order 이다.
    • 하지만 descending order 로 indexing 을 할 수도 있으며, 다음과 같은 경우 이익을 얻을 수있다.
    • 예를들어, post 들을 paging 할때는 최신 순으로 읽어오면서 paging  을 하는데, 이런 경우이다.
    • CREATE INDEX idx_posts_published_at_index ON posts(published_at DESC NULLS LAST);

  • Necessarily
    • Index 를 건다고 해서 row 의 모든 데이터가 전부  index 에 포함되지 않는다. 따라서 index 를 통해 query 가 매칭 된다 하더라도  disk block 을 찾아가서 row data 를 fetching 한다.
    • 따라서 index 는 disk-lookup 을 줄일 수 있는 경우에 사용되어야 한다
    • 예를들어, big table  에서 PK 를통해 접근하는 것은 sequential scanning 을 피할수 있다
    • small table 같은 경우, 예를 들어  cities table 같은,  city_name 으로  querying 을 한다 할지라도 index 가 불필요 할 수도 있다.
    • (Random I/O  는 sequential scanning 보다 비싸니, 이런 경우는 index  를 타는게 overhead  라고 판단되는 것 같다. )
    • 이런 경우 Postgres 는 Index  를 무시하고 sequential scan 을 단행할 수 있으며, 이경우 index 는  dead index  가 된다. 
    • index 는 결코 공짜가 아니므로 이런 관점에서 꼭 필요한지 따져봐야 한다.
    • benchmarking 을 할때도, 실 데이터 혹은 실데이터와 유사한 양의 데이터를 가지고 테스트를해야 효과가 있다. 그저 row 몇백개, 천개 가지고는 원하는 indexing 결과를 보기가 힘들다. 

  • Table Lock
    • MySQL에서도 경험한 적이 있는데,  CREATE INDEX 는 table lock(writing)  을 동반하는 작업이므로, productive 환경에서는 유의해야한다. 서비스 down 이 발생할 수도 있다.
    • Postgres  는 CREATE INDEX CONCURRENTLY 라는 옵션이 있는데, table lock  을 걸지 않고 작업이 가능한것 같다. 물론 훨씬 더 오래 걸린다.
    • index 도 시간이 지남에 따라 fragmented, unoptimized 되는데, 특히나 빈번히 업데이트, 삭제되는 column에 걸린 경우 더 그렇다.
    • 그런 경우  REINDEX 를 수행해야 하는데,  이 역시 table lock 이 걸리므로,  동일한 column  으로  concurrently 수행하고,  old index 를 삭제하는 방식으로 할 수 있다.


Comments

Post a Comment

Popular posts from this blog

삼성전자 무선사업부 퇴사 후기

-
"잠깐 드릴 말씀이 있는데요."  8월 어느날. 갑작스런 내 메신저에, 이미 예상을 하셨는지도 모르겠다. 몇주간 보인 내 근무 태도와, 먼저 메신저로 이런말을 하는 적이 한번도 없는 내가 면담을 요청한거나 마찬가지니. 갑자기 죄송스럽지만, 퇴사를 하겠다고 말씀을 드렸다. 신입사원으로 입사한지 6년 반만이었다.  삼성전자. 글로벌 기업이지만. 그래서일까. 우리나라에서 사기업,대기업 하면 가장 많이 사람들의 입에 오르며, 연일 다양한 언론의 주목을 다각도로 받는 기업. 명절에 가족 친지들을 만나면, 어르신들은 항상 요즘 삼성 어떠냐, 라고 물으셨었다. 내가 어떤지보다는. 무선사업부. 사람들 일상에 제일 가까운 핸드폰을 만들기도 하고, 내가 다니던 동안은 성과급 이야기에 무선 이야기가 늘 빠지지 않았다. 많은 사업부들이 있지만, 적어도 내가 입사 할때는 많은 개발직군은 무선이 최우선 지망이었다. 사내 댓상에서 조차, 삼성에는 전자와 후자가 있고, 전자에는 무선만 있습니다 라는 이야기를. 무선이 아닐때 들었었다. 그땐. 부럽기도 하고 어이가 없기도 했는데. 네임밸류  주위에선 잘다니는 회사를 왜 나오려고 하냐고. 그 안이 전쟁이라면 바깥은 지옥이라고. 이런 말들을 해줬었다. 누구나 아는 회사를 다니면 편하다. 아무도 뭐하는 곳이냐고 묻지않는다. 어렵게 설명하지 않아도 된다. 부모님도, 아들 어디 취직했어? 라고 물어오는 질문들에 대답이 편하셨을테다. 모르는 사람에게 소개할때도 편하다. 이직을 준비하는 과정에서도 그랬다. 이런점이 편했고, 알게 모르게 사람들의 이미지에 적어도 밥벌이는 하겠구나 하는 이미지였으리라. 하는 생각이 든다.  인지도 언론의 기사 제목 뽑는 능력 덕분에, 바깥의 사람들은 삼성 직원이 엄청난 연봉을 받는줄 안다. 그러나 안에서는 어떻게 하면 돈을 더벌까, 더 모을까 이런 이야기들을 한다. 집을 사지 못해 전세를얻고, 회사 앞 수많은 오피스텔에서 다니는 사원들중 본인 소유인 사람은 얼마나 되려나. 임직원중에 부자들...
Read more

개발자 커리어로 해외 취업, 독일 이직 프로세스

-
요즘은 국내 IT 기업도 이런 프로세스를 많이 따라가고 있는것 같다. 아래는 내가 해외 이직을 목표로 준비하면서 밟았던 몇몇 프로세스 경험을 종합했다. 0.  최초 컨택 크게 두가지 경로가 있는데, 링크드인에 프로필을 업로드하고 관리를 하다보면 연락이 오는경우. 그리고 내가 직접 링크드인에서 지원을 하거나 회사 홈페이지의 오픈 포지션에서 지원을 하는 경우이다.  링크드인에 프로필을 업로드하고 관리를 하다보면, 메세지를 받게 된다. 두가지의 경우가 있는데, 하나는 헤드헌터로부터 받는 경우, 그리고 하나는 채용하는 회사의 HR 로부터 받는 경우이다.   헤드헌터의 경우 채용하는 회사의 이름이나 구체적인 정보를 오픈하지는 않는다. 자신의 고객이 인재를 구하고 있는데 너의 프로필이 매칭되는것 같다, 괜찮다면 짧게 소개하고 이야기를 하고싶다, 라는 식이다. 회사의 리크루터가 직접 컨택하는 경우도 있는데, 이때는 보통 팀 소개도 간략히 해주기도 한다. 우리회사의 이런 팀에서 어떤인재를 찾고 있는데 너의 프로필이 잘 어울리는것 같다. 전화를 통해 자세한 이야기를 하고싶다, 라고 온다.  처음엔 몰랐지만, 몇번 메세지를 받다보니 내용은 복붙하고 이름만 바꿔서 뿌리는것 같은 느낌이다. 내가 조건을 필터링해서 구인공고를 검색할 수 있듯이, 리쿠르터들도 키워드를 검색해서 매칭되는 프로필들에게 뿌릴 수 있는것 같다. 운좋게 가고싶었던 회사 인사팀으로부터 연락이와서 정성스레 답장을 보냈는데, 그 뒤로 아무런 응답이 없는 경우도 있었다. 직접 지원을 하는 경우에도,  끝끝내 답장이 오지 않는 경우가 더 많았던것 같다.  1. 첫번째 인터뷰 첫번째 인터뷰는 주로 전화 혹은 스카이프로 짧게 진행되었다. 헤드헌터나 인사팀과 서로 소개하는 식이었다. 주로 받는 질문은 이런것이었다. - 왜 한국을 떠나려고 하는지 - 왜 삼성을 떠나려고 하는지 - 여기서 일하는데 비자를 갖추고 있는지 - 일을 한다면 언제부터 일할 수 있는지 그러면서 ...
Read more

코드리뷰에 대하여

-
우리 개발팀에는 DoR, DoD,DoP 라는 것이 있다. 이전에는 겪어본적이 없는것들이다. 나중에 따로 정리를 하겠지만, 우선은 코드리뷰에 대해 정리를 해보려고 한다.  이전 회사에서도 코드리뷰가 있었다. 처음부터 있었던건 아니고, 나중에 생겼다. 하지만 반드시 reviewer 가 accept 해야 commit 이 되는것도 일부 모듈에 대해서만 적용되었기 때문에 모든 code commit  에 대해 approval  이 필요하지 않았다. 때로는 빨리 검증 받고 배포해야 하는데 review 안되서 이게 걸림돌이라는 느낌이 강했고, 어떤 경우엔 담당자가 나 혼자여서 review 를 해줄 사람이 없었다. 모듈별로 주담당-백업이 나뉘어 있었는데, 백업 모듈에 대해 review 를 하기엔 잘 알지 못하고, 주담당인 모듈에 대해선 누군가 review  를 해줘야하는데 오래 걸리니 걸림돌이 되고. 백업이 없는 경우는 review 가 없는 상황. code reivew  에 대한 인식이 없다가 생긴것은 좋았으나, 그것이 개발에서 꼭 필요한 일부분이라기 보단 형식적인 통과의례로서 병목처럼 여겨졌다. 여기서는 아니다. review 를 받지 못하면 merge 되지 않는다. 우리 팀은 이제 7명. 옆 팀은 더 많다. 한 9명 되나? frontenf, backend 가 한 팀에 있고,  내 모듈, 네 모듈의 개념이 아닌, 우리 팀의 모듈이다. 그래서 특별히 어려운 티켓을 제외하면 누구나 develop, review, test 를 할 수 있게 되어있다.  reviewer  를 찾는 문화도 있다. daily  에서, 혹은 팀 채널에서 티켓 개발이 끝났으니 reviewer  를 찾고 있다, 라든지, 지금 할거 없는데  도움 필요한 사람? 이런식으로 나서기도 한다.  review 도 대충하지 않는다. 철저하다. 여러번 퇴짜를 맞았다. 나도 마찬가지로 적극적으로 의견을 내려고 한다. 아무리...
Read more