tmux
デフォルトはctrl + bだけど、置き換えたほうが使いやすい...
ショートカットキー
- ペイン分割（縦）
- ctrl + b %
- ペイン分割（横）
- ctrl + b "
- ペインレイアウト変更
- ctrl + b [space]
- ペイントを閉じる
- ctrl + b &
コマンド
- 再接続
- tmux attach
screen
- セッションのデタッチ
- ctrl + a , ctrl +d
- セッションの再接続
- screen -r
- セッション一覧
- screen -ls
2013年10月25日金曜日
tmux & screen チートシート
デフォルトはctrl + bだけど、置き換えたほうが使いやすい...
ショートカットキー
コマンド
Clean Code 2章のメモ
社内の輪講で使ったやつ
2章
意味のある名前
意図が明確な名前にする
これはだめ
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if( x[0] == 4 )
list1.add(x);
return list1;
}
ここがよくない
・暗黙さ
こんなかんじ
public<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
flaggedCells.add(cell);
return flaggedCells;
}
偽情報を避ける
似情報の例
・hp,aix,sco などの変数
unix由来？と錯覚する
・Listではないものに、hogeListとする
acoountsぐらいにしておく
・ごく一部のみが違う名前
・小文字のL,大文字のOなど
意味のある対比を行う
ノイズワード
・数字の連続（a1,a2...）
無情報です
source,destinationなど意味のあるものに
・意味のはっきりしない単語
Info? Data?
おなじです
・aとかtheのようなもの
明確な違いが生じるのであればOK
zorkがあるときに、theZorkはNG
発音可能な名前を使用する
・英単語として発音できるものにしよう
検索可能な名前を用いる
・1文字の名前は小さなメソッドのローカル変数でのみOK
・長い定数はあり
なるべく、enum、でいいんじゃね？
エンコーディングを避ける
・読めないものはよくない
・新たなことを覚えさせるのもだるい
ハンガリアン記法
・辞めよう
例）
long整数 lData
PhoneNumber phoneString; // やってしまう...
メンバープレフィックス
・m_など
そもそもなんで昔つかってたの？？
インターフェースと実装
・Iを前置、IHogeFactory
やめよう
・HogeFactoryImp or CHogeFactory
Cは具象のconcreteかな
メンタルマッピングを避ける
・i,j,kはループの中ぐらいなら可
・プロのプログラマは透明性を大事にする（賢い、のではない）
クラス名
・名詞あるいは名詞句をつけろ
Customer,WikiPage,Account,AddressParserCustomer
・Manager,Processor,Data,Info は避けるべき
・動詞を避けるべき
メソッド名
・postPayment,DeletePage,save などの動詞、動詞句
・Accessors,mutators,predicatesといった名前はメソッドが扱う値に付けるべき(get,set,isを前置しろ)
・コンストラクタがオーバーロードされている場合は、staticなファクトリメソッドを用意し、名前に引数を表現するものを含める
気取らない
１つのコンセプトには１つの単語
・複数のクラスで、fetch,retrieve,getを同じ意味で提供するとかやってはいけない
・controller,manager,driver なんかも紛らわしい
・整合性を持った語彙が大切
語呂合わせをしない
・addに、連結とコレクションの追記、２つの意味があるなどやってはいけない
解決領域の用語の使用
・すべての名前をいちいち業務用語か取り出すのは推奨しない
・プログラマーが分かる言葉（JobQueue,AccountVisitor）がよい
問題領域の用語の使用
・処理がプログラマちっくでないのであれば、業務側から用語を持ってきてもよい
意味のある文脈を加える
根拠のない文脈を与えない
2章
意味のある名前
意図が明確な名前にする
これはだめ
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if( x[0] == 4 )
list1.add(x);
return list1;
}
ここがよくない
・暗黙さ
こんなかんじ
public<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
flaggedCells.add(cell);
return flaggedCells;
}
偽情報を避ける
似情報の例
・hp,aix,sco などの変数
unix由来？と錯覚する
・Listではないものに、hogeListとする
acoountsぐらいにしておく
・ごく一部のみが違う名前
・小文字のL,大文字のOなど
意味のある対比を行う
ノイズワード
・数字の連続（a1,a2...）
無情報です
source,destinationなど意味のあるものに
・意味のはっきりしない単語
Info? Data?
おなじです
・aとかtheのようなもの
明確な違いが生じるのであればOK
zorkがあるときに、theZorkはNG
発音可能な名前を使用する
・英単語として発音できるものにしよう
検索可能な名前を用いる
・1文字の名前は小さなメソッドのローカル変数でのみOK
・長い定数はあり
なるべく、enum、でいいんじゃね？
エンコーディングを避ける
・読めないものはよくない
・新たなことを覚えさせるのもだるい
ハンガリアン記法
・辞めよう
例）
long整数 lData
PhoneNumber phoneString; // やってしまう...
メンバープレフィックス
・m_など
そもそもなんで昔つかってたの？？
インターフェースと実装
・Iを前置、IHogeFactory
やめよう
・HogeFactoryImp or CHogeFactory
Cは具象のconcreteかな
メンタルマッピングを避ける
・i,j,kはループの中ぐらいなら可
・プロのプログラマは透明性を大事にする（賢い、のではない）
クラス名
・名詞あるいは名詞句をつけろ
Customer,WikiPage,Account,AddressParserCustomer
・Manager,Processor,Data,Info は避けるべき
・動詞を避けるべき
メソッド名
・postPayment,DeletePage,save などの動詞、動詞句
・Accessors,mutators,predicatesといった名前はメソッドが扱う値に付けるべき(get,set,isを前置しろ)
・コンストラクタがオーバーロードされている場合は、staticなファクトリメソッドを用意し、名前に引数を表現するものを含める
気取らない
１つのコンセプトには１つの単語
・複数のクラスで、fetch,retrieve,getを同じ意味で提供するとかやってはいけない
・controller,manager,driver なんかも紛らわしい
・整合性を持った語彙が大切
語呂合わせをしない
・addに、連結とコレクションの追記、２つの意味があるなどやってはいけない
解決領域の用語の使用
・すべての名前をいちいち業務用語か取り出すのは推奨しない
・プログラマーが分かる言葉（JobQueue,AccountVisitor）がよい
問題領域の用語の使用
・処理がプログラマちっくでないのであれば、業務側から用語を持ってきてもよい
意味のある文脈を加える
根拠のない文脈を与えない
2013年10月18日金曜日
eclipse俺俺チートシート
ショートカット
(macなんで、ctrl ≒ cmd)
まだ書きかけ
(macなんで、ctrl ≒ cmd)
移動
- ジャンプ
- f3
- ジャンプからもどる
- cmd + [
- クラス検索
- cmd + shift + r
- クイック階層移動
- cmd + t
- workspaceの検索
- ctrl + h
生成
- javadoc生成
- cmd + shift + j
整形
- フォーマット
- cmd + shift + f
TIPS
参考になるリンク
http://hutyao.hatenablog.com/entry/eclipse-shortcutkey
まだ書きかけ
2013年10月8日火曜日
自前のWordPressを運用する意義が見いだせなくなったので、Bloggerに引っ越しました。
wordpress形式をexportしたものを下記のサイトでconvertして、bloggerにimportできました。
http://wordpress2blogger.appspot.com/
ありがたい。
wordpressのほうはしばらく放置しておきますが、そのうち消します。
http://wordpress2blogger.appspot.com/
ありがたい。
wordpressのほうはしばらく放置しておきますが、そのうち消します。
2013年9月2日月曜日
かつて、フィールドワークコンサルティング手法を勝手に試してみた話
とどのつまり、何をしたらゴールなのかよくわからない仕事ってあると思います。
普通、なんの仕事でも、始まりの時に、勝利条件を明確にするものですが、仕事を依頼する側も、仕事を受け取る側も、勝利条件がわかっていないとき、まずゲームのルールを探らなければいけない時があります。
現実世界は、ゲームのルールなんて、どっかに書いてあることも少ないので、みんな（利害関係者たち）これがルールかな、とおもったものが、ゲームのルールとなります。
で、ゲームのルールを探る必要があるときに、その手法っていろいろあるかと思います。
何年か前のしごとで、フィールドワークコンサルティング手法を勝手に使ってみたことがありました（フィールドワークコンサルティングという言葉は使ってない）。その時の感想をメモがてら書いておきます。
参考リンク
フィールドワークを活用したコンサルティング手法とその効果
（今日skypeでなぜなぜ分析の話題を出したら、この数年前の仕事を思い出しました）
普通、なんの仕事でも、始まりの時に、勝利条件を明確にするものですが、仕事を依頼する側も、仕事を受け取る側も、勝利条件がわかっていないとき、まずゲームのルールを探らなければいけない時があります。
現実世界は、ゲームのルールなんて、どっかに書いてあることも少ないので、みんな（利害関係者たち）これがルールかな、とおもったものが、ゲームのルールとなります。
で、ゲームのルールを探る必要があるときに、その手法っていろいろあるかと思います。
何年か前のしごとで、フィールドワークコンサルティング手法を勝手に使ってみたことがありました（フィールドワークコンサルティングという言葉は使ってない）。その時の感想をメモがてら書いておきます。
参考リンク
フィールドワークを活用したコンサルティング手法とその効果
（今日skypeでなぜなぜ分析の話題を出したら、この数年前の仕事を思い出しました）
フィールドワークコンサルティング手法に対する自分の理解
- 文化人類学のフィールドワークをベースにしている
- STEP1.えらいひとにインタビュー（まとめておく）
- STEP2.業務フローをつくる
- STEP3.現場に張り付く
- 現場の人の動きをひたすらメモる（なるべく先入観なしで）
- 邪魔者扱いされるが泣かない
- STEP4.現場の人を含めた利害関係者で、ディスカッションしたり個別にインタビュー
- STEP5.まとめて、改善の実行案つくる（もしくは改善案の実行まで行って）おしまい（次につなげる）
きっかけ：とある依頼
- SE派遣をしているSIerがありました
- 派遣している方（SIer）も、受け入れている方（お客さん）も、現場でなにをやっているのかイマイチよくわかってません
- でも、改善したいです
- 改善とかしていきます前向きさをアピールしたい
- あと、実際現場ブラックボックスなんだよねー
前提条件
- 期間は半年
- この件に裂ける人員は俺一人
- 0.3人月 * 6ヶ月ぐらいでよろぴく
- 俺はただのしがないSEだった（25歳ぐらい？）
- この手のしごとはしたこともなかったし、誰もやり方を教えてくれない。
どうしよう
- 契約や、日々のドキュメント類は見せてもらったが、これだけだとやっぱりよくわからん
- とはいえ、きれいなBPRっぽいテンプレドキュメント出したところで、なんか納得されなさそう
- 逃げたい
- ぐぐる
- 富士通のサイトに面白いはなしがのってる
- これだ
まず、やったこと
- 仮設を立てる
- 現状こういう問題があるんじゃない？
- スケジュールを立てる
- ざっくりと
- キックオフをする
- 利害関係者を集めれる範囲でキックオフをして、これから半年やることを宣言する
- この時は、調査３ヶ月、施策３ヶ月ぐらいにしといたと思う
- 怒られたらその部分はなおす
- シートを作る
- インタビューシート、フィールドワークのメモ用シートなどをつくる
じゃあインタビューしてみよう
- 利害関係者のなかでも偉い人方面にインタビューしてみる
- 同じ船に乗ってるとは思えないほど、認識が違う
- 逃げたい
- 無知な若者が、失礼なことを聞いてるんですぅという感じで相手の器量に期待する方向で物事をすすめることを決意する。若くて良かった。
- 現場の人にインタビューしてみる
- 現場ならではの問題意識をいろいろ抱えている
- よくわからないところは、フィールドワークで補うか
- この時点で現場の人が助かる方向に物事を進めようという気になる
- 偉い人方面は、政治のできる人になんとかしてもらおうという気になる
で、フィールドワーク
- 週２回ぐらい、現場にいく
- 現場のSEの後ろについてまわる（マジで）最初はすごく恥ずかしかった。
- だんだん慣れてくる。
- あんたなんなの？の視線にもめげない。
- やっぱり答えは現場にある。
仮説の修正、結果の報告、施策案を提示
- ブラックボックスってのが気になるのであって、箱を開けてあげれば、具体的な議論ができる
- ブラックボックス→あいつら仕事してんの？（不安の裏返し）
- ブラックボックスを紙に可視化
- フィールドワークの結果があるので、説得力はある
- 現場は疲弊している
- こういう理由で疲弊しているので、戦力増強なり、効率化（のためのコストをかける必要がある）みたいな話を、利害関係者の偉い人にいう。
- 紙をいっぱいつくる
- 現場に近い人にとっては有用な資料
- 偉い人向けには、ちゃんとエグゼクティブ・サマリーをつくるのを忘れない
- 偉い人は細かい文書を読まない。くれって言われたら出すぐらいでちょうどいい
- 改善案を出す
- この時は現場よりの改善案だった。
- 実行も結局俺がやることになってしまった。
- 改善案のゴールを明確にする（KPI）
- フィールドワークの結果をもとに、定性的、定量的な改善目標を立てる
- これがゲームのルール
その後
- 業務改善のためのツールをつくった
- が
- 施策の結果は、多分、利害関係者全員が納得できるものではなかった。
- これはひとえに俺の力不足であった。
- 継続的にコミットできる仕事として、このツールをブラッシュアップしていかないと意味ないなーと思った。
- そのために、ツールをつくるにしても、その現場の人が扱えるテクノロジーを採用するってのが大事。
- ただ、自分がそれに習熟しているかは別問題なのであった。。。
まとめ
- フィールドワーク手法はかなり有用だった
- 机上で資料を眺めているよりはるかに意味があった
- 日本の仕事のスタイルで、現場のドキュメンテーションが少ない、ってのも大きい
- 改善案の実行を定量目標を満たすように達成するのはすごく大変
- 特に自分でやる場合、その業務なり、テクノロジーに造詣が深くないと、その成果は微妙なものになりがち。
- なんの仕事でもそうなんだけどね。。。
- とにかくすばやく
- ゆっくりやっていると、組織だったり、技術だったりが変わってしまう
- 来月ココかわるから、手を入れても意味ね～じゃんとか普通に起こりまくる
- メスを入れるべきところの見極めと、素早さが重要
2013年8月22日木曜日
macでbind使いたい人のメモ
Macでインターネッツ共有をしたときに、自前のDNSを参照させたい時ってあると思います。
そんなときに、MacでBINDを使うメモです。
Max OS X Lion
/etc/rndc.keyの作成
named.confの設定
以下サンプル
zoneファイルを作る
以下zoneのサンプル
他のファイルはデフォルトです。
フォアグラウンド起動
デーモン起動
デーモン停止
MacOSXのインターネット共有で、MACアドレス制限を行いたい
そんなときに、MacでBINDを使うメモです。
環境
Max OS X Lion
事前準備
/etc/rndc.keyの作成
sudo rndc-confgen -a
named.confの設定
vim /etc/named.conf
以下サンプル
include "/etc/rndc.key";
controls {
inet 127.0.0.1 port 54 allow {any;}
keys { "rndc-key"; };
};
options {
directory "/var/named";
pid-file "/var/run/named.pid";
allow-query { any; };
// query-source address * port 53;
};
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
zone "blog.shase.info" IN {
type master;
file "blog.shase.info.zone";
};
logging {
category default {
_default_log;
};
channel _default_log {
file "/Library/Logs/named.log";
severity debug;
print-time yes;
};
};
zoneファイルを作る
vim /var/named/blog.shase.info.zone
以下zoneのサンプル
$TTL 86400
@ IN SOA localhost root.example.jp.(
2002122001 ; serial
3600 ; refresh 1hr
900 ; retry 15min
604800 ; expire 1w
86400 ; min 24hr
)
IN NS localhost.
hoge IN A 0.0.0.0
他のファイルはデフォルトです。
起動と停止
フォアグラウンド起動
$ sudo named -g
デーモン起動
$ sudo launchctl load -F /System/Library/LaunchDaemons/org.isc.named.plist
Password:
$ ps aux |grep named
hoge 41792 0.2 0.0 2434892 548 s007 S+ 9:27PM 0:00.00 grep named
root 41784 0.0 0.1 2439512 6280 ?? Ss 9:27PM 0:00.02 /usr/sbin/named -f
デーモン停止
$ sudo launchctl unload /System/Library/LaunchDaemons/org.isc.named.plist
$ ps aux |grep named
hoge 41800 0.0 0.0 2434892 548 s007 R+ 9:29PM 0:00.00 grep named
あわせてどうぞ
MacOSXのインターネット共有で、MACアドレス制限を行いたい
2013年8月5日月曜日
JBODはややこしい
カイワレ先生のブログを見て、自分のメモがてら、JBODについて書いてみます。
JBODって、なんぞやって、日本人なら誰もが一度は考えると思うからです。（RAID0と何が違うの？って）
現状、JBODという言葉は非常に曖昧な言葉です。
日本語wikipediaにも3つ定義があります。
http://ja.wikipedia.org/wiki/JBOD
より。これはこれで微妙なんですが。。。
まず大雑把な理解として、JBODの特徴を2つ挙げます。（どちらともRAIDに対する優位点です）
ちなみに、Aが成立するのは、上記wikipedia定義の1,2,3のときです。
Bが成立するのは、1,2です。（とはいうものの、状況によってRAIDのほうが性能がよかったりします。これは使い方によって変わります。）
3のとき、なぜBが成立しないかというと、ソフトウェアで処理している分オーバーヘッドが大きく、I/Oが出ません。
以下は、ざっくり、1と2は、ハードウェアベースのJBOD。3をソフトウェアベースのJBODとします。
ハードウェアベースのJBODとHadoopの話に入りますね。ハードウェアベースのJBODも２つの意味があります。１つは、「束ねられたディスク群」という意味のJBOD。
もうひとつは「物理ディスクが別々の論理ボリュームにマッピングされて、並列書き込み可能な状態（仕組み）」です。上記とはぜんぜん違いますね。
つまり、OSから見えるマウントポイントと物理的なディスクが紐付いている状態ということです。（そして、きちんと別々に書き込むように対応したコントローラがいわゆるJBOD対応のコントローラってやつです）。
Hadoopはアーキテクチャ上、並列に書き込みをしてくれるようです。これは、マウントポイントと実際のディスクが一対一で結びついている時に、その並列性が意味を成すということです。逆にRAIDを組んでしまうとストライプ書き込みをしてしまうので、そのラウンドロビン並列書き込みの意味がなくなってしまうということですね。
ハードウェアのJBODは外付けのエンクロージャで使用されることが多く、サーバ筐体の内蔵ディスクで対応しているものがどのくらい世にあるのかは知りません。
ちょっとだけ調べたら、さすがにDELLのCシリーズとかはJBOD対応のチップ（HBAとしての役割しか果たさないモード）を搭載したLSIのチップとか積んでるみたいですね。
ソフトウェアベースのJBODの話は余談です。こっちは束ねる方だけ触れておきます。
お仕事用途ではあまり使われないので。カイワレ先生がWindows Home Serverの例を出してましたが、あれは、「Drive Bender」の実装の話だと思います。（別に、HOME鯖が最初のJBOD実装ってわけではないです）。
なぜ、Home Server（家庭用鯖）にJBODが必要とされてMSが実装したかというと（最新のHOME鯖では外されているようです）、発売当時、まだ、HDDの値段はそれなりに高く、ユーザのニーズとして、「ジャンク屋で買ってきたHDDいくつか、組み合わせて、でかいOneボリューム構成したいんだけどなー」というのがあったからです。
そのニーズに合致していたのが、ソフトウェアJBODだったんですね。
Linuxの場合は、LVMでソフトウェアのJBOD（のようなもの）を構成することができます。
JBODという言葉は、いろんな人が勝手にオレオレ定義で使っている言葉です。さりとて、代替になる適当な言葉もないので、JBODいいよーって言いたいエライ人は、適当に新しい言葉をでっち上げていただけると、世のエンジニアが助かります。
ちなみに、Hadoopのクラスタ組もうと思って、JBOD使えないRAIDカードしか積んでないサーバ渡されたら、しょうがないから、1ディスクでRAID 0ってのを一つの筐体で何個か組む感じの構成になるかと思います。お金くれるんだったら、LSIとかのちゃんと対応したチップ詰んだ鯖にしたいですが。
世の事例を見ると、RAID 0を並べたようなものをJBODなんて言ってる例もあるので、みんな適当に使ってる単語といえばそんな感じ。
JBODではWriteキャッシュを切りましょうが一般的なお約束なのですが、もしかしたらHadoopだと気にしなくてもいいのかもしれません。ぐぐればどっかにそんなこと言ってる人いるかも。
JBODって、なんぞやって、日本人なら誰もが一度は考えると思うからです。（RAID0と何が違うの？って）
現状、JBODという言葉は非常に曖昧な言葉です。
日本語wikipediaにも3つ定義があります。
1.JBOD機能を持つRAIDコントローラカードを取り付けて、JBODにしたいハードディスクをRAIDコントローラカードに接続する。
2.JBOD用として製造されたディスクアレイ製品をSCSIやファイバーチャネル等のインターフェースに接続する。
3.すでに接続されている複数のハードディスクを、ソフトウェア的に統合してJBODとする（Windows NT系列のOSには「スパン」という名称でこの機能が標準装備されている）。
http://ja.wikipedia.org/wiki/JBOD
より。これはこれで微妙なんですが。。。
まず大雑把な理解として、JBODの特徴を2つ挙げます。（どちらともRAIDに対する優位点です）
- A.複数のディスクにて、容量が異なる場合も（単純な足し算の）単一のボリュームを構成することができる
- B.I/O性能がよい、とされる
ちなみに、Aが成立するのは、上記wikipedia定義の1,2,3のときです。
Bが成立するのは、1,2です。（とはいうものの、状況によってRAIDのほうが性能がよかったりします。これは使い方によって変わります。）
3のとき、なぜBが成立しないかというと、ソフトウェアで処理している分オーバーヘッドが大きく、I/Oが出ません。
以下は、ざっくり、1と2は、ハードウェアベースのJBOD。3をソフトウェアベースのJBODとします。
ハードウェアベースのJBOD
ハードウェアベースのJBODとHadoopの話に入りますね。ハードウェアベースのJBODも２つの意味があります。１つは、「束ねられたディスク群」という意味のJBOD。
もうひとつは「物理ディスクが別々の論理ボリュームにマッピングされて、並列書き込み可能な状態（仕組み）」です。上記とはぜんぜん違いますね。
つまり、OSから見えるマウントポイントと物理的なディスクが紐付いている状態ということです。（そして、きちんと別々に書き込むように対応したコントローラがいわゆるJBOD対応のコントローラってやつです）。
Hadoopはアーキテクチャ上、並列に書き込みをしてくれるようです。これは、マウントポイントと実際のディスクが一対一で結びついている時に、その並列性が意味を成すということです。逆にRAIDを組んでしまうとストライプ書き込みをしてしまうので、そのラウンドロビン並列書き込みの意味がなくなってしまうということですね。
ハードウェアのJBODは外付けのエンクロージャで使用されることが多く、サーバ筐体の内蔵ディスクで対応しているものがどのくらい世にあるのかは知りません。
ちょっとだけ調べたら、さすがにDELLのCシリーズとかはJBOD対応のチップ（HBAとしての役割しか果たさないモード）を搭載したLSIのチップとか積んでるみたいですね。
ソフトウェアベースのJBOD
ソフトウェアベースのJBODの話は余談です。こっちは束ねる方だけ触れておきます。
お仕事用途ではあまり使われないので。カイワレ先生がWindows Home Serverの例を出してましたが、あれは、「Drive Bender」の実装の話だと思います。（別に、HOME鯖が最初のJBOD実装ってわけではないです）。
なぜ、Home Server（家庭用鯖）にJBODが必要とされてMSが実装したかというと（最新のHOME鯖では外されているようです）、発売当時、まだ、HDDの値段はそれなりに高く、ユーザのニーズとして、「ジャンク屋で買ってきたHDDいくつか、組み合わせて、でかいOneボリューム構成したいんだけどなー」というのがあったからです。
そのニーズに合致していたのが、ソフトウェアJBODだったんですね。
Linuxの場合は、LVMでソフトウェアのJBOD（のようなもの）を構成することができます。
まとめ
JBODという言葉は、いろんな人が勝手にオレオレ定義で使っている言葉です。さりとて、代替になる適当な言葉もないので、JBODいいよーって言いたいエライ人は、適当に新しい言葉をでっち上げていただけると、世のエンジニアが助かります。
ちなみに、Hadoopのクラスタ組もうと思って、JBOD使えないRAIDカードしか積んでないサーバ渡されたら、しょうがないから、1ディスクでRAID 0ってのを一つの筐体で何個か組む感じの構成になるかと思います。お金くれるんだったら、LSIとかのちゃんと対応したチップ詰んだ鯖にしたいですが。
世の事例を見ると、RAID 0を並べたようなものをJBODなんて言ってる例もあるので、みんな適当に使ってる単語といえばそんな感じ。
おまけ
JBODではWriteキャッシュを切りましょうが一般的なお約束なのですが、もしかしたらHadoopだと気にしなくてもいいのかもしれません。ぐぐればどっかにそんなこと言ってる人いるかも。
登録:
投稿 (Atom)