sentry 관련 : 그레이로그 graylog

쿼리dsl로 어떻게 패치해오는 것이냐 이런 것이 중요

@Value 다큐맨트를 사용하는 것은 괜찮음 yml 에서 값들을 따로 관리를 해서 서비스 레벨에서 한줄 또는 두세줄로 압축을 할 수 있을 것 같다. get element by tag name enum으로 관리하기 document를 굳이 써야하느냐 xml로만 지원 xml을 dto객체로 한번에 받고 entity로 받아올 때 mapping해서 entity에는 영향을 주지 않는 방식 한꺼번에 바로 가는 것이 아니라 단계를 나눠놓는 방식 json방식으로? 데이터 포맷이 xml이고 object를 한번에 받아오는 방식이 있을 것이라고 생각 https://ryan-han.com/post/java/xml_to_java_object/ 더 많아지면 라이브러리를 사용하는 것을 고려해 볼 수 있음 우선순위가 높아보이지는 않음

write하는 동시에 read를 해야하기 때문에 stateless를 사용하여 ! 만약 막고 싶으면 lock을 걸어야 함 service 사용자가 감안을 해야함 .. 동시성 이슈가 거의 발생하지 않을 것

db병목이 엄청나게 생김 - 해결하기 힘듬 데이터를 조작하는 것은 application에서 하기 쿼리가 너무 복잡함 서비스 레벨에서 하는게 맞다고 생각함 db에서는 데이터만 가져오고!

쿼리dsl로 구성을 하면 더 편함 sql로 짤 수 있음 https://steady-coding.tistory.com/589 named ?? 패턴이 이렇게 붙였다 뗏다 하는 경우에는 쿼리데쎌 쓰는게 맞음

컴파일 시점에서 문제가 있는지 바로 알 수 있다. sql을 쓰면 날릴 때가 되어야 알 수 있음

매우 효율적임

db로 관리하기! (1) 절대 변하지 않는 값은 static하게 (2) 25개의 구가 변경되지 않을 확률이 매우매우 높 (3) 서비스를 운영하고 있는데 실시간으로 반영을 해야하는 상황

DB에 row만 하나 넣어주면 되는 것 / 변경될 가능성이 있는지 / 실시간으로 반영이 되어야하는지 / 프로젝트에 박혀서 관리하면 관리가 제대로 안됨.

~ N+1 문제 디버깅 해보기 ! stack trace를 타고 들어가보는 방법이 있음 JPA의 hibernate가 어떻게 데이터를 가져오는지 알아볼 수 있음 작동원리가 어떻게 되는지를 파악해 보는 것이 중요 꽤 복잡. 직접 돌려보기! F7을 눌러서 계속 들어가 볼 수 있을 것이다.

한번 다녀오고 나서 데이터를 다 가져오고 싶으면 Eager로 바꿔야 함 eager로 관리할 때의 문제점을 파악해야함 hibernate 에서 미세하게 조정가능함.

distinct의 기준이 되는 애가 있을 거임 그룹바이의 키가 무엇이냐에 따라 달라질 것. 판단 기준이 있을 것이다. 그럴수도 있고 아닐 수도 있다. 디버깅 해보기

저장되는 순서가 db에서 가지고 올때 아이디 순서대로 보야주고 싶다. 객체를 다 보니까 id가 정상적으로 들어가 있고 가지고 올때 순서대로 못가지고 온다는 말. why? fetchjoin을 해오는데 왜 제대로 못가지고 오지? leftjoin을 안하면 태그 없는 포스트를 못가져옴 list자체를 저장하는 데에 db 특성도 봐야하고 jpa특성도 봐야함 order by 자체를 빼고 service에서 정렬 db의 부아를 최대한 줄이고 객체 하나하나를 조회해서 stream을 쓰든 뭘 쓰던 해갖고 정렬하기 ! 데이터 가져오는 부분이 가장 의심스러움