[책 후기] SQL레벨업 리뷰 및 정리

아직 다 읽지는 않았지만 꽤 잘 읽고 있는 SQL레벨업이라는 데이터베이스 책을 소개해보려고 합니다. 개인적으로 내용이 좋아서 읽은 곳까지 간단히 정리해보고 후기를 남겨보겠습니다.

 

 

[목차]

1. 책 소개
2. 기억할 내용
3. 마치며

---

 

1. 책 소개

 

데이터베이스 아키텍처와 SQL 기능과 성능에 관한 내용을 담고 있는 책입니다. 

우선 데이터베이스에 흥미가 많이 없었기 때문에 두꺼운 책을 엄두도 못 내고 있었는데요.

한 2년 전 쯤인가.. 얇고 깔끔한 표지에 쉬워보인다고 덜컥 샀었습니다.

그러나 당시 내공으로 결코 쉽게 읽히지 않아서 초중반에 덮어버린 기억이..

 

그리고 시간이 지나서 최근 11월 초부터 시간날 때마다 조금씩 읽고 있습니다.

다시 읽으니 꽤 잘 읽히고 배워가는 재미가 있습니다.

 

아키텍처, 결합(JOIN), 인덱스, 서브쿼리 등 요소별로 예제와 실무 팁들을 잘 담은 것 같습니다.

 

미크라는 일본인 DB엔지니어가 쓴 책인데 번역도 괜찮은 편이네요.

 

3분의1정도 남기고 좀 안 읽히는데 11월 끝나기 전에 다 읽고 제대로 정리를 해보고 싶네요.

 

다른 데이터베이스 책을 많이 안 봤지만 이 책을 읽고 다른 데이터베이스 책을 읽으면 

꽤 도움이 될 것 같습니다.

 

 

SQL 레벨업 | 미크 - 교보문고

 

 

2. 기억할 내용

 

책 내용의 22강까지 기억할 내용들을 간단히 정리해봤습니다.

 

• DB는 성능향상을 위해 저장소 이외에 메모리에 일부 데이터를 올려서 사용함
• 데이터를 유지하기 위한 메모리는 크게 데이터 캐시, 로그 버퍼
• 데이터 캐시는 조회(SELECT)용 캐시, 로그 버퍼는 갱신(INSERT, UPDATE, DELETE)용 캐시
• 추가적인 메모리 영역 '워킹 메모리'는 정렬(ORDER BY, 집합연산, 윈도우 함수), 해시관련처리(결합 등)에 사용
• 오라클에서는 워킹메모리 명칭이 PGA(Program Global Area)
• 워킹 메모리 부족시 저장소의 임시영역에 I/O 발생하며 접근 속도 느려짐(TEMP탈락 현상)
• 쿼리 처리 흐름(쿼리평가엔진)
  • 파서에서 구문 분석 → 옵티마이저에서 실행계획 작성 후 선택(이때 옵티마이저에게 중요 정보는 카탈로그매니저가 제공. 테이블 또 는 인덱스 통계 정보) → 플랜평가(옵티마이저가 세운 최적의 실행계획 선택)
• 쿼리평가엔진의 카탈로그매니저 통계 정보는 DB엔지니어가 항상 신경써줘야함. 극단적으로 레코드 0개 상태의 카탈로그 정보를 저장 후, 이후 1억 건 데이터 올리고 카탈로그 정보 갱신 안 하면 옵티마이저는 0개 레코드 기준의 카탈로그 정보로 플랜 생성
• 카탈로그 매니저에 있는 통계 정보는? 각 테이블 레코드 수, 각 테이블의 필드 수와 필드 크기, 필드의 카디널리티(값의 개수), 필드값의 히스토그램(어떤 값이 얼마나 분포되어 있는가 등
• GROUP BY를 사용하지 않고 집계 함수를 쓰는 것은 전체를 하나의 그룹으로 그룹핑하는 것
• 윈도우함수는 집약기능이 없는 GROUP BY 구이며 성능에도 중요
• 조건분기는 UNION, CASE를 사용해서 가능. UNION은 SELECT구문 실행횟수가 많아지기 때문에 I/O비용이 높아 성능적으로 거의 좋지 않음
• 결합(JOIN)알고리즘은? Nested Loops, Hash, Sort Merge(Merge join) 크게 3개.
• Nested Loops가 결합 기본 알고리즘이고 MySQL은 Nested Loops 알고리즘밖에 없음. 중첩 반복을 사용함. 구동테이블의 레코드 개수가 적고 내부 테이블 결합키에 인덱스가 존재하면 성능 좋음(내부테이블 레코드 히트 수 많으면 안 좋음). 메모리 소모가 적기 때문에 OLTP에 저합
• Hash는 작은 테이블 스캔 후 결합키에 해시함수를 적용해서 해시값으로 변환. 이어서 큰 테이블을 스캔해서 결합키가 해시값에 존재하는지 확인하며 결합. 작은 테이블에서 해시 테이블을 만드는 이유는 해시테이블이 워킹메모리에 저장되므로 조금이라도 작은 것이 효율적이기 떄문. 그래서 Nested Loops에 비해 메모리 크게 소모
• Sort Merge는 양쪽 모두 정렬 후 결합. 그래서 메모리 소모 큼. 테이블 정렬을 생략할 수 있는 예외적 상황에서 쓸만함
• 서브쿼리는 실제적인 데이터를 저장하고 있지 않기 때문에 접근할때마다 SELECT구문 실행해야 함. 그리고 연산결과를 어딘가에 저장해둬야하기 때문에 데이터 양이 크면 저장소에 쓸 때도 있음(TEMP탈락의 일종)
• 서브쿼리는 또한 구조적으로 테이블과 비슷하지만 인덱스 등 메타정보가 없음. 최적화 불가.
• 서브쿼리는 코딩시 편하긴 함. 그래서 생각의 보조도구로 사용하기.
• 저장소 I/O를 줄이는 것이 SQL튜닝의 가장 기본 원칙

 

 

3. 마치며

 

사실 실무의 복잡한 쿼리에 적용하면 적용이 쉽지 않겠지만 튜닝의 기본은 알아야 제대로 튜닝할 수 있기 때문에 이번 기회에 읽기를 잘 한 것 같습니다.

 

그리고 JPA로 쿼리를 손쉽게 생성할 수 있지만 JPA 역시도 SQL을 위한 빌더 역할을 하기 때문에 SQL 성능 개선 방법을 알아둬야 JPA 사용도 좀 더 효율적으로 할 수 있을 것 같다는 생각이 드네요. 최근에 JPA 학습을 했는데 이 책과 읽기에 좋은 시기였던 것 같습니다.

 

나머지 22강 뒷 내용도 조만간 정리해서 올려보곘습니다.

 

감사합니다!