감각적신사 의 멱살잡고 IT

# DynamoDB Table 설계

---------------------------

1. 요소

        - 프라이머리 키 선택 = 유니크 키

        - 개별 항목에 대한 작업 부하 패턴

2. 테이블 설계 시, 고려 사항

- Randomizing Across Multiple Hash Key Values

- suffix set 를 이용하여 프라이머리키를 고르게 분포되도록 한다 ( write / read 속도 향상 )

- example: 2014-07-09.1, 2014-07-09.2 ~ 2014-07-09.200

- Understand Partition Behavior

- aws 에 의해 table 이 커지면 새로운 partition 이 추가된다

- partition 크기 관련 고려사항

- 테이블 데이터 사이즈

- Provisioned Throughput

- Use Burst Capacity Sparingly

- 설정한 Throughput 만큼 사용하지 않아 남은 것을 "burst" 라 한다

- DynamoDB 는 최근 5분에 대한 "burst" 보관하여 일시적으로 더 빠른 Throughput 를 일시적으로 제공한다

- 일시적으로 사용가능할 뿐 이 값을 의존하여 설계하면 안된다

- Understand Access Patterns for Time Series Data

- Old data 를 S3 로 이동

        - Cache Popular Items

- aws 의  ElastiCache 를 이용하여 cache layer 를 구성하는 것을 권장

3. Item 설계

- Use One-to-Many Tables Instead Of Large Set Attributes

- 한 table 에 많은 column 을 만드는 것보다 여러 table 로 중복되게 저장하는 것이 좋다

- 이유

- 하나의 큰 size 를 읽는 것보다 여러 작은 size 를 읽는 것이 비용적으로 효율적인다

- 작은 데이터 가 입출력 I/O 가 더 좋다

- example

- 많은 attr 테이블

- attr 가 적은 테이블 지향

- 긴 Attribute Values 저장하는 것을 지양

- GZIP or LZO 알고리즘 사용하여 압축

- Amazon S3 에 값을 저장

- Multiple Items 으로 쪼개어 저장

- cross-item transactions 을 지원하지 않는 점을 고려하여 설계에 유의

4. Query 조건 고려사항

- Avoid Sudden Bursts of Read Activity

- Reduce Page Size : a Scan operation reads an entire page (by default, 1 MB)

- Isolate Scan Operations

- Take Advantage of Parallel Scans : "sweeper" process

- 조건

- The table size is 20 GB or larger

- Sequential Scan operations are too slow

- 그러나 비싼 과금 지불이 필요하다

5. Secondary Indexes

- 개념

- DynamoDB 는 일반적으로 primary key (hash OR hash+range) 에 대한 index 를 지원한다

- key column 을 제외한 나머지 column 으로 조건을 걸어 조회시, scan 형태로 전체 데이터를 받아온 뒤, 가공하게 된다

- 그래서 **Secondary Indexes** 가 필요하다

- 종류

- Global Secondary Indexes

- index 처리한 column 으로 새로운 table 을 생성하여, 기존 테이블과 비동기 방식으로 데이터를 맞춘다

- 별도의 테이블 이 생성된다

- Local Secondary Indexes : 

- 별도의 테이블 생성 없이 기존의 테이블에 추가적으로 작업

- 지원 옵션

- KEYS_ONLY : 가장 작은 단위의 옵션. 단일 column 을 index 로 활용한다

- INCLUDE : KEYS_ONLY 에 추가적으로 column 을 추가하여 index 로 활용한다

- ALL : 모든 column 을 index 로 활용한다

        - 별도의 Throughput 설정이 필요하다

6. 가이드 라인 in AWS

- primary 키 선택

- 통일된 작업에 사용될 키를 사용해라

- 값이 고르게 분포될 수 있는 값을 선택해라 == 특정 부분에 집중되어 있는 값을 선택할 경우, 값을 가져오기 힘들다

- 인덱스 선정 시, Take Advantage of Sparse Indexes

- 일부 컬럼에서는 가지고 있지 않은 값을 선택하는 것이 좋다 == index_table 자체를 작게 가져갈 수 있기 때문이다

- 인덱스 사용 시, Use a Global Secondary Index For Quick Lookups

- use non key 

- use key : index table 에 컬럼을 일부만 사용

- 읽기 조건 사용 : Create an Eventually Consistent Read Replica

- 자주 사용하지 않을 index 를 만들지 마라 == 파일 I/O 가 더 발생하게 된다

0. 데이터 분산 모델

- Master-Slave 복제

- master node : read/write 가능

- slave node : read 만 가능, master node 의 데이터를 동기화 한다

- Peer to Peer 복제

- 모든 node 에 대한 read/write 가능

- 하나의 node 에 대한 write 요청이 실패할 경우, write 실패

- Sharding

- write 에 대한 수평확장을 제공

- 저장 node 에 대한 매커니즘(샤딩키)을 정의 하여 사용

- 샤딩 적용시 고려사항

- 샤딩키 : 성능을 좌우하는 결정적 요소, 

                                        cardinality (==분포도) 가 적절한 필드 선택해야 한다 (낮으면 한 노드에 집중될수도...)

- 샤딩키 분배방식

- range : 데이터 분포를 예측 할수 있어야 한다

- hash

- 데이터 재분배 rebalancing

- 샤드간 데이터 조인 최소화

- 한 node 로 부터 요청에 대한 데이터를 얻을 수 있도록 데이터를 분산시켜야 한다

- Sharding + Peer to Peer 복제

- column family 형 nosql 에서 주로 사용하는 전략

- Scalability 에 따른 데이터 분산 모델

1. 관계형 DB 의 한계

- 관계형 DB 의 Scalability

- MPP(massively parallel processing) 방식의 scale out 아키텍처를 통해 RDB의 DW 계열의 Scalability 를 지원하지만, OLTP 용도의 DB, OSS DB 로 적합한 제품을 찾기 어렵다

- 관계형 DB 의 Sharding 구현

                - 자동으로 샤딩 기능 지원 하는 DBMS 사용

                - sharding 플랫폼 도입

                - application 단에서 처리하는 방법

                    - 다양한 용도로 사용하기 어렵다

                    - ex : user key 를 샤딩키로 적용하여 application 단에서 DB 를 선택적으로 이용

2. NOSQL 배경

        - 새로운 데이터 타입의 등장 / 방대한 양의 데이터

        - 확장성(Scalability) 에 대한 needs 의 증가 >> 관계형 DB 의 Scalability 는 기술적으로 제한된다

        - 주로 DB 가 병목지점이다

        - read 분산은 쉬우나 write 분산은 쉽지 않다

3. NOSQL 개념

        - 정의 : 비관계형/비구조적 데이터 를 저장하기 위한 분산 저장 시스템

        -  특징

            - 조인 기능 없음

            - 대부분 open source

            - 클러스터 환경에서 구동하며 자동 샤딩을 제공한다

            - 분산, 수평적 확장이 용이

            - auto failover 지원

- 제품 분류

1. 정의 

- C++로 작성된 오픈소스 문서지향(Document-Oriented) 적 Cross-platform 데이터베이스

2. 데이터 모델

- Database : Collection 들의 물리적인 컨테이너 로 파일시스템에 여러파일들로 저장된다

- Collection : MongoDB Document의 그룹 으로 schemaless 하다

- Document

- Document는 RDMS의 record 와 비슷한 개념으로 한개이상의 key-value pair 으로 이뤄져있습니다

{

"_id": ObjectId("4b866f08234ae01d21d89604"),

"username": "mr.sense",

"address": { city: "seoul", zipcode: "11140"" }

}

- _id 는 12bytes의 hexadecimal 값으로서, 각 document의 유일함(uniqueness)을 제공 _

- Document 는 동적(dynamic)의 schema 를 갖는다

3. architecture

- 구성

- mongos

- mongos demon : router

- config server : sharding meta 정보를 관리한다

- mongod

- primary : read/write

- secondary : read only

4. features

    - hash, range 방식의 sharding 방식 지원

    - auto failover 지원

        - primary node 가 down 시, election 을 통해 secondary 가 primary 로 선출

    - replica

    - primary 의 write 이후 작성되는 oplog 를 전송받아 secondary 에 write 한다(최대 11)

5. 데이터 구조

- 논리 데이터 구조 

- 하나의 collection 에 대해 b-tree 구조 로 복수개의 index 를 관리한다

- extent : 데이터가 저장되는 논리적인 단위

- document : 정렬된 key/value의 집합

- 물리 데이터 구조

- OS에 의해서 제공되는 Virtual Memory를 사용하게 되는데, Pysical Memory 양이 작더라도 Virtual Memory는 훨씬 큰 공간을 가질 수 있다

(하지만 메모리 사이즈가 작으면 page fault 가 자주 발생해서 시스템이 느려진다)

- Virtual Memory는 page라는 블럭 단위로 나뉘어 지고, 이 Block들은 Disk의 block에 mapping이되고, 이 block들의 집합이 하나의 데이타 파일이 된다

- memory block -- OS 에 의한 write --> disk block

6. read / write

    - write 

        - step1. primary memory 에 write

        - step2. primary disk 로 flush

        - step3. secondary 요청으로 Oplog 를 복사 후 적용

        - (*) 이 때, write 성공의 조건은 write concern type 에 의해 결정된다

    - read

    - https://docs.mongodb.com/manual/core/read-preference/

    - "local" readConcern :  reads from the primary reflect the latest writes in absence of a failover;

- "majority" readConcern : read operations from the primary or the secondaries have eventual consistency.

7. lock

- database 단위의 lock 을 지원한다 == document 의 변경시 database 전체가 write lock 발생

참고

https://docs.mongodb.com

http://bigmatch.i-um.net/2013/12/mongodb%EB%A5%BC-%EC%93%B0%EB%A9%B4%EC%84%9C-%EC%95%8C%EA%B2%8C-%EB%90%9C-%EA%B2%83%EB%93%A4/

# HBase

------------

1. 정의 : HDFS에 구현한 분산 컬럼 기반 database

2. hiostory :

- 2006년 말 : 구글의 빅테이블(구조화된 데이터용 분산 스토리지 시스템)을 모델 을 기반으로 시작

- 2007년 10월, HBase 배포판 open

- 2010년 5월, 하둡 서브프로젝트 > 아파치 최고 수준 프로젝트 로 등록

- 도입 사례 : 어도비, 스텀블 어폰, 트위터, 야후 등

3. pre requirements

- java 7 이상

4. architecture

- feature

- Master - Slaver(region server) 구조 이다

- Zookeeper : 분산 시스템 코디네이터

- region 단위로 auto sharding 을 지원

5. 데이터 모델

- Table

- Row들의 집합 (Row Key가 있으며 다수의 column family로 구성)

- Schema 정의서 Column Family 만 정의

- Row Key

- 임의의 Byte열로 사전순으로 내림차순 정렬

    - 빈 Byte문자열은 테이블의 시작과 끝을 의미

- 문자열, 정수 바이너리, 직렬화된 데이터 구조까지 어떤 것도 로우키가 될 수 있다

- Column Family

- Column들의 그룹으로 모든 컬럼패밀리의 Member는 같은 접두사를 사용

- NOSQL:Cassandra와 NOSQL:HBASE 는 NOSQL이라는 컬럼 패밀리의 멤버컬럼

- 컬럼패밀리 접두사는 반드시 표시할 수 있는 문자로 구성

- 테이블 스키마에서 정의의 한 부분을 먼저 지정해야 한다

- 모든 컬럼패밀리 멤버는 물리적으로 파일시스템에서 함께 저장

- 새로운 컬럼패밀리 멤버는 동적으로 추가가능

- Cell

- ROW KEY & Column & Version이 명시된 튜플

- 값은 임의의 Byte열이며 Timestamp

- 테이블 셀은 버전관리 된다 (오직 셀들만)

6. 논리 스토리지 구조

- 하나의 key-value (column)에 대한 data block

- Row key : sharding key 이면서 유일한 key

- Column Quailifier : 컬럼 명

- row size 계산

- physical key 에 해당하는 고정 값 들의 byte 합이 기본으로 저장된다

- 따라서 rowkey, column family name, column qualifier 의 이름은 짧게 유지하는 것이 좋다

6. Sharding 기준

- Row key 기준으로 Range Sharding 방식을 따른다

- Row range 단위로 물리 Region 을 생성

- Region 을 RegionServer 로 분산하여 관리

7. write / read 방식

- write

- step 1 : wal 파일에 transaction 정보 입력

- step 2 : memstore 에 데이터 기록 후 client 에 결과 return

- step 3 : memstore full 시 disk 에 write

- step 4 : disk compaction

- read

- step 1 : read from memstore

- step 2 : step 1 에서 결과를 받지 못하였을 때, read from block cache

- step 3 : step 2 에서 결과를 받지 못하였을 때, read from disk

          (block cache write 이후에 client 에게 전달)

8. replication

- master - slave replication : master(write) <- sync - slave

- master - master replication (== peer to peer) : 각각이 master 로 write 실행

- cyclic replication : write node <- replica - other node

- request 에 따라 매번 다른 node 에 write 를 요청하며 write 가 일어난 node 를 다른 node 에서 replication 한다

9. consistency level

- write consistency : wal 파일과 memstore 에 저장 성공이면 replica 의 성공여부와 상관없이 success

- read consistency : 선택한 하나의 node 에서 read 요청

(== cassandra 의 ONE level 과 유사)

10. DR 아키텍쳐

    - cluster 간 replication

- master cluster 는 wal reader 가 wal 파일 을 읽어 waledits 형태로 전송 준비를 함

- replication 우선순위 queue 에 waledits 를 저장

- slave cluster 는 queue 에서 오래된 waledits 부터 비동기 방식으로 순차적으로 처리

    - zookeeper 역할

    - slave cluster 등록

    - replication 시작/중지

    - queue 에 wal 등록

    - region server 의 장애 핸들링

참조

https://hbase.apache.org/book.html

http://wiki.gurubee.net/display/DEVSTUDY/NoSQL+HBase

java client of couchbase  

------------

1. 자바 클라이언트 적용  

- pom.xml 에 관련 dependency 추가  

-

    <dependency>

      <groupId>com.couchbase.client</groupId>

      <artifactId>couchbase-client</artifactId>

      <version>1.2.3</version>

    </dependency>

  - client 호출  

  - 

  public CouchbaseClient getCouchbaseClient(){

    CouchbaseClient couchbaseClient = null;

    ArrayList<URI> nodes = new ArrayList<URI>();

    // Add one or more nodes of your cluster (exchange the IP with yours)

    nodes.add(URI.create("http://lvm001:8091/pools"));

    try {

    couchbaseClient = new CouchbaseClient(nodes, "default", "");

    } catch (Exception e) {

    System.err.println("Error connecting to Couchbase: " + e.getMessage());

    System.exit(1);

    }

    return couchbaseClient;

 }

2. 자바 클라이언트를 통한 read/write to couchbase  

    - data 저장방식  

- java object : java 에서 생성한 object 그대로 입출력, admin-web 에서 json document 형태로 확인이 가능  

- json object : java object 를 json 형태의 object 로 변환하여 입출력, admin-web 에서 json document 형태로 확인이 가능  

- string : java object 를 string 형태로 변환하여 입출력, admin-web 에서 json document 형태로 확인 불가  

    - example  

    - java object  

        public void setObject(String id, CouchbaseVO couchbaseVO){  

      couchbaseClient.add(id, couchbaseVO);  

      }  

      public CouchbaseVO getObject(String id){

      CouchbaseVO couchbaseVO = null;  

      couchbaseVO = (CouchbaseVO)couchbaseClient.get(id);  

      return couchbaseVO;  

      }

    - json obejct  

        public void setJsonObject(String id, CouchbaseVO couchbaseVO){

      Gson gson = new Gson();  

      couchbaseClient.set(id, gson.toJson(couchbaseVO));  

        }

        public CouchbaseVO getJsonObject(String id){  

        Gson gson = new Gson();  

        CouchbaseVO couchbaseVO = null;  

        couchbaseVO = gson.fromJson((String)couchbaseClient.get(id), CouchbaseVO.class);  

        return couchbaseVO;  

        }

    - string   

        public void setString(String id, CouchbaseVO couchbaseVO){  

            couchbaseClient.set(id, couchbaseVO.toString());  

        }   

        public CouchbaseVO getString(String id){  

        CouchbaseVO couchbaseVO = null;  

        String value = (String) couchbaseClient.get(id);      

        couchbaseVO = CouchbaseVO.convert(value);       

        return couchbaseVO;      

        }   

      - 비교

- write : string > java == json  

- read : string > java == json  

- 큰 차이가 존재하지는 않았으나 string 타입으로 처리하는 것이 빠른 속도를 내는 것으로 보였다  

- but  

- string 타입은 web 상으로 값이 구분이 안되기 때문에 잘 데이터 확인이 필요한 수준을 판단해야 한다  

- object 를 string 타입으로 잘 변환할 수 있는 java code 를 구현해야 한다

# hector - cassandra java client

1. pool architecture

- cassandraHostRetryService : 다운된 node 에 대한 재시도

- retryDownedHosts: 서비스 사용유무 . 기본값 true

- retryDownedHostsQueueSize: 모니터링 할 node 수 . 기본값 -1 (전체)

- retryDownedHostsDelayInSeconds: 사용주기 . 기본값 10 sec

- nodeAutoDiscoverService : 새로운 node 에 대한 ring 에 추가할 것인가

- autoDiscoverHosts: 서비스 사용유무 . 기본값 false

- autoDiscoveryDelayInSeconds: 사용주기 . 기본값 30 sec

- autoDiscoveryDataCenters: 특정 datacenter 에 한한 서비스 사용 . 기본값 전체

2. 데이터 일관성 (read , write 따로 적용 가능)

- ANY: 복제본에 대한 응답이 존재할 때 까지 대기  

- ONE: 복제본 1개에 대한 응답이 존재할 때 까지 대기

- TWO: 복제본 2개에 대한 응답이 존재할 때 까지 대기

- THREE: 복제본 3개에 대한 응답이 존재할 때 까지 대기

- QUORUM: (replicationi_factor / 2 ) + 1 개 만큼의 복제본이 응답할 때 까지 대기

- LOCAL_QUORUM: 동일 데이터 센터에서 quorum 만큼의 응답 대기

- EACH_QUORUM: 각각의 데이터 센터에서 quorum 만큼의 응답 대기

- ALL: 모든 replicationi_factor 만큼의 복제본 응답 대기

3. feature

- connection pooling

- 클라이언트 단에서의 장애조치 기능

- JMX(Java Management Extension) 기반의 모니터링

- load balancing 에 대한 설정 기능

- thrift 통신에 대한 캡슐화 , 숨김

- 다운된 node 에 대한 자동 재시도

- 추가된 node 에 대한 자동 검색

- 쉽게 사용할 수 있는 ORM(Object-Relational Mappging)

- cassandra’s data model 에 맞는 type-safe approach

4. hector object mapper

- 카산드라 데이터 저장 단위에 mapping 되도록 지원하는 모듈

- 설정 및 사용

      @Entity

 @Table(name="TestColumnFamily")

 public class MyPojo {

   @Id // rowkey

   private UUID id;

   @Column(name="col1")

   private long longProp1;

      @me.prettyprint.hom.annotations.Column(name = "color", converter = ColorConverter.class)

      private Colors color;

 private Map<String, String> anonymousProps = new HashMap<String, String>();

   @AnonymousPropertyAddHandler

   public void addAnonymousProp(String name, String value) {

    anonymousProps.put(name, value);

   }

      }

    Keyspace keyspace = HFactory.createKeyspace("TestKeyspace", cluster);

         entityMgr = new EntityManagerImpl(keyspace, "패키지명");

    MyPojo pojo = new MyPojo();

    pojo.setId(asdd-asdasd-asdsad-asdasd);

    pojo.setLongProp1(0L);

    pojo.setColor("black");

    // 저장

    entityMgr.persist(desk);

    // 읽어오기

    MyPojo loadPojo = entityMgr.load(MyPojo.class, "asdd-asdasd-asdsad-asdasd");

# astyanax - cassandra java client

1. hector lib 를 리팩토링한 lib

2. 3 main part

- connection pool : 다양한 방법으로 load balancing 구현

- cassandra-thrift API implementation

- recipes and utilities : csv import 가능

3. util

- CSV importer

- JSON exporter

4. feature

- context 설정을 통해 장애조치

- 특정 node 에 요청 보내도록 하는 기능

- 토큰 범위를 통한 Host partitions

- latency tracking 기능

- load balancing 선택 가능

- 다운된 node 에 대한 요청 보내지 않음

- JMX 를 통한 모니터링 (단, 커낵션 pool 내부에 대한 로깅 X)

- 다운된 node 자동 재시도

- 추가된 node 자동 검색

- Minimal use of synchronized by using non-blocking data structures

# java driver - cassandra java client

1. datastax 에서 cql 언어를 java 단에서 사용하기 위해 제공

2. 적합성  

3. feature

- Asynchronous

- Nodes discovery

- Configurable load balancing

- Transparent failover

- Convenient schema access

4. cql문과 cassandra-cli 를 통해 생성된 스키마 간의 호환

- 일부 호환 (select * : o) (insert : x)

- 생성된 스키마에 대한 다른 방법으로 변경 불가

# lib 비교

# lib 비교 분석을 통한 cassandra 사용에 대한 사견

1. cql 사용시 최소한의 리소스로 원하는 데이터를 얻을 수 있다.    

- 상황 : sns 를 사용하는 user 를 출력하고 싶다

- cql : select * from UserCF where use_sns='Y';

- cassandra-cli :

1) get[UserCF];

2) use_sns='Y' 에 대해 추가 작업 필요

2. 단, cql 로 생성하지 않는 스키마에서는 cql 의 모든 기능을 사용하기엔 제한된다.

- cassandra-cli 로 생성한 Column Family 에서는 select column명 from CF; (동작하지 않았다)

- cassandra-cli 로 생성한 Column Family 의 스키마 변경이 되지 않았다

3. 그러나~ cql 스키마로 생성하기에는 데이터 모델링에 대한 소요 가 많다.

- DB 에 대한 깊이가 얕은 나로서는 사용하기 적합하지 않다

- append 가 자유롭고 구조가 유연하다는 장점이 발휘되지 않는다는 느낌이 조금 있다

- column key 가 알지 못하는 값으로 들어올 경우 cql 로는 얻기 어렵다? -> select * 을 통해서만 값을 가져올 수 있다

4. 그렇다면!!! hector, astyanax 등으로도 유연하면서 리소스를 잘 다룰수 있는 스키마 생성이 필요하다

- column 에는 많은 정보를 담지 않는다 -> json, map 타입의 데이터는 안 좋지 않을까, 대신 컬럼을 많이 늘리자

- CF 에 대한 rowkey 관리가 필요하다 -> rowkey 는 select * 을 통해 얻거나 client 가 직접 알고 있어야만 하는 정보이다

# Intro of DynamoDB  

1. intro  

- Nosql Database service  

- SSD 구축  

- aws 에 의해 관리  

- 데이터 분할, 복제  

- 서버용량 프로비저닝  

2. consistency  

- write : 3 replica 유지 (aws S3 와 마찬가지로 3개의 region 에 복제본 유지)  

- 복제 관리는 aws 에 의해 관리됨  

- read : 

- *Eventually Consistent Read(default)* : 읽기 처리량 최대, 최신 기록을 반영하지 못할 수도 있다.  

- 문서에 의하면 1초 이내에 최신 기록을 3 복제로 반영해준다고 한다  

- Strongly Consistent Read : 해당 읽기 전에 성공적인 응답을 수신한 모든 쓰기를 반영한 결과를 반환함  

3. feature  

- 다양한 쿼리 지원  

- GET : 1 MB 이내 컬럼 처리  

- GetItem

- BatchGet : 다중 컬럼 입력 가능

- SET : 1 MB 이내 컬럼 처리  

- PutItem

- BatchPut : 다중 컬럼 입력 가능

- UPDATE  

- DELETE  

- **TODO : batch 와 일반 입출력 성능 비교?**

    - 조건부 연산 지원  

    - boolean 함수 : ATTRIBUTE_EXIST, CONTAINS, BEGINS_WITH  

    - 비교 : =, <>, Between, In  

    - 논리 : NOT, AND, OR  

    - 증가, 감소 지원  

4. data model  

- table  

- item 의 모음  

- primary key 는 반드시 지정해야 한다

- 제한 사항

- item 의 개수 제한이 없다

- 한 리전에 최대 256 개의 테이블 생성 가능 (추가 생성요청은 aws 통해서..)

- item  

- attribute 의 모음  

- 제한 사항

            - attribute 의 개수 제한이 없다

        - 한 item 의 attribute (key,value) 의 총 합은 400 KB 이하여야 한다

        - attribute

          - key-value 의 조합

            - hash key (필수) == primary key     /     range key (선택)

5. data type  

- scalar data type : number, string, binary

- multi-valued type : number set, string set, binart set

# opscenter - cassandra monitor tool

1. opscenter 소개

- DataStax 에서 제공하는 cassandra monitoring , data explorer

- JMX 를 이용하여 모니터링과 node management 를 한다

2. opscenter 설치

- cassandra 가 설치 되어있어야 한다

- 다운로드 http://www.datastax.com/what-we-offer/products-services/datastax-opscenter

- python ./bin/setup.py

- 실행 : ./bin/opscenter

- 실행 확인 : http://localhost:8888

3. opscenter 사용

- 기존 multi cluster 를 모니터링 한다

- cluster 추가시 해당 node 에 agent 를 설치해야되기 때문에 sudo user 의 id/pw 를 입력한다

   - NODES 메뉴에서 추가된 ring 을 확인할 수 있음         

# cassandra 간단설치

1. cassandra 소개

    - 오픈소스 분산 데이터베이스 관리 시스템

    - 아마존 다이나모 분산 디자인 과 구글 빅데이블 의 데이터 모델을 기반으로 페이스북에서 활용

2. cassandra 다운로드

    - http://cassandra.apache.org

    - cassandra 2.0 이후 부터는 java 1.7 에서 동작한다

3. 압축 풀기 및 기본 설정

    - ./bin : 실행 파일 cassandra , cassandra-cli 가 존재한다

    - ./conf : cassandra.yaml --> TODO 정리 필요

        - 기본적으로 /var/lib , /var/log 를 path 로 사용

        - sudo chown -R 소유자.소유자그룹 /var/lib/cassandr /var/log/cassandra

4. 실행

    - ./bin/cassandra

# cassandra multi cluster 구성하기

1. vm 구성

- 3개의 노드 준비 (lvm001, lvm002, lvm003)

- /etc/hosts 에 각 노드 등록 : (ip hostname)

- vm 간 방화벽 확인 (port 9160)

- cassandra.yaml

- rpc_port: 9160

- 각자 동작 중인 cassandra 중지 및 데이터 삭제 , commit log 삭제 (/var/lib/cassandra ...)

- cassandra.yaml : 

- data_file_directories: /usr/local/var/lib/cassandra/data

- commitlog_directory: /usr/local/var/lib/cassandra/commitlog

2. 단일 데이터센터 내 멀티 클러스터로 구성하기

- cassandra.yaml 파일 수정

- cluster_name: 'MyDemoCluster'

- num_tokens: 256

- seed_provider:

 - class_name: org.apache.cassandra.locator.SimpleSeedProvider

    - parameters:

          - seeds:  "lvm001"

- listen_address: lvm001 (* 본인 vm 의 값을 넣어준다)

- rpc_address: 0.0.0.0

- endpoint_snitch: RackInferringSnitch

- auto_bootstrap: false : 없는 옵션이므로 추가한다

3. 클러스터 구성 확인하기

- 실행 : ./bin/cassandra &

- 구성확인 : ./bin/nodetool status

4. cassandra.yaml

- path : ./conf/cassandra/yaml *or* /etc/cassandra/conf/cassandra.yaml

- 수정 point

- listen_address : 노드 간 통신하기 위한 address

- default 값은 localhost

- 0.0.0.0 은 노드간 통신 불가

- 멀티노드 구성시 변경이 필요하다

- rpc_address : client 가 접근할 수 있도록 listen address 지정

- default 값은 localhost

- 0.0.0.0 : 전 ip 에 대해 접근 가능하도록 변경

    - rpc_port : client 가 접근할 수 있도록 listen port 지정  

    - seed_provider : 노드가 추가될 때 contact point

    - default 값은 127.0.0.1

    - 멀티노드 구성시 변경이 필요하다

# DynamoDB in detail

1. index

- 기본 index : primary key 를 이용 (default)

- Local Secondary Index : 메인 테이블과 별개로 테이블이 생성되는 것은 아니고, 데이터를 저장하는 물리적인 node의 local storage에 색인 데이터가 생성

- Global Secondary Index : 메인 테이블과 별개로 새로운 테이블이 생성되고, 메인 테이블의 일부 item들을 projection한 결과를 저장할 수 있음

2. provisioned throughput

- aws 는 저장용량에 대한 비용 외로 추가적으로 read/write 에 대한 성능을 보장하면서 비용을 더 받는다

- 가격정책은 http://aws.amazon.com/ko/dynamodb/pricing/ 서 확인 가능하다

- Unit : 초당 읽은/쓴 아이템 수 * kb 단위 아이템 크기

- Read Capacity Units

- Eventually Consistent Read * 2 = Strongly Consistent Read

- 200 GetItem = 10 BatchGet (50 times) : api call 수가 아닌 아이템 수 이다...

- Write Capacity Units

- example : 512 byte * 200 read/sec = 1kb * 200 = 200 unit

        - 10TB 이상의 경우 실제 물리 서버가 나뉘게 되는데 이때 throughput 은 나뉘진 물리 서버 갯수만큼 나누어 적용되게 된다

   - example : 10 WCP 의 table 의 경우 node 10개 일 때 각각 1 WC 가 적용된다

3. Get the item

- 2가지 조회 방법이 있으며 두 방법 다 최대 1 mb 까지 조회 가능하다

- scan : 조건 없이 table 내의 모든 item 반환

- query : 조건(primary key)을 통해 해당되는 item 반환

4. Local Test

- http://dynamodb-local.s3-website-us-west-2.amazonaws.com/dynamodb_local_latest.tar.gz

- 압축 해제

- 실행 : java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar 

- 실행옵션

- -port 8888 : 8888 port 로 사용한다 (기본포트는 8000)

- -inMemory : db파일 생성하지 않고 memory 를 사용한다

    - 실행 확인

     - web : http://localhost:8888/shell

     - java client

        client = new AmazonDynamoDBClient(credentials);

               client.setEndpoint("http://localhost:8888");

5. 기타 제약 사항

- http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html