MySQLのチューニングを戦う方へ
本連載もついに最終回となりました。 本連載では、MySQLクエリーチューニングことはじめで予告した通り、「チューニング箇所の洗い出しのテクニック」について説明してきましたが、「チューニングの方法」については一切触れませんでした。 「本連載ではチューニングそのものの方法については詳しく説明しません。それは見出しの通り「銀の弾丸」などはなく、MySQLのパフォーマンスチューニングは計測と改善を繰り返し行っていくべきものだからです。そのため、特定のケースにマッチする改善の手法よりも、繰り返し使われる計測の手法にフォーカスを当てて説明していきます。」 その理由としてこの一文が全てではありますが、今回は参考までに筆者が考えるチューニングの指標を紹介したいと思います。それがあなたの環境に当てはまるかどうかは、これまでに紹介してきたツールなどを利用して計測してみてください。 チューニングの基本方針 基本
Dockerの管理・監視ツール(2)
前回は、シンプルなユーザーインターフェースのDockerUIと多彩な機能を備えたShipyardを紹介しました。今回は、エンタープライズでの利用を見据え、最近の注目株である、Rancher とDockerコンテナ同士のリンクをリアルタイムで可視化するWeave Scopeというツールを紹介します。 最近注目を浴びているDocker管理ツール「Rancher」 Rancherは、エンタープライズレベルでの運用を視野に入れたDockerの管理ソフトウェアです。LDAPやGitHubによるユーザー認証、計算資源の使用状況の可視化、ログ出力、そして、クラウド環境やネットワーク上のDocker環境を跨いだ一元的な管理が可能となっており、注目が集まっています。2015年9月中旬現在、Rancherは、Amazon EC2、DigitalOcean、Rackspaceなどのパブリッククラウド上のDock
これからはじめるRuby on Rails
はじめに Rubyと出会ったころ、その簡潔さに感動した著者は、「ここまで自然言語に近い形でプログラムが書けるのであれば、インターネットとPCの違いすら理解しない妻でも、少しはプログラミングができるようになるかもしれない」と、家庭での普及に挑戦したことがあります。 その試みは、渡した入門書を「はじめてのRUBAI」と読まれた時点で頓挫したわけですが、その経験から「Rubyの文法に従ってはいるが、何やら他言語の匂いを感じるコード」のことを、Rubyの潜在力を生かしきれていないという意味で「RUBAIコード」と呼ぶことにしました。 そして、社内のさまざまな分野のプログラマにRuby開発を指導してみて分かったのは、"RUBAIコード"には、実装レベルの間違いと、設計レベルの間違いがあるということです。 実装レベルの間違いとは、処理を他言語の習慣に従って記述することで引き起こされます。Javaプログ
RailsのテストフレームワークRSpecの基礎知識
実践Ruby on Rails 4 現場のプロから学ぶ本格Webプログラミング 顧客管理システムの構築を体験しながら、Railsアプリケーション開発のノウハウを習得！ この記事は、書籍『実践Ruby on Rails 4 現場のプロから学ぶ本格Webプログラミング』の内容を、Think IT向けに特別にオンラインで公開しているものです。詳しくは記事末尾の書籍紹介欄をご覧ください。 本記事では、テストフレームワークとしてRSpecを採用します。RSpecをうまく活用すると、簡潔で読みやすいテストコードを書くことができ、Railsアプリケーションの保守性を高めることができます。 しかし、RSpecの用語法や表記法はやや独特で、慣れるまでには時間がかかります。読者の中にはとまどいを覚える方がいらっしゃるかもしれませんが、次章以降を読み進めるうえでの鍵となりますので、是非じっくりと読んで理解してく
youRoomとPivotalTrackerではじめる無駄のないコミュニケーション
プロジェクト画面の「ADD STORY +」ボタンから、図14のようにチケットを登録します（画面上には「ストーリー」と表記されていますが、前回の記事から一貫して「チケット」と呼称しているため、引き続き「チケット」と呼ばせて頂きます）。 最低限設定しなくてはいけない項目は「Story Title」で、図14では「デッキの一覧を見ることが出来るようにしたい」という部分にあたります。項目名は「Story Title」ですが、ここにはそのままユーザーストーリーを書いてしまうのが良いと思います。 ユーザーストーリーですが、一般的には以下のようなフォーマットで表されます。 （ 誰？ ）として、（ 要求 ）が欲しい、なぜなら（ 理由 ）するためである。 必ずしもフォーマット通りにユーザーストーリーを書く必要があるとは思いません。重要なのは、ユーザーストーリーを通じてプロダクトオーナーとプログラマーが共通
ソフトウエアエンジニアがUX/UIを考える上で読むべき4冊の良書と名言たち
筑波大学 システム情報工学研究科 コンピュータサイエンス専攻 非数値アルゴリズム研究室(NPAL) 五十嵐 悠紀 2004年度下期、2005年度下期とIPA未踏ソフトに採択された、『天才プログラマー/スーパークリエータ』。筑波大学 システム情報工学研究科 コンピュータサイエンス専攻 非数値アルゴリズム研究室（NPAL）に在籍し、CG／UIの研究・開発に従事する。プライベートでは二児の母でもある 何か製品を考える時、そのものがカタチのあるものであっても、はたまたコンピュータの中で動くソフトウエアだったとしても、「ユーザーインターフェース（以下、UI）」について考える必要があります。さらには、わたしたちが日常生活においてストレスなく過ごせている裏側には、さまざまな人によって考えられてきたUIデザインが隠されていたりもします。 わたしは滞在先のホテルで、洗面所に入ったものの出ようとした時に
教科書的ではなく、現場にあったデータベース設計のコツ
前回はデータベース設計をする際に誰もがぶつかる問題である、「列名に日本語を使うか？」「どのデータ型を使うか？」ということをテーマに取りあげました。今回も引き続き、データベース設計をする際に迷いやすい点をいくつか取りあげてみようと思います。 今回は前回と同様、SQL Serverのサンプルデータベース「Northwind」を元にして、データベース設計で迷いやすい点について考えてみましょう。図1は「Northwind」をER図にリバースした中から、エンティティ「商品」「商品カテゴリ」をサブウィンドウで表示したものです。 図1のように商品を分類するためにカテゴリコードをつけるエンティティ構造はよくあります。しかし実際の販売管理システムにおいては、このようなフラットなカテゴリ構造は不便です。なぜかというと、一般に商品カテゴリなどは表1のように階層構造で分類する必要があるからです。 01 ハードウェ
DBサーバーの負荷分散
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
