データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
付加価値の落とし穴
以前、（最高の土管が欲しい）というエントリで「付加価値」という価値観が日本に蔓延していることについて述べた。今回は付加価値が何故ダメなのかということについてさらに掘り下げて論じてみようと思う。 付加価値が生まれる背景 我々のいちばんの疑問は「なぜ次から次へと付加価値と称するくだらない不要な機能やサービスが生まれるのだろう？」というものではないだろうか。この問いに対して、読者の皆さんにがっかりする答えを提示してみよう。 ぶっちゃけた話、付加価値をつけることは手軽だということが第一の理由ではないかと思う。 付加的な機能やサービスは、あくまでもオマケなので、既存の製品やサービスの延長でできる。つまり本命の製品やサービスにはあまり手を加えなくても良い。製品やサービスの屋台骨に手を加えるのは大きな決断となろう。もしそれが今まさに儲かっているものであれば、変更するのはリスク以外の何者でもない。しかし本
違いが分かるエンジニアのためのMySQL/InnoDB/ZFSチューニング！
明けましておめでとうございます。今年もコンピューター道に邁進して参りますのでよろしくお願いします！ さて、今年一発目のネタはMySQL利用時におけるZFSのチューニングについて取り上げようと思う。Solarisに搭載されている機能の中でも最も注目度の高いものの一つであるZFSであるが、MySQLのバックエンドとしてはあまり利用されていないように思う。（そもそもSolarisのユーザー数自体がそれほど多くないという話もあるが。）ZFSは優れたファイルシステムであり、ファイルシステム自体にスナップショット機能が搭載されていたり容量の限界に先が見えない（充分すぎるほど余裕がある）といった管理上のメリットがあり、DBAにとっては垂涎のファイルシステムであると言える。（Linuxで利用出来ないのが難点だが、ZFSを使うためにSolarisを使うのもアリだろう。） MySQL利用時におけるZFSのチュ
[書評]MySQLをハックしまくりたい人のためのスゴ本「MySQL 5.1 Plugin Development」
MySQLはGPLv2で頒布されているフリー（自由な）ソフトウェアだ。誰でも自由に改造、改善、機能追加して、GPLv2のもと再頒布することが出来る。 そうは言っても改造なんて敷居が高くて出来ないよ・・・という人に朗報なのが本書「MySQL 5.1 Plugin Development」だ！MySQLはストレージエンジンによってデータを管理するレイヤーが独立しているのはよく知られているが、MySQL 5.1ではさらに一歩進んで、ストレージエンジンを含む様々なプラグインを作成できるようになった。プラグインAPIを使ってMySQLを拡張すれば、無造作に改造してしまうよりもずっと楽にMySQLをハック*1することが出来るだろう。 MySQL 5.1で利用可能なプラグインPlugin APIは、MySQL 5.1で新たに追加された機能である。これにより、共有ライブラリ形式で後から機能を追加することが
![[書評]MySQLをハックしまくりたい人のためのスゴ本「MySQL 5.1 Plugin Development」](https://cdn-ak-scissors.b.st-hatena.com/image/square/3165ef8c077a667a657fd339d76a79f3f1c61732/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FAJ0KDdVrPXiuDGq-VAZPqqvw6A0UTON9n_J6zp4jPrtoggBaA9_y3VJdVf3Ytk5TFv26f6-hkR9WoPjYUiZ1bgPvMJEjzXED8KLhmGfTJgpyn4x9z3i0aSLLvUjKrdZ9F7YAdWZ4mvpT0as%3Dw1200-h630-p-k-no-nu)
LINEAR HASHパーティショニングってなんだ？
MySQL 5.1から利用出来るパーティショニングの種類には、次の4つがある。 RANGEパーティショニング LISTパーティショニング [LINEAR] HASHパーティショニング [LINEAR] KEYパーティショニング RANGEパーティショニングは値の範囲を指定する。次のように日付を用いて範囲を指定するのが代表的な使い方だ。詳細はこちらの記事（パーティショニングの使用例 - http session情報）を見て欲しい。 mysql> CREATE TABLE http_session ( -> session_id VARCHAR(32) NOT NULL, -> last_access TIMESTAMP NOT NULL, -> created TIMESTAMP NOT NULL, -> t_session_data VARCHAR(1024) -> ...(中略)...
「優れたMySQL DBAを見分ける27+3の質問」に対する回答例
随分と更新が空いてしまったが、「優れたMySQL DBAを見分ける27+3の質問」に対する回答例（漢バージョン）を紹介しよう。実は質問を掲載した際「難しい！」というコメントが非常に多く、もう少し易しい質問にするべきだったかと思って次のように呟いてみたのだが・・・ 非常に心強くて安心した。さすがに日本を代表するMySQLのエキスパートである。出題のレベルは間違ってはいなかった！！ そんなわけで、回答の方に移ろう。 MySQLのサーバープロセスはいくつある？ひとつ。mysqldはシングルプロセス・マルチスレッドモデルを採用しているので、"サーバー"プロセスはひとつである。多くの場合、Linuxなどでmysqldを動かす場合には、お供にmysqld_safeも常に動いていることが多いが、mysqld_safeはサーバーではなく、mysqldのためのラッパーであるので数には含めない。 rootユー
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
