JDBC의 Connection, PreparedStatement(vs Statement)

JDBC

JDBC(Java Database Connectivity)는 자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API다. JDBC는 데이터베이스에서 자료를 쿼리하거나 업데이트하는 방법을 제공한다.

 

JDBC가 나오게 된 배경

클라이언트가 애플리케이션 서버를 통해 데이터를 저장하거나 조회하면, 애플리케이션 서버는 다음 과정을 통해서 데이터베이스를 사용한다.

1. 커넥션 연결: 주로 TCP/IP를 사용해서 커넥션을 연결한다.
2. SQL 전달: 애플리케이션 서버는 DB가 이해할 수 있는 SQL을 연결된 커넥션을 통해 DB에 전달한다.
3. 결과 응답: DB는 전달된 SQL을 수행하고 그 결과를 응답한다. 애플리케이션 서버는 응답 결과를 활용한다.

 

하지마 각각의 데이터베이스마다 커넥션을 연결하는 방법, SQL을 전달하는 방법, 그리고 결과를 응답 받는 방법이 모두 다르기 때문에 다음과 같은 문제가 발생하게 된다.

• 데이터베이스를 다른 종류의 데이터베이스로 변경하면 애플리케이션 서버에 갤발된 데이터베이스 사용 코드도 함께 변경해야 한다.
• 개발자가 각각의 데이터베이스마다 커넥션 연결, SQL 전달, 그리고 그 결과를 응답 받는 방법을 새로 학습해야 한다.

따라서 자바에서는 데이터베이스에 접속할 수 있도록 하는 자바 표준 인터페이스인 JDBC가 나오게 되었다.

 

JDBC 표준 인터페이스

JDBC 표준 인터페이스는 다음 3가지 기능을 표준 인터페이스로 정의해서 제공한다.

• java.sql.Connection: 연결
• java.sql.Statement: SQL을 담은 내용
• java.sql.ResultSet: SQL 요청 응답

이 대표적인 세 기능을 정의해두어 각각의 DB 벤더에서는 자신의 DB에 맞도록 구현해서 라이브러리로 제공하는데, 이를 JDBC 드라이버라고 한다. 따라서 위에서 발생하는 2가지 문제를 해결할 수 있게 되었다.

첫 번째 문제에서는 애플리케이션은 이제 JDBC 표준 인터페이스에만 의존하면 되기 때문에 다른 종류의 데이터베이스로 변경하고 싶으면 JDBC 구현 라이브러리만 변경하면 된다.

두 번째 문제에서는 개발자는 각각의 데이터베이스마다 커넥션 연결, SQL 전달, 그리고 결과를 응답받는 방법을 새로 알 필요 없이 이제 JDBC 표준 인터페이스 사용법만 학습하면 된다.

 

JDBC를 활용한 다양한 기술

JDBC는 1997년에 출시될 정도로 오래된 기술이고, 사용하는 방법도 복잡하다. 그래서 최근에는 JDBC를 직접 사용하기 보다는 JDBC를 편리하게 사용하는 다양한 기술이 존재한다. 대표적으로 SQL Mapper와 ORM 기술로 나눌 수 있다.

 

SQL Mapper

SQL Mapper는 SQL 응답 결과를 객체로 편리하게 변환해주거나 JDBC의 반복 코드를 제거해줌으로써 JDBC를 편리하게 사용하도록 도와준다. 하지만 개발자가 SQL을 직접 작성해야 한다는 단점이 존재한다. 따라서 데이터베이스를 변경하는 경우에는 드라이버만이 아닌 데이터베이스의 일부 문법도 변경해야 하는 경우가 생길 수 있다.

 

ORM

ORM은 객체를 관계형 데이터베이스 테이블과 매핑해주는 기술이다. 이 기술 덕분에 개발자는 반복적인 SQL을 직접 작성하지 않고, ORM 기술이 개발자 대신에 SQL을 동적으로 만들어 실행해준다. 추가로 각각의 데이터베이스마다 다른 SQL을 사용하는 문제도 중간에서 해결해준다. JPA는 자바 진영의 ORM 표준 인터페이스이고, 이것을 구현한 것으로 하이버네이트와 이클립스 링크 등의 구현 기술이 있다.

 

JDBC의 대표 인터페이스 - Connection

Connection 인터페이스는 JDBC에서 가장 중요하고 핵심적인 인터페이스를 제공하는 API 중 하나로 데이터베이스 서버와의 연결을 나타내며, 이를 통해 데이터베이스에 접근하고 SQL 쿼리를 전달할 수 있다. Connection 객체를 통해 Statement, PreparedStatement 등의 다른 JDBC 인터페이스를 생성하여 SQL 쿼리를 실행할 수 있다.

Connection 객체를 생성하기 위해서는 데이터베이스 서버에 대한 연결 정보(주소, 사용자 이름, 암호 등)를 제공해야 한다. 데이터베이스 드라이버를 로드하고, DriverManager 클래스를 사용하여 데이터베이스와의 연결을 설정한다.

그 외의 트랜잭션 관리, 자원 관리 등을 하는 데에도 사용하지만 데이터베이스와 연결에 중점적으로 살펴보자.

 

데이터베이스 연결

먼저, 데이터베이스에 접속하는데 필요한 기본 정보를 편리하게 사용할 수 있도록 상수로 만들었다. 이제 JDBC를 사용해서 실제 데이터베이스에 연결하는 코드를 작성해보자.

 

데이터베이스에 연결하려면 JDBC가 제공하는 DriverManager.getConnection(...)을 사용하면 된다. 이렇게 하면 라이브러리에 있는 데이터베이스 드라이버를 찾아서 해당 드라이버가 제공하는 커넥션을 반환해준다. 여기서는 MySQL 데이터베이스 드라이버가 작동해서 실제 데이터베스와 커넥션을 맺고 그 결과를 반환해준다.

 

간단한 학습용 테스트 코드를 만들어서 실행해보면 connection=com.mysql.cj.jdbc.ConnectionImpl 부분을 확인할 수 있다. MySQL 데이터베이스 드라이버가 제공하는 MySQL 전용 커넥션이다. 물론 이 커넥션은 JDBC 표준 커넥션 인터페이스인 java.sql.Connection 인터페이스를 구현하고 있다.

 

JDBC DriverManager 연결 이해

 

JDBC가 제공하는 DriverManager는 라이브러리에 등록된 DB 드라이버들을 관리하고, 커넥션을 획득하는 기능을 제공한다.

1. 애플리케이션 로직에서 커넥션이 필요하면 DriverManager.getConnection()을 호출한다.
2. DriverManager는 라이브러리에 등록된 드라이버 목록을 자동으로 인식한다. 이 드라이버들에게 순서대로 다음 정보를 넘겨서 커넥션을 획득할 수 있는지 확인한다.
   1. 만약 MySQL 드라이버가 아닌 H2 드라이버가 먼저 본인이 처리할 수 있는지 확인하는데 만약 처리할 수 없다면 처리할 수 없다는 결과를 반환하게 되고, 다음 드라이버에게 순서가 넘어간다.
3. 이렇게 찾은 커넥션 구현체가 클라이언트에게 반환된다.

 

JDBC의 대표 인터페이스 -  Statement

회원 데이터를 데이터베이스에 삽입하는 기능을 개발해보자.

 

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

import kr.idolucopy.idolucopy.db.DBConnectionUtil;
import lombok.extern.slf4j.Slf4j;

@Slf4j
public class MemberRepository {

    public Member save(Member member) throws SQLException {
       String sql = "insert into member(member_id, money) value (?, ?)";

       Connection con = null;
       PreparedStatement pstmt = null;

       try {
          con = getConnection();
          pstmt = con.prepareStatement(sql);
          pstmt.setString(1, member.getMemberId());
          pstmt.setInt(2, member.getMoney());
          pstmt.executeUpdate();
          return member;
       } catch (SQLException e) {
          log.error("db error", e);
          throw e;
       } finally {
          close(con, pstmt, null);
       }
    }

    private void close(Connection con, PreparedStatement pstmt, ResultSet rs) {
       if (rs != null) {
          try {
             rs.close();
          } catch (SQLException e) {
             log.info("error", e);
          }
       }

       if (pstmt != null) {
          try {
             pstmt.close();
          } catch (SQLException e) {
             log.info("error", e);
          }
       }

       if (con != null) {
          try {
             con.close();
          } catch (SQLException e) {
             log.info("error", e);
          }
       }
    }

    private Connection getConnection() {
       return DBConnectionUtil.getConnection();
    }
}

getConnection()를 사용하여 이전에 만들어둔 DBConnectionUtil을 통해서 커넥션을 획득한다.

 

SQL 전달

• con.prepareStatement(sql): 데이터베이스에 전달할 SQL과 파라미터로 전달할 데이터들을 준비한다.
  • sql: insert into member(member_id, moneny) values (?, ?)
  • pstmt.setString(1, member.getMemberId()): SQL의 첫 번째 ?에 값을 지정한다. 문자이므로 setString을 사용한다.
  • pstmt.setInt(2, member.getMoney()): SQL의 두 번째 ?에 값을 지정한다. int형 숫자이므로 setInt를 지정한다
• pstmt.executeUpdate(): Statement를 통해 준비된 SQL을 커넥션을 통해 실제 데이터베이스에 전달한다. 참고로 executeUpdate()는 int를 반환하는데 영향받은 DB row 수를 반환한다.

그런데 코드를 보면 알 수 있듯이  Statement라고 하고 실제로는 PreparedStatement를 사용하고 있다. 둘의 차이는 무엇일까?

 

Statement 

Statement 객체는 Statement 인터페이스를 구현한 객체로 Connection 클래스의 createStatement() 메서드르 호출함으로써 얻을 수 있고, SQL 쿼리를 데이터베이스로 보내고 실행하는데 사용된다. 매번 실행할 때마다 SQL 쿼리 문자열을 포함한 전체 쿼리를 데이터베이스 서버로 전송한다. 그리고 SQL 쿼리에 사용자 입력을 직접 포함할 경우 SQL 인젝션 공격에 취약할 수 있다.

 

SQL Injection

SQL 인젝션은 보안 공격 중 하나로, 사용자 입력을 적절하게 검증 또는 이스케이프하지 않고 SQL 쿼리 문자열에 직접 삽입하는 공격이다. 이를 통해 악의적인 SQL 쿼리를 실행하거나 민감한 정보에 접근할 수 있다.

 

위 코드를 보는 것처럼 Statement를 사용하는 경우에 사용자 입력을 적절하게 검증 또는 이스케이프하지 않는 SQL 문을 작성하게 되면 의도치 않게 사용자 정보가 조회되는 경우가 발생할 수 있다.

 

PreparedStatement

PreparedStatement는 미리 컴파일된 SQL 쿼리를 나타낸다. 쿼리가 미리 컴파일되므로 동일한 쿼리를 여러 번 실행할 때 Statement보다 효율적이다. SQL 쿼리 문자열 내에 바인딩 변수(? 연산자)를 사용하여 값을 동적으로 설정할 수 있기 때문에 자동으로 이스케이핑되어 SQL 인젝션 공격으로부터 보호된다.

 

Statement vs PreparedStatement

Statement와 PreparedStatementsms JDBC에서 SQL 쿼리를 실행하기 위한 두 가지 주요 인터페이스이다. 이 두 인터페이스는 데이터베이스와 상호작용하는 방법에서 차이가 있으며 가장 큰 차이는 캐시 사용 유무이다. 쿼리 실행 순서에 대해 살펴보자.

1. 쿼리 문장 분석
2. 컴파일
3. 실행

Statement 같은 경우에는 매번 1 ~ 3단계를 거치므로 SQL 문을 실행할 때마다 쿼리 파싱과 컴파일을 수행하므로 동일한 쿼리를 여러 번 실행할 때 비효율적이다.

반면에, PreparedStatement는 선처리 방식 사용으로 SQL문을 미리 준비해 놓고 바인딩 변수(? 연산자)를 사용해서 반복되는 비슷한 SQL 문을 쉽게 처리할 수 있다. 즉, 처음 한 번만 3단계를 거친 후 캐시에 담아 재사용한다. 이러한 Client-side Pre

 

Client-side PreparedStatement

Client-side PreparedStatement는 SQL 쿼리를 클라이언트(또는 애플리케이션) 측에서 처리한다. 애플리케이션 코드에서 SQL 쿼리를 PreparedStatement로 준비하고, 이 PreparedStatement는 클라이언트 메모리에 저장된다. 따라서 SQL 쿼리의 실행 계획이 클라이언트 측에서 미리 컴파일되고 캐싱된다. 클라이언트는 데이터베이스에 SQL 쿼리를 보내기 전에 이미 컴파일된 쿼리를 사용하여 데이터베이스와 상호작용한다. 이러한 특징을 정리하면 다음과 같다.

• 클라이언트 부담: Client-side PreparedStatement는 클라이언트 애플리케이션에서 SQL 쿼리를 컴파일하고 캐싱하므로 데이터베이스 서버의 부담을 줄일 수 있다.
• 캐시 관리: Client-side PreparedStatement는 애플리케이션 메모리에 쿼리 실행 계획을 캐시하기 때문에 애플리케이션이 종료되면 캐시도 소멸한다.
• 동적 쿼리: Client-side PreparedStatement는 쿼리가 정적이며 미리 컴파일되어야 한다.
• 네트워크 오버헤드: 쿼리와 결과를 클라이언트와 데이터베이스 서버 간에 전송해야 하므로 네트워크 오버헤드가 발생할 수 있다.

 

Server-side PreparedStatement

Server-side PreparedStatement는 SQL 쿼리를 데이터베이스 서버 측에서 처리한다. 애플리케이션 코드는 SQL 쿼리를 서버에 보내고, 데이터베이스 서버에서 PreparedStatement가 동적으로 컴파일되고 실행된다. 즉, SQL 쿼리의 실행 계획이 데이터베이스 서버에서 생성되며 캐싱된다. 

• 서버 부담: Server-side PreparedStatement는 데이터베이스 서버에서 쿼리를 처리하므로 서버 측에서 추가 부담이 발생할 수 있다.
• 캐시 관리: Server-side PreparedStatement는 데이터베이스 서버에서 쿼리 실행 계획을 관리하므로 여러 클라이언트가 공유할 수 있다.
• 동적 쿼리: Server-side PreparedStatement는 동적 쿼리를 처리할 수 있으며 실행할 때마다 최적의 실행 계획을 생성할 수 있다.
• 네트워크 오버헤드: 쿼리를 서버 측에서 처리하므로 네트워크 오버헤드가 상대적으로 적다.

 

대부분의 JDBC 드라이버와 DBMS는 기본적으로 Server-side PreparedStatement를 사용하고 있다. 따라서 PreparedStatement는 SQL 쿼리가 데이터베이스 서버 측에서 처리되고 실행 계획이 서버에서 관리된다. 이 접근 방식은 데이터베이스 성능을 향상시키고 보안 측면에서 이점이 있다.

 

 

출처

[JDBC] Statement, PreparedStatement

MySQL의 PreparedStatement

스프링 DB 1편 - 데이터 접근 핵심 원리