| Prepared Statement사용의 기본적인 원리를 | 2005/01/14 |
|
 |
|
|
|
Prepared Statement사용의 기본적인 원리를 기술하는 내용입니다. 아래의 글은 한솔 텔레컴의 서정희씨가 www.ejbinfo.com의 기사를 번역한 것입니다
Statement의 궁금점을 해결하는데 도움이 되었으면 합니다. -중완주-
Why Prepared Statements are important and how to use them "properly"
.
v 1.0
JDBC에 관련된 사항을 더 보실려면..
http://home.megapass.co.kr/~to2space/
------------------------------------------------
Why Prepared Statements are important and how to use them "properly".
왜 PreparedStatements는 중요하고 어떻게 이들을 “적절히” 이용해야할까요?
데이터 베이스는 다루기 힘들다. 많은 수의 클라이언트로부터 동시에
sql쿼리문을 받아들이고 많은 데이터에 대해서 가능한 효율적으로 쿼리를 실행한다.
Statement들을 수행하는 것은 퍼포먼스를 많이 잡아 먹는 작업이지만 데이터 베이스들은
현재 가능하다면 이런 오버헤드를 줄이는 방식으로 기록되어진다.
그러나 만약 우리가 최적화 과정에 중점을 둔다면 이러한 과정은 개발자의 도움을
필요로 한다. 이 기사는 정확한 PreparedStatements의 사용이 얼마나 데이터 베이스가
이러한 최적화 과정을 도와 줄 수 있는지를 보여준다.
How does a database execute a statement?
어떻게 데이터 베이스가 statement를 수행할까요?
분명히, 이 글에서는 많은 세부적인 것을 기대하지 마십시오.
우리는 단지 이 기사의 중요한 측면을 검증하기만 할 것입니다
데이터 베이스가 하나의 statement를 받을 때 데이터 베이스 엔진은 처음 문장을
parse시키고 잘못된 문법을 검사한다. 일단 statement가 parse되어지고
그런 다음 데이터 베이스는 statement 실행하기 위한 가장 효율적인 방법을 알아야한다.
이것은 계산상 아주 큰 비용이 들수가 있다.(서버 성능을 순간적으로 많이 잡아먹는다)
데이터 베이스는 도움이 된다면 어떤 인덱스를 쓸것인지 혹은 테이블에 있는 모든 row를
다 읽어야 하는 지를 확인한다. 결국 데이터 베이스는 무엇이 가장 좋은 방법인지를
이해하는데, 특정한 데이터에 대해서 통계를 이용한다.
일단 쿼리 플랜query plan( 역자주 query를 얼마나 효율적으로 할 수 있는지에
대한 플랜, 미리 데이터 베이스는 플랜을 세운 후 쿼리를 진행한다.)이 이루어지면
이것은 데이터 베이스엔진에 의해 수행되어진다.
이런 데이터에 대한 접근 계획의 생성은 cpu 전원을 소모 시킨다.
관념적으로 만약 우리가 똑같은 statement 를 데이터 베이스에 두번째로 보낸다면
우리는 데이터 베이스가 첫번 째 statement에대한 접근 계획을 재사용하도록 하는 것을
선호할 것이다. 이것은 또 한번 접근 계획을 생성 시키는 것 보다 적은 cpu점유율을
사용할 것이다.
Statement Caches
데이터 베이스들은 이런 방식으로 조절되어진다.
데이터 베이스는 보통 일종의 statement cache을 가지고 있다.
이 cache는 statement 자체를 키로써 사용하고 데이터에 대한 접근 계획은 이 cache 속에
대응되는 statement와 함께 저장되어 있다.
이것은 데이터 베이스 엔진이 이전에 실행 되었던 statement들에 대한 플랜을
재사용하게 한다. 예를 들어 만약 우리가 데이터 베이스에
“select a,b from t where c = 2”와 같은 statement를 보냈다면 계산된 실행 플랜은
cache에 저장되어진다. 만약 우리가 똑같은 statement을 또다시 보내면 데이터 베이스는
지난 번에 쓴 접근 계획을 재사용할 수 있게 되어서 cpu 사용율을 줄이게 해준다.
전체 statement가 키라는 것을 주지하고, 예를 들어서 우리가 나중에
“select a,b from t where c = 3” 라는 statement를 보냈다면
이것은 접근 계획을 발견 할 수 없을지도 모를 것이다. 이것은 c=3이 cache에 저장된
플랜의 c=2와 다르기 때문이다.
예를 들어,
for(int I = 0; I < 1000; ++I) {
PreparedStatement ps = conn.prepareStatement("select a,b from t where c = " + I);
ResultSet rs = Ps.executeQuery();
rs.close();
ps.close();
}
여기에서는 cache는 사용되지 않을 것이다. For loop의 각각의 I값에 해당하는
다른 sql문을 데이터 베이스에 보낸다. 새로운 접근 계획이 각각의 I 값의 해당하는
sql에 의해 계산되어지고 기본적으로 우리는 이런 접근 방식을 이용하므로써 cpu 사용을
소모시켜 버린다. 그렇지만, 다음 예제를 보면
PreparedStatement ps = conn.prepareStatement("select a,b from t where c = ?");
for(int I = 0; I < 1000; ++I) {
ps.setInt(1, I);
ResultSet rs = ps.executeQuery();
rs.close();
ps.close();
}
위의 예제는 더욱더 효율적일 것이다. 데이터 베이스에 보내어지는 위의 sql문에서 ?
표시는 대응되는 파라메터 값을 받고 있다. 이것은 모든 iteration에 해당하는 sql
문장이 하나의 같은 sql문장으로 "c=?" 에 대응되는 다른 파라메타 값과 함께
데이터 베이스에 보내어진다는 것을 의미한다. 이것은 데이터 베이스가 위
예제의 하나의 문장에 대한 접근 계획을 이용하게 하고 프로그램이 데이터 베이스
내부에서 더욱 더 효율적으로 수행되게 한다. 이것는 기본적으로
여러분의 애플리케이션이 더 빠르게 수행되게 하거나 또는 더 많은
cpu 의 비점유 부분을 데이터 베이스의 다른 유저에게 제공 되게한다.
PreparedStatements and J2EE servers
우리가 J2EE서버를 이용할 때 상황은 좀더 복잡해질수 있다.
보통 a prepared statement는 하나의 단일 데이터 베이스 connection과 관련이 있다.
Connection이 닫혔을 때 a prepared statement는 버려진다.
보통 a fat Client무거운 클라이언트 애플리케이션(역자주 서버에 주요 비즈니스 로직을
두지 않고 클라이언트에 주요 비즈니스 로직을 둔 형태)은 connection을 하나 가지고
애플리케이션의 종료 시점까지 가지고 있다.
이것은 또한 모든 prepared statement들을 “격력하게” 혹은 “완만하게” 만든다.
“격렬하게” eagerly라는 의미는 모든 prepared statement들이 애플리케이션이
시작할 때 한번에 만들어 진다는 것이고 “완만하게”
lazily의 의미는 a prepared statement들이 사용될 때에 만들어진다는 것이다.
전자는 애플리케이션이 기동할 때 지연 현상을 주나 기동하면 최적의 조건에서 잘 수행된다.
(역자 당연히 모든 prepared statement들이 만들어지므로 느리다)
후자는 어떠한 사전의 준비가 이루어 지지 않는다 그러나 애플리케이션의 동작함에 따라
prepared statement들이 애플리케이션에 의해 처음으로 사용되어질 때
prepared statement들은 만들어진다. 이것은 모든 문장들이 준비되었을 때까지 공평하지
못한 성능을 나타낸다. 그러나 결국엔 애플리케이션이 안정적으로 수행되고 “격렬하게
수행되는 애플리케이션” 보다 빠른 성능을 나타낸다. 어떤 것이 최고냐는 여러분이
“빠른 시작을 원하는가?” 또는 “평균적인 성능을 원하는 가?”에 달려있다.
J2EE 애플리케이션에 있어서의 문제는 이처럼 동작하지 않는 것이다.
이것은 단지 하나의 요청 기간 동안 하나의 connection에 대해서 유지된다.
이는 요청이 실행될 때 마다 prepared statement들을 반드시 만들어야 한다는 의미다.
이것은 매번 요청이 될 때 마다 만들어지는 것보다 prepared statement들이 한번에
만들어지는 무거운 클라이언트 접근 방식의 경우 만틈 효율적이지 않다.
J2EE 벤더들은 이를 알고 성능 감소를 피하기 위해서 connetion pooling을
디자인 하였다. J2EE 서버는 여러분의 애플리케이션에 하나의 connection을 제공했을 때,
이것은 실질적인 connection이 아니라 여러분은 하나의 wrapper(역자주: 실질적인
connection이 아닌 벤더들에 의해 만들어지 새로운
클래스에 의해 쌓여진 wrapped것을 말한다) 를 얻은 것이 된다.
여러분은 이것을 주어진 connection에 대한 클래스의 이름을 보고 확인 할 수 있다.
이것은 JDBC connecion는 아니고 여러분의 application server에 의해 만들어진
클래스일 것이다.
모든 JDBC객체는 applicaion server의 커넥션 메니져에 의해 관리되어질 것이다.
모든 JDBC ResultSets, statements, CallableStatements, preparedStatements등은
wrapper되어서 proxy객체(역자 주 여기서는 실질적인 JDBC의 객체들connection,
resultset등을 대신해서 application server에서 만들어진 클래스)로서
애플리케이션으로 제공될 것이다. 여러분이 Connection을 닫을 때 이들 객체는
무용하다고 표시되고 jvm에 의한 garbage collect가 이루어진다.
보통 여러분이 하나의 connection를 닫으면 jdbc driver는 connection을 닫는다.
우리는 이 connection이 J2EE 애플리케이션에 의해 close가 불려질 때 pool풀로
되돌아갈수 있기를 원한다. 이렇게 하기 위해서 실제 connection과 유사한
proxy connetion을 만든다.
이것은 실제의 connection의 reference를 가진다. 우리가 connection에 대해서 어떤
메소드를 호출할 때 이 proxy는 호출을 실질적인 conncetion으로 호출한다. 그러나
우리가 실질적인 connection의 close 메소드를 호출할 때 실제의 connection의 close를
호출하는 대신 간단하게 connection을 connection pool에 반납한다.
그리고 proxy connection이 불필요하다는 표시를 한다, 만약 표신된
connection을 애플리케이션에 의해 다시 쓰여진다면 exception에러를 발생 시킬것이다.
이 wrapping은 매우 유용하고 또 역시J2EE 애플리케이션 서버 수행을 도와 여러가지
이해하기 쉬운 방법으로 prepared statements에 대한 도움을 줄것이다.
애플리케이션이 Connection.prepareStatement을 호출할 때 이것은 driver에 의해
a PreparedStatement 로 되돌아 간다. 애플리케이션은 connection을 가지고 있는
동안 핸들을 유지하고 요청이 끝났을 때 Connection.prepareStatement를 닫고
connection을 닫는다. 그러나 connection이 pool로 반납된 후 나중에 같은 혹은
다른 애플리케이션에 의해 재사용된다면 그때 만약 그 애플리케이션이 또한 같은
문장을 이상적으로 준비중이라면, 우리는 같은 PreparedStatement가
애플리케이션으로 가기를 원할 것이다.
J2EE PreparedStatement Cache
이것은 J2EE server connection pool manager에 있는 cache을 이용해서 이루어진다.
J2EE server는 풀에 있는 각각의 database connection에 대한 prepared statements 의
모든 리스트를 유지 한다. 애플리케이션이 하나에 connection에 대해서
prepared statement를 호출하면 서버는 그 문장이 미리 준비되어 있는가를 확인한다.
만약 그것이 미리 준비 되었다면 PreparedStatement 객체가 cache속에 있을 것이고
이것은 애플리케이션로 반환 된다. 만약 그렇지 않다면 이 호출은
jdbc driver로 넘겨지고 다시 쿼리/ PreparedStatement 객체가 그 connection cache에
추가 된다. Jdbc driver가 이렇게 동작하기 때문에 우리는 connection마다
하나의 cache를 필요로한다. 우리가 이 cache의 잇점을 잘 이용하기 원한다면
앞에서 말한 바와 같이 파라메터화 된 쿼리를 사용해서 cache속에 미리 준비된 것을
사용한다. 대부분의 애플리케이션 서버는 이 prepared statement cache의 사이즈를
조절 할 수 있도록 되어있다.
Summary
그래서 우리는 prepared statements를 파라메터와 함께 사용해야한다.
이것은 미리 만들어진 접근 계획을 재 사용하므로서 데이터 베이스에 대한 로드를
줄여 준다.
이 cache는 데이터 베이스가 확장된 것이어서 여러분의 모든 애플리케이션이
유사한 파라메터화된 sql을 사용하면 하나의 애플리케이션이 다른 애플리케이션에
의해 사용된 prepared statements를 이용하므로 캐시 스키마의 효율성을 증대
시킬 수 있다.
이것은 application server 사용의 이점이다. 왜냐하면 데이터 베이스에 접근하는
로직은 데이터 접근 계층에 집중화 되어야하기 때문이다.
두번째로 prepared statements의 올바른 사용은 또한 여러분이 애플리 케이션 내부의
prepared statements cache를 잘 이용할 수 있게 한다. 이것은 애플리케이션이
이전에 사용했던 prepared statements 호출을 재사용해서 JDBC driver에 대한 호출의
수를 감소시켜 성능의 향상을 시킨다. 이것은 현명한 fat clients 사용을 효율적으로
그리고 경쟁력있게 만들고
독점적인 connection을 유지할 수 없는 불이익을 제거한다.
만약 파라메타화된 prepared statements를 사용한다면 여러분은 데이터 베이스와
코드를 가지고 있는 application server의 효율을 높일 수 있다. 이들 개선된 점은
여러분의 애플리케이션의 성능을 향상 시킬수 있게 할것이다 |
|
|
|
|
| |
