にわかサーバー屋さんの覚書

サーバー系を担当しているけど、設計などは日々勉強中のプログラマの覚書

すみません、VARCHARとCHARの違いを理解していませんでした。

すみません、VARCHARとCHARの違いを、 理解していませんでした。

VARCHAR 可変長文字列

CHAR 固定長文字列

でした。

あまり固定長文字列使わなかったので、 ん?なんだっけってなりました。

固定長で短い文字突っ込んだら、お尻スペースで埋めて文字数合わせてくれちゃうんだって。

ID管理のヒント - オンラインデータリバランシング@LINEの技術

LINEの技術 - オンラインデータリバランシング

 

急増するLINEインフラの課題と対応

http://tech.naver.jp/blog/?p=3041

 

上記のLINEのエンジニアのブログ内容が興味深い。

特に、DBのshardに関する部分の設計は、なるほどと思った。

 

見せてもらったことのあるシステムで、

DBを分割することを前提にテーブル設計してあるものを見たものはほとんど無かった。

 

いや、一つ見たことがあるけど、IDの番号からDBの番号算出して、

その番号DBにデータを書き込むというシステムだった。

 

単に余り(ID%10=DB-No)から番号出して、その番号のDBに書き込みだけ。

つまり、最初からDBを分割してからスタートアップしていた。

なので、最初からキャパとってるだけで、さらにそれ超えると作り直し。

設計したのはアホなのかと思う。

 

 

LINEのID管理は、

 

・IDから、ハッシュ値でグループ化

・ハッシュのグループにDB番号をマッピング

 f:id:xev:20140516160806p:plain

しているらしい。

 

 

マッピングも、現在のDB番号と、移行先のDB番号を用意しており、

システム的に無停止で増設などが出来る様に作っているらしい。

 

まぁ、そこの部分は自社開発の仕組みっぽいので、

参考になるのは、IDに関しては、

 

[ID-Hashグループ] -> [Hashグループ->Shard先/Shard移行先]

 

という感じで設計しておくのが良いよねって感じですかね。

 

 

Shardingに関してはこちらの解決策も併せて考えておきたい。

SPIDER for MySQL
http://spiderformysql.com/

 

データベースエンジニア養成読本(その他、養成読本シリーズ)

この養成読本シリーズは読みやすくて好きです。 

データベースエンジニア養成読本 [DBを自由自在に活用するための知識とノウハウ満載!] (Software Design plus)

データベースエンジニア養成読本

 

 クラウドなんちゃらってのは買ったのですが、

Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus)

Webアプリエンジニア養成読本

 

 

その他、いろいろと出てるんですよね。

個人的には、

iOSアプリエンジニア養成読本[クリエイティブな開発のための技術力/デザイン力/マインドを養う! ] (Software Design plus)

iOSアプリエンジニア養成読本

  • 作者: ?橋俊光,諏訪悠紀,湯村翼,平屋真吾,平井祐樹
  • 出版社/メーカー: 技術評論社
  • 発売日: 2014/03/20
  • メディア: 大型本
  • この商品を含むブログを見る
 

これくらいは、何かあったときのために、内職用。  

AWSから、テーブル多いからinnodb_file_per_tableを0にしろと怒られた

AWS様からAlertメールが来た。

内容は以下の感じ。

DB Instance dev-DB-XXXX has a large number of tables and has the

parameter innodb_file_per_table set to 1, which can increase database recovery

time significantly. Consider setting this parameter to 0 in the parameter group

associated with this DB instance to minimize database downtime during reboots

and failovers.

 なんとか頑張って読むと、どうやら、

DBにテーブルありすぎて、もしクラッシュ&リカバリーって自体になったときには、

スゲー時間がかかるぞ。いいのか!?という警告メッセージのようでした。

 

で、もう、AWS様が言うならということで、

innodb_file_per_tableを0に設定(my.conf)しましました。

 

で、innodb_file_per_tableって何なのさ。ってところですが、

innodb_file_per_table 

テーブル毎にバイナリファイルを作ってくれる

というオプションらしいです。

そちらの方が、ディスクI/Oが減るんで良いみたいってことで、

Amazon RDSではデフォルトで、指定されているようです。

※mySQL5.6ではデフォルトでONとのこと

 

ただ、今回怒られたように、テーブルが多いと

リカバリの際に、多数のファイルがあるとその分、

リカバリが遅くなるよってことのようです。

 

で、0にすると、ファイル分割しなくなっちゃうので、

何かする度に全部ロックされちゃったりと、それはまたやっかいなことになりそう。

まぁ、途中でやると、それ以降のテーブル作成が同じバイナリで構成されるようです。

 

以下のサイトで、検証もしてくれております。判りやすいー

 

【AWS】RDS for MySQLで共有テーブルスペースに構成変更する際の所要時間を実測してみた

http://dev.classmethod.jp/server-side/db/rds-mysql-innodb_file_per_table/

てきとーなパフォーマンステストは意味が無い

とあるプロジェクトで、あきらかにサーバー処理が足りない。

大盛況で、めちゃくちゃアクセスが多いって訳でも無い。

 

調べると、本来というか稼働中は通信は全て暗号化で行われるのに、

性能テストでは、暗号化を外しておいてプレーンな状況で行っていたらしい。

 

本番環境と異なる構成や条件でテストしても、

出てきた答えで判定できるわけ無いよねー

 

私は、まだ銃弾飛び交う戦場の前線におかれて開発はしていないので、

もしかすると、その状況下なら「ええぃ、暗号化分は1.2倍で盛っておけぇ」とかやってるかも知れませんが。

 

本音と建て前の世界があるのだと思います。

 

あとは、いくらサーバー側チューニングしても、

 

「こんな酷いSQLじゃそりゃ遅えよ」とか、

「ここ必死にチューニングするくらいなら、ざっとハードスペックあげたら?」

 

って、俯瞰して判断する人もいるなぁという話を聞きました。