WW30

240722

- 오후에 유해화학물질 교육 (1시부터 4시)
- 그라파나 부분 env 추가해서 작성

 

 

240723

 

- mysql 스터디(성능 최적화)
- 로키, 프롬테일로 그라파나 연동 완료! (알람까지??)

- 시간대 안맞아서 도커파일에 추가 필요!! (ENV TZ=Asia/Seoul)

- rolling file 조건 변경 필요

 

240724

- 그라파나 마무리
- zipkin 으로 분산추적할건데 사실 aws cloudwatcher이 있어서 그리 중요치는 않다.

 

 

240725

- zipkin 도커로 띄우고 각 서비스랑 연동하고 로그 변경해서 zipkin UI로 확인 가능
- 다만 kafka는 trace Id랑 span Id가 안뜨나..?


---------------- MySQL 스터디(성능 최적화) ---------------
- 옵티마이저가 인덱스 있는 것을 항상 Driven table로 선택
(인덱스 없는게 테이블이 작을 수도 있으니 변경하고 싶으면 hint 사용)

- sql 순서 : from join where group by having order by limit

- 다대다는 join 필요 없음

- hash join은 hash buffer 사용해서 순서가 아주 정확하지 않아. 순서 중요하면 order by를 꼭!

- 서브쿼리를 FROM 절에 사용하면, 데이터베이스는 이 서브쿼리를 먼저 실행하여 결과를 임시 테이블로 생성합니다. 이 임시 테이블에 대해 다시 쿼리를 실행하게 되므로, 성능이 저하될 수 있습니다.

- in 절에 서브쿼리 쓰면 안좋아. inner join으로 변경

- SQL에서의 "cost"는 쿼리 실행에 필요한 자원의 추정치로, 시간, I/O 작업, CPU 사용량, 메모리 요구 사항 등을 포함
 
- UNION은 두 결과 집합을 결합하고 중복된 행을 제거
- UNION ALL은 중복을 제거하지 않고 모든 결과를 반환합니다. 따라서 UNION ALL이 더 빠름

- select에 파티션 쓰면 빠르다

- Repeatable Read: 트랜잭션이 시작된 후부터 종료될 때까지, 트랜잭션이 읽은 모든 데이터를 동일한 상태로 보장함. 팬텀 리드(트랜잭션이 진행되는 동안 다른 트랜잭션에 의해 새로운 행이 삽입되거나 삭제되어, 동일한 쿼리에서 결과 집합이 달라지는 현상)는 발생할 수 있지만, 동일한 데이터에 대한 반복적인 읽기는 동일한 결과를 반환함
- Serializable: 가장 엄격한 격리 수준으로, 모든 트랜잭션이 순차적으로 실행된 것처럼 동작합니다. 팬텀 리드, 더티 리드, 반복 읽기 문제를 모두 방지함. 높은 무결성을 요구하는 환경에서 사용되며, 성능에는 부정적인 영향을 미칠 수 있습니다. MS SQL Server에서 자주 사용됨

 

 

240726

 

- Zipkin 에러 해결 중 (스프링부트3과 micrometer 간의 문제로 보임)
   1. feignClinet로 다른 서비스로 보낸 것의 trace id가 불일치함
   2. 카프카에서 trace id와 span id가 생성되지 않음