디스크에 대한 엑세스 설명(순차/랜덤) 그리고 랜덤 엑세스의 횟수를 줄이는 것이 바로 쿼리 튜닝의 대부분이라는 것!
B-Tree 기반의 인덱스 생성/변경/삭제에 대한 개론
인덱스의 설계와 사이즈는 전반적인 읽기 성능에 많은 부분 영향을 줌. 인덱스 사이즈가 커지면 커질수록 페이지 사이즈도 커지고 그에 따라 B-Tree에서의 뎁스가 깊어질 여지가 있음.
인덱스는 정렬된 상태로 생성. 인덱스의 스캔 방향은 옵티마이저에 의해 역순도 가능하나 기본적으로 인덱스 생성 자체는 MySQL에서는 정순(오름차순)을 기준으로 함.
MSA와 같은 업무 환경에서…
다른 팀과의 인터페이스에서 늘 고려해야 할 부분을 놓쳐서 운영상의 큰 이슈까지는 아니었지만 아주 소수의 고객들이 동시성 이슈를 겪었음
발단은 페이지에서 시작한 Double-Click(따닥)이지만(웹뷰가 따닥과 함께 중첩되서 노출, 고객은 따~~~닥 느낌으로 트랜잭션을 시작) 타 팀과의 인터페이스에서 발생하는 동시성 이슈로 인해 락을 고민할 수 밖에 없었음
데이터베이스 레벨의 락은 늘 고려 대상에서 마지막 우선 순위라 가장 뒤로 미뤄뒀고 우선 고려해볼 수 있는 선택지가 바로 Atomic 연산자를 제공해주는 Redis를 고려. Redisson이라는 클라이언트를 업무에서 사용중인데 분산락 구현체를 제공해주기 때문에 해당 부분을 사용하는 것도 고려해봤고 SETNX와 같은 연산자를 사용하는 것도 고려해보고 있다. 인프라스트럭쳐적인 방어 장치와 더불어 인터페이스하는 타팀에서 다행히 Pre-Validation 성격의 API를 제공해주고 있어서 그거도 호출하여 확인하는 방법까지 같이 고려를 해보고 있는 중이다.
아주 작은 이슈긴 하지만 MSA 환경으로 가면 갈수록 이거보다 더 큰 이슈들은 산재하게 될텐데…과연 도메인을 잘찢어놓고 팀을 그거에 맞게 잘 구성했는지도 늘 고민