<31302DB5A5C0CCC5CDBAA3C0CCBDBA20B9D720C0CEC5CDB3DDC0C0BFEB2DC3D6BFEBB6F42E687770>

Size: px

Start display at page:

Download "<31302DB5A5C0CCC5CDBAA3C0CCBDBA20B9D720C0CEC5CDB3DDC0C0BFEB2DC3D6BFEBB6F42E687770>"

태조 빙
5 years ago
Views:

Journal of the Korea Institute of Information and Communication Engineering 김철호 1 박경원 2 최용락 3* Web Service Performance Improvement with the Redis Chul-Ho Kim 1 Kyeong-Won Park 2 Yong-Lak Choi 3* 1

1 Journal of the Korea Institute of Information and Communication Engineering 김철호 1 박경원 2 최용락 3* Web Service Performance Improvement with the Redis Chul-Ho Kim 1 Kyeong-Won Park 2 Yong-Lak Choi 3* 1 Department of Software, Graduate School of Information Science, Soongsil University, Seoul , Korea 2 Department of Software, Graduate School of Software Soongsil University, Seoul , Korea 3* Department of Software, Graduate School of Software Soongsil University, Seoul , Korea 요약 대부분의 Web Service 는성능개선을위해사용자접속로그를생성하여관리한다. 생성된접속로그를통해트래픽이많이발생하는시간대와어떤 Resource 가많이사용되는지확인할수있으며로그분석을통해 Web Service 의성능측정및개선하는데이용된다. 하지만, 많은공공부문 Web Service 와같이일정기간동안에접속량이증가할때, 처리할사용자접속로그수증가로인해 Web Service 의성능이저하된다. 이를해결하기위해, 시스템의성능을개선하거나튜닝을필요로하지만많은비용이발생하게되며일정한시간이지나면, 사용자의접속이줄어들게되어더많은비용이발생한다. 본논문에서는사용자접속로그처리의성능을개선을통한 Web Service 의성능개선을제안한다. 또한, 최근대용량데이터를처리하기위하여많이사용되고있는 Redis 를활용하여 NoSQL 을일부적용한방법을제안한다. ABSTRACT To improve performance, most of Web Services produce and manage User Access Logs. Through the Access Logs, the record provides information about time when the most traffic happens and logs and which resource is mostly used. Then, the log can be used to analyze. However, in case of increasing high traffics of Web Services at the specific time, the performance of Web Service leads to deterioration because the number of processing User Access Logs is increasing rapidly. To solve this problem, we should improve the system performance, or tuning is needed, but it makes a problem cost a lot of money. Also, after it happens, it is not necessary to build such system by spending extra money. Therefore, this paper described the effective Web Service s performance as using improved User Access Log performance. Also, to process the newest data in bulk, this paper includes a method applying some parts of NoSQL using Redis. 키워드 : Redis, 관계형데이터베이스, NoSQL, 웹서비스 Key word : Redis, RDBMS, NoSQL, Web Services Received 28 May 2015, Revised 16 July 2015, Accepted 31 July 2015 * Corresponding Author Yong-Lak Choi( ylchoi58@ssu.ac.kr, Tel: ) Department of Software, Graduate School of Software Soongsil University, Seoul , Korea Open Access print ISSN: online ISSN: This is an Open Access article distributed under the terms of the Creative Commons Attribution Non-Commercial License( by-nc/3.0/) which permits unrestricted non-commercial use, distribution, and reproduction in any medium, provided the original work is properly cited. Copyright C The Korea Institute of Information and Communication Engineering.

Ⅰ. 서론초고속인터넷과무선인터넷의기술이발달하고스마트폰의보급으로인해사용자들은언제어디서나인터넷을활용하여모바일서비스를통해소셜네트워크서비스 (SNS: Social Network Service) 및사물네트워크 (IoT: Internet of Things) 를통하여콘텐츠의생성및공유가가능하게되었으며, 이로인해데이터의사용및생성량이급증하였다. 데이터의급증으로인해 Fig.

2 Ⅰ. 서론초고속인터넷과무선인터넷의기술이발달하고스마트폰의보급으로인해사용자들은언제어디서나인터넷을활용하여모바일서비스를통해소셜네트워크서비스 (SNS: Social Network Service) 및사물네트워크 (IoT: Internet of Things) 를통하여콘텐츠의생성및공유가가능하게되었으며, 이로인해데이터의사용및생성량이급증하였다. 데이터의급증으로인해 Fig. 1과같이 2018년까지모바일데이터트래픽은향후 3년간약 11배증가해연평균 190EB(1ExaByte: Bytes) 에달할것이라고시스코 (Cisco) 사에서전망했다. 개선을하는데어려움이있다. 대부분의 Web Service는성능개선을목적으로사용자의접속로그를생성하여저장하고관리한다. 특정시간에사용자가접속할경우, 대량의접속로그를처리하는과정에서 RDBMS의특성으로인해성능이저하되기때문에 Web Service의성능이떨어진다. 따라서본논문에서는테이블간의조인이불필요한데이터에대해서 RDBMS가아닌 Redis를이용하여대용량의접속정보를빠르게처리할수있는 NoSQL에서사용하는데이터저장방식을일부적용함으로써사용자급증으로인한대량의접속정보처리의성능향상을통해전반적인 Web Service의성능을개선하고자한다. Ⅱ. 관련연구 그림 년전세계모바일데이터트래픽전망 Fig. 1 A traffic prospect of mobile data of the World in 2018 기존관계형데이터베이스관리시스템 (RDBMS: Relational Database Management System) 은 SQL (Structure Query Language) 문을처리할때테이블간의조인 (Join) 이필요하기때문에데이터처리시간이늘어난다. 따라서, 이러한문제를해결하기위해조인을필요하지않은비관계형데이터베이스인 NoSQL(Not only SQL) 이등장하였다. 참고문헌 [10] 에서현재대부분의 Web Service는 RDBMS형태로데이터를관리하고있지만, RDBMS 는시간이지남에따라데이터양이증가하고이를처리할때시스템의성능이저하되는문제를내포하고있다. 이와같은시스템의성능저하를개선하기위해서하드웨어의추가나 SQL의튜닝을해야한다. 특히공공부문 Web Service의경우특정시간대에일정기간에많은사용자가접속하고그기간이지나게되면사용자의수가감소하여고성능시스템의유지보수비용이많이발생하게되기때문에실제로위와같은 2.1. RDBMS 참고문헌 [2] 는 RDBMS의정의를제시하고있다. RDBMS는일련의정형화된테이블 (Table) 로구성된데이터항목들의집합체로서, 테이블을재구성하지않고다양한방법으로접근하거나조합이가능하다. RDBMS는수학적인개념과원리에기초한데이터베이스로행과열로이루어진 2차원테이블구조에자료를저장한다. 테이블구조를가진오브젝트간의관계를외래키 (Foreign Key) 로표현하거나, SQL 문을작성할때에조인조건으로정의할수있어야한다. 사용자와 RDBMS 를연결시켜주는표준검색언어로 SQL을활용하며 SQL문은관계형데이터베이스에있는데이터를직접조회하거나또는보고서를추출하는데사용되며데이터를조작할때에도이용된다 PostgreSQL 참고문헌 [3, 4] 는 PostgreSQL의정의를제시하고있다. PostgreSQL은객체- 관계형데이터베이스관리시스템 (ORDBMS: Object-oriented Database Management System) 은현재가장선호하는오픈소스데이터베이스다. PostgreSQL는강력한차세대 ORDBMS으로서 Berkeley Postgres 데이터베이스관리시스템에서파생되었으며강력한객체- 관계형데이터모델과풍부한 2065

데이터타입, 쉬운확장성을가지고있다. 그리고 PostQuel 질의언어를확정된 SQL의부분집합으로대체하고있다. PostgreSQL은다양한데이터타입을지원한다. 사진, 소리또는비디오같은 Binary Large Objects의저장을지원하며 C/C++, Java,.Net, Perl, Python, Ruby, Tcl, ODBC에대한인터페이스를가지고있다. 2.3.

3 데이터타입, 쉬운확장성을가지고있다. 그리고 PostQuel 질의언어를확정된 SQL의부분집합으로대체하고있다. PostgreSQL은다양한데이터타입을지원한다. 사진, 소리또는비디오같은 Binary Large Objects의저장을지원하며 C/C++, Java,.Net, Perl, Python, Ruby, Tcl, ODBC에대한인터페이스를가지고있다 NoSQL 참고문헌 [1] 에서 최근인터넷의발달로모든사물들이인터넷과연결되어센서로부터환경, 위치, 온도등의데이터를입력받을수있다 고되어있다. 그리고스마트폰의이용확산으로인해트위터, 페이스북등 SNS 데이터의폭발적인증가로인해데이터가기하급수적으로증가함에따라빅데이터가화두로떠올랐으며관계형데이터베이스로대량데이터처리의한계문제를해결하기위해 NoSQL 기술이부각되기시작했다. NoSQL은다음과같은특징을가지고있다. 1) 관계를정의하지않는비관계형데이터베이스이다. RDBMS는외래키를이용하여테이블간의조인등의관계연산이가능하며 SQL을이용하여테이블의데이터를조작한다. 반면 NoSQL은각테이블이독립적인하나의테이블로관계를정의하지않는비관계형데이터베이스로조인을지원하지않으며 SQL을사용하지않는다. 2) 분산형저장구조를통해대량의데이터처리가가능하다. RDBMS는대량데이터처리에많은시간이소요되는문제점을가지고있다. 그러나 NoSQL은각테이블이독립적으로설계되어데이터를여러서버에분산시키는데이터분산이용이하며이로인하여서버에서다루는데이터양을분산시킴으로써대량의데이터처리에이점을가지고있다. 또한 RDBMS는대량의데이터처리서버의성능을높이기위해서하나의서버에 CPU 또는 Memory 사이즈를증설하는 Scale-Up 방식을사용하여성능을높이지만이는하드웨어의제약으로인하여한계가있는반면 NoSQL은데이터분산에용이한설계로인하여서버하나의성능을높이는방식이아닌서버자체를더추가하는 Scale-Out 방식을사용하여시스템의용량을증대시킨다. 3) 데이터베이스스키마가고정되어있지않다. 참고문헌 [5] 에서 RDBMS의데이터베이스스키마는데이터베이스에서자료의구조, 자료의표현방법, 자료간의관계를형식언어로정의한구조 라고정의되어있다. 데이터베이스관리시스템이주어진설정에따라데이터베이스스키마를생성하며, 데이터베이스사용자가자료를저장, 조회, 삭제, 변경할때 DBMS는자신이생성한데이터베이스스키마를참조하여명령을수행한다. NoSQL은테이블생성이후동적으로스키마를정의하거나변경할수있는유연성을갖는다. RDBMS에서테이블이 Fig.2 RDBMS에서의테이블설계예제와같이되어있다면해당테이블은반드시사용자ID(UserID), 비밀번호 (Password), 휴대전화번호 (HPNumber) 문자열만들어갈수있다. 그림 2. RDBMS 에서의테이블설계예제 Fig. 2 Example of table design in RDBMS 반면에 NoSQL은사용자ID로사용하는키부분만타입이같고밸류에해당하는다른필드들은 Not Null 로지정하면어떤타입이나명칭이저장되어도상관없다. 아래 Fig. 3 NoSQL에서의테이블설계예제는사용자ID는공통이지만밸류에해당하는필드는각기다른타입이나명칭을저장해도상관이없다. 그림 3. NoSQL 에서의테이블설계예제 Fig. 3 Example of table design in NoSQL 2.4. Redis 참고문헌 [6, 7] 은 Redis의정의를제시하고있다. Redis(Remote Dictionary Server) 는인-메모리 (In- Menory) 기반으로하는 NoSQL의키-밸류 (Key-Value) 데이터저장소로 ANSI C로작성되었다. 참고문헌 [8, 9] 에서는 Redis는실제로데이터구조서버로다른종류의데이터값들을지원한다고되어있다. 전통적인키 -밸류저장방식은 String 키에 String 밸류를지원하지만 Redis의밸류는단순문자열에제한적이지않고더 2066

4 복잡한데이터구조를가질수있으며 String, Hashes, Lists, Sets, Sorted sets, Bitmaps, HyperLogLogs를지원한다. Ⅲ. PostgreSQL 과 Redis 의성능비교 3.1. 성능비교실험계획및실험환경 PostgreSQL과 Redis를활용하여데이터의 Insert, Select, Update, Delete 명령에대해서처리하는시간을측정한후비교하는방식으로진행한다. 실험을수행하기위해서 Table. 1에제시된방법으로실험계획을수립하였다. 표 1. 실험계획 Table. 1 Experimental Design Order Plan Contents 1 HardWare CPU, OS, RAM, HDD 2 Server ProgreSQL Server, Redis Server 3 Modeling RDBMS Modeling using ProgreSQL & NoSQL Modeling using Redis 4 Table Create Tables in ProgreSQL and Redis 5 Client Implement Client using Java 6 Testing Test Functions about Insert, Delete, Update, Select Table. 1에제시된실험계획에따라서하드웨어 (Hardware) 를구성하였는데하드웨어에의해발생하는데이터성능에미치는영향을최소화하기위해서동일한사양의하드웨어를설치하였다. DB서버를구성하기위해사용하는소프트웨어 (Software) 는운영체제 (OS: Operating System) 를 Microsoft Windows7 64bit를사용하기때문에 PostgreSQL과 Redis는모두 Microsoft Windows 64bit를지원하는 64bit 버전을설치하였다. Client는동일한사양의하드웨어에 Java로구현하였다. 성능비교실험을위한환경구성의정보는 Table. 2에기술되어있다. DB설계를위해논리 ERD와물리 ERD를작성하였으며현재운영중인 Web Service와거의유사한환경으로구축하기위해서 Web Service의사용자정보와사용자접속정보를참조하여설계했다. 표 2. 실험환경 Table. 2 Experiment Environment Section Content Specification Server Client CPU OS RAM SSD PostgreSQL Redis CPU OS RAM SSD Language Intel(R) Core(TM) i5-2467m 1.60GHZ Windows7 64bit 8.00GB 128GB postgresql windows-x64 redis win32-win64 Intel(R) Core(TM) i5-2467m 1.60GHZ Windows7(64bit) 8.00GB 128GB Java(jdk-8u20-windows-x64) RDBMS 모델링은 PostgreSQL에서사용할 RDBMS 모델링과 Redis에서사용할 NoSQL 모델링으로진행하였다. PostgreSQL에서사용할테이블은사용자ID(USER_ ID) 를기본키 (Primary Key) 로갖는사용자정보 (USER _INFO) 테이블과사용자ID(USER_ID) 와세션키정보 (SESSION_KEY_INFO) 를기본키로갖는사용자접속정보 (USER_ACC_INFO) 테이블간의관계는 1:N이며사용자ID는사용자정보테이블의사용자ID를외래키로참조한다. Fig. 4, Fig. 5는사용자정보와사용자접속정보의 RDBMS의논리 ERD와물리 ERD를나타내고있다. 그림 4. PostgreSQL 논리모델 ERD Fig. 4 Logical Model ERD in PostgreSQL 2067

그림 5. PostgreSQL 물리모델 ERD Fig. 5 Physical Model ERD in PostgreSQL Redis의모델링은 PostgreSQL의모델링과다르게진행된다. RDBMS 모델링은도메인을분석하고저장하고자하는개체 (Entity) 를정의하고개체간의관계를정의하여테이블을설계하고 SQL을사용하여데이터를조회하는순으로모델링을진행한다.

그러나 NoSQL에서는조인을지원하지않기때문에원하는데이터를조회하기위하여데이터를중복시키거나그룹화를통해비정규화를수행한다.

따라서 PostgreSQL의기본키에해당하는 Key를사용자ID, 로그인일시의결합으로 Key가유일성 (Uniqueness) 을가지도록설계하였으며사용자의이름을보여주기위하여 Fig.4의사용자정보테이블의사용자이름을추가하였다. Fig. 6, Fig. 7은 ERwin 7.3을활용하여작성한것으로 Fig. 8이실제구조와더근접한그림이다. 그림 8.

5 그림 5. PostgreSQL 물리모델 ERD Fig. 5 Physical Model ERD in PostgreSQL Redis의모델링은 PostgreSQL의모델링과다르게진행된다. RDBMS 모델링은도메인을분석하고저장하고자하는개체 (Entity) 를정의하고개체간의관계를정의하여테이블을설계하고 SQL을사용하여데이터를조회하는순으로모델링을진행한다. 반면, NoSQL의모델링은도메인을분석하고조회할데이터에따라개체를정의하고테이블을설계한후데이터를조회하는순으로모델링을진행한다. RDBMS 모델링과 NoSQL 모델링의차이점으로는 RDBMS는데이터의중복을최소화하기위해서정규화 (Normalization) 를한다. 그러나 NoSQL에서는조인을지원하지않기때문에원하는데이터를조회하기위하여데이터를중복시키거나그룹화를통해비정규화를수행한다. Redis의데이터모델설계는화면에서조회하는항목을사용자ID(USER_ID), 세션키정보 (SESSION_KEY _INFO), 로그인일시 (LOGIN_DTM), 로그아웃일시 (LOGOUT_DTM), 사용자IP주소 (USER_IP_ADR), 사용자명 (USER_NM) 으로정의하고진행하였다. 따라서 PostgreSQL의기본키에해당하는 Key를사용자ID, 로그인일시의결합으로 Key가유일성 (Uniqueness) 을가지도록설계하였으며사용자의이름을보여주기위하여 Fig.4의사용자정보테이블의사용자이름을추가하였다. Fig. 6, Fig. 7은 ERwin 7.3을활용하여작성한것으로 Fig. 8이실제구조와더근접한그림이다. 그림 8. Redis 모델데이터구조 Fig. 8 Data Structure of Redis Model 데이터는 Redis에서지원하는해시데이터를이용하였다. 해시데이터는하나의 Key에여러개의 Value를가질수있어 PostgreSQL의데이터저장구조와유사하게사용이가능하다. 위와같이모델링을마친후 Fig.4의테이블을생성하기위하여 Fig. 9, Fig. 10과같이테이블생성 SQL을작성하여테이블을생성하였다. 그림 6. Redis 논리모델 Fig. 6 Logiical Model ERD in Redis 그림 9. 사용자정보테이블생성 SQL Fig. 9 Creating table about user information with SQL 그림 7. Redis 물리모델 Fig. 7 Physical Model ERD in Redis 성능측정실험은설계를마친각각의데이터베이스모델을바탕으로하여 Insert, Select, Update, Delete 의처리시간을측정하고정량화된수치로비교가가능하도록시나리오를작성하여단계별로성능측정을수행 2068

하였다. 그림 10. 사용자접속정보테이블생성 SQL Fig. 10 Creating table about user access information with SQL 3.2.

그후성능테스트에사용할데이터가들어있는 File을읽어내어배열 (Array) 형태로저장함으로써성능테스트에필요한데이터와데이터를읽어들이는시간을동일하게맞추어하드웨어로인하여발생하는성능테스트의영향을최소화하였다.

1) Insert 성능분석 PostgreSQL과 Redis의데이터의 Insert성능을그래프로나타내었다. Fig. 11에서 10건의데이터를 Insert했을때에는 PostgreSQL에서의실행시간과 Redis에서의실행시간이비슷했지만 100건의데이터를 Insert했을때부터는 Redis에서의실행시간이 PostgreSQL에서의 실행시간보다약 4배단축되는것으로나타났다.

6 하였다. 그림 10. 사용자접속정보테이블생성 SQL Fig. 10 Creating table about user access information with SQL 3.2. 성능비교실험동일한조건에서실험하기위해서동일한하드웨어에 PostgreSQL과 Redis를함께설치하였으며 Insert, Select, Update, Delete 등에필요한데이터는형식에맞추어텍스트파일로작성하였다. 그후성능테스트에사용할데이터가들어있는 File을읽어내어배열 (Array) 형태로저장함으로써성능테스트에필요한데이터와데이터를읽어들이는시간을동일하게맞추어하드웨어로인하여발생하는성능테스트의영향을최소화하였다. 위의방법을통해서동일한조건에서 PostgreSQL 과 Redis를사용하여데이터를처리함으로써성능테스트의정확성을확보하였을뿐만아니라프로그램실행후에생성되는버퍼 (Buffer) 에남아있는데이터의영향을최소화하기위해서모든테스트는총 10회를진행하였으며최종 5회의결과의평균값으로성능을측정하였다. 타내었다. 1) Insert 성능분석 PostgreSQL과 Redis의데이터의 Insert성능을그래프로나타내었다. Fig. 11에서 10건의데이터를 Insert했을때에는 PostgreSQL에서의실행시간과 Redis에서의실행시간이비슷했지만 100건의데이터를 Insert했을때부터는 Redis에서의실행시간이 PostgreSQL에서의 실행시간보다약 4배단축되는것으로나타났다. Fig. 12는 PostgreSQL과 Redis의 Insert할때의메모리사용량으로 100건의데이터를 Insert할때까지는 Redis의메모리사용량이많지만 5,000건의데이터를 Insert했을때부터는 PostgreSQL에서처리할때사용하는메모리사용량이 Redis보다많은것으로나타났다. 그림 11. PostgreSQL 과 Redis 의 Insert 실행시간 Fig. 11 Run-time of Insert about PostgreSQL and Redis 3.3. 성능분석데이터를처리하기위해서는메모리에적재 (Loading) 시켜야하는데이는처리해야하는데이터량에따라처리시간및메모리사용량의차이가발생한다. 따라서, 본실험에서는 PostgreSQL과 Redis의데이터량에따른메모리사용량과시간을분석하기위해 10건, 100건, 5,000건, 10,000건, 50,000건, 100,000건의데이터의 Insert, Select, Update, Delete 성능을총 10회의테스트하여하위 5번의결과값의평균을데이터건수에대한실행시간과메모리사용량에대해서그래프로나 그림 12. PostgreSQL 과 Redis 의 Insert 메모리사용량 Fig. 12 Usage of memory about Insert of PostgreSQL and Redis 2) Select 성능분석 PostgreSQL과 Redis의데이터의 Select성능을그래프로나타내었다. Fig. 13에서 10건의데이터를 Select 했을때에는 PostgreSQL에서의실행시간이 Redis에서의실행시간보다상대적으로짧았으나 100건이상의 2069

Redis의메모리사용량이많지만 5,000건의데이터를 Update했을때부터는 PostgreSQL에서처리할때사용하는메모리사용량이 Redis의메모리사용량이많은것으로나타났다. 그림 15. PostgreSQL 과 Redis 의 Update 실행시간 Fig. 15 Run-time of Update about PostgreSQL and Redis 그림 13.

7 데이터를 Select했을때부터는 Redis에서의실행시간이 PostgreSQL에서의실행시간보다약 1.4배단축되는것으로나타났다. Fig. 14는 PostgreSQL과 Redis의 Select 할때의메모리사용량으로 100건의데이터를 Select할때까지는 Redis의메모리사용량이많지만 5,000건의데이터를 Insert했을때부터는 PostgreSQL에서처리할때사용하는메모리사용량이 Redis보다많은것으로나타났다. Redis의메모리사용량이많지만 5,000건의데이터를 Update했을때부터는 PostgreSQL에서처리할때사용하는메모리사용량이 Redis의메모리사용량이많은것으로나타났다. 그림 15. PostgreSQL 과 Redis 의 Update 실행시간 Fig. 15 Run-time of Update about PostgreSQL and Redis 그림 13. PostgreSQL 과 Redis 의 Select 실행시간 Fig. 13 Run-time of Select about PostgreSQL and Redis 그림 16. PostgreSQL 과 Redis 의 Update 메모리사용량 Fig. 16 Usage of memory about Update of PostgreSQL and Redis 그림 14. PostgreSQL 과 Redis 의 Select 메모리사용량 Fig. 14 Usage of memory about Select of PostgreSQL and Redis 3) Update 성능분석 PostgreSQL과 Redis의데이터의 Update성능을그래프로나타내었다. Fig. 15에서 10건의데이터의 Update 했을때에는 PostgreSQL에서의실행시간이 Redis에서의실행시간보다짧았으나 100건의데이터를 Insert했을때부터는 Redis에서의실행시간이 PostgreSQL에서의실행시간보다단축되는것을알수있으며데이터의 Insert수가많을수록그격차는더큰것으로나타났다. Fig. 16은 PostgreSQL과 Redis의 Update할때의메모리사용량으로 100건의데이터를 Update할때까지는 4) Delete 성능분석 Fig. 17은 PostgreSQL과 Redis의데이터의 Delete성능을총 10회의테스트중하위 5번의결과값의평균을그래프로나타낸것으로 10건의데이터처리에서는 PostgreSQL이좋은성능을보였고 100건에서는거의동등한성능을보였지만데이터의량이 5,000건이상으로증가할수록 Redis의성능이약 3.5배가량좋은것을확인할수있다. Fig. 18 PostgreSQL과 Redis의 Delete 를처리할때의메모리사용량으로 10건, 100건의데이터를처리할때에는 PostgreSQL이적은메모리를사용하지만 5,000건의데이터를처리할때에는거의동등한사용량을나타냈으며 10,000건이상으로데이터를처리할때에는 Redis의메모리사용량이 PostgreSQL에비해적게사용하는것으로나타났다. 2070

따라서, 일정수이상의방문자가접속할경우, 불필요한조인의과정을거치지않는 NoSQL을활용함으로써 Web Service의품질을향상시키고보다안정적인서버운영을통하여서버의과부하를줄일수있다. 하지만, 앞으로더많은데이터를처리하기위해서는메모리의사용량을위의방법보다더개선시킬필요가있다. REFERENCES 그림 18.

8 그림 17. PostgreSQL 과 Redis 의 Delete 실행시간 Fig. 17 Run-time of Delete about PostgreSQL and Redis 터의 Insert, Select, Update, Delete의처리시간과메모리사용량을측정하였다. Insert, Select, Update, Delete 에대한데이터처리와관련된실행시간과메모리사용량을비교했을때, 소량의데이터의경우 PostgreSQL 이 Redis보다메모리사용량이적었으며실행시간에는큰차이가없으나데이터량이증가할수록 Redis가 PostgreSQL보다더적은메모리를사용하였으며실행시간도더짧은것으로나타났다. 따라서, 일정수이상의방문자가접속할경우, 불필요한조인의과정을거치지않는 NoSQL을활용함으로써 Web Service의품질을향상시키고보다안정적인서버운영을통하여서버의과부하를줄일수있다. 하지만, 앞으로더많은데이터를처리하기위해서는메모리의사용량을위의방법보다더개선시킬필요가있다. REFERENCES 그림 18. PostgreSQL 과 Redis 의 Delete 메모리사용량 Fig. 18 Usage of memory about Delete of PostgreSQL and Redis Ⅳ. 결론 본논문에서는사용자의증가에따른문제를해결하기위해 Web Service의성능을향상시키고원활한서비스를제공하기위해복잡한연산을하지않고조인을필요로하지않은사용자접속정보를처리과정을기존의 RDBMS가아닌 Redis를활용하여 NoSQL의키-밸류데이터저장소를적용하는방안을제안하였다. 성능테스트는 RDBMS로는 PostgreSQL을사용하고 NoSQL로는 Redis를사용하여두데이터베이스에데이 [ 1 ] Hyung-Nam Shim, TK-Indexing:An Indexing Method for SNS Data Based on NoSQL, 2012 [ 2 ] Terminology Dictionary in MK, New2006/desc.php?dic_key=1765, 2014 [ 3 ] PostgreSQL, [ 4 ] [ 5 ] schema, 2014 [ 6 ] Jung Gyeong Seok, This is Redis, [ 7 ] [ 8 ] Park, Joon Seok, Design and Implementation of Web- Application Framework for Classroom Management using REDIS, 2014 [ 9 ] Kang Dae Myeong, Operation Management of Redis, [10] Ko,Seon Pil, A Study on the non-relational database for big data of NoSQL, 2012 김철호 (Chul-Ho Kim) 숭실대학교정보과학대학원공학석사 관심분야 : 빅데이터, 사물인터넷 2071

9 박경원 (Kyeong-Won Park) 숭실대학교 SW 특성화대학원석사과정 관심분야 : 데이터웨어하우스, 빅데이터, 클라우드컴퓨팅 최용락 (Yong-Lak Choi) 숭실대학교 SW 특성화대학원교수 관심분야 : 소프트웨어공학, 데이터베이스, 데이터모델링, 클라우드컴퓨팅 2072

<30312DC1A4BAB8C5EBBDC5C7E0C1A4B9D7C1A4C3A52DC1A4BFB5C3B62E687770>

<30312DC1A4BAB8C5EBBDC5C7E0C1A4B9D7C1A4C3A52DC1A4BFB5C3B62E687770> Journal of the Korea Institute of Information and Communication Engineering 한국정보통신학회논문지(J. Korea Inst. Inf. Commun. Eng.) Vol. 19, No. 2 : 258~264 Feb. 2015 ID3 알고리즘 기반의 귀납적 추론을 활용한 모바일 OS의 성공과 실패에 대한