내 공부

어이 너, 내 삽질 볼래?

Java의 Integer... 익숙한 놈에게 당했던 경험

우선 Kafka Broker가 Kafka Client(컨슈머)가 살아있는지 확인하는 방법에 대해 알아보자.

다들 이미 익숙해져버린 에러 메시지들이 있을것이다. 특정 타이밍에 온다던가, 같은 API에서 이따금씩 한번만 발생한다던가 등등의 사유로 무감각해지는 에러들이 있다. (그러면 안되지만 🥲)요청 빈도가 높은 조회 API중 하나가 일주일에 한두번 정도 500 에러를 내뱉는

인덱스를 적용해보자 인덱스를 적용해도 생각만치 성능이 개선되지 않는다. Order By에 계산된로직이 들어가면서 인덱스를 충분히 활용하지 못함 Group BY와 정렬의 기준이 겹치는 부분이 많지 않다. Where 조건이 인덱스 커버리지에 포함되지 않는 상황

지난 1편에서는 브로커가 컨슈머가 죽었는지 알기위해서, 어떻게 살아있는지 확인하는 방법에 대해 알아봤었다. 이번편에서는 컨슈머가 종료될 때 어떤 동작을 하게되는지 한번 살펴보고자 한다.

배경 1편과 2편을 통해서 컨슈머가 종료되었을 때 컨슈머 서비스와 브로커에서 일어나는 일련의 동작들에 대해서 알아봤다. 이 과정에서 디버깅 시 겪었던 자동컨슘(?) 상황도 이해할 수 있게 되었다. 이번엔 반대로 그러면 컨슈머가 생겨났을 때, 컨슈머 서비스와 브로커에선

서비스 아키텍처에서 Application과 DB는 필수 구성 요소다. Application으로 요청이 들어오면, 대부분의 경우 SQL이 DB로 전달된다.그렇다면 DB는 이 SQL을 어떻게 실행할지 어떻게 결정할까?

앞서 MySQL 옵티마이저가 실행 계획을 세우는 과정을 살펴봤다. 옵티마이저는 통계 정보(Cardinality)를 기반으로 여러 실행 계획 후보 중 가장 비용(Cost)이 낮은 계획을 선택한다고 했다. 그렇다면 더 깊이 들어가보자.