Druid (Interactive Analytics at Scale) - 설치기

Druid 설치는.... 공식 Web Site 의 Getting Started 를 참조 했지만, 무지 skip이 많다.

http://druid.io/

홈페이지 대문에 링크되어 있는 Getting Started는 그대로 따라하면 대략 5~6개의 에러를 만난다. 대표적으로, wikipedia 셈플은 MySQL 디펜던시가 없다고 해놓구선, 실행해보면 mysql 관련 시도를 한다...

물론 config 쪽에서 MySQL 접근을 하지 않도록 하는 방법도 있겠지만, Sample  만 돌리고 말것도 아니므로...대략적인 Full Setting 을 해 보았다. 기타 기본적인 세팅과 데몬 구동이 필수 필요함에도, Getting Started  는 모든걸 skip 하고 있었다.

어찌되었든, Getting Started 가 좀 비약이 심하지만, 나머지 Document 정리는 잘 되어 있는 느낌이다. github 내 소스들도 최근에도 활발히 소스 갱신이 있었음을 확인 하였다.

[Druid Dowload & install & Setting]

1. wget http://static.druid.io/artifacts/releases/druid-0.7.0-bin.tar.gz
2. tar xvzf druid*.tar.gz
3. Download Zookeeper & Setting
1. wget http://mirror.apache-kr.org/zookeeper/zookeeper-3.3.6/zookeeper-3.3.6.tar.gz
2. tar xvzf zookeeper-3.3.6.tar.gz
3. cp conf/zoo_sample.cfg conf/zoo.cfg
4. ./bin/zkServer.sh start
4. Install MySQL & initial Setting
1. sudo yum install -y mysql-server
2. sudo service mysql start
3. mysql -u root

4. GRANT ALL ON druid.* TO 'druid'@'localhost' IDENTIFIED BY 'diurd'; 

   CREATE DATABASE druid DEFAULT CHARACTER SET utf8;
5. Coordinator Node settings
1. 주석제거

1. druid.host=localhost
   druid.port=8081

2. strart
1. java -Xmx256m -Duser.timezone=UTC -Dfile.encoding=UTF-8 -classpath config/_common:config/coordinator:lib/* io.druid.cli.Main server coordinator
6. Historical Node settings
1. 주석제거
1. druid.host=localhost druid.port=8083
2. start
1. java -Xmx256m -Duser.timezone=UTC -Dfile.encoding=UTF-8 -classpath config/_common:config/historical:lib/* io.druid.cli.Main server historical
7. Broker Node Settings
1. 주석제거
1. druid.host=localhost druid.port=8082
2. start
1. java -Xmx256m -Duser.timezone=UTC -Dfile.encoding=UTF-8 -classpath config/_common:config/broker:lib/* io.druid.cli.Main server broker
8. Realtime Node Settings
1. 주석제거
1. druid.host=localhost druid.port=8084
2. start
1. java -Xmx512m -Duser.timezone=UTC -Dfile.encoding=UTF-8 -Ddruid.realtime.specFile=examples/wikipedia/wikipedia_realtime.spec -classpath config/_common:config/realtime:lib/* io.druid.cli.Main server realtime
2. realtime 으로 데이타를 가져오는 것까지 준비가 되어 있다. example 로 우선 구동 태스트를 해 보았으며, 결과를 빠르게 확인해보기 위해서는 위 .spec 파일을 열어 수집 갱신 주기를 바꾸어 주면 가능하다.

위 처럼 Coordinator ip:port 를 브라우저에서 치면, web ui 를 볼 수 있다.

아래처럼 저장해둔 example query 를 콘솔에서 restful url 로 수행해 보자 결과가 json 으로 떨어진다. 즉, WebService 를 위한 별도의 WAS 나 Gateway Ajax 용 호스팅 Web Page 를 만들지 않아도 된다.

일단, 오늘은 싱글노드 설치 & 쿼리 결과 보는 것 까지...!!!!

Druid (Interactive Analytics at Scale) - 시작기

Druid 를 시작했다.

그전에 여러가지 아키텍처에 대하여 고민 및 조사를 해보았고, 현재 우리 Production 에 존재하는 여러 NoSQL과 In-Memory 엔진의 조합도 고려해 보았었다.

* 요건
-> 테라 단위, 초 대용량 단일 테이블에 수많은 컬럼에 대한 Group By & Aggregation 요건
-> 일 수십 기가 insert (insert 는 현재는 준 실시간. 향후는 실시간 insert)
-> 리얼타임 Group By & Aggregation 분석용 쿼리가 수초 이내에 답이 나오는것이 목표.
-> 동시에 여러 사람이 쿼리를 날릴 수 있음.

이 문제를 풀기 위해, 고려해본 Legacy hadoop Eco 시스템 활용 시나리오 들은 아래와 같다.

1. Hash 기반 NoSQL
1. 우리가 가지고 있는 Hash 기반 NoSQL 은 이 시나리오 에서는 고려의 가치가 없다.
2. Hash 기반 NoSQL 들은 요런 시나리오 에서는 MySQL보다도 못한 성능 벤치마크 blog들을 많이 본적 있어서, 실험도 하지 않기로 했다.
2. Range Dictionary 기반 NoSQL
1. 범위가 있는 경우 HBase 는 MongoDB나 Casandra 보다 월등한 성능을 보인다. Group By 시 Grouping Key 가 소수일때는 PK 설계를 잘 하면, 그런데로 좋은 성능을 보일 수 있다.
2. 그러나, 우리의 시나리오 에서는 Grouping Key가 15개에 달한다. 해당 Key가 항상 등장하면 또 가능하다. 그러나, 그중 팩토리얼 개수의 조합으로 Dynamic 하게 key 가 선별적으로 조회 요청 될 때는 답이 안나올게 불보듯 뻔함. SKIP. 
3. RDBMS

1. 테이블 1개가 테라 단위 이상일 때는 MySQL 샤딩도 답이 안나온다.
2. 사실 MySQL 은 컬럼이 많을때 300기가만 넘어도 100초가 훌쩍 넘어간다. (1대 기준이긴 하지만... RDBMS 는 scale out 을 할수도 없고, 하더라도 MPP 방식이 아닌지라... 2~3대가 한계... )
3. Oracle  이나 Maria 디비가 후보군으로 더 고려 가능하지만.... 대동소이 할것으로 사료 되므로...SKIP.
4. 우측 그림은 Machine 1대 기준 Aggregation 쿼리에 대한 MySQL vs Druid 의 수행시간 비교 자료.
4. ElasticSearch RealTime Search Engine
1. ElasticSearch가 훌륭한 Group By Aggregation Query String 을 지원하지만, 이 역시 Hash 기반이라 성능을 기대하지는 않는다.
2. 단, ElasticSearch 에서는 셈플링하여 확률 기반으로 Aggregation 결과를 뿌려 주는 기능을 제공한다. 트랜드를 보는 BI 시나리오에서의 활용은, 정확도를 약간(threshold 값으로 정확도를 정교하게 trade off 가능) 포기 하고, 속도를 취할 수 있어 고려해볼 만 하다고 생각하여 후보군으로 올려 두었다.
3. 하지만, 저정도의 크기를 테스트 하기에 우리 ElasticSearch 의 Node 대수가 현재는 너무 작다... 곧 늘릴 거긴 하지만... 
5. Spark를 통한 선 집계 
1. Spark 는 훌륭한 In-Memory 배치 시스템으로 완벽하게 현재 재 역할을 해주고 있지만, 이 시나리오 에서는 Spark 배치도 답이 안나온다.
2. 그 조합이 1억 개에 가깝기 때문이다.
3. 또한 그간의 Production 운영 경험 상. RDD가 전체 병렬 Node 메모리 합보다 훨씬 커지기 시작하면, 기하급수적으로 속도가 느려 짐을 경험한 바 있다.(Hive 나 M/R 보다는 훨씬 빠르지만..)
6. Spark 를 데몬화 하여 on the fly 로 처리
1. Spark 를 Spark Streaming + Mesos + Marathon 의 조합으로 데모나이즈 화 해놓고, On the Fly 로 반응하게 하는 시나리오는 추가로 실험해볼 예정이다. 
2. Spark streaming 은 CEP 엔진이지, 이런 시나리오를 위한 엔진은 아니므로, 큰 기대를 하고 있지는 않다.
7. 현재 Legacy 로는 존재하지 않지만, Aggregation 에 최적화된 별도 NoSQL고려.
1. 가장 현실성 높은 시나리오 이다.
2. 요 시나리오를 우선 최우선 고려.
3. 여러가지 NoSQL 중 Druid 선정.

그래서 Group By Aggregation 에 최적화된 NoSQL 관련 여러 NoSQL 을 고려 하던 중, 우선 Druid 를 직접 설치, 우리의 Real 요건을 가지고 Real Data 로 가능성을 타진 해 보기 위한 설치 테스트를 진행해보기로 하였다.

Druid 또한 2010년도 Google 의 Dremel 논문의 영향을 받은 In-Memory 기반 SQL 을 지원하는 NoSQL이다. (공식 홈페이지 : http://druid.io/ )

아래는 Druid 를 선정하기까지 고려한 여러 아티클 들이다.

1. http://druid.io/blog/2011/04/30/introducing-druid.html
1. 성능 벤치마크 자료
2. 좀 오래전 자료라, 요즘에는 이보다 훨씬 성능이 좋으리라 기대한다.
2. http://druid.io/blog/2014/03/17/benchmarking-druid.html
1. 역시 성능 벤치마크 자료
2. 작년 자료라 첫번째 자료보다는 신빙성이 간다.
3. MySQL 과는 천양지차의 압도적인 성능을 보여준다. 사실 MySQL은 테이블 한개가 천문학적인 크기로 커질 때는 샤딩으로도 답이 없다. 뭐 여타의 RDBMS 가 다 그러하지만...
3. https://github.com/pulsarIO/realtime-analytics/wiki
1. ebay 가 오픈소스로 오픈한 realtime-analytics 프레임워크
2. 내부에 druid 와 casandra 등 nosql  과의 colaboration mesh up 이 되어 있다. 
4. https://www.linkedin.com/pulse/20140909054748-5574162-true-performance-measure-of-realtime-big-data-analytics-platforms
1. 빅데이타 에코시스템의 강자 Linked-in이 realtime analytics  로 내부 고려하며 남긴 아티클.
2. 상용1개(parstream)와 druid 를 최종 후보로 선정. ( 함께 비교한 Riak 은 성능이 좋지 않음을 확인 한 문구가 보인다. MongoDB 와 Casandra 는 해볼필요도 없다는 투의 문구도 보인다. 사실 그런 류의 Key Value 스토어 에서의 Group By Aggregation 은 자료구조 상 빠를래야 빠를 수가 없다.)
5. http://druid.io/
1. druid 공식 홈페이지.
2. 홈페이지는 나름 잘 정리되어 있다.
3. getting started 는 지금 여러 방식으로 설치 중인데...최악이다.

Docker & Mesos - 그 역학관계에 대하여....

가상화 기술 -> 클라우드 컴퓨팅 -> OpenStack & Hadoop Eco System 에 이어…..요즘 Docker 기술에 대하여 많은 글들이 Posting 되고 있습니다.

Docker는 일종의 Process Virtualization 기술인데요…

그 시작에 역쉬 Google 이 있습니다. 구글이 1년에 한편 꼴로 발표했던 논문들을 Open Source 진영에서 아래처럼 따라가고 있었는데요..대표적인것들이 아래와 같습니다.

[ Google ]                  vs      [Open Source]

GFS(2003)                      vs        HDFS

MapReduce(2004)             vs        MapReduce

Chubby(2006)                  vs        zookeeper

BigTable(2006)                 vs        HBase

Dremel(2010)                   vs        Drill,Impala, ( vs Spark )   

Omega(2013)                   vs        Docker, ( vs Mesos 접근 방법이 좀 다르지만.. )

위 처럼 그 말단 중… 바로 전 세대가 SQL on Hadoop(with In-Memory Technology….) 기술로서 Dremel   vs   Impala , Drill, Spark …였다면…(현재 춘추 전국인데… Spark로 많이 기울었음..)

지금 막 시작하고 있는 기술이 Docker 가 되겠습니다.

그런데 Dremel 때부터, 약간 3파전 양상을 띠고 있습니다. 즉, 구글이 Dremel 논문을 발표하고, Open Source 가 Drill , Impala 등으로 논문 뒤 쫓아가기를 시작 했는데, 버클리DB 로 내공이 상당한 버클리 대학의 AMPlab 이 구글 논문에 자기들 만의 아키텍처를 더하여, 약간 많이 변형된 대항마를 내놓고 있다는 것입니다.

Dremel 에 대항하는 Spark  는 그렇게 현재 SQL on Hadoop 춘추 전국에 종지부를 찍으며, 거의 천하 통일을 하려는 듯한 분위기를 이끌어 가고 있습니다.

그리고 아직은 초창기라 태동 단계이긴 하지만… Docker 진영이 생겨났고. 역시 버클리대학 AMPlab이 주도하는 또 약간 변형되어 접근되고 있는 Apache Mesos 가 있다 하겠습니다.

(저희 BigData 시스템 Production 에 얼마전 새롭게 추가된 Layer 입니다.)

둘의 역학관계를 잘 설명하는 좋은 슬라이드가 있어 공유 합니다. 각각 약간 다르게 접근되고 있어, 장단점이 극명하여, 함께 쓰는 시나리오를 설명하고 있습니다.

https://speakerdeck.com/stevendborrelli/next-generation-infrastructure-with-docker-and-mesos

사실 Docker 와 Mesos 는 접근 방법이나 철학이 좀 다를 수는 있습니다. 그러나, 저의 주관적인 생각으로는 접근 방법이 어찌 되었든...둘다 Process 관점에서 추상화된 레이어 위에서 구동에 주력하고 있어, 한통속으로 여겨진다는 것입니다. 단지, Mesos는 Process(혹은 task) 를 추상화된 복수의 수많은 클러스터에서 손쉽게 병렬 혹은 centric 구동 하게 해준다는 측면으로 접근하였고, Docker 는 가상화 OS 가 아니라 가상화 Process 를 부모 OS와 독립하여 구동하는 것 자체에 집중하여 접근하였다는 차이가 있습니다. 그래서.... 최근에는 Docker 를 Mesos 위에 올려서 그 각 접근 방식의 장점을 어느정도 취합하려는 시도도 조금씩 보이긴 합니다.

아래는 홀로 독주하는(물론 모두 Open Source 화 하였음…) 버클리대학 AMPlab 의 Data Analytics 스택입니다. 아래 스택에 저희와 겹치는게 2/3 이상이네요..

Spark 를 매우 잘 쓰고 있는 기업 중 하나는, 이미 Amazon을 뛰어 넘어, 세계 최대 쇼핑몰이 된 중국 알리바바의 Taobao 쇼핑몰입니다.

공식적으로 Production 환경에서 Spark On Yarn Cluster 를 세계 최초로 적용한 기업이 알리바바의 Taobao 입니다.

아마도 국내에서는 Production 환경에서 Spark On Mesos Cluster 를 국내 최초로 적용한 기업은 저희가 아닐런지...

Spark Upgrade 및 성능 비교 - Spark 1.1.0 vs Spark 1.2.0 ( on Apache Mesos )

Spark 1.1.0 이 작년 9월 경 버전업 된 이후로 1.1.1 업그레이드가 한번 더 있었고, 1.2.0 업그레이드도 최근에 있었다. Apache Mesos 와의 연동 작업도 세팅할 겸. Production 의 Spark 버전을 업그레이드 해 주었으며, 업그레이드 전 후 성능 비교도 해 보았다.

1. Spark Download
1. wget http://mirror.apache-kr.org/spark/spark-1.2.0/spark-1.2.0-bin-hadoop1.tgz
2. tar xvzf spark-1.2.0-bin-hadoop1.tgz
2. Library Upload
1. hadoop dfs -mkdir /user/spark
2. hadoop dfs -put ./spark-1.2.0-bin-hadoop1 /user/spark/
3. Apache Mesos 설치
1. Apache Mesos 설치는 [Apache Mesos 설치기] 요기에서....
4. Config Setting on Master
1. mv spark-env.sh.template spark-env.sh
2. vi spark-env.sh
   
   MESOS_NATIVE_LIBRARY=/data01/mesos/mesos-0.18.1/build/src/.libs/libmesos.so
   
   SPARK_EXECUTOR_URI=hdfs://master001.prod.moneymall.ssgbi.com:9000/user/spark/spark-1.2.0-bin-hadoop1.tgz
3. vi spark-defaults.conf
   spark.executor.uri              hdfs://master001.prod.moneymall.ssgbi.com:9000/user/spark/spark-1.2.0-bin-hadoop1.tgz
5. Spark Shell 실행

1. 먼저 shell 모드 실행
2. 위 처럼 1.2.0 버전으로 잘 떳음...
6. Spark Program 구동

1. 이어서 기존에 1.1.0 에서 돌던 Scala Batch 프로그램을 1.2.0 에서 수행하기 위해 위 처럼 인자를 바꾸고 수행.
2. executor memory 와 driver memory 값을 적절하게 주어야 Heavy 한 Batch Job 이 원할하게 수행 됨. 속도도 더 빨라 짐.
7. Spark 1.1.0 수행 속도 : 61초 

8. Spark 1.2.0 ( on Apache Mesos ) 수행 속도 : 35초

9. Spark 1.2.0 on Apache Mesos 업그레이드 고찰
   (1)   기존 JVM Spark 엔진은 설정 공유 메모리 만큼 JVM 데몬이 메모리를 점유 하고 있어서, Hadoop Job 과 Memory 경합이 있을 수 있음. 경합을 피하기 위해 OS Full Memory 를 쓰지 못하고, 보수적으로 Fix 점유 해놓은 메모리 만큼 만 공유하는 구조였음.
   Ø  바뀐 Mesos 는 C++ 엔진인지라, 별도로 Memory 할당이 필요 없고, OS 가 가지고 있는 물리 Memory를 Full 로 쓸 수 있음.
   Ø  공유 메모리 Pool 이 56G 에서 약 280G 정도로 5배 가까이 커짐.
   (2)   속도 향상.
   Ø  Memory 공유 방식 뿐만 아니라 CPU 공유 메커니즘도 포함 되면서, 위 결과 처럼 약 1.8배의 속도 향상이 있었음.

Scala - vim Syntax Highlight

Vi에서 Scala Syntax Highlight 사용하기.

mkdir -p ~/.vim/{ftdetect,indent,syntax} && for d in ftdetect indent syntax ; do curl -o ~/.vim/$d/scala.vim https://raw.githubusercontent.com/derekwyatt/vim-scala/master/syntax/scala.vim; done

Apache Mesos 설치기 1 - 설치 및 활용성에 대한 고찰

한때 메모리를 클러스터링 하여, NFS 공유 파일시스템 쓰듯이 공유 메모리 Pool 을 쓸 수 있게 해주는 Tachyon (http://tachyon-project.org)에 관심을 갖은 적이 있었다. (결과 적으로 몇번의 Deep 한 테스트 이후 현재는 Tachyon 을 쓰고 있진 않지만, IO 를 많이 쓰는 공유 저장소가 필요할 때, 여러 Layer 에서 손쉽게 쓸 수 있는 좋은 대안이라는 생각에는 변함이 없다. NFS 처럼 Mount 될 수 있으며, NFS 보다 수십 배에서 수백 배의 성능을 얻을 수 있다.)

Spark 엔진 또한 Tachyon 과 Collaboration 하여 Batch 성능을 향상해보려는 테스트를 한바 있었는데…. 그때가 작년 8~9월 이었다.

그로부터 3~4개월이 흘렀고….그 짧은 기간 동안에 Spark 는 3번의 버전업이 있었다.

최근에 Spark 진영은 Tachyon 과의 Collaboration 보다는 Hadoop 2.0 Yarn 과의 Collaboration , 그리고 Apache Mesos 와의 Collaboration 을 하는 방향으로 유행이 바뀌어 있다.

아래는 Apache Mesos 가 무엇인지 와 닿게 하는 기사 글 이다.

http://www.itworld.co.kr/news/89034

특징을 한마디로 요약하자면….

Tachyon 은 메모리를 공유해준것에 그쳤다면…

Mesos 는 CPU와 memory 와 storage 와 기타 다른 컴퓨트 리소스들을 추상화 하여 하나의 pool 로서 쓸 수 있게 해준 다는 것이다.

C++, Java , Python ,Scala 등의 어플리케이션을 Mesos가 제공하는 Framework 위해서 구동할 수 있으며, Hadoop , Spark , ElasticSearch 그리고 Jenkins 까지도, mesos 와 Collaboration 구동되게 데몬 자체를 Mesos Layer 위에 구동 설치가 가능하다.(이 경우 기존 클러스터링 설치보다 더 뛰어난 성능을 얻을 수 있다.)

아래는 필 받은김에 이번 주말에 설치해본 간략 설치기 이다.

1. Installing Mesos
• Spark 1.2.0 is designed for use with Mesos 0.18.1 
• http://mesos.apache.org/
• wget http://archive.apache.org/dist/mesos/0.18.1/mesos-0.18.1.tar.gz
• tar xvzf mesos-0.18.1.tar.gz
• root 계정으로 vi /etc/yum.repos.d/wandisco-svn.repo
• [WandiscoSVN] name=Wandisco SVN Repo baseurl=http://opensource.wandisco.com/centos/6/svn-1.8/RPMS/$basearch/ enabled=1 gpgcheck=0
• yum groupinstall -y "Development Tools"
• yum install -y python-devel zlib-devel libcrul-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 apr-devel subversion-devel
• Java 및 maven계열 설치는 기 설치되어 있어서 skip....
• cd mesos홈
• ./bootstrap ( root 계정에서 일반 계정으로 돌아옴. & sudo 활용)
• mkdir build
• cd build
• ../configure
• make ( 요 단계 꽤 오래 걸림...., sudo 도 안되고 su 가 필요한 경우도 있음. )
• make check
• make install ( sudo 가 필요한 경우가 있었음.. )
• 위 과정을 Master 역할을 할 서버에 설치
• 위 과정을 Slave 역할을 할 전체 서버에 모두 설치
2. Mesos Cluster 구동
1. Master 구동 
1. ./bin/mesos-master.sh --ip=서버IP --work_dir=/dataXX/mesos &
2. Slave 구동
1. ./bin/mesos-slave.sh --master=서버IP:5050

Elasticsearch 사용기 1 - 리얼타임 분석엔진입장에서 elasticSearch vs Strom

elasticSearch 는 빅데이타 에코시스템의 부족한 부분 중 상당히 많은 부분을 체워 줄 수 있다. 물론 이 부분을 다른 여러 가지로 나누어 메꾸거나, Storm 이라는 걸쭉한 리얼타임 엔진으로 대부분을 커버 할 수도 있긴 하다.

그러나, storm 을 기 사용하고 있었고, elasticSearch 를 짧은 시간이나마 다시 운영 Hadoop에 적용하여, 이리 저리 실험적으로 사용해본 첫 느낌으로는.....

Real Time Analytics 에 있어 Storm 과 elasticSearch 는,
마치 Java Map/Reduce (on Spring Hadoop) 와 REPL 콘솔을 갖춘 Scala In-Memory M/R (on Spark) 의 차이와 같은 느낌이라고나 할까....(비유가 더 어려웠나???)

여튼 Storm 은 멀 할라 치믄 일단, 할게 많고, 공들여 개발한 다음 배포하고, 데이타를 원하는 포맷으로 이리 저리 필터 걸거나 조건을 넣어, 실제로 드려다 보기까지 귀찮은 작업이 이만 저만이 아니다... 그리고 원하는 데로 결과가 나오지 않아 검증이라도 하고싶거나, 혹은 뭔가 결과가 나오긴 했는데, 과연 맞게 나온 결과인지, 런타임 디버깅이라도 해보고 싶다면, 여간 난감한게 아니다. 그래서, 상용 솔루션이긴 하지만, 에스퍼(http://esper.codehaus.org/)를 Collaboration 을 해서 쓰거나, 아예 좀더 애자일 하게 Storm을 쓰기 위해 clojure  와 trident 기반으로 Storm 을 사용하는 경우(우리처럼...)도 많이 봐왔다.

elasticSearch 는 일단, 여러가지 plugin 중 head 하나만 가지고도  할수 있는게 상당히 많다. 코딩을 하기 전, 데이타를 이리저리 만지작 거리며, 제대로된 모델을 사전 검증하거나, 중간 단계 슈도 코드로 Real-Data 를 통하여 검증하는 것을 쉽게 할 수 있다는 장점이 있다.

검증을 REPL 에서 바로바로 할 수 있는 Scala on Spark 와 비슷한 느낌이라고나 할까... 게다가 결과도 Spark 이상으로 빠르다. 사실 간단한 로직의 경우는 훨씬 더 빠르다. 물론 리얼타임 검색 엔진이니까..빠른게 당연하지만...

단점이 없는 것은 아니다. elasticSearch 엔진의 queryString 은 복잡한 비지니스 요건을 전부 처리하는데에는 한계가 있다. 즉, 요녀석도 그냥 NoSQL 처럼 에코시스템 중 One of Them 인것이다.
즉, elasticSearch 는 여러 에코시스템 중 elasticSearch 가 장점이 있는 부분에 요긴하게 쓸수 있으며, 그 부분이 다른 NoSQL 에 비하여 RealTime 활용 쪽에서는 상당히 넓은 부분을 커버 할 수 있으며, plugin등 자체 에코시스템도 상당히 갖추어져 있어 응용 확장성도 뛰어나다.. 정도로 요약 가능할 듯 하다. 게다가 kibana 라는 걸쭉한 시각화 도구 까지...

아래는 SQL 과 elasticSearch  의 queryString 을 비교 수행해본 결과이다.

1. SQL 쿼리

• SELECT COUNT(*) FROM log GROUP BY browser ORDER BY COUNT(*) DESC

2. ElasticSearch 쿼리

• ElasticSearch 의 쿼리는 아래와 같다.

{

  "size": 0,

  "aggs": {

    "group_by_state": {

      "terms": {

        "field": "browser"

      }

    }

  }

}

결과는 아래처럼 나온다. 놀라운 것은 이것이 1초전 Insert 된 Real Time 이벤트까지 반영된 실시간 결과라는 점!!!!!!

3. 아래 처럼 쿼리를 좀 확장해서 쓸수도 있다. 정규표현식으로 필터를 그룹 주고, 그 결과로 그룹핑 된 PV  정도는 손쉽게 리얼타임 장표를 만들어 낼 수 있다.
(여기서의 리얼타임이란, 시간당 수백만 PV가 들어오는 트래픽에 대하여, 고객들이 들어오는 특정 페이지의 PV  를 1~2초 안의 최신성을 반영하여 시각화 가능하다 정도...사실 Scale Out 이 가능하므로, 트래픽이 큰 문제가 되지는 않는다.)

GET /test/data/_search?search_type=count{
  "aggs" :{
    "total_count" : {
      "global" : {}
    },
    "XX999" : {
      "filter" : {
        "regexp":{
            "product_code" : "[a-z]{2}[0-9]{3}"
        }
      } 
    },
    "X99999" : {
      "filter" : {
        "regexp":{
            "product_code" : "[a-z]{1}[0-9]{5}"
        }
      } 
    },
    "no_format" : {
        "missing" : {
            "field" : "product_code"   
        }
    }
  }
}