만약 자신의 집에서 사용중인 전기를 측정하는 센서가있다고 치고 , 그 센서는 1초에 한번씩 전력값을 측정한다고 치자. (사실 센서에서는 수천번 측정한다고한다.그것들의 1초 평균값을 가져온다고 생각하자. 더 상세하게 분석하려면 1초 평균값,최대피크값등등 가져오면 더 좋을것이다.물론BM에따라서는 1분당 , 1시간당 평균,최저,최고값을 사용할수도있겠다.) 이 측정 값을 분석해서 , 집안에서 사용중인 모든 가전제품등의 대기전력 및 여러가지 패턴을 알아낸다고 하자.
막간 상식 코너 ~!
와트(W) : 움직이는 전하는 일을 한다. 예를 들어 열을 발생시키거나 전동기를 회전시키는 등의 일을 한다. 일의 능률(전기에너지가 빛이나 열에너지로 바뀌는 비율)을 전력이라 한다.
전력 (P) : 단위시간(1초) 동안 전기기구에서 소모하는 전기에너지의 량.
P = V(볼트) * A(암페어)
1초에 한번씩 생성되는 데이터를 시간/값 => ( "2015-10-15 10:50:30" , 563.34) 라고 하면 Postgresql 같은 일반 관계형데이터베이스에 저장한다고 치자.
timestamp or Character (20 byte) : real (4byte) 이렇게 2가지의 컬럼이 필요하겠지.
대략 25 바이트라고치고 ,
1분에 1500 byte
1시간에 90000 byte
1일에 2160000 byte (대략 2 mb)
1달에 64800000 byte (61 mb)
1년에 788400000 byte (751 mb)
집안에 센서가 여러개면 더 늘어나겠지. 일단 센서1개 로 잡고 백업,인덱스등 부산물의 데이타용량은 제외 , 데이터를 압축 등 적용안한다고 치고 대략적으로 1기가라고 잡자.
한가구에 대략 1기가로 잡고 , 만약 전기서비스를 하는 회사를 만들었다고 치고, 빅데이터들을 관리 분석한다고 할때 , 1만가구쯤을 대상으로 서비스한다고 치면 1만기가 = 9 테라바이트 정도 된다.
요즘 테라단위의 HDD 들이 나오고 있다. 10TB 도 나온듯하다. 와우~ (http://it.donga.com/21465/)
프로토타입으로 저런 데이터를 postgresql 에 모아서 ,모여진 데이터를 실시간으로 d3.js 를 이용해서 가시화 하고 있다고 하자.
이제부터 본격적인 시스템을 설계한다고 치면, 언제까지 저런 데이터를 postgresql 에 담아두고 활용할거냐는건데.. 웬지 , 용량을 더 늘려야할거 같다. 스케일 업을 할수도있고, 스케일 아웃을 할수도있겠지..스케일 아웃에 대해서 고려해면다면 couchbase / hadoop hdfs / mongodb 뭐 이런것들이 떠오른다. 분석을 생각해본다면 , Apache storm 이나 spark streaming 도 떠오른다.
여기서 한발 더 나아가서 , 저런 시계열 데이터를 특별히 다루는것들이 있는지도 살펴봐야겠는데..몇몇가지가 있더라~~ 그래서 이번 게시물에서는 그 몇몇가지에 대해서 한번 살펴본다.
그 시계열 DB 들이 couchbase / hdfs / mongodb 와 경쟁을 하게될지, 협업을 하게될지..나는 아직 잘모른다. 그 시계열 DB 들이 RDBMS 들과 어떤 앙상블을 이루게될지 희미하다. 따라서 일단 정리해본다. -.-v (일단 주워담고, 차근차근 정리해본다. 당분간 정신없을 게시물이될듯)
OpenTSDB (http://opentsdb.net/)
InfluxDB (https://influxdb.com/)
0) 2013년 첫 릴리즈
1) InfluxDB는 data store를 위해 구글이 만든 key/value database library인 LevelDB를 사용하고 있습니다.따라서, 아래와 같은 LevelDB의 특징을 가지고 있습니다.(다음버전엔 RocksDB 로 이동예정)
– 기본적으로 데이타를 compression하기 때문에 읽기와 삭제에 다소 느릴 수 있습니다.
(출처: http://obfuscurity.com/2013/11/My-Impressions-of-InfluxDB, https://code.google.com/p/leveldb/)
– 그러나, LevelDB와 다르게 SQL-like query language를 지원합니다. group by, join, 또 복수개의 time series(RDBMS에서 테이블이라고 이해하시면 됩니다.)를 merge하는 것도 가능합니다.
2) InfluxDB는 distributed and scale horizontally하게 설계되었습니다. 따라서, cluster에 새로운 node만 추가하면 쉽게 scale-out 할 수 있습니다.
3) Continuous Queries를 지원합니다. 이게 뭐냐면, 정해준 시간마다 해당 query를 실행해서 그 결과 값을 지정하는 테이블의 특정 칼럼으로 저장하게 해줍니다. 보통 분석, 통계 데이타를 쌓을 때 스케줄러를 통해 많이 하는 작업(downsampling 같은 작업)인데요. InfuxDB는 이런 작업을 Continuous Query 한방으로 해결해줍니다.
4) MongoDB 처럼 Schemaless design입니다.
5) Primary interface로 native HTTP API를 제공하고 Java, Javascript, Ruby, Rails, Python, PHP, Node.js, Go 등 많은 library를 제공합니다.
6) Go로 작성되었습니다.
7) InfluxDB는 오픈소스입니다. 소스를 다운로드 받아서 쓰실 수 도 있고 아니면, influxdb.org에서 매달 일정 비용을 내고 호스팅 서비스를 받으실 수 있습니다.
8) Linux & OS X
9) 스키마 프리
10) HTTP API / JSON over UDP
11) Numeric data and String
12) Sharding 지원 / Selelctable replication factor
InfluxDB 는 여러모로 시계열 DB 중에 가장 널리 선택받고 사용될듯 합니다.
(저도 전력빅데이터 분석을 위해서 InfluxDB + Grafana 조합을 사용중입니다)
Graphite (http://graphite.wikidot.com/)
Graphite 는 무엇인가?
Graphite 는 높은 확장성을 가진 실시간 그래픽 시스템이다. 당신이 관심있어하는 그래프를 그리기위한 수치 타임시리즈 데이터를 수집할수있는 어플리케이션을 만들수있으며. 그것을 Graphite 의 벡엔드로 보낼수도있다. 그 데이터들은 Carbon 이라 불리는 Graphite 의 특별한 데이터베이스에 저장될것이다. 그리고나서 Graphite 의 웹 인터페이스를 통해 가시화될수있을것이다.
Graphite 는 수치 타임시리즈 데이터를 다루기위해 특별히 디자인되었으며, 따라서 주식을 나타내는데 도 좋다. 오직 수백건을 표현하기위해서라면 Graphite 는 지나치다. 수백개의 서버에서 나타내는 수많은 성능 지표들을 나타내기위해서 적절하다.
어떻게 스케일 확장가능한가?
CPU 관점에서 Graphite 는 프런트엔드 와 백엔드 양쪽모두 수평적으로 확장할수있다. 이 말은 당신은 그저 더 많은 서버를 추가하기만 하면 된다는것이다. 그것은 벡엔드 서버가 고장났을때, 데이터 손실을 야기하는 상황에서 내고장성을 가지고있다는뜻이며, 만약 충분한 수용능력이 있을경우 시스템 운용에 지장받지 않는다는것이다.
I/O 관점에서 봤을때, under load Graphite 는 매우 빠르게 많은 다른 파일들상에서 작은 I/O 오퍼레이션을 수행한다. 이것은 Graphite 로 보내는 각각의 distinct metric 들이 자신의 데이터베이스 파일에 저장되기 때문이다.
Graphite 의 벡엔드는 만약 디스크가 크기가 작은 수많은 쓰기 연산을 다룰수 없을때 들어오는 데이터를 캐쉬한다. (대부분의 디스크들은 초당 수천 I/O 연산을 할수없다.비록 각각의 데이타포인트가 오직 수 바이트일지라도. 추가: HDD의 경우 초당 랜덤 엑세스가 100~200회 밖에 되지 않는다. TPS가 1,000이 넘어가는 요청은 랜덤 엑세스로는 처리하기가 어렵다. MySQL InnoDB의 경우 Sequential write를 통해 초당 2,000회 정도의 Insert가 가능하다.) . 그런 현상이 발생했을때 Graphite 의 데이터베이스 엔진 (Whisper) 은 카본에 한번에 여러개의 데이터포인트를 쓰는것을 허용한다. 그리하여 전반적인 처리량을 증가시킨다.
- 2006 년 첫 릴리즈
- 최근 릴리즈는 0.9.10 (12년 5월 31일. 업데이트가 안되는듯?)
- python 으로 만들어진 오픈소스이다. (python 관련 라이브러리를 잔뜩 설치해야한다)
- webapp 은 Django 로 만들어졌으며 , ExtJS 를 사용한다. 그래프 랜더링은 Cairo 를 사용함.
- 주요모듈은 carbon / whisper / graphite-web 이다.
- Linux / Unix (설치가 비교적 복잡한 편)
- 데이터 스키마 있음
- HTTP API / Sockets
- Numeric data only
- Sharding / replication factor 없음
- Apache 2.0 License. (굉장히 자유스러운 라이센스)
Collector는 Graphite에 어떠한 데이터를 쌓기 위한 모듈입니다. 여기에 대한 특별한 제한은 없습니다만, 시계열 데이터베이스의 특성상 기본적으로 데이터가 저장될 네임스페이스와 시간, 데이터 이렇게 3가지 데이터가 필요합니다. 이러한 정보를 Graphite의 모듈인 Carbon-Cache에 보냅니다. Carbon-Cache는 Collector가 보낸 데이터를 받아 Whisper에 저장합니다. Carbon-Cache가 데이터 수집기라면 Whisper는 실제로 데이터를 파일시스템에 저장하고 읽어오는 모듈입니다. 자 이제 Whisper를 통해 데이터가 파일 시스템에 저장되었습니다. 그렇다면 이 데이터를 어떻게 가져올 수 있을까요. 이 시점에서 등장하는 게 Graphite-Web입니다. Graphite-Web은 http 프로토콜을 통해서 Whisper에 저장된 데이터를 읽어와 이미지 파일이나, 데이터 형식으로 출력합니다. Graphite-Web은 기본적으로 데이터를 제공하는 API와 대시보드 기능 두 가지를 제공하고 있습니다. 여기서 제공하는 대시보드 기능을 그냥 사용해도 무방합니다만, 기본적으로 그렇게 편리하지는 않습니다. 직접적인 Graphite 프로젝트는 아닙니다만, 이 Graphite-Web에서 대시보드를 제외하고 API 기능만을 따로 구현해둔 Graphite-api라는 모듈도 있습니다. 다른 대시보드를 사용한다면 Graphite-Web이나 Graphite-api 어느 툴을 사용해도 무방합니다.
Grafana (http://grafana.org/)
레퍼런스:
http://brad2014.tistory.com/334
http://blog.nacyot.com/articles/2014-07-17-graphite-with-dokcer/
https://josephkim75.wordpress.com/2014/03/12/influxdb-distributed-time-series-database/
'NoSQL' 카테고리의 다른 글
| Neo4j - 인덱스 사용하기 (0) | 2015.10.30 |
|---|---|
| Neo4j 인사이드 : 파일 스토리지 (0) | 2015.10.30 |
| MongoDB vs Couchbase (2) (0) | 2015.09.03 |
| MongoDB vs Couchbase (1) (0) | 2015.09.03 |
| 카우치베이스(Couchbase) - 아키텍쳐 구조 (0) | 2015.05.06 |