Riak관련 스터디 메모

Vnode
- vnode - process (One Erlang process per partition in the ring)
  partition - data
- Vnode는 MR 처리를 하는 Worker가 따로 있음
- VNode Master
 : Receieve msg from request corrdinator
- FSM (Finate State Machine)
  1) Type 1 : Preference list-based : single key
  2) Coverate based : entire keyspace

W+R > N : Consistency 를 보장할 수 있다.
(W : Write Replica 수)
(R : Read Replica 수)

Java SDK 에 Load Balancing  Logic 이 들어있다.

Vector Clock
- Every node has an ID (changed in ID)
- Send last-screen vector clock in every "put", "delete" request
- Riak tracks updates
 1) auto-reslves stale version
 2) Lets you decide conficts

※ Vector Clock 이 동일한 값이 나오는 경우가 Sbling 이 발생하고, 사용자가 풀어서 결정해야 한다.
- Conflict는 Network partition이 발생했을 때, 발생할 가능성이 높음
- vClock 을 update할 때, 인위적으로 같은 vClock을 동시에 넣을때 발생함
  (vClock을 GET하고, 다시 PUT할때)

Search

==============
Storage Backend
1. Bitcask
- append only KV store
- All key is stored in memory
- copaction을 통해서 garbage collection. (Stop 하지 않고 async로 발생, 언제 발생할지도 설정할 수 있다)
- 1 compaction process가 추가로 필요하다.

2. Innostore
-  Write Ahead log + B tree
- 순차대로 데이타가 insert될때, 유리 하다.
-  메모리에 Key를 안 올린다. 그래서 Bitcask에 비해 메모리 사용률이 적다.

3. LevelDB
- Append Only
- Mutiple leve of SSTable-like structure
- Secondary Index를 지원함. (BitCask는 지원 안함)
- Performance 가 Bitcask에 비해서 more variable
=======

/etc/riak/vm.config --> Erlang VM Configuration
/etc/riak/app.config --> Riak Config

====
FileSystem : ext3/4, ZFS 파일 시스템을 사용할것
Innostore 사용시 log 데이타 disk를 분리할것

===

Riak MR --> Memory를 사용하고, Disk를 사용 안함 (smallish scale)
 (무거운 MR은 Riak Hadoop Connector를 사용해서 Hadoop에서 실행)

>Pre-reduce : MAP 단계에서 Final Reduce가 발생하기 전에, pre-reduce수행
>reduce의 수행 횟수를 조정할 수 있음 : (Paging에 활용 가능) 1000개 합치는거가 100개씩 10번 수행되면 1번씩 수행해서 10개 페이지로 나눌 수 있음 (reduce_phase_only_1 옵션)
>reduce_phase_batch_size

- Riak의 하나의 Client 처럼 동작함

===

Secondary Index
--> 1/N node에서 수행되는게 문제가 아니라, 하나의 Server로 network traffice이 모이고, 나가기 때문에, Network IO (bandwidth)가 더 문제가 된다.
--> TCP retry time out 시간을 50ms 로 줄이는게 났다.
--> 결과는 Sorting되서 오지 않는다. (왜냐하면, 여러 vNode에서 오기 때문에)

=====
Riak Search
뒷단에 Index 저장은 별도의 데이타 구조체를 사용한다. (Cassandra와 유사함)

====
모니터링

=====

☆ Ring Size는 Cluster 초기 설정시에만 정할 수 있고 나중에는 바꿀 수 없다.
--> 6개월후에는 업그레이드 될것, (Dynamo 아키텍쳐의 약점)
--> Manual로는 가능

Erlang은 Each Process가 heap을 별도 가지고 있다.
Java 처럼 Heap을 share하지 않기 때문에 GC 문제도 안나고
모니터링도 Physical memory만 하면 된다.

=====
덤프 툴 같은 것도 있고
Erlang Shell로 붙어서 모니터링도 가능

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

데이타 모델링 관점
서버 셋업,운영 (장애 대처 및 튜닝)