이벤트들에이블리 인턴에서 정규직으로에이블리 인턴에 합격하고, 수습을 거쳐 정규직 전환까지 되었다. 에이블리에서 근무 하면서 좋았던 건 인턴 / 신입 / 주니어임에도 불구하고 꽤 높은 수준의 책임감을 요구한다는 점이다. 솔직히 처음에는 아무 맥락도 모르는데 과제가 주어지고 결정들을 혼자 해야하는 경우가 많기도 하고, 주위에서 푸시는 계속해서 들어와서 많이 힘들었다. 주말에 코드를 1줄도 못짜고 하루종일 흰 화면의 코드들만 보다가 눈물난 적도 있다. 그런데 오히려 맥락이 없다보니 요청들을 하나씩 읽어나가면서 나름대로 코드를 읽는 능력이 길러진 것 같다. 이 점은 좋은 것 같다. 물론 아쉬운 점들도 있지만 일도 재밌고 현재는 만족하며 지내고 있다. 특히 지금 이동한 팀에서는 PO가 입사했을 때 사수분인데, 개..

NL Join과 인덱스책 친절한 SQL 튜닝 272페이지를 보면, 다음 쿼리와 인덱스에서 잘못된 부분을 찾아 개선하라는 문제가 나온다.# index: (SALE_ORG_ID, STRD_GRP_ID, STRD_ID, STC_DT)select *from PRA_HST_STC a, OOM_TRMS bWHERE a.SALE_ORG_ID = :sale_org_idand a.STRD_GRP_ID = b.STRD_GRP_IDand a.STRD_ID = b.STRD_IDorder by a.STC_DT descindex 공부하기 전에는 못맞췄을 것 같은데, 지금은 2가지 문제가 보인다. 내가 생각한 답을 말하자면, 나는 인덱스를 2개 만들 것 같다. OOM_TRMS(b) 테이블에서(STRD_GRP_ID) or (STRD..

결합 인덱스에서 all equal 조건절에서는 칼럼 순서가 중요하지 않다인덱스 쪽에서 유명한 틀린 예제가 있다.SELECT 이름, 성별FROM 사원WHERE 성별='여자' AND 이름='유관순'위 예제에서 (성별, 이름) 인덱스를 사용하는 것과 (이름, 성별) 인덱스를 사용했을 때의 성능이 다르다는 것이다. 따라서 결합 인덱스에서 컬럼 순서가 중요하다는 것을 말한다. 그 이유는 사원 50명 중, 여자가 25명 유관순이 2명이라면(성별, 이름) 인덱스: 성별로 거르기(25명 남음) -> 이름으로 거르기(25명 중 2명만 남기기)(이름, 성별) 인덱스: 이름으로 거르기(2명 남음) -> 성별로 거르기(2명 중 2명 남음)위 순서로 필터링하기 때문에 B-Tree를 타고 내려가면서 필터링하는 수가 줄어들어 (..

뇌피셜 주의!이 글은 이 책을 읽고 느낀 개인적인 생각을 적은 글입니다. 곧이 곧대로 믿지 말아주시고, 틀린 내용이나 의견 있으면 자유롭게 남겨주세요 :)NoSQL Distilled최근 읽은 책중에 재밌게 읽은 게 있어서 소개해 보려고 가져왔다. 크게 1부(기본 개념)와 2부(적용)로 나뉘어 있는데, 2부에서는 각 NoSQL 제품군들의 종류에 대한 간략한 소개가 들어있다. 정말 간략한 소개이기 때문에 1부만 보아도 충분할 것 같다. 그렇기에 이번 내용에도 거의 1부 내용만 소개하려고 한다. 내가 재밌게 읽었던 부분들은 다음과 같다. - NoSQL의 등장 배경과 특성  - aggregate data model의 특성- 일관성 / 분산 모델 / 맵 리듀스- 스키마 관련 이 책을 읽고나서 원래 가지고 있던 ..

문제 상품 전시(display)쪽이라 호출이 엄청 많기도 하고, 상품 보여줄 때마다 이 상품이 특정 상태의 상품인지 확인해야 하는 로직이 있다. 그 특정 상태는 PM분이 상태를 등록할 수 있도록 slack 메시지로 등록할 수 있게 만들어 둔 상태고, redis에 올려놓고 쓴다. 그런데 그 특정 상태를 체크하기 위해 매번 redis에 찌르면 redis 호출하는 횟수가 너무 많을 것 같아, client를 싱글톤 인스턴스로 만들고, 프로세스 전역에서 그 인스턴스만 쓰도록 구현을 해놓았다. class _SpecificGoodsRedisClient: def __init__(self): self._cached_specific_goods_list = [] def get_cached_spec..

엄밀히 말하면 내 업무는 아니긴 한데, 다른 분 리뷰를 봐주다가 COUNT 쿼리가 엄청 느린 케이스가 있었다. 상품에 대한 리뷰 보여주는 방법을 변경하는 실험이었다. 다른 경우에는 괜찮은데, 상품에 대해 리뷰가 많을 경우 리뷰에 대한 COUNT가 너무 느려지는 케이스가 있어 문제가 되었다. 대략 리뷰 수가 N만개가 넘어가면 느려지는 걸로 보였다. 이걸 어떻게 풀까 고민하면서 일단 1. 캐싱 2. 인덱스 3. 쿼리튜닝 정도가 생각났다. 그런데 리뷰 수가 많은 거면 인기 상품이라는 의미라 리뷰가 얼마든지 더 달릴 수 있는 거고, 리뷰 프로세스가 존재해서 특정 상태의 리뷰들만 사용자에게 노출하다 보니 캐싱하기 어려워서 어째저째 쿼리를 다시 짜는 걸로 해결했다. (기존 쿼리에선 DISTINCT 때문에 임시 테..