【感想】MySQLのパフォーマンスに関する記事を読んで
以下の記事を読んで自分なりに解釈＆所感。
Yakst - MySQLの大きなテーブルでのパフォーマンスを改善する10の方法
1.MyISAMではなくInnoDBを使う。
→MySQLのチューニングとしてはまぁ普通の考え。
「古い時代のアーキテクチャ」とか「ファイルシステムに毛が生えたようなもの」って聞いたし。
が、当然ながら新規構築なら設計時に大前提で考慮することなので、後からチューニングとかって類の考えではない。
2.InnoDBは、ユニークでないセカンダリインデックスを・・・
→つまり5.5以降+InnoDBにバージョンアップしろと。
新しいバージョンにするというアプローチはパフォーマンス改善の考え方としてはありだけど、
チューニングとは言えないかも。
アプリ変更・テストが必要なケースなどが多々あるので優先度は高くできない。
3.パーティショニングは・・・MySQL5.7.2で・・・
→これは知らなかった。ていうかまだリリースされていないし。
新機能を使うというアプローチもチューニングとは言い難いけど。
でも、「パーティション化する」は立派なチューニング。
4.InnoDBの圧縮機能を使う
→圧縮はread/write性能が悪くならないかちょっと心配だけど5.6でかなり良くなったとのウワサ。
Oracleなども圧縮機能はある。
データ縮小によるフルスキャン性能UP ＞ read/write性能down と判断できるなら検討の余地あり。
5.ソートしたデータをバルクロード
→ロード方法を変えて時間を短縮するアプローチもよくやるね。
6.不要なインデックスを消す
→地味に必要。なかなか運用中手をつけにくいけど。
インデックスが多いと更新性能が落ちるので。
7.プライマリキーの種類（データ型）変更
→データ型とデータ長もread性能に響くので、テーブル設計時の重要な要素。
8.新しいテーブルにバルクロードする場合は、PRIMARY KEY以外のインデックスは後で作る。
→大事。
データの一意性が保証されているものをロードするなら、PrimaryKeyですらロード後に作る。
ロード処理をバッチに入れていたりするなら、チューニング（調整）になるが、
どちらかというとお作法（常識）な気がする。
9.メモリを増やせば (ry
→当然ね。
InnoDB＆Readメインならとにかくバッファにどれだけ載せられるかが勝負なので。
10.メモリと同じく、SSDも役に立つ。
→これも。今だとioDriveが選択肢か。
・・・とまぁ、人の書いたもので感想述べただけですが、
設計・運用でパフォーマンスに影響する要素のまとめとして、勉強になりました。
靴紐の通し方
年始の買い物で革靴を買ってきた。
家に帰って箱から出し、靴紐を抜いてイチから通す。やれやれ・・・
ちょっと待て。
いつも思うんだが、なぜ新品の靴の紐はこんなメチャクチャな通し方してあるんだろう？
ディスプレイの都合上？
でもそれにしちゃ、履くときと全然違う通し方をしてあるというのも変な話だ。
もしかして何か意味があるのでは・・・？
いや、そもそも革靴の紐ってどうやって通すのが正しいんだ？
気になったので調べてみよう。Google先生～！
（※この時 1/6 1:00過ぎ。つまり仕事初め前。早く寝るべき。）
靴紐の通し方と呼び方 | 靴のあれこれ | リーガルコーポレーション
・・・これ見てショック。
メチャクチャだと思っていた買ったばかりの革靴の紐は、「シングル」という
れっきとしたビジネスシューズ用の通し方になっていたのか。。
ちなみにここらで薄々気づかれていると思うが、
自分の知っている紐の通し方は、スニーカーの紐を通す時に使う
アンダーラップとオーバーラップだった。
しかも両者の違いはなんとなく見栄えで使い分けていただけで、
名前があることすら分かっていなかったという。。
なんと恥ずかしい。
もう社会に出て何年経つんだ(+。+)
まぁ、今後靴紐を通すのが少し楽しくなってきた。
今回はシングルにしたが、パラレルも今度やってみよう。
新年から一つビジネスファッションの基本を知ることができた2014年のスタートでした。
s3fs と s3cmd
EC2からS3に大量のログファイルを保存するために
・s3fs（正確にはs3fs-c）
・s3cmd
の2種類を使っていたがどちらも一長一短という感じで、悩みが。
【それぞれの特徴】
・s3fs
（長所）ファイルシステムとしてマウントしローカルファイルのようにcpなどの操作が可能
（短所）メモリリーク（swapが激しい）←ホントにイタイ
・s3cmd
（長所）S3の操作の多くがコマンドラインで出来る
（短所）pythonのメモリ消費量多め、数GBサイズの大きいファイルの操作（後述）
長所としてはどちらも良い所があるのだが、s3fsの短所：メモリリークがどうにも許容できず、
s3cmd一本で行こうと思い始めたところ、数GB級のファイルをS3にputしようとして下記エラー。
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
An unexpected error has occurred.
Please report the following lines to:
s3tools-bugs@lists.sourceforge.net
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Problem: KeyError: 'size'
S3cmd: 1.1.0-beta2
Traceback (most recent call last):
File "/usr/local/s3cmd/s3cmd", line 1804, in
main()
File "/usr/local/s3cmd/s3cmd", line 1745, in main
cmd_func(args)
File "/usr/local/s3cmd/s3cmd", line 969, in cmd_sync
return cmd_sync_local2remote(args)
File "/usr/local/s3cmd/s3cmd", line 936, in cmd_sync_local2remote
(item['full_name_unicode'], uri, response["size"], response["elapsed"],
KeyError: 'size'
’size’と出ていたものの何が悪いのかはっきりとは分からなかっただが、
幾つかのファイルを試して、ファイルサイズが問題だということに。
どうにもならないのかぁぁと諦めかけたものの、よーくヘルプを見てみると、
以下のようなオプションが。
--multipart-chunk-size-mb=xx(MB)
どうやら、5GB以上の大きいファイルをアップする場合、このオプションが無いとエラーになるらしい。
↓ こちらにわかりやすい解説があった。
cloudpackブログ: s3cmdでmultipartオプションを利用してs3へアップロード
ということで、以下のように指定。
s3cmd put --multipart-chunk-size-mb=5120 転送するファイル s3://バケット名/オブジェクトパス
これでうまくアップ出来るようになった。
良かった。
以下も分かりやすく、参考になった。
s3cmdで5GB以上のファイルをS３にアップロードする方法 - 雑多なインフラエンジニア日記
CentOS で キーボード配列が日本語106じゃない場合の対処方法
VMware Player にインストールしている CentOS 5.5 を触っていたら、
なぜかパイプ（|）が打てない。
？と思いながらもうしばらくすると、アスタリスク(*)も打てない。
これはまさか・・・
そう、キーボード設定が日本語じゃなくてUS配列になっているのである。
どーすりゃいいんだ〜〜っ！
と、ググったらなんとまぁドンピシャなblog記事がありました。
CentOSでキーボード設定が日本語じゃないときの対処法: m6 BLOG
1. /etc/sysconfig/keyboard
KEYTABLE="jp106" # USになってたら訂正2. /etc/X11/xorg.conf
Option "XkbModel" "jp106" # pc105とかになってたら訂正
Option "XkbLayout" "jp" # usになってたら訂正
俺は両方とも該当していました。
ともにviで編集。
・・・ちなみにコロン（:）も配列変わってるので保存できない！と1分悩むｗ
最終的にはWikipediaにも助けてもらいましてｗ
プラス(+)入力をしたら無事にコロン出てきました。
なお、変更しても即時反映ということはなく、
(キーボードのデーモン？ってあるんでしょうか？）
OS再起動後にめでたく治りました。
ちゃんちゃん♪
