MySQL に関する話題ならなんでも OK な Advent Calendar です。 例: MySQL をこうやって使っている！ ストレージエンジンを作った！ GTIDかわいいよGTID MySQLの実装を読んでみた MySQL のチューニングを頑張って ISUCON に優勝した などを想定しています。 MySQL の話題をカジュアルに出していきましょう。
About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
序章 最近筆者があるシステム上の非同期ワーカーに対して作業していたところ、新しいコードをデプロイしてこのプロセス達を再起動すると全てのワーカーが同じタイミングで停止→再起動してしまうのでアラートがちらほら流れてきました。クリティカルなものではないのですが、アラートはうざいです。さらに開発機では何回か失敗もしたのですが、その失敗のせいでワーカーが起動に失敗することもありました。その間は当然ワーカー機能は止まったままです。 アラートはできればみたくないのです。さらに万が一新しいコードが起動に失敗した場合でも前の世代が動いていればこのあたりの心配をする必要がなくなります自分がそのあたりに手を入れるタイミングでServer::Starterをかまして対処してしまうことにしました。 元のワーカー まず前提として、このワーカー達は以下のような形で「実行するワーカーのコマンド名（実際はクラス名）」と「い
gfxと申します。 Perlは後方互換性を重視しているので、標準モジュールはめったに取り除かれる事がありません。しかしそれでも、いくつかのモジュールが将来的に取り除かれる見込みです。そのようなモジュールは使用しないほうがいいでしょう。また、取り除かれはしないものの、様々な理由から使用すべきでないモジュールもいくつかあります。今日は、そういった使うべきでないモジュールを紹介します。なお、このエントリの対象バージョンは5.8から5.14を想定しています。 さて、まずは取り除かれるモジュールです。現在のところ、以下の三つのモジュールが5.14でコアから削除される予定です。 Class::ISA Pod::Plainer Switch Class::ISAはクラス階層を直列化するモジュールですが、5.10以降はmroに取って代わられました。5.10未満のバージョン用にはMRO::Compatが用意
やあハッキングモンスターのみんな、元気かーい？ ぼくは普通です。 きょうはみんなでログをう゛ぁーてぃかるぱみゅぱみゅしちゃうぞ！あ、こんにちは bayashi です。 さて、ログは見てるかい？cat してるかい？ tail してるかい？ GB単位のログを vim で開いてフリーズさせてやいないかい？ログは吐いたら終わりじゃいけないぜ！ちゃんとうぉっちしないと鬼がでちゃうぞ！！ とはいえ、そんなログも、たいていは1行につらつらと書かれてて見るのがつらいね！！例えばこんなやつだ。 $ tail log 127.0.0.1 - bayashi [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.0 (compatible
前置き こんにちは。はじめまして i47_rozary と申します。みなさん、意識は高まっていますか？ 僕は上々でいたーいです。今回は拙作のTime::Piece::Over24というモジュールを紹介いたします。 皆さん Time::Piece ってモジュールご存知ですか? 軽いとの評判もあり、DateTime に代わって使われるようになってきている時間系のモジュールであります。 ボクは時間周りの処理をよくするので、よく使うんですけれども。Time::Pieceは、24時以降の時間(例えば、25時は翌日の1時であるとか)を扱えないので、深夜帯に生きるボクには活かせづらいときがままありました。 だので、そこら辺をよしなにしたいなといった趣向のモジュールになります。 24時以降のTime::Pieceオブジェクトを作っちゃう use strict; use warnings; use Time
2012年2月1日の更新を持って、カレンダーおよび記事の登録を完全に完了しました。また 2012 年の Advent Calendar でお会いしましょう！ カレンダーのカテゴリに関しては、勉強不足のために不適切なカテゴリに分類されている可能性があります。カテゴリ移動についての希望があればご連絡下さい。( @otchy ) 記事へのリンクテキストについては、原則として記事タイトルからカレンダー名やタグ名などを除いたものとしています。 ただ、「アドベントカレンダー名＋日付」などのように内容が推測出来ない記事タイトルだった場合、記事の内容の簡単なメモをリンクテキストとするように心がけています。
新年あけましておめでとうございます。年明け早々ではありますが、去年の話をします。 昨年末は各種の技術系アドベントカレンダーが盛り上がっていて、そのまとめを作っていました。 まとめサイト自体はすでに公開済でしたが、ようやく (ほぼ) 全ての記事の登録が終わり「完結」と呼べる程度になったので再度アナウンスします。 じゃん！ 上のリンクから飛べる専用サイトで、合計 97 個のカレンダーとそれらに含まれる 2264 もの記事全てに直リンクしています。 2012 年のはじめにこれらのカレンダーの記事をまとめ読みして、今年の抱負なんかを考えてみるのもいいんじゃないでしょうか？ それにしても驚くべきは記事の質の高さとその数です。普段あまり目にする事のない、Web 系以外の技術情報もかなりの数があり、こんな世界があるのかと驚くことも度々でした。日本の Web は技術情報の宝庫です！ 数字の分析 全部で 9
こちら Yappo の日でございますが、 Yappo の執筆ペースが芳しくないので、本日も社員のオオサワが代打で「DBI」や「ORM」について書かせて頂きたいと思います。 trigger / hook point insert, update, delete クエリの前後処理を拡張して、レコード作成時刻の設定や update 時刻の更新はたまたレコード削除時に削除テーブルへの自動コピー等を、一度ベースクラス上で定義しておけば新しく作るテーブルへも use parent する等して簡単に適用出来きるように便利になりますが、うっかりしてると後続の開発者がハマったり制約が出てきます。 DBMS の trigger ORM の機能の trigger を多用していると、後続は DBMS 本体の trigger を使う事に躊躇します。使っちゃいけないというわけではないでしょうが、一つのクエリに対する副
Perl AdventCalendar初投稿でドキドキしているriywoです。目指せhirose31ということで「コードも書けるインフラエンジニア」を所望していますが、正直、DBI使ってゴリゴリアプリとか作ってない。。。限りなくひとりDBIx::Casual Trackではありますが、そんな僕だからこそ書けるゆるふわなエントリをどうぞ！ 情弱なんで生SQLがいいんです。。。 Tengとかすごい魅力的なんですが、ゆるふわ過ぎてついつい生でSQLを書きたくなります。ORMのメソッド覚える努力をしないだけ情弱なんですが、特にインフラはいつも慣れ親しんでいるSQLをそのままアプリでも使いたくなっちゃいます。 とは言え、こんなコードを書いてしまうと色々と残念な感じです(注：2年前くらいの僕)。 my @line = `mysql -N -uuser -ppass hoge -e "select *
※ブクマコメントで指摘頂いた箇所を追記しました＞＜ MySQL Casual Advent Calendar 2011 21日目の記事です。 前日は@sohgohさんの 「MySQLのUDFでカジュアルにファイル操作【MySQL Casual Advent Calendar 2011 20日目】」 でした。図や動画もあって見やすいですね！ 改めて自己紹介です。21日目を担当する、今回のカレンダーでNo.1カジュアルの座を狙っているid:oranie（オラニエ）です。 今回はMySQLもそこそこで、僕の名前の正しい読み方だけを覚えてくれれば今日は大丈夫です。 意図的に間違えている人もたまにいますが、心が汚れすぎていると思うのでお寺で座禅とかした方がいいと思います。 今までの記事を拝見させて頂き、みんな真面目に色々Tipsを書いているのでニッチ狙い＆初心者の僕は 「MySQLに対して、カジュア
2011年8月のkazeburoさんのエントリに対する解説記事です。結論から言うとkazeburoさんの案に賛成なのですが、本日はどうしてそうなったのかというところを確認していきたいと思います。本記事はMySQL Casual Advent Calendar 2011の17日目のエントリです。16日目はakira1908jpさんでした。 当時の内容を覚えていない方は、先にkazeburoさんのエントリをご一読ください。また、テストケースがGitHubに公開されていますのでカジュアルに再現試験をすることも可能です。 Covering Index と self-join と MySQL - blog.nomadscafe.jp kazeburo's gist: 1150842 - Gist 問題のSQLをチューニングするには、MySQLがインデックスに対してどのようにアクセスするかという点につ
カジュアル！(挨拶) このエントリは MySQL Casual Advent Calendar 2011 の18日目の記事です。 昔、専ら PostgreSQL を使っていた頃、MySQL のクエリキャッシュって簡単に性能上がるしみたいだし羨ましいなあ、と思っていました。そのため、1年ほど前から業務で MySQL を使うようになっても、クエリキャッシュは当然のごとく有効にしておりました。 ところが先日 DSAS開発者の部屋:クエリキャッシュは切ったほうがいいんじゃなイカ？ というエントリを読みまして、クエリキャッシュはグローバルロックを獲得するとのこと。これはちょっと検証してみなければなるまい、ということでベンチマークをしてみました。 ベンチマーク結果 結果は別ページにまとめました benchmark script と my.cnf ざっくりと説明しますと、 平均 260 byte/行、1
やぁ。可愛いアイコンでお馴染みの@nekokakだよ。 mysql-casualとか言ってるけどカジュアルな記事が@oinumeさんくらいしかないよね。 ドン引きだね'`,､('∀`) '`,､ ということでガクンと敷居を下げようって感じで超絶カジュアルな話をしてみようと思うんだ。 カジュアル運用していると、「あれなんかこのテーブルまじレコード数おおすぎね？」 とかあるあるですよね。 そこでカジュアルにcountして見るわけです。 InnoDBのテーブルになのにそれもmsaterに対して。 カジュアルですね。 mysql> select count(*) from accesslog; +----------+ | count(*) | +----------+ | 11676738 | +----------+ 1 row in set (1 min 36.99 sec)1分半くらいかか
aloelightです。 みなさん、DBIx書いてますか？私は5年以上はPerlを使っていますが、DBIxを書いたことがありません。CPANの既存ライブラリとDBIの基本機能で間に合ってしますからです。今日はDBI付属の機能の中からDBI::Profileを紹介したいと思います。 どんな時に使うの？ 開発時には何気なく実行してたけど、なんかこの機能が遅いような気がする。そんなことありませんか？ MySQLではEXPLAINを使ってクエリの実行計画を確認することで、そのクエリがなぜ遅いかを判断することができますが、その前にどのクエリが遅いかを判断しなければいけません。お手軽さを求めるなら、DBI::Profileを使うのがいいんじゃないでしょうか。 使い方 DBI::Profileの使い方はいくつかありますが、今回は$ENV{DBI_PROFILE}にセットする方法を使います。他には$dbh
こんにちは、最近 PSP1000 の電池が一瞬で切れてしまってまともにゲームができない xaicron です。 さて、みなさんは DBI から吐かれた SQL をみたいなーと思うこともあるでしょう。 そんな時は、$ENV{DBI_TRACE} = 2 とかしてみると、ドバーッといっぱいデバッグログが出てきて、 その中に実際に発行された SQL がちょろっと出てたりするのでこいつを頑張ってパースすればいい感じですね！ っていうのはだいぶ面倒だったりしますね。あたりまえですね。 そこで、use するだけでとりあえず全部の発行された SQL を STDERR にはいてくれるモジュールを書きました。 その名も DBIx::QueryLog です。そのままですね。 つかいかた 使い方は至極簡単で、どっかで適当に use するだけです。ほかには何もいりません。 そうすると、以下のような感じで STDE
こんばんは。 MySQL Casual Advent Calendar 2011 5日目担当のid:marqsです。 東京は12月6日になってしまったかもしれませんが、京都は霊力が強いせいかまだ12月5日のようです。 MySQLにまつわるCasualなネタ、なかなか思いつかなかったのですがちょっと前に調べたInnoDBのテーブル統計情報について書いてみます。 InnoDBのテーブルのインデックス統計情報ですが、基本的に以下のタイミングで更新されます。 テーブルがオープンされたとき テーブル統計の情報が更新された後、テーブルの全行数の1/16が更新されたとき テーブル統計情報の更新後、20億行以上の行が更新されたとき ANALYZE TABLEが実行されたとき SHOW TABLE STATUS, SHOW INDEX FROM …が実行されたとき この統計情報の更新処理ですが、@nippo
2011-12-08 00:40追記 @karupaneruraさんに指摘されて、s/Plack::Middleware::Conditionals/Plack::Builder::Conditionals/ しました。ありがとうございます。@kazeburoさんすみませんでした。 こんにちは。Songmuです。鎌倉の面白法人でPerlでソーシャルゲームの開発をおこなっています。 「ぼくらの甲子園熱闘編」や「ぼくらのワールドリーグ」の開発に携わっております。 アプリはArk + DBIx::Class + Text::MicroTemplate::Extendedという構成で作ることが多いのですが、 今回はソーシャルゲーム開発で活用しているPlack関連モジュールを2つ紹介させていただきます。 ちなみにArkのadvent calendarもやっておりますので、併せて読んでもらえると嬉しい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く