Leaving Oracle, Joining DeNA
9月1日付けでオラクルを退職し、9月2日付けでディー・エヌ・エーに転職しました。新会社への入社の報告よりも(だいぶ)前に退職の報告をする方が多いようですが、私が外向けにオラクル退職の報告をするのはこれが初めてです。退職と転職の報告と同時に行なうのは、多くの方がナーバスになっているオラクルとMySQLの行く末について、できるだけ悪い印象を与えたくないと考えたためです。ディー・エヌ・エーは世界でも指折りのMySQLの超ヘビーユーザとして知られています。オープンソースの世界では、ベンダーからヘビーユーザの事業会社に転職し、その専門性を生かした仕事を続けることは珍しくありません(オープンソースのメリットの1つです)。というわけで、引き続きMySQLの仕事を続けます。MySQLコミュニティの方はどうか安心してくださればと思います。今後ともどうぞよろしくお願い致します。 私は2006年9月にMySQL
MyISAMとInnoDBのどちらを使うべきか
Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL
マスターInnoDB、スレーブMyISAMが勧められない理由
MySQLにおいて、マスターをInnoDBにして、スレーブをMyISAMにすると幸せになれるという主張をよく聞くことがあります。マスターは耐障害性の高いInnoDBにする一方で、スレーブは耐障害性が低くても大丈夫なので、InnoDBのかわりに高速とされるMyISAMを使えば、可用性と性能の両方をバランス良く実現できる、という考えです。 しかし、多くの場合これで幸せになることはできません。マスターとスレーブでストレージエンジンを合わせた方が無難です。その理由を以下に示します。 ●MyISAMはテーブルロックになる マスターへの更新結果はバイナリログに更新系SQL文として書かれ、スレーブのI/Oスレッドによってリレーログとして同じフォーマットで記録され、スレーブのSQLスレッドによってその更新系SQL文がそのまま実行されます。この更新系SQL文は、当然ながらスレーブに対して発行されるSELEC
InnoDBのAUTO_INCREMENTが遅い問題は5.1でどう改善されたのか
MySQL5.1のGA版が出てから8ヶ月余りが経過しましたが、まだ5.0(あるいはそれ以前)をメインで使っている方も多いのではないでしょうか。5.1の何が良いのかいまいち分からないという方も多いかもしれません。そんな方にとって分かりやすい例の1つが、「5.1でInnoDBのAUTO_INCREMENT性能が大幅に改善された」という点です。私は仕事柄Web系の技術者の方と話をする機会もよくありますが、意外と知られていない改善なので(まさにトラフィックと同時接続数の多いWeb系システムのための改善なのに…)この機会に取り上げることにします。 簡単に言えば、AUTO_INCREMENTを持つテーブルに対してINSERTをするクライアント数が数十、数百と増えていった時に、従来はスループットが指数関数的に落ちてしまっていたのが、5.1では高速かつ安定するようになりました。以下にmysqlslapのI
新書籍「Linux-DBシステム構築/運用入門」
Linux上で「高速で、落ちない」DBサーバーを構築するための技術解説をした書籍を出版します。タイトルはストレートに「Linux-DBシステム構築/運用入門」です。 9月17日発売ですが、ジュンク堂など一部の書店ではすでに入荷しているそうなので、見かけたらぜひ読んでみてください。章構成は以下の通りです。 第1章 論理ボリュームマネージャ(LVM)を活用する 第2章 Heartbeatによるクラスタ環境の構築 第3章 DRBDによるネットワークミラーリング(前編) 第4章 DRBDによるネットワークミラーリング(後編) 第5章 高可用DBサーバーの構築 第6章 現場で使われる高可用構成 第7章 DBサーバーのパフォーマンス概論 第8章 インデックスのチューニング(前編) 第9章 インデックスのチューニング(後編) 第10章 DBサーバーのハードウェア選定 第11章 SSDの効果とアプリケーシ
正しいベンチマークをするための10のポイント
世の中ではたくさんの人が独自にベンチマークを行ない、独自に情報発信がされています。そのベンチマークの中には、非常に参考になるものもあれば、現実性に大きく欠けるものもあります。競合他社が、ライバル社の製品にとって不利な条件でベンチマークを行い、それを発信することも日常的に行われています。ベンチマークの結果を鵜呑みにすることは危険で、結果の意味を判断するスキルを持つことが重要です。これはプロジェクトにおいて負荷テストを行う場合にも重要です。負荷テストの条件設定が正しいかどうかを判断できるようになるためです。 ここでは、私がDBサーバのベンチマーク/負荷テストを行ったり結果を読んだりする上で、心がけているポイントを10個ほど紹介したいと思います。 ■ハードウェアに関する4つのポイント 1. ハードウェアのスペックと設定を注視する ハードウェア構成によってベンチマーク結果は劇的に変わるので、言わず
全テーブルの統計情報をサイズ順に一覧表示する
MySQLにおいて、テーブルサイズやインデックスサイズ、レコード数、平均レコード長などの統計情報を知る上でshow table statusは定番です。ただ雑多な表示項目も多いので、たくさんのテーブルの統計を見る場合、必要な情報だけを返したいことは多いです。また全テーブルのうち、どのテーブルが一番大きいのかを知りたいとか、サイズが多い順に一覧表示したいとか、一目で分かるような情報がほしいことも多いです。 こういうときはinformation_schema.tablesを使うと便利です。以下の例では、appデータベースの全テーブルについて、「テーブルサイズ+インデックスサイズ」の大きい順に、ストレージエンジン、レコード数、平均レコード長、テーブルサイズ(MB)、インデックスサイズ(MB)などを返しています。 use app; select table_name, engine, table_
InnoDB Plugin 1.0.4 - InnoDB史上極めて重要なリリース
日本時間の今日、InnoDB Pluginの新バージョン1.0.4がリリースされました。このバージョンでは、「バイナリログを有効にするとグループコミットが効かなくなる問題」が修正されています。ほとんどの環境にとって極めて効果の高い修正です。ほかにもI/Oスレッドの多重化(同様のものがMySQL5.4にも搭載)など効果的な修正が行なわれています。 InnoDB PluginはまだGA(安定版)ではないので、品質面では標準搭載されているInnoDBよりも落ちます。ただしMySQL Enterpriseサブスクリプションを買っている方であれば追加費用無しでInnoDB Pluginのサポートを受けることができるので、お気軽に試してみて頂ければと思います。 グループコミット問題修復の効果のほどは、一目瞭然なので図を見た方が分かりやすいでしょう。下図は、mysqlslapで、複数のコネクションから並
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
