MySQLのZero Dateへの対処法
MySQLのZero Dateへの対処法 MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳 このエントリで、MySQLのゼロが含まれる日付け、いわゆるZero Dateについての問題点が色々挙げられているのを見かけたので、手短に対処法を述べておきたい。 Zero Dateが存在する理由なぜそんな厄介なデータが存在するのかというのは、開発の経緯や互換性といった深淵な理由からなので気にしないで欲しい。まあ、人間は完璧ではないので、人間が作るプログラムも完璧ではないということだ。 当然ながらSQL標準から外れているものは、例外的な使い方をしたい場合を除き、使うべきではない。アンチパターンも使い方次第という話もあるが、例外的な使い方は基本的に苦労が増えるので使うべきではない。 SQLモード実は、Zero DateはSQLモードで禁止できる。SQLモー
データベースについてのそもそも論
先月のはじめのほうで、「リレーショナルデータベースとの上手な付き合い方」というタイトルで、2回発表をした。ひとつは「まべ☆てっく Vol.1」であり、もうひとつは「Hacker Tackle（ハカタクル？）」である。 「リレーショナルデータベースの開発・運用に纏わるもろもろの話をして欲しい」というような内容の話をしてくれないかという同じような依頼を、ちょうど2日違いのイベントで頂いた。9/8のまべ☆てっくと、9/10のHacker Tackleである。そうなると必然的に話す内容も、同じようなものになってくる。同じ人物（＝私）が話すのだから、テーマも同じで時期も同じであれば、内容が同じようなものになるのが自然である。もし違うものになってしまっているのであれば、片方はウソをついているということになるはずだ。今日は発表に使用したスライドを紹介しつつ、なぜデータベースを使うべきなのか（あるいは使う
書籍発行のお知らせ：詳解MySQL 5.7 〜進化したMySQLをよく知るためのテクニカルガイド〜
既に昨日のdb tech showcaseのスライドでご存じの方も多いだろうが、この度MySQL 5.7の新機能を解説するための書籍を発行させていただくこととなった。8月23日発売予定である。 MySQL 5.7の新機能については、これまでブログでは紹介してこなかった。というのも、あまりにもボリュームが多すぎて、ブログという媒体でカジュアルに紹介するには向いていないと思ったからだ。とはいえ、MySQL 5.7を皆さんに使っていただくには、誰かが新機能をしっかりと解説しなければならない。どうするべきか考えた結果、書籍としてまとめて出させていただくことになった。 新機能について真面目に解説しようとすると、新しいポイントがどこなのかということを言及するために、結局のところ元々の機能についてもある程度解説が必要になってしまう。そういうわけで、この書籍では、MySQLが持つ機能の基本的なコンセプトや
あの超オスもセパレート式キーボードを使ってるらしい（ErgoDoxじゃないけど）
超オス。それは漫画、バキシリーズで登場する単語であり、常人離れした、規格外の体格を持った格闘家を指すときに使われる。そんな超オスがIT業界にも存在する。いや、あまりにも有名なので、恐らく業界人であればその名を知らぬ人は居ないだろう。そう、ウェブ魚拓の開発者、新沼大樹氏である。はっきり言って、IT業界で新沼氏を知らなかったらモグリだと言って差し支えない。それどころか、その名はIT業界だけで収まらず、アスリートたちの間でも広まっている。なんせ、握力日本一である。CoCのNo.4（166kg相当）をコンスタントに閉じられるということなので、もしかすると世界一かも知れない。（参考：IRONMAN BLOG:新沼大樹氏、未公開写真、握力王 新沼大樹氏 テレビ出演 - YouTube） 実は、そんな新沼氏から衝撃の発言を聞いた。 「私もセパレート式のキーボードを使っています。」 ・・・ 〜〜〜〜〜〜〜
MySQL・PostgreSQLユーザーグループ（MyNA・JPUG）合同DB勉強会で発表した資料を公開しました。「データモデルについて知っておくべき7つのこと 〜NoSQLに手を出す前に〜」
表題の通り、MyNAとJPUGの合同DB勉強会で発表をしたので資料を公開した。 内容の詳細はスライドそのものを見ていただくとして、言いたいことの主旨はこうである。世の中に完璧なデータモデルはないので、NoSQLは当然の如く必要になる。だが、何でもかんでもNoSQLを使えば良いというものではない。むしろアプリケーションが必要としているデータモデルが何かということをよく理解し、本当に必要な場合にこそ、NoSQLを使うべきなのである。つまり「ご利用は計画的に！」ということだ。 大切なのは、様々なデータモデルを理解し、アプリケーションにとってベストな製品を選択するということだ。ベストなのがRDBかも知れないし、そうでないかも知れない。最適なデータモデルを選択した場合に、出来上がったものの性能も最高になるし、開発効率も最も良くなる。データベースの主流はRDBだが、それはリレーショナルモデルがカバーで
MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
まだMySQL 5.5で消耗してるの？MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法
MySQL 5.6が登場してからかなりの月日が過ぎたが、他のことで多忙だったせいか、MySQL 5.6についてはあまりブログで情報を発信していないことに気がついた。これはイカン！！と思い、MySQL Casual Advent Calendar 2014に合わせて、MySQL 5.6を使用する上で最もオススメしたい機能であるクラッシュセーフなレプリケーションについて解説しようと思う。この記事は16日目の記事である。 レプリケーションがクラッシュセーフとはどういうことかクラッシュセーフとは、何らかの事情により、プロセスがダウンしたりマシンが電源ごと落ちたり（つまりクラッシュ）しても、再起動後に以前の状態に戻って処理を再開できるということだ。データのクラッシュリカバリであればみなさん既によくご存知であろう。（REDOやUNDOするアレのことだ。本稿では面倒臭い・・・ではなかった、本題ではないた
lessでソースコードに色をつける
シェルの操作中「テキストファイルをちょこっと覗きたいな」と思ったときに抜群に便利なlessコマンドであるが、普段綺麗に色付けされたソースコードを見慣れていると、モノクロのソースコードの見づらさに愕然としてしまう。結局lessを終了して他のエディタで開きなおすことになるのだが、lessでソースコードに色付け（シンタックスハイライト）できれば便利なのになーっ！と思ったことはないだろうか。そう、あるんです！lessでシンタックスハイライトする方法はあるんです！というわけで、今日はその方法を紹介しよう。 GNU Source-highlight結論から言うと、今日紹介する方法はGNU Source-highlightを使う。GNU Source-highlightを使えばイッパツだ。なのでまずGNU Source-highlightをインストールしよう。UbuntuやFedoraならリポジトリにあ
「優れたMySQL DBAを見分ける27+3の質問」に対する回答例
随分と更新が空いてしまったが、「優れたMySQL DBAを見分ける27+3の質問」に対する回答例（漢バージョン）を紹介しよう。実は質問を掲載した際「難しい！」というコメントが非常に多く、もう少し易しい質問にするべきだったかと思って次のように呟いてみたのだが・・・ 非常に心強くて安心した。さすがに日本を代表するMySQLのエキスパートである。出題のレベルは間違ってはいなかった！！ そんなわけで、回答の方に移ろう。 MySQLのサーバープロセスはいくつある？ひとつ。mysqldはシングルプロセス・マルチスレッドモデルを採用しているので、"サーバー"プロセスはひとつである。多くの場合、Linuxなどでmysqldを動かす場合には、お供にmysqld_safeも常に動いていることが多いが、mysqld_safeはサーバーではなく、mysqldのためのラッパーであるので数には含めない。 rootユー
高速SSDの落とし穴。データベースで利用するときはご注意を！
今年はSSDの台頭がめざましい。価格の低下、大容量化、そして高速化、さらには低電力化まで期待できるというからもうHDDの出番はなくなるんじゃないだろうかというぐらいの勢いである。しかしそんなSSDもデータベースで利用する時には気をつけてもらいたい。 MySQL Performance Blogでインテル製SSDを使って検証した結果がレポートされている。 インテル製SSDはめっぽう早い。彼らのテストでは一秒間に5250回もの書き込みが出来たそうだ。しかしそれはライトバックキャッシュが有効になっているときの話であって、ライトバックキャッシュを無効にすると書き込みは秒間1200回まで低下したらしい。（それでも高速だが。） で、このインテル製SSDのライトバックキャッシュはくせ者で、バッテリー等で保護されていない。つまり、ライトバックキャッシュにダーティな（まだディスクへの書き出しが完了していない
オープンソースによる新しい受託スタイルの提案
前々回のエントリ「受託開発とGPL」では、受託開発においてGPLのソフトウェアを用いる際に注意すべき点やライセンスの扱いについて書いた。ただし、その視点はあくまでも「GPLはSIerにとって注意すべき≒厄介なシロモノであり、如何に地雷を踏まないようにするか」というものであったように思う。だが、「厄介である」という性質は、裏を返せば「味方につけると頼もしい」ということだ。つまり、GPLは、味方になれば強力で頼もしい存在なのである！今日は、SIerが今の開発スタイルから脱却し、如何にしてGPLを味方につけて戦っていくかということについて語ろうと思う。ちょっとひどい妄想夢物語的な記述も入っているのだが、「何言ってんだコイツ？！」とツッコミたいところをぐっとこらえて最後までお付き合い頂ければ幸いである。 システム全体を再構築するのは大変SIと一口で言ってもその規模は大小様々であるが、業務（基幹系）
MySQL 5.1のスロークエリログ
MySQL 5.1で追加されたメジャーな機能の影に隠れた、地味だが便利な改善がある。それがスロークエリログに関する仕様である。MySQL 5.0まではスロークエリログは1秒未満のクエリを捕捉することが出来なかった。が、MySQL 5.1では1マイクロ秒までのクエリを記録できるようになっている。従って、0.5秒かかるけど大量に実行されてパフォーマンスに大きな影響を与えている！というようなクエリの発見が出来るようになった。1秒未満のクエリを追跡したい場合、例えば以下のような設定をする。 [mysqld] slow_query_log=ON slow_query_log_file=mysql-slow.log long_query_time=0.1 MySQL 5.0まではlog_slow_queryというオプションだったのが、MySQL 5.1ではslow_query_logというオプション名
快適スケールアウト生活への第一歩。SPIDERストレージエンジンを使ってみよう！
先月、Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジンというエントリでSPIDERストレージエンジンによるスケールアウトが凄い！という話を書いた。SPIDERストレージエンジンは凄いヤツだが、ノウハウがあまりウェブ上で見つからない。唯一見つかる日本語の記事は、ウノウラボによる「国産MySQLストレージエンジン「Spider」の作者、斯波健徳氏に聞く 」だけである。SPIDERストレージエンジンは斯波氏による単独の作品であるため、斯波氏は開発だけで手いっぱいであり、使い方の紹介記事を書くことまでは手が回らないのであろう。こんな凄いストレージエンジンをドキュメントが足りないせいで使って貰えないなんて勿体ない！！ というわけで、今日はSPIDERストレージエンジンの基本的な使い方について紹介する。少し長いエントリであるが、最後までお付き
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
パーティショニングの使用例 - http session情報
今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする（たぶん昨日の例よりも）もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDB（MySQL Cluster）ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
プロファイリングで快適MySQLチューニング生活
MySQL 5.1からデフォルトで有効になっている便利な機能としてプロファイリングというものがある。MySQL 5.0でも利用出来たのだが、実験的な機能という位置づけであり、搭載されていたのはGPL版のMySQL Community Server限定だった。MySQL 5.1からは全てのエディションでプロファイリングを利用することができる。 プロファイリング機能を利用すると、クエリの状態（特に状態遷移やリソースの消費状況）を詳細に分析できるのでとても便利だ。MySQLエンジニア必携の機能といって良いだろう。というわけでプロファイリング機能の使い方を説明しよう。 MySQLサーバにログインしたら、まずは次のようにしてプロファイリングを有効にする。 mysql> SET profiling=1; すると、クエリの情報が記録されるようになる。次に、分析したいクエリを実行する。クエリはなんでもいい
Drizzleという名前の新しいおもちゃ
先日、Drizzleという名のプロジェクトが発表された。これはMySQLをベースにした新しいブランチであり、主にバージョン5.0で行われた拡張をそぎ落とし、パフォーマンスに特化したものを目指している。そして、マイクロカーネルアーキテクチャを採用することにより、必要な時だけ機能をプラグインで改めて追加できるようになるという。 MySQLの大改造であり、Brian Aker氏をはじめ開発者たちにとってはまさに新しいおもちゃであろう。 Drizzleがどういうものかについては、Mixiの前坂氏のBlogが分かりやすいので参考にしていただきたい。 http://alpha.mixi.co.jp/blog/?p=189 そして以下がプロジェクトを率いるBrian Aker氏のブログポスト。 http://krow.livejournal.com/602409.html Drizzle Wiki ht
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
