Official-Dev. blog

서비스를 운영하다보면 Redis, MySQL, Mongo, ElasticSearch 등 다양한 DB를 사용해야 할 일이 생긴다.MySQL을 위한 MySQL-Workbench, MongoDB를 위한 MongoDB-Compass 등 다양한 도구를 익히면 중간에 컨텍스트 스위칭이 안되는 경험을 많이 했다.JetBrains DataGrip을 사용하면 대부분 종류의 DB를 동일한 도구에서 관리할 수 있어서 많이 사용한다.Redis 지원DataGrip 2022.3 이상 버전부터는 Redis 조회도 지원한다.해당 기능을 사용하면 아래와 같이 Redis 데이터도 편리하게 조회하거나 명령어를 수행할 수 있다.아래와 같이 코드 자동완성 기능도 있어서 Command를 사용할 때보다 확실히 편리한 것 같다.도구에 너무 익숙해..

파티션을 사용할 때 고려할 부분합류한 새로운 팀에서는 파티셔닝을 적극적으로 사용하고 있었다.Partitioning(파티셔닝)은 논리적으로 하나의 테이블이지만, 물리적으로는 여러 개의 파일 시스템에 분산하는 방법이다.파티셔닝은 테이블과 인덱스 모두 적용된다. 파티셔닝을 사용하는 이유는 다음과 같다.더 많은 데이터를 하나의 테이블에 저장할 수 있다.유용성을 잃은 데이터에 대해 특정 파티션을 제거하는 등 관리가 가능하다.검색에 대한 DB 부하를 감소하는 기능이다. (WHERE 절로 필요하지 않은 파티션은 자동으로 제외)아래 공식 문서를 기반으로 파티셔닝을 사용할 때 고려해야할 부분에 대해 알아보자.1. 인덱스(Index)파티셔닝을 사용할 때 고려해야 할 것이 있다. 바로 Index이다.파티셔닝을 사용할 때 인..

지난번 커버링 인덱스를 적용한 쿼리를 추가 개선한 이야기이다. 커버링 인덱스 적용 - https://jaehoney.tistory.com/333 지난번 조회 Latency가 너무 커서 커버링인덱스를 조회해서 2~3배, 최대 10배 효율적으로 개선을 할 수 있었다. 문제는 Latency는 큰 문제가 없음에도 TPS가 너무 안나왔다. HTTP 트랜잭션이 0.3s~0.4s 정도인 반면 TPS가 10.8 밖에 안나왔다. 결과를 먼저 소개하자면 LeftOuterJoin 구을 Split해서 TPS를 10.8에서 107.7로 개선했다. 아래는 문제 재현을 위해 임의로 구성한 환경에서 테스트를 진행한 부분이다. 기존 코드 먼저 기존 코드를 보자. @Repository public class ArticleReposito..

Optimizer가 원하는 Index를 사용했으면 최적의 쿼리인걸까?! 그렇지 않다! 예시를 통해 알아보자. 아래는 예시를 위해 생성한 Index이다. 아래의 쿼리를 실행시키면 어떻게 될까? explain select * from employees where office_id = 1 and money = 50; key로 custom_index가 선택되었다. 글자가 너무 작아서 중요한 부분을 확대했다. 실행 시간 해당 쿼리의 실행 시간은 548ms 이다. Index도 원하는 대로 탔고, 매우 간단한 데 쿼리임에도 불구하고 매우 오래걸린다. 뭐가 잘못된 걸까..? 1. key_len 다시 실행 계획을 보자. 여기서 가장 중요한 지표는 key_len이다. key_len은 쿼리 조건으로 사용된 인덱스 컬럼들의 ..

최근에 팀원 분이 LEFT OUTER JOIN의 ON 절에 일반 조건이 포함된 쿼리를 작성하신 것을 봤다. SELECT * FROM team t LEFT OUTER JOIN member m ON t.id = m.team_id AND m.team_id = 4; 해당 부분이 예상대로 동작하지 않을 것을 예상하고 리뷰를 드리면서, 생각보다 잘 모르시는 분이 많으실 것 같아 정리하게 되었다. 미리 말하지만 해당 SQL은 의도대로 동작하지 않는다. ON 절과 WHERE 절의 차이에 대해 알아보자. Sample Data 삽입 테스트를 위해 데이터를 삽입했다. Team을 5개 삽입 각 팀별 멤버를 2개 삽입 WHERE SELECT * FROM team t LEFT OUTER JOIN member m ON t.id =..

어느 날 신입 분이 나한테 찾아와서 물었다. '메일 조회를 할 때 권한이 없으면 404가 아니라 401 또는 403이 나와야 하는 것 아닌가요?' (인덱스 얘기한대놓고 무슨 권한 얘기인지..) 나도 쌩신입때 선배분께 동일한 질문을 했었다. 인덱스 오해 아래 코드는 비즈니스에서 Mail을 조회하기 위해 사용되던 코드이다. mailRepository.findByUserIdAndId(userId, id) .orElseThrow(() -> new EntityNotFoundException("Mail", id)); 여기서 내가 생각한 문제는 3가지가 있다. 쿼리에 비즈니스 로직이 들어간다. 가독성이 나빠지고 객체지향적인 설계가 불가능해진다. 프로그래밍 초식의 쿼리에서 로직 빼기 부분을 참고하자. 자신의 소유가 아..

개발 DB에는 데이터가 잘 저장되는데 실 서버 DB에서 데이터가 잘리는 문제가 발생했다. 확인해보니 문자열의 이모지 뒷 내용이 전부 잘린 것으로 확인해서 DDL을 각 DB의 DDL을 비교해봤다. (MySQL을 사용하고 있다.) 그런데 개발 서버 DDL과 실서버 DDL이 동일했다. 그런데 왜 데이터가 개발 서버에서만 잘렸지..? utf8 vs utf8mb4 개발 서버와 실서버의 컬럼은 모두 charset - utf8을 사용하고 있었다. utf8과 utf8mb4는 어떤 차이가 있을까? utf8 - 내부적으로 한 문자당 가변으로 최대 3바이트를 사용한다. utf8mb4 - 내부적으로 한 문자당 가변으로 최대 4바이트를 사용한다. 여기서 이모지는 4바이트를 차지한다. 즉 utf8mb4로는 표현할 수 있고, ut..

해당 포스팅에서는 Redis cluster에 대해서 다룬다. Sharding 일반적으로 샤딩을 할 때 아래와 같이 Hash-Based Sharding을 사용할 수 있다. 문제는 위의 경우 샤드가 하나 늘어날 때마다 기존 데이터들을 전혀 다른 곳으로 이동시켜야 한다. Redis(레디스)는 이러한 점을 해결하고자 HashSlot을 사용한다. Redis는 16384개의 Hash Slot으로 Key 공간을 나누어서 관리한다. 각 키는 CRC16 해싱 후 16384로 Modulo Op(나머지 연산)를 하고 Hash Slot에 매핑한다. Hash slot은 각 노드들에게 나누어 분배한다. 이러한 과정으로 인해 새로운 샤드가 추가되더라도 모든 데이터가 영향을 받지 않고 Slot이 겹쳐지는 일부 샤드의 데이터만 옮겨주..

1. 너무 큰 배열 문제 아래 카페 서비스의 데이터 모델링을 한 예시가 있다. db.cafe.insertMany([ { _id: 1, name: "IT Community", desc: "A Cafe where developer's share information.", created_at: ISODate("2018-08-09"), last_article: ISODate("2022-06-01T10:56:32.00Z"), level: 5, members: [ { id: "tom93", first_name: "Tom", last_name: "Park", phone: "000-0000-1234", joined_at: ISODate("2018-09-12"), job: "DBA" }, { id: "asodsa123"..

대용량 데이터 대용량 데이터의 기준은 뭘까? 일반적으로는 사람들이 다뤄보지 않은 데이터의 수준을 대용량 데이터라고 하는 것 같다. 그래서 회사마다 기준이 다르겠지만, 대용량 데이터의 기준은 1PB라고 말하곤 한다. MongoDB는 대용량 데이터를 위한 DB일까? MongoDB는 1PB의 데이터를 감당할 수 있을까..? MongoDB Atlas에서 어느정도 스펙까지 서버를 제공해주는 지를 보면 객관적인 수치라고 볼 수 있을 것이다. MongoDB Atlas에서 제공해주는 크기(조율이 가능) 중 가장 높은 스펙의 경우 RAM = 768GB, Storage(SSD) = 4096GB 이다. 즉 Storage는 4TB이고 기본 운영에도 스토리지가 사용된다는 것을 감안하면 300대가 있으면 1PB를 커버할 수 있다..