데이터베이스를 다루다 보면 필연적으로 성능 문제가 발생한다. 따라서 가능한 초기부터 성능에 대한 지식을 가지고 있어야 한다.
특정 처리의 시작부터 종료까지 걸린 시간을 나타낸다.
이 일괄 처리에 1시간이 걸렸다.
특정 처리를 단위 시간에 몇 건 처리가 가능한지를 나타낸다.
트랜잭션을 초당 50건 처리한다. = 50 TPS
중요한 점은 초, 분 같은 단위 시간의 지표가 없으면 '처리율'이 아니다.
150만 명이 이용하고 있다. ❌
연간 10만 명이 이용하고 있다. ⭕
처리율은 중요한 성장 지표로, 시스템의 자원용량을 결정한다.
동시 실행 처리 수가 많아질수록 처리율이 떨어지며, 필요로 하는 자원 수도 증가한다.
이 때 최초로 한계에 다다른 자원(시점?)을 버틀낵 포인트라고 한다.
이처럼 처리율과 응답 시간이 극단적인 저하를 시작하는 시점을 한계점이라고 한다.
이러한 정점을 생각해 자원을 확보하는 것을 '사이징' 혹은 '개퍼시티 플랜'이라고 한다.
정점이 주기적으로 일어나는 경우(ex:대학 수강신청)에는 어느정도 대비가 쉽지만 돌발적으로 일어나면 예측과 대응이 어렵고, 정점이 아닐때 자원 낭비가 심하다.
이런 돌발형을 대응하는 수단 중 하나로 Cloud Server가 뜨고 있다.
요즘 '빅데이터' 같은 개념의 등장으로 데이터의 중요도가 증가하면서 데이터 보관 총량이 증가하는 추세이다.
데이터베이스의 병목 지점은 저장소이기 때문에 스케일 아웃이 어렵다.
Shared Nothing을 제외한 모든 방식이 스케일 아웃이 불가능하다.
이런 제한 때문에 데이터베이스는 전통적으로 튜닝 기술이 발달했다. 튜닝은 애플리케이션을 효율화해 같은 양의 자원이라도 성능응 향상하게 하는 기술이다.
DBMS 기능 중 쿼리 평가 엔진에 대해서 다루는데 "SQL 레벨업"의 1장 내용과 비슷하여 정리하지 않았다.