1. @controllerAdvice VS @RestControllerAdvice
2. PostgreSQL
1. @controllerAdvice VS @RestControllerAdvice
두 어노테이션의 차이는 @RestController와 @Controller와의 차이점과 같습니다.
@ControllerAdvice와 @RestControllerAdvice는 전역적으로 예외를 처리할 수 있는 Annotation입니다. @Controller 어노테이션이 붙은 컨트롤러에서 발생하는 예외를 처리할 수 있습니다.
@ControllerAdvice와 @RestControllerAdvice의 차이점
두 Annotation의 차이는 @RestController와 @Controller와의 차이점과 동일합니다.
공식 문서에 따르면 RestControllerAdvice = ControllerAdvice + ResponseBody 입니다.
즉 RestControllerAdvice 로 선언하면 컨트롤러에서 리턴하는 값이 응답 값의 body로 세팅되어 클라이언트에게 전달됩니다.
아래 "ModelNotFoundException" 과 "IllegalArgumentException" 예외를 잡는 RestControllerAdvice 를 선언했다.
@RestControllerAdvice
class GlobalExceptionHandler {
@ExceptionHandler(ModelNotFoundException::class)
fun handleModelNotFoundException(e: ModelNotFoundException): ResponseEntity<ErrorResponse> {
return ResponseEntity
.status(HttpStatus.NOT_FOUND)
.body(ErrorResponse(message = e.message ))
}
@ExceptionHandler(IllegalStateException::class)
fun handleIllegalStateException(e: IllegalStateException): ResponseEntity<ErrorResponse> {
return ResponseEntity
.status(HttpStatus.CONFLICT)
.body(ErrorResponse(e.message))
}
}
만약 위의 코드에서 RestControllerAdvice를 ControllerAdvice로 바꾸고 실행한다면 에러가 발생하며,
RestControllerAdvice가 리턴값을 바로 클라이언트에게 전달하는 것과 달리 ControllerAdvice 는 리턴값을 기준으로 동일한 이름의 view를 찾는다. 여기서는 그 뷰가 없기 때문에 에러가 발생합니다.
여기서 View가 아닌 Data만을 응답하기 때문에 @ControllerAdvice 대신 @RestControllerAdvice 를 사용합니다.
Controller의 Method에 표기하여 우리는 Spring에게 어떻게 Exception을 Handling 할지 알려줄 수 있습니다.
아래의 예시를 참고해보면, controller의 메서드에 해당 어노테이션을 표기하여 어떻게 핸들링할지 알려주고 있습니다.
@RestController
class CourseController {
...
@ExceptionHandler(ModelNotFoundException::class)
fun handleModelNotFoundException(e: ModelNotFoundException): ResponseEntity<ErrorResponse> {
return ResponseEntity.status(HttpStatus.NOT_FOUND).body(ErrorResponse(e.message))
}
...
}
하지만 각 Controller마다 Exception에 대한 핸들링을 하다보면 중복 코드가 많이 발생할 수 있다는 단점이 있습니다.
이를 위해, Spring에서는 Exception을 전역적으로 처리할 수 있도록 @ControllerAdvice, @RestControllerAdvice 어노테이션을 제공하는 것이고,
해당 Annotation을 Class에 지정한 후 @ExceptionHandler 를 통해 전역적으로 Exception을 핸들링 할 수 있습니다.
2. PostgreSQL
전 세계 사용률은 상위 3개의 DB(Oracle DB, MySQL, Microsoft SQL)에 이어 4위인데, 꾸준히 상승하고 있는 것이 특징이며 비교적 사용률이 높은 국가는 북미와 일본으로,
강의에서 PostgreSQL 데이터베이스가 기업 데이터 환경에서 사용하는데 많은 이점이 있다하여 추가적으로 서칭해 보았고,
1. "ORDBMS"을, 그리고 2."PostgreSQL의 이점"을 순서로 작성해보았습니다.
ORDBMS란?
객체 관계 데이터베이스(object-relational database; ORD, ORDB) 또는 객체 관계형 데이터베이스 관리 시스템(object-relational database management system; ORDBMS)은 객체지향 데이터베이스 모델을 가진 관계형 데이터베이스 관리 시스템(RDBMS, 관계 데이터베이스)을 말합니다. 소프트웨어 개발자가 스스로 데이터 형과 메서드(이 두 조합은 객체 지향에서 말하는 객체의 클래스에 해당)를 자유롭게 정의하여 데이터베이스를 개발할 수 있는 데이터베이스 관리 시스템 (DBMS)입니다.
- 사용자 정의 타입을 지원한다.
- 참조 타입을 지원한다.
- 중첩 테이블을 지원한다.
- 대용량 객체의 저장, 추출이 가능하다.
- 객체 간의 상속을 지원한다.
관계형 데이터베이스에서는 다른 레코드와 연관관계를 조인을 통해서 나타낼 수 있었지만, 객체 관계형 데이터베이스는 참조 구조를 사용하여 접근이 가능합니다.
이미지, 오디오, 비디오 등 멀티디미어는 기존의 데이터보다 크기가 큰 특징을 가지고 있는데, 이러한 데이터 유형을 지원하기 위해 (LOB, Large Object) 타입이 기본 타입으로 지원되고 있습니다.
대표적인 객체 관계형 데이터베이스 관리시스템에는 위에서 설명한 PostgreSQL이 있습니다.
PostgreSQL의 이점
어떤 이점들 때문에 개발자들이 Postgesql 을 선택할까요?
- 복잡한 쿼리에 탁월
- 대용량 데이터 관리에 적합
- Catalog 기반임으로 확장이 용이
- Table, Column 에 단순히 데이터를 저장만 하지 않고, 데이터 형식, 인덱스 형식, 함수형 언어를 저장
- ORDMBS
- MVCC
- ACID 를 준수
- 동시 연결성이 높음
- NoSQL 및 다양한 데이터 형식 지원 (JSON, hstore, XML 포함해서 등등)
- 커뮤니티 활성 Level 이 높음
- 높은 안정성과 신뢰성을 제공
여기서 '복잡한 쿼리에 탁월'한 이유를 중점으로 학습해보려 합니다.
1. Query Optimizer
- PostgreSQL에는 쿼리를 분석하고 가장 효율적인 실행 계획을 결정할 수 있는 강력한 Query Optimizer Tool 이 있습니다. Optimizer Tool 은 테이블의 데이터 분포, 인덱스의 존재 및 여러 작업의 비용과 같은 다양한 요소를 고려하여 쿼리를 실행하는 가장 좋은 방법을 결정합니다.
2. Indexing
- PostgreSQL은 B-tree, Hash, GiST, GIN, SP-GiST 를 포함한 광범위한 인덱스 유형을 지원하므로 효율적인 데이터 검색이 가능합니다. Query Optimizer Tool 는 이러한 인덱스를 사용하여 쿼리를 실행하는 데 필요한 데이터를 신속하게 찾을 수 있으므로 데이터 검색에 필요한 시간을 줄일 수 있습니다.
3. MVCC
- PostgreSQL은 MVCC를 사용하여 데이터에 대한 동시 액세스를 관리하므로 여러 트랜잭션이 동일한 데이터에 동시에 액세스하고 수정할 수 있습니다. 그래서 다른 트랜잭션에 의해 차단되지 않고 여러 행과 테이블에 액세스해야 하는 복잡한 쿼리를 지원합니다.