タグ

ブックマーク / opendatabaselife.blogspot.com (13)

  • ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift

    最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。 このは、データベースのためのということで、データベース設計、SQLMySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に格的に使われている方々による記事なので大いに参考になると思います。 私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。 ・MySQL (RDBMS) 私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します

    kazeburo
    kazeburo 2014/03/24
    “Open database life: ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift”
  • インフラエンジニアのキャリアとクラウドについて

    もう注目されるようになって久しいクラウドについて、思うところを書いておきます。 LinuxなりMySQLなりといったインフラ技術のスペシャリストの人が、GoogleなりFacebookなりといったサービス事業者で働くことは珍しくありません。これはそうしたサービス事業者にとって、インフラ技術のスペシャリストがある程度必要だということでもあります。ではこれからLinuxなりMySQLなりのスペシャリストになりたいという人(新卒/中途問わず)はどういう会社を目指すのが良いのでしょうか。私は家ベンダー(RedHatなりOracleなり)や大手サービス事業者(FacebookなりDeNAなり)が良いと思っていますが、一点「クラウド上で主力サービスを展開している事業者」はやめた方が良いと考えています。 なぜなら、インフラ技術を語る上で欠かせないハードウェアとネットワークが、クラウド上ではブラックボッ

    kazeburo
    kazeburo 2013/04/09
    “Open database life: インフラエンジニアのキャリアとクラウドについて”
  • 新著「Webエンジニアのための データベース技術[実践]入門」

    データベース技術に関する新著を執筆しました。「Webエンジニアのための データベース技術[実践]入門」というです。 第1章:データベースがないと何が困るのか 第2章:インデックスで高速アクセスを実現する 第3章:テーブル設計とリレーション 第4章:SQL文の特徴とその使いこなし方 第5章:可用性とデータの複製 第6章:トランザクションと整合性・耐障害性 第7章:ストレージ技術の変遷とデータベースへの影響 第8章:データベース運用技術の勘どころ 第9章:MySQLに学ぶデータベース管理 第10章:MySQLのソースコードを追ってみよう 第11章:データベース技術の現在と未来 第12章:ビッグデータ時代のDB設計 ---「はじめに」より 私たちが日々活用しているオンラインサービスでは、ほぼ例外なくデータベースが背後で重要な役割を果たしています。ブログサービスのような無料のものだけでなく、ショ

    kazeburo
    kazeburo 2012/03/07
  • Leaving Oracle, Joining DeNA

    9月1日付けでオラクルを退職し、9月2日付けでディー・エヌ・エーに転職しました。新会社への入社の報告よりも(だいぶ)前に退職の報告をする方が多いようですが、私が外向けにオラクル退職の報告をするのはこれが初めてです。退職転職の報告と同時に行なうのは、多くの方がナーバスになっているオラクルとMySQLの行く末について、できるだけ悪い印象を与えたくないと考えたためです。ディー・エヌ・エーは世界でも指折りのMySQLの超ヘビーユーザとして知られています。オープンソースの世界では、ベンダーからヘビーユーザの事業会社に転職し、その専門性を生かした仕事を続けることは珍しくありません(オープンソースのメリットの1つです)。というわけで、引き続きMySQL仕事を続けます。MySQLコミュニティの方はどうか安心してくださればと思います。今後ともどうぞよろしくお願い致します。 私は2006年9月にMySQL

    kazeburo
    kazeburo 2010/09/02
    ひゃー
  • 全テーブルの統計情報をサイズ順に一覧表示する

    MySQLにおいて、テーブルサイズやインデックスサイズ、レコード数、平均レコード長などの統計情報を知る上でshow table statusは定番です。ただ雑多な表示項目も多いので、たくさんのテーブルの統計を見る場合、必要な情報だけを返したいことは多いです。また全テーブルのうち、どのテーブルが一番大きいのかを知りたいとか、サイズが多い順に一覧表示したいとか、一目で分かるような情報がほしいことも多いです。 こういうときはinformation_schema.tablesを使うと便利です。以下の例では、appデータベースの全テーブルについて、「テーブルサイズ+インデックスサイズ」の大きい順に、ストレージエンジン、レコード数、平均レコード長、テーブルサイズ(MB)、インデックスサイズ(MB)などを返しています。 use app; select table_name, engine, table_

  • デブサミ2010でLinux/DBに関する話をします

    デブサミ2010で「高性能・安定運用のためのLinux-DBシステム構築/運用技術」というタイトルで講師をすることになりました。2010年2月18日の13:10から14:00のセッションです。 DB サーバには、RDBMSはもちろんのこと、OSやハードウェアも当然必要ですし、運用管理ツールやクラスタリングソフトウェアなどの支援ツール併用することも多いです。現実の運用では、支援ツールを使うことによって引き起こされるトラブルもあります。DBサーバを取り巻く全体像を把握した上で適切な対処を取れることが大切です。セッションではこうした話をします。またRDBMSを安定稼働させ、かつ性能を発揮させるにあたって、ハードウェア、スワップ、ファイルシステム、I/Oスケジューラ、Linuxカーネルなど、どういった要素や現実問題としてトラブルになりやすく、どうすれば効果があるか、といった実戦的な話もします。

    kazeburo
    kazeburo 2009/12/23
  • MyISAMとInnoDBのどちらを使うべきか

    Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL

  • スワップサイズをゼロにしてはいけない

    先月発売された書籍「Linux-DBシステム構築/運用入門」は、なかなか上々の売れ行きとなっているようです。Amazonではしばらく「1-2ヶ月待ち」の状態が続いてしまっていたのですが、最近になってようやく解消され、容易に入手できるようになっているようです。Amazonの在庫切れ問題がひと段落したところで、これからは書籍のサポート的な情報を書いていくことにします。 まず、書を購入された皆さまありがとうございました。結構な数の方がBlogやTwitter等で、このをほめてくださっていることに大変感謝しています。まだ自体の認知度が低い(存在自体を知らない顧客も多い)ので、普及活動をしつつ、これからも読者の期待に応えられる記事を書いていきたいと思っています。 最初は、よく見かけることの多い「メモリ管理」の話題を取り上げようと思います。第12章では、メモリ管理とスワップ領域に関する解説をして

  • 新書籍「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. ハードウェアのスペックと設定を注視する ハードウェア構成によってベンチマーク結果は劇的に変わるので、言わず

  • DBチューニングではディスクI/O性能を注視する

    DBチューニングにおいて、気を配るべきところは数多くありますが、中でも真っ先に見るべきところはディスクI/Oでしょう。なぜかというと、メモリアクセスに比べてHDDの方が圧倒的に遅く、最もパフォーマンス阻害要因になりやすいためです。ディスクI/Oネックの解決方法を探っていくと、「テーブル/インデックス設計やSQL文の見直し」に行き着くこともまた多いです。これらが不適切だと、結果として大量のレコードをアクセスすることになり、ディスクI/Oが多く発生してしまうためです。根的な原因はディスクI/Oにあります(CPUネックになることもありますが、その例は別の機会に取り上げます)。 ディスクI/Oには大きく分けてシーケンシャルアクセスとランダムアクセスの2種類のアクセスパターンがありますが、RDBMSではインデックスアクセスが主体となるため、ルート→ブランチ→リーフ→実レコードという経路でのランダム

    kazeburo
    kazeburo 2009/08/14
  • InnoDB Plugin 1.0.4 - InnoDB史上極めて重要なリリース

    時間の今日、InnoDB Pluginの新バージョン1.0.4がリリースされました。このバージョンでは、「バイナリログを有効にするとグループコミットが効かなくなる問題」が修正されています。ほとんどの環境にとって極めて効果の高い修正です。ほかにもI/Oスレッドの多重化(同様のものがMySQL5.4にも搭載)など効果的な修正が行なわれています。 InnoDB PluginはまだGA(安定版)ではないので、品質面では標準搭載されているInnoDBよりも落ちます。ただしMySQL Enterpriseサブスクリプションを買っている方であれば追加費用無しでInnoDB Pluginのサポートを受けることができるので、お気軽に試してみて頂ければと思います。 グループコミット問題修復の効果のほどは、一目瞭然なので図を見た方が分かりやすいでしょう。下図は、mysqlslapで、複数のコネクションから並

    InnoDB Plugin 1.0.4 - InnoDB史上極めて重要なリリース
  • 勉強会「MySQL Hackingの手引き」を終えて

    昨日は、グリー勉強会にて「MySQLハッキングの手引き」というテーマで発表をしました。資料とデモに使用したソースコードやビルドスクリプト等はこちらに公開しています(サンプルプログラムのコンパイルにはソースからビルドしたMySQL5.1以降が必要)。声をかけてくださったグリーの一井さんや、会場準備など諸手続きを行なってくださったグリーのスタッフの方々、参加された皆さまありがとうございました。 ●参加者数の意外な多さ 無料の勉強会とはいえ、このようなマニアックなテーマで、60名定員のところに150名を超える応募が来たというのは驚きました。相当数の方が抽選落ちしてしまったのは残念でしたが、評判が良ければ似たようなテーマでのセミナーをまたどこかで行ないたいと考えています。 自分はMySQLコンサルティングという、MySQLの使い手としての専門職(パフォーマンスチューニングとか運用管理とか)に従事

  • 1