검색 상세

웹 기반 환경에서 대량의 데이터 출력을 안정적으로 처리하기 위한 데이터 접근 패턴의 개선 방안

Ways to improve data access patterns in order to stably process large amounts of data output in web-based environments

초록/요약

본 논문에서는 대량의 데이터를 처리하는 웹 기반 애플리케이션 서버에서 데이터 접근 패턴의 개선을 통해 메모리 사용 효율성을 높여 안정성과 성능을 개선하는 방법에 대해 제안하였다. 제안된 방식은 기존 Sun에서 제안하는 J2EE Core Pattern 중에 Data Access Object(DAO) Pattern과 비교해서 데이터 객체를 애플리케이션 계층 간 통신 수단으로 하지 않고, 질의로부터 생성된 ResultSet의 Handler를 이용하는 방식이다. 이 방식에서는 데이터를 저장하기 위해 하나의 Value Object만을 재사용하는 Singleton Pattern과 Iterator Interface를 통해 비즈니스 로직에서 순차적인 데이터 접근시에 애플리케이션 서버에 걸리는 부하를 최소화 하였다. 다만, 제안하는 방식에선 데이터 객체 제공을 List와 같은 Collection 형태로 제공하지 않기에 데이터 객체 캐싱이 어렵고, 사용이 서버측에 한정되어 가용성이 낮은 한계점이 있다. 제안된 방식을 통한 성능 평가에서 한정된 애플리케이션 서버 상태로 세팅하여 기존 DAO Pattern에 비교하였을 때, 단일 요청의 single thread 평가항목에선 큰 개선점이 나타나진 않았으나 동시에 다수 요청의 multi thread 평가항목에선 동시 요청수와 조회하려는 데이터 건수에 따라 최대 1363%의 차이를 보였다.

more

초록/요약

This study proposes ways to improve stability and effectiveness by increasing the efficient use of memory through the improvement of data access patterns in the web-based application server that processes large amounts of data. The proposed method is to compare with the Data Access Object (DAO) from the J2EE Core Pattern proposed by Sun and use the handler from the result set produced by the query instead of using the data object as a communications mechanism between application layers. This method has minimized the load on the application server when serial data approaches through business logic are made through integrator interface and a singleton pattern that only reuses one value object to save the data. The drawback to this method is that because it does not provide data object in a collection form such as a list, data caching is difficult. Also, because the use is limited to the server's side, the availability is low. In the evaluation of the proposed method, when it was set to a limited application server, a large improvement was not observed in the single thread category in comparison to the existing DAO pattern. But in the multi thread category which has multiple requests simultaneously, there was a maximum difference of 1363% depending on the number simultaneous requests and the amount of data that was trying to make inquiries.

more