DB設計の難しさ
今日は徒然なるままにDB設計について思っていることを並べてみようと思う。 ようやくWEB+DB Pressの次号の原稿を書き終えた。2年間の連載であるが、来年はプライベートが忙しくなる予定なので、連載はこれにて終了とさせてもらうつもりである。 「なぜ人はリレーショナルデータベースを使いこなせないのか」 このところ執筆や講演を通じてリレーショナルモデルについて説明する機会を色々頂いているが、それらの活動の根源となっているのが、この素朴な疑問である。その疑問をパワーにしてこれまで活動を行なってきた。 現時点での自分の回答は「データベース設計が難しいから」である。もちろんリレーショナルモデルそのものの難しさというのもあるが、それよりは「適切な使い分けができていない」ということが大きいように思う。言葉を変えると、リレーショナルモデルを適用すべきデータとそうでないデータの判断ができていないからDB設
賢いdtraceの使い方
皆さんはdtraceをご存じでしょうか？このようなシビレル機能はオトコとしては見逃せません。今回は皆さんにdtraceを紹介しようと思います。 DTraceとは？ Solaris 10に搭載された機能で、名称はDynamic Tracingから来ています。Sunのマニュアルを見ると「動的トレース」と書いてあります。ようはシステムを動かしたままトレースする（システム今どこを実行しているのか、変数がどんな値になっているかなどを調査する）ツールのことです。使いようによっては強力なデバッガーになります。また、プログラムが動作した痕跡（どの関数を何回呼び出したか？など）を集計できることから、性能分析にももってこいです。デバッグやパフォーマンスチューニングでお悩みの皆さんは、是非使ってみてください。 これまで、DTraceのような機能を提供するプログラムはありませんでした。似たようなものがあったとして
MySQLerのTwitterアカウントまとめ。
松信氏の、 MyISAMとInnoDBのどちらを使うべきか Twitterで話題になってたので簡単にまとめました。 というエントリが人気を博しているが、松信氏が言うように最近はTwitterでMySQL関連の話題も結構増えてきているように思う。Twitterの流行の勢いは凄まじく、今は右を向いても左を向いてもTwitter、寝ても覚めてもTwitter、猫も杓子もTwitterという雰囲気である。従ってMySQLもTwitterで盛り上がるのは当然の成り行きというもであるし、Twitterを活用しない手はない。 しかしMySQL関連の話で盛り上がると言っても「じゃあ誰をフォローすれば話に入れるんだよ？！」と多くの皆さんは疑問に思われることだろう。そこで、今日はMySQL関連のTwitterアカウントを独断と偏見と愛と勇気と努力をもって紹介する。MySQLの情報が欲しい人、もしくは話題の輪に
HA化機能を手に入れたSPIDERストレージエンジンにはもはや死角はなかった。
本ブログでも何度か取り上げたことのあるあのSPIDERストレージエンジンがさらにパワーアップして便利になった！８月にリリースされたバージョン2.22では次の２つの強化が行われている。 HA機能の追加（データノードの冗長化） LinuxおよびWindows用ビルド済みMySQLパッケージの配布 インストールが簡単になった！前回SPIDERストレージエンジンを紹介したときには、ソースコードからコンパイルする必要があり、なおかつMySQL本体にパッチを適用しなければならず、利用するまでの敷居が高かったように思う。しかし、バージョン2.22よりSPIDERを含んだビルド済みバイナリが提供されたことにより、SPIDERを利用する手間はぐっと少なくなった。しかもこのビルド済みのバイナリにはSPIDERだけでなく各種パッチと、さらにはVPストレージエンジンまで含まれているという気の利きようだ。コンパイル
快適スケールアウト生活への第一歩。SPIDERストレージエンジンを使ってみよう！
先月、Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジンというエントリでSPIDERストレージエンジンによるスケールアウトが凄い！という話を書いた。SPIDERストレージエンジンは凄いヤツだが、ノウハウがあまりウェブ上で見つからない。唯一見つかる日本語の記事は、ウノウラボによる「国産MySQLストレージエンジン「Spider」の作者、斯波健徳氏に聞く 」だけである。SPIDERストレージエンジンは斯波氏による単独の作品であるため、斯波氏は開発だけで手いっぱいであり、使い方の紹介記事を書くことまでは手が回らないのであろう。こんな凄いストレージエンジンをドキュメントが足りないせいで使って貰えないなんて勿体ない！！ というわけで、今日はSPIDERストレージエンジンの基本的な使い方について紹介する。少し長いエントリであるが、最後までお付き
知って得するInnoDBセカンダリインデックス活用術！
InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
