タグ

MySQLに関するgidooomのブックマーク (33)

  • ウェブオペレーションエンジニアはリリース前のソースコードのココを見ているッ! - blog.nomadscafe.jp

    「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る!」みたいな記事があればいいね — masahiro nagano (@kazeburo) November 20, 2012 ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。 そのサービスへの導線とランディングページの確認 まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります — masahiro nagano (@kazeburo) November 20, 2012 どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対し

    gidooom
    gidooom 2012/12/10
    導線先は要注意。
  • ガチでDeNAの技術情報が詰まった「Mobageを支える技術」を読んだ - まいんだーのはてなブログ

    先週末くらいに頂いたのに週末読めなかったけど先程だいたい読み終わりました。 実際の発売日は6/13からなので、今すぐアマゾンで予約するか屋に並ぶといいよ! をいただいて感想を書くのは初めてなわけなのでどう書いたらいいやらわかりませんが読んでおもったことを素直に言えばいいのかなと思うのでそのように書きます。 このはここ数年各所で出ているMobageないしDeNAの技術ノウハウ系情報を一堂に集めて全部書いた総集編的な位置づけと考えるとわかりやすいでしょう。 各章「今/明日から使えるテクニック」みたいなものではないケースが多いですが、ひとつのサービスの技術だけでこれほどの情報量が出てくるのは凄いことですね。 yappoさんも書いていますが、書の分量的にはpart2, part3が圧倒的で「インフラの面倒を見ている人やサーバサイドのコードを書いているけど下のレイヤも考えてる人、もしくは考え

    ガチでDeNAの技術情報が詰まった「Mobageを支える技術」を読んだ - まいんだーのはてなブログ
    gidooom
    gidooom 2012/06/12
    Amazonから届くのが楽しみ
  • 米国への引越とFacebook入社のご報告

    件名の通り、私は米Facebookに最近入社したことをここでご報告します。 相変わらずMySQL関係の仕事をすることになります。 チームメンバーはアジアには誰もおらず大半が米国社(Menlo Park)にいるため、自分も引っ越すこととなりました。 すでに生活の拠点を会社から10km未満というそう遠くないところに移しています。 当然ながら入社前に話をオープンにするわけにもいかないので、DeNAの中の方たちや、ごく親しい人にしかご挨拶ができずにすみませんでした。 このBlogの読者であればご存知のように、私はキャリアの途中からほぼMySQL仕事をしてきています。 実はDeNAは、世界でも指折りのMySQLのヘビーユーザとして認知されています。 去年の米MySQL Conferenceでは会社としてAwardを受けました。それも純粋に技術的な貢献が評価された上での受賞であり、「日でのコ

    gidooom
    gidooom 2012/03/27
    マジすか!!
  • 大規模ソーシャルゲーム「ドラゴンコレクション」運営の最前線で得られたノウハウ ~チューニングと運用、18のポイント~

    11月25日、「mobidec 2011」においてコナミデジタルエンタテインメントのスタジオITセンター長である正延光弘氏によるセッション「大ヒットSNSゲーム『ドラゴンコレクション』を支えるコナミのクラウド技術の活用」が行われました。 ドラゴンコレクションは、GREEで提供されている携帯電話向けのカードゲームタイプのRPG。プレイヤーは、エリアごとにある複数のクエストをクリアしていき、モンスターカードや「秘宝」を手に入れ、さらに「ドラゴンカード」を集めていきます。また、ほかのプレイヤーとバトルすることでも秘宝を入手できるというSNS要素も取り入れられていました。2010年9月のサービス開始後、順調にプレイヤー数を伸ばし、現在では登録人数が500万人を超えています。 サービス開始当初は社内でサーバを構築し、フロントエンドに6台のサーバ、バックエンドに3台のデータベースサーバ、そしてロードバ

    大規模ソーシャルゲーム「ドラゴンコレクション」運営の最前線で得られたノウハウ ~チューニングと運用、18のポイント~
    gidooom
    gidooom 2011/12/22
    参考になるなる。MySQL 5.1からのパーティショニング活かしてるんすね。
  • MySQLにおけるレプリケーション遅延の傾向と対策

    レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということをエントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ

    MySQLにおけるレプリケーション遅延の傾向と対策
    gidooom
    gidooom 2011/12/14
    レプリ遅延が起きて原因をいまいち分からないときに見返したい内容
  • oinume journal

    Raycastを使い始めて1年経ったので、どういうことに使っているかを振り返ってみる。去年書いた AlfredからRaycastに移行した - oinume journal の記事から少し使い方が変わっているところもあるのでメモがてら。 基的な使い方 Cmd + QをRaycast起動のショートカットとして割り当てている。Pro版は使っていないのでAI機能などは使ったことがない。 ブラウザのブックマーク検索など、よく使うけどHotKeyを割り当てるほどでもないRaycastコマンドはbmのようにAliasを設定している。 Cmd + QでRaycastを起動してbmと入力するとブックマークの検索ができるので楽ちん アプリケーションランチャー機能 アプリケーションを起動するときのランチャーとして使っている。よく使うアプリにはHot Key(ショートカット)を割り当ててる。 Clipboar

    oinume journal
    gidooom
    gidooom 2011/12/11
    これやってみようー
  • MySQLがおかしい!あなたならどうしますか? – MySQL Casual Advent Calendar 2011 - As a Futurist...

    しわっす!DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい>< MySQL がおかしい! 03:14 hidek: なんかエラー出まくってるんだけど! 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね?ね?ね?こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう?既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま

    MySQLがおかしい!あなたならどうしますか? – MySQL Casual Advent Calendar 2011 - As a Futurist...
  • [37signals] Moore氏はシャーディングを蹴飛ばす

    (原文: Mr. Moore gets to punt on sharding) シャーディングは大規模データベースをより小さなものに分割するデータベース構築手法だ。でかい鉄のかたまりのような1台のマシンに100万人ぶん格納する代わりに、より小さな個別の10台のマシンに10万人ぶんづつ格納する。 この手法については一般に、必要に迫られるまで手を出すな、と言われている。Martin Fowler(訳注: リファクタリングでおなじみ)が分散オブジェクト設計の第一法則として「オブジェクトを分散させるな」と言っているのと似たようなものだ。シャーディングはいまだに他の手法と比べて難しいし、支援ツールは貧弱だし、あきらかにセットアップ作業が複雑化する。 まぁ、選択の余地がなくなる日が来るのは避けられないのだということは常に意識してはいる。上方向への拡大(訳注: マシンのパフォーマンス向上などのことか)

  • MySQL/レプリケーション - がしまっくす

    対象DB・テーブル、除外DB・テーブルの設定 † /etc/my.cnf に以下のようにずらずらと記述する 複数指定したい場合は複数行書けば良い show slave status で設定が有効になっているか確認すべし replicate-wild-do-table = repl_%.% ............ repl_●.● はレプリケーション replicate-ignore-db = repl_test2 .............. repl_test2 は除外 replicate-ignore-db = repl_test3 .............. repl_test3 は除外 replicate-ignore-table = repl_test.hogehoge ... repl_test のhogehogeテーブルは除外 ↑ Query caused differe

  • スレーブへのレプリケーションのタイムラグを解消 - Bacchus.gif

    昨夜、Webアプリに対するリクエスト数が急激に増大し、MySQLのスレーブに対するレプリケーションのタイムラグがみるみる増加し、アプリケーションロジック上のエラーが頻発するようになってしまった。 一昨日のピークが秒間300リクエストちょい、昨日が800超え。。。おそるべし、ソーシャルアプリ。 cacti で見ていたタイムラグの単位が、てっきりミリ秒だと思ってたら、実は秒だったことが発覚して、青ざめた。 遅延が2秒になっちゃったよ、やべーよ、と話していたら、実は2,000秒だった罠。。。orz オワットル。ひさびさにシビれた。。。 実践ハイパフォーマンスMySQLに助けを乞うと、「 8.7.14 レプリケーションの過度の遅延」というまさにぴったりの項目があり、とにかくスレーブに余計な仕事をさせるな、とのお達しが。ディスクのIOWaitが結構あったので、ディスクへのIOを減らす目的で、で紹介

  • AndroidのNFC機能でFeliCaの読み書きをする | −ゆめログ− | ゆめみスタッフブログ

  • 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

    InnoDBのAUTO_INCREMENTが遅い問題は5.1でどう改善されたのか
    gidooom
    gidooom 2011/08/10
    5.0と5.1でINSERTの性能曲線がかなり違う。そしてデッドロックしていないのにデッドロック扱いのエラーの発生も5.1なら抑えられるという。これは5.1に上げるべきだな。。
  • Kazuho@Cybozu Labs: MySQL のウォームアップ (InnoDB編)

    « DBIx::Printf と LIKE 式 | メイン | メッセージキュー事始め in Perl - コマンドラインクライアントを作ってみた » 2007年10月11日 MySQL のウォームアップ (InnoDB編) サーバの起動直後はデータがメモリ上にないためデータベースの応答速度が遅い、というのは良く知られた話かと思います。MySQL の場合、使っているエンジンが MyISAM であれば、各データファイルをあらかじめ cat ... > /dev/null するなりしてバッファキャッシュに載せておけばいいのですが、InnoDB は独自のキャッシュを持っているのでそういうわけにもいかないように思います。 具体的には、パフォーマンスを最大限発揮するためには OS のキャッシュにではなく、InnoDB のバッファプールにデータをロードすべきであるという点。それに、たとえ OS のキャ

    gidooom
    gidooom 2011/07/05
    メモリに乗せる事の大切さを味わった一日だったよ・・・
  • ソーシャルゲームのためのMySQL入門その2 | BLOG - DeNA Engineering

    こんにちはこんにちは。11インチMacBook Airが欲しくてたまらないiwanagaです。 前回の記事 が幸いにもご好評を頂けた様で非常にうれしいです。嬉しくなって、ついがんばって第2弾を書いてしまいました。引き続き、ソーシャルゲームでよく使われるテーブルタイプ毎にちょっとしたテクニックを紹介していきます。 今回はちょっとライトな感じ&読み物になってしまっていますが「ユーザID単位で1つだけ持つデータ」と「パラメータなどのマスターデータ」についてご説明したいと思います。ちなみに次回はInnoDBのデータ構造の簡単な説明と複合プライマリーキーのデータについて、その次で紹介し損ねたちょっとマニアックなテクニックや性能管理のための手法を紹介することを予定しています。 その前に。。。 先日行われた JAPAN INNOVATION LEADERS SUMMIT で弊社松信が「ソーシャルゲーム

    ソーシャルゲームのためのMySQL入門その2 | BLOG - DeNA Engineering
  • MySQLでALTER TABLE文の進捗状況を確認する - SH2の日記

    MySQLでテーブルへのカラム追加やテーブルの再編成を行うには、ALTER TABLE文を使用します。MySQLのALTER TABLE文は、変更後の定義にもとづく作業用テーブルを作成し、変更前のテーブルから作業用テーブルへデータをコピーして、最後に二つのテーブルを入れ替えるという仕組みになっています。テーブルへのインデックス追加についても、現在のところ大半のケースで内部的にALTER TABLE文が実行されています。 ALTER TABLE文の怖いところは、処理がもうすぐ終わるのかどうかが分からないところです。テーブルサイズが1GBを超えるあたりから分単位の時間がかかるようになり、100GBともなると当に終わるのか?と見ていて不安になります。メンテナンス時間が限られている場合は、作業を中断すべきかどうか難しい判断を迫られることもあります。 実は、というほどではありませんが、ALTER

    MySQLでALTER TABLE文の進捗状況を確認する - SH2の日記
  • MySQL スレーブで SQL スレッドが停止した場合の対処方法 - maruko2 Note.

    MySQL スレーブで SQL スレッドが停止した場合の対処方法 提供:maruko2 Note. 移動: 案内, 検索 MySQL スレーブで SQL スレッドが停止(Slave_SQL_Running: No)した場合、次のような対処方法がある。 mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event 省略 Relay_Log_Pos: 13550246 Relay_Master_Log_File: mysql-bin.000010 Slave_IO_Running: Yes Slave_SQL_Running: No 省略 Last_Errno: 1062 Last

    gidooom
    gidooom 2011/06/19
    いざという時のためにメモっとこう。
  • 『データベースを高速化するためにindexを張るよ』

    なぜindexを張らないといけないのか SQLを高速にするためにはindexを張る必要があります。 indexとは、コンピュータが検索しやすいようにデータつける索引の事です。 検索で利用する条件にあわせてindexを張ってあげると大量データの場合は大幅にパフォーマンスが改善されます。 indexに関して、詳しくは下記のサイトをみると良いと思います。 インデックスの基礎知識 indexの張り方(mysqlの場合) MySQLのindexは1つのクエリーに対して1つしか効きません。 そこでアプリ内で発行するクエリーごとにどのようなindexを張るか検討していきます。 複数の項目を利用して検索する場合は複合インデックスを使います。 説明は下記のサイトが素晴らしいです。 MySQLパフォーマンスチューニングのためのインデックスの基礎知識Comments また、ひとつのindexは数100件から10

    『データベースを高速化するためにindexを張るよ』
    gidooom
    gidooom 2011/05/10
    勉強させて頂きやす!
  • 最終回 治療としてのパフォーマンスチューニング―システムの病気はどう治す?(1) | gihyo.jp

    前回のおさらい&今回の概要 前回では、ユーザから受け取ったSQLに対して、DBMSがどのような手順を踏んでデータを取り出す(または更新する)か、という一連の流れを解説しました。今回は、そこから一歩進んで、実際にシステムに性能問題が発生したとき、どのように対処するか、という実践的なところに踏み込んで解説したいと思います。 前回の内容を前提とするものではありませんが、オプティマイザを中心とするクエリ評価エンジンの機能については、知っていたほうが理解しやすいでしょう。忘れてしまったという方は、第4回(1)で簡単におさらいしてください。 パフォーマンスチューニングは医療に近い 筆者は、仕事でパフォーマンスチューニングを引き受けることがよくあります。性能試験の一環として遅延が発生した処理のチューニングを行うこともあれば、すでにカットオーバーされて運用に入っているシステムが遅延を起こして、お祭りの会場

    最終回 治療としてのパフォーマンスチューニング―システムの病気はどう治す?(1) | gihyo.jp
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 5.4.5 スロークエリーログ

    スロークエリーログは、実行に long_query_time 秒を超える時間がかかり、少なくとも min_examined_row_limit 行を検査する必要がある SQL ステートメントで構成されます。 スロークエリーログは、実行に長い時間がかかっているため最適化の候補となるクエリーを見つけるために使用できます。 ただし、長いスロークエリーログの調査には時間がかかる場合があります。 これを簡単にするために、mysqldumpslow コマンドを使用してスロークエリーログファイルを処理し、その内容を要約できます。 セクション4.6.9「mysqldumpslow — スロークエリーログファイルの要約」を参照してください。 初期ロックを取得する時間は実行時間として計算されません。mysqld がスロークエリーログにステートメントを書き込むのは、ステートメントが実行されて、すべてのロックが解

  • 全てのデータを削除する(TRUNCATE TABLE文)

    指定したテーブル名( table_reference )に格納されているデータをすべて削除します。 全てのデータを削除するには DELETE 文を使って DELETE FROM tbl_name でも同様のことが行えます。ただ DELETE 文がデータを 1 つずつ削除するのに対して、 TRUNCATE TABLE 文の場合はテーブルをいったん削除して改めてテーブルを作成するためテーブルに格納されているデータが非常に多い場合には高速で行える場合があります。また他にも異なる点があるのでのちほど解説します。DELETE 文については「データを削除する(DELETE文)」を参照されてください。 -- -- それでは実際に試してみます。次のようなテーブルを作成しました。

    全てのデータを削除する(TRUNCATE TABLE文)
    gidooom
    gidooom 2011/04/26
    DELETEとTRUNCATEの違い