MongoDB vs. Couchbase  (1)

 NoSQL 분류중 문서 데이타베이스는  아마 가장 유명한 (많이 활용되는 )  할 것이다.  그것들의 엄청난유연성은 ( 스키마가 쉽게 변경되거나 늘어날수있는 ) 많은 어플리케이션에 적합하게 한다. 카우치베이스 서버는 비교적 최신임에도 불구하고  몽고디비와 함께  가장 유명한 오픈소스 문서형 디비가 되었다. 

이 게시글에서 말하는 "문서" 라는것은 워드프로세싱파일이나 PDF 를 말하지 않는다. 문서는 이름붙혀진 필드의 모음으로써  정의된 데이터 구조를 말한다. JSON(JavaScript Object Notation) 는 현재 문서형 디비에서 문서를 정의하기위해  가장 널리 쓰이는 표기법이다. JSON 의 객체 표기법으로서의 장점은 딱 봐서 이해하기 쉽다는것이고, 당신이 문서디비에서 많은 스키마를 정의하기위한  모든것을 나타낼수있을 것이다.  문서형 디비에서 각각의 문서는 자신만의 스키마를 가질수있다.  (해당 테이블에서 각각의 로우들이 동일한 컬럼들을 가져야하는  RDBMS 와는 다르게 ) 

카우치베이스 와 몽고디비의 최신 버전은 새롭게 나왔는데, 2012년 겨울 (역주: 옛날이네요 ㅎ)  카우치베이스는 2.0을 릴리즈했고 그 버전은 카우치베이스를 제대로된(full-fledged) 문서디비로 만들었다.  해당 릴리즈 전에  사용자는 JSON 데이터를 카우치베이스에 저장할수있었는데, 데이타베이스는 JSON 데이타를 blob 으로 썼다. 카우치베이스는 실제적으로 key/value 데이타베이스였다.

10gen 은 몽고디비 2.4 를 이번주에 릴리즈했고 몽고디비는 시작부터 문서형 디비였다. 최신버전은 성능이슈와 편의성 개선을 발전시켰다. 

두개의 디비는 모두 일반서버상에서 돌아가도록 디자인되었고, 샤딩을 경유해 수평적 확장을 할수있다. (카우치베이스는 샤드에 대해 러프한 동등성을 가지고있는데 파티션이라 불린다) . 두개의 디비는 문서정의 노테이션으로 JSON 을 사용하며 (몽고디비는 표시법으로 BSON (Binary JSON) ) 두 디비는 자바스크립트를 주요 데이타 관리 언어로 사용하며 데이타베이스를 조작하기위한 접근을 위해 많은 유명한 언어를 지원한다. 

주요 차이점  

물론 여러가지 차이점이 있다. 첫번째로 몽고디비의 도큐먼트 핸들링이 좀더 개발되어졌다. 이것은 몽고 쉘에서 명백히 드러나는데 , 몽고쉘은 관리와 개발윈도우를 제공한다.  데이타베이스, 컬렉션 그리고 문서들은 쉘에서 first-class 객체이고  컬렉션들은 사실 데이타베이스 객체상의 속성이다. 

위의 말이 카우치베이스가 좀 떨어진다는건 아니다. 당신은 쉽게 카우치베이스 클러스터를 관리할수있다. - 추가하고, 삭제하고, 문서를 패칭하고  카우치베이스 관리 GUI 를 통해서  -- 만약 당신이 GUI 컨솔을 이용하여 관리하는게 더 좋다면 카우치베이스에 준다.  뭐 당신의 삶이 까만 커맨드라인과 함께했다면 몽고디비쪽이겠지만~

클라우드 기반의 몽고디비 모니터링 서비스 (MMS) 는 모든것을 갖춘 디비관리인터페이스라고  말하는건 아니다.그러나 몽고디비환경은 데이타 오브젝트와 데이타베이스 엔터티 사이의 부드러운 연결을 해준다. 이것은 당신이 한번의 호출로 특정 문서필드상에서 인덱스를 만드는걸 발견할때 꽤나 분명해진다. 반면 카우치베이스의 인덱스는 반드시 복잡한 맵리듀스 오퍼레이션에 의해 만들어진다.

http://www.infoworld.com/article/2613970/nosql/nosql-showdown--mongodb-vs--couchbase.html  요약번역

MQTT 시작하기 좋은 글 

https://dzone.com/refcardz/getting-started-with-mqtt

MQTT 란?

(http://www.codejs.co.kr/mqtt-mq-telemetry-transport%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0/ 펌)

Mosquitto (http://mosquitto.org/) 

모스키토는 MQ Telemetry Trasport  프로토콜 버전 3.1 과 3.1.1 을 구현한 오픈소스 메세지브로커이다. MQTT 는 생산자/소비자 모델을 사용한 메세지 이동에 관한 가벼운 메소드를 제공한다. 이것은  저전력 파워센서 나 모바일 디바이스 , 임베디드 컴퓨터나 아두이노 마이크로 컨트롤러  같은 "디바이스 to 디바이스 " 간의 메세징을 처리하기에 적합하다. 

관련 내 블로그 글 

http://brad2014.tistory.com/389

실제 빅데이터 플랫폼 속의 위치 (http://brad2014.tistory.com/185)

http://www.infoworld.com/article/2876247/application-development/building-an-iot-analytics-solution-with-big-data-tools.html  요약 번역

데이터 얻고 저장하기

ad  IoT 디바이스들로부터의 이벤트(데이터)를 받을수있는 무수한 프로토콜중에 (특별히 로우레벨에서) 우리의 목적에 부합하기위해 디바이스가 블루투스,스마트폰,WI-FI 또는 하드웨어 커넥션인지는 중요하지 않다. 다만 정해진 프로토콜을 사용하는는 어떤 종류의 브로커에게 메세지를 보낼수있는지가 중요하다. 

이에 IoT 에서 사용하는 가장 유명한 프로토콜중에 하나는 MQTT (Message Queue Telemetry Transport) 이다. 이것은 잘 알려진 많은 오픈소스 클라이언트/브로커와 활용되는데 특별한 다른 이유가 있지 않다면  Mosquitto  는 가장 잘 알려지고 널리 쓰이는 오픈소스 MQTT 브로커를 사용하면 된다.  모스키토는 오픈소스이기때문에 예산이 부족한 당신이 낭비를 피하면서 당신의 분석 컨셉을 미리 실험 해볼수도 있다.

일단 모스키토같은 브로커에 메세지가 오면, 당신은 분석 시스템으로 메세지를 건네줄수있게된다. 가 장 좋은 방법중 하나는  분석을 위해 전처리/변경되야하기전에 오리지널 데이터는 따로 저장하는것이다. 그렇게 되면 디버깅이슈때나 다시 리플레이 할때나 이전 기록을 테스팅을 다시 해볼수있다는것이다. 

데이터를 저장하기위한 여러가지 옵션이 있는데, 많은 프로젝트들이 Hadoop 과 Hive 를 사용하는데, 최근에 나는 문서기반 NoSQL 의 하나인 Couchbase  ( 역주: 다른 문서기반 NoSQL 몽고DB 가있으며 http://www.infoworld.com/article/2613970/nosql/nosql-showdown--mongodb-vs--couchbase.html  비교해놓았다.)  은 를 사용했는데 매우 만족하였다. Couchbase 는 높은 처리율과 낮은 지연률을 꽤 훌륭히 컴비네이션한  특성을 가지고있다. 그것은 또한 스키마가 없는 문서형 데이타베이스라서 쉽게 새로운 이벤트타입을 추가할수있다. HDFS (역주: 하둡의 분산파일 저장시스템, 저장하기위한 시스템이고 저장된 데이터를 분석하기위한 유명한것으로 맵리듀스가 있다)  에 직접적으로 데이터를 쓰는것은 실용적인 옵션이다. 그렇게 하면 나중에 Hadoop 을 이용하여 배치기반의 분석도 사용할수있게 된다. 

영구저장소에 소스데이터를 쓰기위해 커스텀코드를 메세지브로커에 붙히거나  (예를들어 , 모스키토 브로커) 또는 아파치 카프카 같은 중간 메세지브로커에 메세지를 전달할수있다. (당신의 시스템의 다른 부분에 메세지를 이동하기위해 카프카 컨슈머를 사용하거나) 

결국 하나의 입증된 패턴은 카프카에 메세지를 넣는것과 2개의 컨슈머 그룹이 있다는것이다. 하나는 당신의 영구저장소에 로우데이터를 쓰기위한 것이고, 나머지 하나는 실시간 분석도구(아파치 스톰같은) 로 데이터를 넘겨주는 역할을 한다. 

만약 당신이 MQTT 와 모스키토 및 여러가지를 묶어서  편한길을 가려면  MQTT 스파우트 (역주: 스파우트는 아파치 스톰의 개념으로 스파우트를 통해서 데이터를 모아서 볼트를 통해서 분석작업을 하게된다.)  를 사용해서 아파치 스톰에 직접적으로 전달하는것이다. 

전처리 및 데이터 변환 

로우 형태를  가진 디바이스로부터의 데이터는 분석하기엔 적절하지 않은 경우가 많다. 데이타를 읽어버릴수도있고, 좀 더 많은 정보를 가진것으로  요구되기도 한다. 값을 표현하기위ㅐ 변경이 필요할수도있다. ( 데이타에 시간필드를 추가한다던가 하는)  

이런것을 하기위해 전처리 / 변환 과정이 필요하며 다양한 방법이 있다. 내가 경험했던 가장 좋은 방법은  위에 언급했듯이 일단 로우 소스 데이터와 함께 변경된 데이터를 저장할 필요가 있다는것이다.

지금 이렇게 생각할수도있을것이다 " 내가 항상 그것을 다시 변경할수있는데 왜 해야하지? " 하지만 이것은 매우 큰 비용을 들이게 된다. 

데이터 변환을 하는것은 여러가지 방법이 있다. 만약 배치모드에 촛점을 맞춘다면 HDFS 로 데이터를 쓰고 ( 피그 등을 통해 분석할수있을것이다. 피그는 시간은 오래걸리며 워크플로우에 지연도 길다.) 실시간 분석을 하기위해서는 아파치 스톰을 사용할수있다.   (역주: 스톰으로 분석하고 결과 데이터는 HDFS 에 쓸수도있고, Couchbase 에 쓸수도있고 그렇다) 

비지니스 혜안을 얻기위한 분석

일단 데이터가 적합한 상태로 변환이 되고 저장이 되면 , 이제 분석을 위해 그것들을 다룰수있게 된다. 아파치 스톰은 연속된 데이터 흐름을 분석하기위해 고안되었다. 그것은 정확히 IoT 시스템이 생성하는 데이터 흐름을 다루기에 적합하다.  이벤트 상관관계(event correlation), rolling metric calculations, and 집합통계(aggregate statistics) 같은것을 수행할수있게된다. 물론 상황에 적절한 여러가지 알고리즘을 직접 넣을수 있다. 

우리가 경험한바로는 스톰은 스트리밍 IoT 데이터 처리에 매우 잘 맞는 옷이었고, 어떻게 당신의 분석파이프라인의 중요요소로 작동하는지 살펴보자.

스톰에서는 기본적으로 토폴로지들이 영구히 동작하는데 , 당신의 끊임없는 메세지를 처리할수있다. 토폴로지는 어떤 개수와 프로세싱스텝으로도 구성될수있으며 , 일명 "볼트" 라고 불리는 처리단위가 클러스터의 노드에 분산되어 있다. 

볼트에서 처리된 데이터들은 버려질수도있으며, 재 가공되어 넘겨질수도있고, 결과 데이터들은 영구저장소에 저장되거나 , 뷰어에 의해 디스플레이되어 사용자에게 보여질수도있다.

위의 그림을 설명해 보면 

1.엣지디바이스/센서로부터 데이터가 생성되어 약속된 프로토콜인  MQTT (모스키토) 로 보내지고, 

2. 그 데이터들은 카프카에 모인후 카프카에서는 

      2-1. 로우데이터 자체를  Couchbase 로 보내서 저장하고 

      2-2. 데이터 분석을 위한 다른 컨슈머는 스톰에게 보내고 

           2-2-1.  실시간 분석중에 위험요소 발견하면 즉시 디바이스에 통보하고

           2-2.2.  실시간 데이터를 타임스탬프와 함께 사용자에게 그래프 등으로 보여주고

           2-2.3.  분석하기위해 필터링된  데이터를 Couchbase 로 저장하며

           2-2.4.  분석 결과 데이터는  Couchbase 와 HDFS 에 저장됩니다.

3. HDFS 에 저장된 데이터는 추후에 배치분석에 사용될수있으며

4. Couchbase 에 저장된 데이터는 사용자가 쿼링하여 살펴볼수있게됩니다.

Netty 홈페이지에 jar 다운받으러 갔더니 배너에 저런게 있네요? ㅎㅎ  귀엽습니다.  한동안 아래 Netty in

Action 책을 기다렸는데 8월31일날 발간한다더니 역시나 10월달로 연기됬네요.  마지막 사진은 진짜네티

입니다. ^^

http://www.informationweek.com/big-data/big-data-analytics/when-internet-of-things-meets-big-data/a/d-id/1298137

http://www.infoworld.com/article/2876247/application-development/building-an-iot-analytics-solution-with-big-data-tools.html

https://dzone.com/articles/iot-analytics-big-data-small

https://www.acquia.com/examples-big-data-projects

http://www.zdnet.com/article/ten-examples-of-iot-and-big-data-working-well-together/

http://seeallhearall.blogspot.kr/2012/06/netty-tutorial-part-15-on-channel.html  번역 예정

Netty 는 높은 수준의 병렬 네트워킹 어플리케이션/서비스를 목적으로 만들어진 자바 라이브러리/API 이다. Netty 가 표준 Java API 들과 구분되는 뚜렷한 이유는 비동기 API 라는점이다. 이 용어는 사람마다 다르게 해석될수도있는데 논블럭킹 과 이벤트드리븐이라는 용어와 연관되어진다. 어쨋던 전에 비동기 API를 사용해보지 않았다면, Netty 를 구현함에 있어서 사고방식의 전환이 조금 필요할것이다. 비동기적으로 호출된다는것은 즉시 반환이 이루어진다는점과 리턴값이 없다는점을 염두해야한다. 받아야할 리턴값은 다른 쓰레드가 미래의 어느 시점에 되돌려 줄것이다. 이것이 일반적인 표준API 과 기본적인 차이점이다. 아래 예를 통해 잠시 살펴보자.

위의 getWidgetCount 함수는 int 값을 리턴하지만, 아래의 비동기 방식에서는 리턴하지 않으며 대신 응답 핸들러를 주입하게됩니다. 이 핸들러는 나중에 작업을 처리하는 쓰레드에 의해서 호출되어 질것이며, 사용자는 결과를 얻고 싶을때 가져와서 사용하게 됩니다. 보증할수없는 복잡성한 레이어를 추가한것으로 보이지만 이것은 높은성능향상을 어플리케이션과 서비스에 가져다 주게됩니다. 클라이언트는 응답을 기다리기위해 wait() 함수속에서 시간을 낭비할 필요가 없습니다. 엄마가 밥도 아직 차리지 않았는데, 멍하니 식탁에 앉아있을 필요가 없습니다. 게임하면서 놀다가 엄마가 부르면 그때 나가서 냠냠하면 된다는 이야기입니다.(실제 엄마들 처럼 미리 부르지 않습니다 ^^;;) 이런 시스템은 Selectors 라는것과 함께 사용되는데 이것은 OS 시스템과 연동되어집니다.OS 에서 준비가 완료되면 알려주며, 이런 과정은 추상화되어 개발자는 상위레벨에서 쉽게 Java NIO / Netty API 를 구현할수있게 됩니다.

이 연재에서는 기본컨셉과 코어블럭들의 이름에 대해서 소개하고, 실제 코드예제를 볼것입니다.

..번역중..

 ChannelFactory

 NioClientSocketChannelFactory and NioServerSocketChannelFactory

The Boss Threads

The Worker Threads

ChannelEvent

SimpleChannelHandler

ChannelFuture.

ObjectEncoder /  ObjectDecoder

DateReceiver

ServerBootstrap /  ClientBootstrap

messageReceived / messageEvent

Upstream and Downstream

Dynamically Modifying ChannelHandlers in the Pipeline

ChannelHandlerContext

레퍼런스 

http://seeallhearall.blogspot.kr/2012/05/netty-tutorial-part-1-introduction-to.html  요약정리

http://claude-martin.ch/enumbitset/  참조 (라이브러리 여기있음)

Project EnumBitSet

This is the project home for EnumBitSet. It's a small project offering more functionality with enum types in Java.

Java 8 is needed to use any of the code!!

Is EnumBitSet the right thing for you?

Do you know this situation: You have created some enum types in Java and now you want to use them but you don't know how to store them in a database? Hibernate and JPA can help you but ORM isn't always the best approach. Maybe you just want to have more control on how the data is stored to the database. 
EnumBitSet can help you working with sets of enum constants and storing those sets in one single database field. Just use the method toLong() if you are sure that there are not more than 64 elements in the enum type. Or use toBigInteger() for enum types of any size. 
This library also offers a more general interface to bit sets that are restricted by a domain (universe). Three implementations exist:

• EnumBitSet (for enum types, mutable)
• GeneralDomainBitSet (for all types, mutable)
• SmallDomainBitSet (for up to 64 elements of any type, immutable)