2015-11-23

dynamoDBのthroughputについてメモ

aws

dynamoDBではthroughputの設定が料金に直結している。そのあたりを調べたのでわかったことをメモ。

throughputの消費

read

1unit = 1項目のconsistent read/sec (4KB以内)
consistent readを使わなければ2回で1unitとなる
4KBを超える項目を読み込む場合は2unit以上が必要になる
例えば10KBのデータなら3units, 15KBなら4units

write

1unit = 1項目の書き込み/sec (1KB以内)
1KBを超える項目を読み込む場合は2unit以上が必要になる
例えば1.5KBなら2units、4KBなら4units
indexが張られている場合はそちらへの書き込みも1項目分としてカウントされる

バースト時のthroughput

最大で直近300sec分の使っていないthroughtputをバーストに対して使うことができる。ただし、その部分のthroughtputはメンテなどの裏側の処理でも消費されているらしくフルで使えるわけではない。

partitionの設定

throughputとテーブルのデータ量に応じてpartition数が決定される。以下の式で算出されたpartition数のうち大きい方となる。

throughput

partition数 = (read throughput) / 3000 + (write throughput) / 1000

データ量

partition数 = (データ量) / 10GB
データ量はaws consoleの各テーブルの概要タブで確認できる。

参考

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/ProvisionedThroughputIntro.html
http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.Bursting
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/GuidelinesForTables.html

2015-10-30

特定ファイルの変更があるコミットだけをcherry-pick

git

まず以下のコマンドで現在までのhoge.txtの変更だけを取り出して見ることができる。

$ git log -- hoge.txt

また、以下のようにすることでコミット間の変更を取り出すことができる。

$ git log <sha1>..<sha1>
or
$ git log branchA..branchB

なのでこれらを組み合わせれば指定したコミット間で特定ファイルの変更があったコミットだけを抜き出せる。

$ git log <sha1>..<sha1> -- hoge.txt

cherry-pickの際はsha1だけ必要なのでgit logではなくgit rev-listを使う。
また、古いものから適用するために逆順に並べる。

$ git rev-list --reverse <sha1>..<sha1> -- hoge.txt

あとはこれをcherry-pickすればよい。

$ git rev-list --reverse <sha1>..<sha1> -- hoge.txt | xargs git cherry-pick --stdin

マージコミットが要らなければ--no-mergeも付ける。

conflictしたらrebase時と同じようにしていけばよい。

$ edit conflcted_file
$ git add conflcted_file
$ git cherry-pick --continue

2015-10-18

autoloadの関数が見つからない -- Unknown function: submode#enter_with

vim

vim-submodeを入れてみた際、以下のように.vimrcに設定したところエラーが出た。

NeoBundle 'kana/vim-submode'
call submode#enter_with('winsize', 'n', '', '<C-w>>', '<C-w>>')
call submode#map('winsize', 'n', '', '>', '<C-w>>');

これでloadし直すと以下のようなエラーが出た。

E117: Unknown function: submode#enter_with
E117: Unknown function: submode#map

変なところにvim-submodeが置かれてしまっているのかと思い、確認してみるとちゃんとデフォルトの位置にファイルが置いてあった。
.vim/bundle/vim-submode/autoload/submode.vim

runtimepathに含まれてないことも疑ってみた

:set runtimepath
runtimepath=...,...,...,~/.vim/bundle/vim-submode/,...

ちゃんと入っていた。

プラグインのインストールや使用準備は正しく完了しているらしい。
なのでもしやと思って関数のcallを.vimrcの最下部においてみると、、、動いた。

NeoBundleコマンドによるプラグインの読み込みがcall時に終わっていないらしい。ということで遅延読み込み時にやっているように読み込み時にhookしてコマンドの設定を行うようにした。

NeoBundle 'kana/vim-submode'
let s:bundle = neobundle#get("vim-submode")
function! s:bundle.hooks.on_source(bundle)
    call submode#enter_with('winsize', 'n', '', '<C-w>>', '<C-w>>')
    call submode#map('winsize', 'n', '', '>', '<C-w>>')
endfunction

これで問題なし。

NeoBundleコマンドによるプラグインの読み込みや初期化は同期的に完了するものと思っていたが違った模様。プラグインマネージャとしてずっと使っているがコードを見たことないので、この機会に見てみようと思った。

あと、vim-submodeの↑の設定はsplitしたウィンドウのサイズ変更を簡単にできるようにするもの。それについてはこちらのページでわかりやすくまとめてくれていた。
submode.vim とその設定例なんかを紹介 - 永遠に未完成

追記
上述の設定の場合、NeoBundleコマンド中でのhooksの実行と、on_source用のhooks登録の順番は実行タイミングに依ってしまいそうだったので、以下のようにLazyを用いるようにした。

NeoBundleLazy 'kana/vim-submode', {                                                       
    \ 'autoload': { 'mappings': ['<C-w>>'] }                
    \}                                                                                    
let s:bundle = neobundle#get("vim-submode")                                               
function! s:bundle.hooks.on_source(bundle)                                                
    call submode#enter_with('winsize', 'n', '', '<C-w>>', '<C-w>>')                       
    call submode#map('winsize', 'n', '', '>', '<C-w>>')                                   
endfunction