2012年12月6日木曜日

virtual node について


virtual nodeについて(Cassandra勉強会第24回のスライド)

http://www.slideshare.net/seki_intheforest/virtual-node


virtual nodeはバージョン1.2.0 から実装されますが
Strategy関係で問題がある為最低でも1.2.1以降からと思っておいたほうがよい

動作として単純に一つのノードに割り当てるトークンをランダムに複数持つようにする機能で
複数のノードをランダムで複数のトークンを持たせる事で比較的負荷を均等にする事ができ
レンジが多く細分化されるのでパーテショナーによってデータの偏りがあまり起こらない

また、一つのノードに複数のトークンがある際、同じノードのトークンが連続する事があるが
レプリケーションが一つのノードに二重に取られる事は無い

virtual nodeの良い点悪い点


virtual nodeの良い点
  • ランダムの値のトークンに任せるのでトークンの値のmoveの作業をしなくて良い
  • ノードがダウンした際リング内の隣のノードが複数になるので負荷が集中しない
  • ノード追加した際の他のノードの受け渡しも全体のノードで行うようになるので早い
  • ノードの負荷はレンジの領域の多さではなく、トークンの数の多さで考えられるようになる
  • パーテショナーの偏りに対応できる
virtual nodeの悪い点
  • トークンの値を任意に変更できない
  • 起動後にトークンの数を変更できない
  • virtual nodeのトークンを全体的に変更する際はノードのdecommisionをしてから再度追加する事になる
  • トークンを大量に増やさなければ比較的に分散されない
  • 大量のトークンでの nodetool ring の見栄えがすごい

virtual nodeは総合的に見て、よりメンテナンスフリーに近づく形にはなっている

virtual node をメンテナンスする上での追加ツール


virtual nodeのトークンの値を変更する為のツールも1.2から登場する
  • shuffle
現在あるトークンの値を変えずにそのトークンを別のノードに移してシャッフルする
  • バランスツール
現在未実装、恐らく1.2.1から登場する

virtual node の使用の仕方

cassandra.yaml で設定を行いcassandraを起動するとトークンが作られる

(1.2.0 beta1 の cassandra.yaml)
# This defines the number of tokens randomly assigned to this node on the ring
# The more tokens, relative to other nodes, the larger the proportion of data
# that this node will store. You probably want all nodes to have the same number
# of tokens assuming they have equal hardware capability.
#
# If you leave this unspecified, Cassandra will use the default of 1 token for legacy compatibility,
# and will use the initial_token as described below.
#
# Specifying initial_token will override this setting.
#
# If you already have a cluster with 1 token per node, and wish to migrate to 
# multiple tokens per node, see http://wiki.apache.org/cassandra/Operations
# num_tokens: 256
num_tokensをコメントアウトして持ちたいトークンの数を指定する(デフォルトだと256が入っている)
また、initial_tokenの設定は無効になる

2012年12月5日水曜日

Leveled Compactionについて

Leveled Compactionについて(Cassandra勉強会第23回のスライド)

http://www.slideshare.net/seki_intheforest/leveled-compaction
 

Leveled Compactionを選ぶ上でよい場合とそうではない場合

よい場合
  • 読み込みのレスポンスを早くしたい
  • 書き込みより読み込みが多い
  • 一定のデータが頻度に更新され、使用される
  • 頻度にRowデータの削除などを行う
そうではない場合
  • I/Oのリソースが厳しい
  • 頻繁に大量の書き込みを行う
  • 一度きりの書き込みが多い
構造上SSTableを細分化するのでレスポンスや読み込みが早くなり
細かいSSTableのコンパクションも頻度に起こるので削除データもデータから消えやすいが
同時に細かいコンパクションが多発するので頻繁に大量の書き込みをしてI/Oのリソースを常に使う場合は
I/Oのリソースが足りなくなる可能性がありお勧めできない
 

JWT(Jason Webトークン)を理解するJWT(Jason Webトークン)を理解する

JWT ( Jason Web トークン)を理解する   JSON Web Token はオープンスタンダードです。これは、任意の 2 つの機関 ( ユーザー、サーバー)間で情報を転送するために使用されます。 JWT では、ユーザーデー...