대머리개발자

R2DBC는 여전히너무 단순한 형태의 API만 제공하기 때문에  페이징 처리를 위해서는 네이티브로 작성해야 한다. @Query( """ SELECT id, action, amount, regDt FROM Product WHERE userId =:userId ORDER BY regDt ASC LIMIT :pageIndex, :pageSize """ ) fun searchPointByUserId(userId: String, pageIndex: Int, pageSize: Int) : Flux ⭐⭐ 객체를 인자로 받아서 깔끔하게 바인딩 해볼라고 했더니...역시나. ㅋ 뭐 일단 낱개로 넘..

3천Row 밖에 안 되지만 본문 컨텐츠가 무거워 export할 때 용량은 거의 1GB에 육박했다. 현재 서비스를 이용하는데는 크게 문제는 없으나 추후 테이블의 구조가 변경될 때 이슈가 발생할 여지가 있기 때문에 이미 그런 경험을 맛 보았기 때문에 분리하려고 한다. 또 한편으로는 굳이(?) ㅡㅡㅋ 유비무환이다. 본문의 내용을 별도 테이블로 관리하기 때문에 장점을 또 굳이...이야기해보면. 1. 버전관리가 가능하다. 2. 메인테이블이 가벼워진다. 다시 말해 확장이 필요할 때 부담이 없어진다. 단점. 1. 관리 포인트가 많아진다. 2. 성능 문제가 예기치 못하게 발생할 수 있다. 본문이 컨텐츠가 더 커지면..파일로 관리해보자 ㅋ 가즈아!

https://hcnmy.tistory.com/153 mysql json type 최고의 장점은 JSON은 비정형 데이터를 저장하며, 컬럼 스키마 변경 없이 새로운 필드를 추가할 수 있는 유연성을 제공합니다. 즉, 몽고디비처럼 사용할 수 있다 근데 막상 적용하려고 보니 해도 hcnmy.tistory.com 같은 고민의 반복이다. 이벤트의 속성은 이벤트마다 다르기때문에 고민했던 부분이다. 게시판의 경우도 게시판의 성격에 따라 데이터가 조금씩 다르다. 이번 CASE의 선택은 확장속성 테이블의 구현이다. create table if not exists extendAttr ( id bigint PRIMARY KEY comment 'board ID', `key` varchar(100) not null commen..

JPA 마이그레이션하면서 쿼리 자체에 대한 response가 맘에 들지 않았다. 100ms 이내로 만들고 싶다...가즈아!! ★ ★ ★ 1 -> 2 번째 단계는 서브 쿼리를 조인쿼리로 변경스 ★ ★ ★ ★ ★ 2 -> 3 번째 단계는 범위 축소다. 인덱스도 조져보고 이것저것 try 해봤지만...미미하다. 댓글, 조회수, 좋아요, 기타 등등 가져오는 "무거운 작업"을 하는데 정확히!! 페이징 데이터만큼 하는 것이다. 결은 전체를 대상으로 무거운 작업을 하는 것이 아니라 limit 0, 20 된 결과만 작업!!s 1번째 code -> 164ms .. 생략.. https://hcnmy.tistory.com/178 querydsl로 마이그레이션 nativeQuery로 작성된 쿼리를 querydsl 형태로 변경하..

nativeQuery로 작성된 쿼리를 querydsl 형태로 변경하고자 한다. why? 새로운 기획요건에 대응이 안 된다. 물론 새로운 end-point로 만들면 되는데 기존 쿼리에 단순 조건절 추가임에도 중복 코드가 산더미처럼 만들어진다. 물론 mybatis로 했으면 고민도 안 했을테쥐... ## 고민의 포인트는 아래 두가지에 대한 클린 쿼리 작성 1. 통계 데이터 조인을 How -> querydsl (방법상) left outer join ( select targetId, SUM(if(type = 0, 1, 0) ) as viewCount ,SUM(if(type = 1, 1, 0) ) as goodCount from countstat c group by targetId 2. 각종 서브쿼리를 조인쿼리로 ..

DB 컬럼의 타입도 ENUM을...와우...진작 이야기를 해줘야제..이미 한참 전에 있었겠지만 이제서야 알앗네.. create table if not exists Point ( id bigint AUTO_INCREMENT PRIMARY KEY comment 'ID', userId varchar(32) not null comment '사용자 ID', amount INT NOT NULL, actionType ENUM('EARN', 'REFUND', 'SPEND') NOT NULL, status ENUM('ACTIVE', 'EXPIRED') default 'ACTIVE' not null comment 'point 상태', regDt datetime default current_timestamp() not nu..

기본적으로 DB를 통해서 처리할 수 있으면 그것이 가장 best practice일 듯 하다. 이벤트 대상자의 정보를 "비지니스 로직"으로 옮겨와 작업하게 되면 리소스(메모리)의 부하가 발생할 수 있다. 이벤트 Size가 작은 경우는 크게 문제될 부분은 없을것 같지만 몇 십만명 단위라면....그런거 해보고싶당. 다행히도 MYSQL은 rand() 함수를 제공해 준다. rand()함수는 0 ~ 1 사이의 유리수를 랜덤하게 출력해 준다. 출력된 값을 그대로 order by해서 줄을 세우면 된다. 딱 끝..고민없이 하면 되는데... 중복으로 참여한 사용자 위주로 추첨될 수 있도록 요청이 왔다. 전체 무작위로 뽑아도.. 참여를 더 많이 했으니 다른 사용자보단 (참여횟수) / (전체 대상자) 만큼의 확률이 올라간다...

모듈별 디펜더시가 없으면 좋긴 하지만 너무 쪼개면 관리가 포인트가 그 만큼 늘어나서...지친다. ㅋ 적당히 MSA 하자 각각의 모듈에서 레디스를 직접 호출하는 것보다는 일렬종대 헤쳐모아를 위해서 작업을 진행했다. 인증서버는 implementation 'org.springframework.boot:spring-boot-starter-data-redis-reactive' 레디스 서버는implementation 'org.redisson:redisson-spring-boot-starter:3.19.3' 인증서버에서 박아 넣은 데이터를 레디서 서버에서 꺼내려고 보니깐. 띠로링..com.esotericsoftware.kryo.KryoException: Encountered unregistered class ID: ..