보라코딩
WW25 본문
240617
- Jeager vs Zipkin 분산 모니터링 서비스 비교
- interface 테스트코드 (minio)
- watcher 코드리뷰 요청함
ㄴ 수정 중...
ㄴ 서비스에 있는 메서드를 domain으로 옮겨서 코드 깔끔하게!
ㄴ 도메인은 pojo class로 구성!!! 중요!!!
ㄴ 도메인에 비지니스 로직이 들어가게!!!!
240618
- watcher 코드 리뷰 중...ㅎㅎㅎ (Map구조 List로 다시 변경)
- jpa 연관관계 편의 메서드
240619
- 리팩터링 : 도메인(pojo class로 의존성 없게)에 비지니스 로직 들어가게하고, 도메인 구성을 잘 해야 한다...!
- allocationSize : 시퀀스 한 번 호출에 증가하는 수(성능 최적화에 사용)
ㄴ allocationSize를 50으로 설정하면 한 번의 호출로 50개의 연속된 시퀀스 값을 얻을 수 있습니다. 매번 데이터베이스에 접근하는 빈도를 줄이고 성능을 향상시킬 수 있습니다.
ㄴ batch size도 동일하게 50으로 관리하면 좋다!
240620
- min io 테스트코드 완료
- MySQL 스터디
- 디스크 I/O 최소화:
- SSD 사용을 권장: SSD는 주소 기반 데이터 접근으로 디스크 I/O를 줄여 쿼리 응답 시간을 단축시킵니다.
- 데이터베이스 캐시 활용: 메모리에 자주 접근하는 데이터를 캐시하여 디스크 I/O를 줄입니다.
- 인덱스 최적화:
- 적절한 인덱스 사용: 필요한 검색 조건에 맞는 인덱스를 생성하여 쿼리 성능을 개선합니다.
- B+Tree 인덱스: 작은 데이터셋에서 유리하며 범위 검색에 적합합니다.
- B-Tree 인덱스: 대용량 데이터에서 좋은 성능을 발휘합니다.
- 인덱스 클러스터링:
- 주요 검색 조건에 인덱스 클러스터링을 사용하여 성능을 향상시킵니다.
- 인덱스 클러스터: 테이블의 주요 검색 조건을 기반으로 클러스터링된 인덱스를 사용하여 데이터 접근 속도를 높입니다.
- 인덱스 논클러스터: 외래 키(FOREIGN KEY)와 같은 보조 인덱스를 사용하여 연산 효율을 높이는데 유리합니다.
- 쿼리 최적화와 힌트:
- 옵티마이저 활용: MySQL 옵티마이저를 사용하여 쿼리 실행 계획을 최적화합니다.
- 쿼리 힌트 사용: /*+ hint */와 같은 형태로 힌트를 제공하여 옵티마이저가 자동으로 선택하는 최적의 실행 계획을 변경할 수 있습니다. 예를 들어, 인덱스 사용을 강제할 수 있습니다.
- 16KB 디스크 블록 크기:
- 하드 디스크의 블록 크기가 16KB라는 것은 한 번의 입출력 작업(I/O)에서 처리할 수 있는 데이터 양을 의미합니다.
- SSD는 랜덤 접근이 빠르기 때문에 디스크 블록 크기가 크게 중요하지 않지만, 하드 디스크의 경우 랜덤 접근이 느려질 수 있습니다.
- 인덱스와 범위 스캔:
- 인덱스를 사용한 범위 스캔을 통해 효율적인 데이터 접근을 가능하게 합니다.
- IN 절보다는 범위 조건을 사용하여 쿼리 성능을 최적화할 수 있습니다.
이러한 기법들을 통해 MySQL 데이터베이스의 성능을 향상시키고, 시스템이 예상된 부하를 처리할 수 있도록 준비할 수 있습니다.
240620
- watcher 서비스 (FTP 데이터 4만건, DB 6만건 비교해보기 -> 속도체크)
- interface refactoring