생각해보기

DB 와 I/O 데이터베이스의 성능 튜닝은 어떻게 디스크 I/O를 줄이느냐가 관건일 때가 많다. 쿼리 튜닝은 꼭 필요한 데이터만 읽도록, I/O를 줄이는 방향으로 쿼리를 개선하는 것을 의미한다. SSD는 디스크 원판을 기계적으로 회전할 필요가 없어 HDD 보다 빠르게 읽고 쓸 수있다. SSD는 순차 I/O 도 HDD보다 빠르지만 랜덤 I/O에서 훨씬 빠르다. 성능 옵션에서 SSD도 고려해 보자. (SSD 초당 436, HDD 초당 60개 트랜잭션 처리) 디스크의 성능은 얼마나 많은 데이터를 한 번에 기록하느냐에 결정 될 수 있다. 따라서 빈번하게 읽고 쓰는 랜덤 I/O 보다, 순차 I/O가 빠르다. 인덱스 DBMS에서 인덱스는 데이터의 저장성능을 희생하고(일관성 정렬을 유지해야하기 때문에) 그 대신 데이..

Mysql의 잠금이 무엇이 있는지 확인해보고 싶었습니다. Mysql에서 사용되는 잠금은 크게 스토리지 엔진 레벨과 Mysql 엔진 레벨로 나눌 수 있습니다. Mysql 엔진 레벨의 잠금은 모든 스토리지 엔진에 영향을 미치지만, 스토리지 엔진 레벨의 잠금은 스토리지 엔진 간에 영향을 미치지 않습니다. Mysql 엔진 레벨의 잠금은 다음과 같습니다. 글로벌 락 Mysql에서 제공하는 락 중에 가장 범위가 큽니다. 한 세션 에서 글로벌 락을 획득하면 다른 세션에서는 조회를 제외하고 락이 해제 될 때 까지 대기 해야 합니다. 테이블 락 개별 테이블 단위로 설정되는 락입니다. 스키마를 변경하는 DDL의 경우 테이블 락이 설정됩니다 네임드 락 임의의 문자열에 대해 잠금을 설정할 수 있습니다. 여러 서버를 동기화 해..

mysql의 서버는 크게 mysql 엔진과 스토리지 엔진으로 구분할 수 있습니다. mysql 엔진의 역할 사람으로 치면 머리에 해당하는 역할입니다. 쿼리를 파싱하고 쿼리를 최적화 하여 sql을 실행합니다. 스토리지 엔진의 역할 사람으로 치면 손과 발에 해당하는 역할입니다. mysql 엔진이 커넥터를 통해 스토리지 엔진에게 데이터 읽기/쓰기 명령을 보냅니다. 스토리지 엔진은 해당 명령을 수행합니다. 대표적인 스토리지 엔진은 InnoDB가 존재합니다 MySQL의 특징 중에 대표적인 것은 플러그인 모델입니다. 각각의 기능들을 플러그인 형태고 개발해서 사용할 수 있습니다. 따라서 사용자는 기본적인 기능 이외에도 부가적인 기능을 위해서 직접 개발을 할 수 도 있습니다. 대표적으로 스토리지 엔진에서는 InnoDB,..

jpa에서 쿼리 등록이 어떻게 되고, 어떻게 관리되는 지 궁금했습니다. jpa 내부를 살펴보겠습니다. JpaRepository가 호출될때 jdkDyamicAopProxy를 통해서 여러개의 interceptor를 체인 형태로 호출하게 됩니다. 체인 형태로 호출 할때 ReflectiveMethodInvocation을 사용합니다. // ReflectiveMethodInvocation @Override @Nullable public Object proceed() throws Throwable { // We start with an index of -1 and increment early. // 사용되는 interceptor는 순차적으로 interceptorsAndDynamicMethodMatchers에 등록됩니..

서블릿과 필터는 Java EE(enterprise edition)을 스펙을 기반으로 합니다. 기존의 filter를 등록하는 표준 방식(ex. web.xml 설정)에서는 서블릿 컨테이너에 의해 직접 관리됩니다. 따라서 서블릿 컨테이너가 직접 관리하는 필터는 스프링 애플리케이션 컨텍스트 내에서 정의하는 빈들을 인식하지 못합니다. 따라서DelegatingFilterProxy를 통해 스프링 빈으로 요청을 위임합니다. DelegatingFilterProxy는 FilterProxy(FilterChainProxy)구현체를 찾아 위임합니다. // DelegatingFilterProxy.java @Override public void doFilter(ServletRequest request, ServletResponse..

conda 와 virtual env에서 requirement.txt를 추출하다 보니, 이전에 실험용으로 다운 받은 의존성도 실수로 같이 받아져서, requirement.txt 가 커지고 빌드 시간이 나는 문제가 있었습니다. 또한 더 좋은 편의성을 갖추고 싶었습니다. 편의성 측면에서 원했던 것은 크게 2가지 였습니다. 첫번째는 모듈을 받을 때 어떤 모듈에 의존성을 가지는지 궁금했고, 의존성 트리를 보고 싶었습니다. 두번째는 test와 dev, local 등으로 group을 나누어 의존성을 관리하면 의존성을 보기 쉽고 안전하게 만들고 싶었습니다. 이러한 이유로 poetry를 도입하게 되었고, poetry에 대해서 간략한 설명과 어떻게 사용되고 있는지 공유하겠습니다. poetry란? poetry는 파이썬 의존..