タグ

mysqlに関するnipotanのブックマーク (87)

  • NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ/秒を実現

    モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか? それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範(まつのぶよしのり)氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」(英語)をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で

    NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ/秒を実現
  • MySQLでサービス停止のないALTER TABLEの検討 - SH2の日記

    MySQLでテーブルへのカラム追加、インデックス追加やテーブルの再編成などを行うと、その間テーブルに共有ロックがかかってしまいます。そのためこれらのメンテナンス処理は、通常利用者の少ない深夜早朝帯にサービスを止めて実施する必要があります。日はそれを無停止、オンラインのままでできないかという話題です。 基的なアイデア メンテナンス対象の元テーブルをコピーして、作業用の仮テーブルを作ります 仮テーブルに対して、カラム追加などの変更を加えます その間、元テーブルに対して行われる更新処理について差分を記録しておきます 仮テーブルの変更が終わったら、記録しておいた差分データを仮テーブルに反映します 差分データの反映が終わったら、元テーブルと仮テーブルを入れ替えます これと似たようなことを考えた方は結構いらっしゃるのではないでしょうか。ただ、言うは易し、行うは難しです。整合性がきちんと取れるかどう

    MySQLでサービス停止のないALTER TABLEの検討 - SH2の日記
  • MySQL の複合 DELETE 構文 - 日向夏特殊応援部隊

    1ヶ月半ぶりのエントリです。皆さんお元気ですか? 何故か最近 Eclipse ばっかり使ってる zigorou でございます。 12.2.1 DELETE 構文 を見ていたら複合 DELETE 構文ってのが有ったので試してみました。 前提としてレコードがうんざりする程多いテーブル、、、と言う背景があります。 解説 とりあえず次のようなテーブルがあるとしましょう。 CREATE TABLE `diary` ( `id` int(11) NOT NULL AUTO_INCREMENT, `guid` int(11) NOT NULL, `subject` varchar(32) DEFAULT NULL, `body` text, `created_on` datetime DEFAULT NULL, `updated_on` datetime DEFAULT NULL, PRIMARY KE

    MySQL の複合 DELETE 構文 - 日向夏特殊応援部隊
  • MySQLで、指定したときだけクエリキャッシュする - (ひ)メモ

    今までMySQLのクエリキャッシュはは有効にしてたんですが、Webサービスだとキャッシュヒットするようなクエリはそんなに多くないし、どこかで見かけたんですが(失念…)クエリキャッシュをオフにしたら(逆に)パフォーマンスが上がっただか負荷が下がっただかというのも目にしたので、今度クエリキャッシュはオフにしようと思ってました。(どのみちヒット率悪いし) そんなとき、同僚に query_cache_type を教えてもらいました。(4.0からあるオプションなのに今まで知りませんでした。。。><) http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_query_cache_type てっきりクエリキャッシュはオンかオフかしかできないと思い込んでたんですが、"DEMAND" を指定すると、「原則キャッシ

    MySQLで、指定したときだけクエリキャッシュする - (ひ)メモ
    nipotan
    nipotan 2010/04/06
    知らなかった。そして my.cnf 罠すぎる
  • 漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。

    InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い(テーブルの行数を保持してる)のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ

    漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
    nipotan
    nipotan 2010/03/09
    うな場合でも、セカンダリインデックスをスキャンするだけで正しい結果が得られることになり、オプティマイザは最も効率よくスキャンが出来るカラム=サイズの小さいカラムを選択するわけだ。ちなみに、COUNT(a)でもカ
  • Kazuho@Cybozu Labs: Mycached: memcached protocol support for MySQL

    It is a well-known fact that the bottlenecks of MySQL does not exist in its storage engines, but rather in the core, for example, its parser and execution planner.  Last weekend I started to wonder how fast MySQL could be if those bottlenecks were skipped.  Not being able to stop my curiousity, I started  adding memcached proctol support to MySQL as a UDF.  And that is Mycached. From what I unders

  • Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法

    MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a

  • mysqlでいちいちshow databasesとか打つのがめんどい→readlineのマクロで解決 - (ひ)メモ

    MySQLでいちいちshow tables;とか打つのがだるい。\tみたいなalias設定できないのかなぁ http://twitter.com/weboo/status/1658300902 おぉ、readlineのマクロを使えばいいのかー http://twitter.com/weboo/status/1658314333 なるほ!ってことでちょっと設定してみました。 # ~/.inputrc $if mysql "\C-xd": "show databases;" "\C-xt": "show tables;" "\C-xu": "select user,host,password from mysql.user order by user,host;" "\C-xb": "select user,host,db from mysql.db order by user,host;"

    mysqlでいちいちshow databasesとか打つのがめんどい→readlineのマクロで解決 - (ひ)メモ
    nipotan
    nipotan 2009/06/01
    .inputrc あんまいじったことない
  • livedoor Reader

    livedoor Readerサービス終了のお知らせ 2014年12月をもちまして、LINE株式会社が提供するlivedoor Readerの運営を終了しております。 長きに渡りご愛顧をいただきまして、誠にありがとうございました。 livedoorホームへ戻る

    nipotan
    nipotan 2009/05/19
    うわ。やばい。まったくモザイクかかってない。美しすぎる上に、見えすぎる。やばい。こんなすごいの初めてみた。みるく噴きだしてきた。止まらない。たすけて。
  • hansode.org - このウェブサイトは販売用です! - hansode リソースおよび情報

    このウェブサイトは販売用です! hansode.org は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、hansode.orgが全てとなります。あなたがお探しの内容が見つかることを願っています!

  • ALTER TABLEを上手に使いこなそう。

    テーブル定義を変更したい。インデックスが壊れてしまったので再作成したい。そんな場合はALTER TABLEを使う。ALTER TABLEはテーブル定義を変更するお馴染みのコマンドであるが、その挙動は意外と知られていない。(エキスパートとおぼしき方々からも度々質問を受ける。)そんなわけで、今日はALTER TABLEについて解説しようと思う。 まず結論から言うと、なんとMySQLのALTER TABLEはテーブルのデータを全てコピーし直すのである。なんて無駄なことを!?と思うかも知れないが、テーブル定義(スキーマ)の変更を動的に行うには、ストレージエンジンによるサポートが必要であり、動的なスキーマ変更をサポートしているストレージエンジンはまだ少ないのである。(動的スキーマ変更をサポートしているのはMySQL Clusterぐらいだ。しかも追加だけ。)デフォルトで利用出来るMyISAMはInn

    ALTER TABLEを上手に使いこなそう。
  • Bug #314570 - Comment #4

    nipotan
    nipotan 2009/04/17
    うお、再現した。。
  • Yahoo!オークションでのMySQL 冗長化技術

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちはオークション事業部プラットホーム技術のチャックです。 オークションでは一部サービスに RDBMSMySQL を使ってサービスをご提供させていただいております。 オークションでは多くのお客様よりアクセスを頂いておりますので、大量の更新、参照の処理速度に優れた MySQL を選択し、お客様にストレスなくサービスをご利用いただけるよう 日々業務に取り組まさせていただいております。 しかし、精密機器には故障がつきもので、サービス運用の観点からは 「機器が故障するのはしかたない、しかしそれをいかに早く復旧させるか」 といったことを念頭に入れております。 実際には、障害が起こってから復旧させるのではなく、障害が発生した場合に

    Yahoo!オークションでのMySQL 冗長化技術
  • なぜMySQLのサブクエリは遅いのか。

    よくMySQLはサブクエリが弱いと言われるが、これは当だろうか?半分は当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし

    なぜMySQLのサブクエリは遅いのか。
  • Re URLを扱うテーブルを作るときにどうすべきか - kazuhoのメモ置き場

    数日前、 pathtraqの事例を詳しく知りたい URLを扱うテーブルを作るときにどうすべきか - 金利0無利息キャッシング – キャッシングできます - subtech に対し、 pathtraq は前方一致検索が必要だから算術系圧縮して varbinary(767) だけど、順序の維持が不要ならハッシュのが速いはず はてなブックマーク - kazuhookuのブックマーク / 2009年3月11日 と書いた件について。 ハッシュ値を使えるべきケースでは使うべきってのは、まあ間違いではないけれども、常にそうかというと微妙だなと思わないわけでもないわけであり。mala さんに対しては今更言うまでもないような気がするけど、なんか自分の頭の中がもやもやしてるので、まとめてみる。 気になる点としては、まず、disk I/O の回数。RSS リーダーのようなケースでは、「あるフィードの、特定時点以

    Re URLを扱うテーブルを作るときにどうすべきか - kazuhoのメモ置き場
  • MySQLのマーチン・ミコス氏がSunを退社へ

    米Sun Microsystemsに買収されるまでスウェーデンMySQL社でCEOを務め、買収後はSunでデータベースグループ担当シニアバイスプレジデントを務めるマーチン・ミコス(Mårten Mickos)氏が、Sunを離れることが、6日(現地時間)明らかになった。 米Sun Microsystemsに買収されるまでスウェーデンMySQL社でCEOを務め、買収後はSunでデータベースグループ担当シニアバイスプレジデントを務めるマーチン・ミコス(Mårten Mickos)氏が、Sunを離れることが、6日(現地時間)明らかになった。複数の米メディアが報じているほか、MySQL社コミュニティ担当バイスプレジデントのカジ・アーノ(Kaj Arnö)氏も自身のブログで明らかにしている。 Sunの組織再編により、ミコス氏が担当していたグループは「MySQLおよびソフトウェアインフラストラクチャ」グ

    MySQLのマーチン・ミコス氏がSunを退社へ
  • うごメモはてな

    うごメモはてな サービス終了のお知らせ 「うごメモシアター」と「うごメモはてな」は、2013年5月31日24:00をもちまして、サービスを終了させていただきました。 2008年12月から今まで生まれた素晴らしい作品は、どれも皆様の心に深く残っていることと思います。ご利用いただいた全てのユーザー様に心よりお礼申し上げます。 「うごメモシアター」と「うごメモはてな」をご利用いただき、ありがとうございました。 株式会社はてな Flipnote Hatena has ended its service The Flipnote Hatena website and Flipnote Hatena for Nintendo DSi ended on May 31, 2013. We would like express our sincere gratitude to the members of

    nipotan
    nipotan 2009/01/30
    「正規化が何かって」「何を」「正規化」「ええ」「知らない?」「だから何を言ったの」「正規化って知らないかって」「知ってます」「知ってますね?正規…」「当たり前でしょそんなこと!!!!!」
  • MyISAM と InnoDB の SELECT パフォーマンスの話 - kazuhoのメモ置き場

    InnoDB は MVCC で遅そうだから読み込み主体の場合は MyISAM とか言うけど、そういう発想の人はそもそも MVCC 不要=複雑なクエリを書かない人なわけで、で、永続的なハッシュとしてしか MySQL を使わないようなケースでは、どのみちプロセス間通信がボトルネックになるので InnoDB でも MyISAM でもパフォーマンスは変わらないんじゃないかと思った。 以下は、250 万件のテーブルからランダムにプライマリキーを指定して読み込んだ場合のパフォーマンス (10万回)。 クエリ MyISAM InnoDB WHERE id=x 10.4秒 10.7秒 WHERE id>x LIMIT 10 19.8秒 18.1秒 環境は MySQL 5.1.28-rc。チューニングとしては、key_buffer_size, myisam_use_mmap, innodb_buffer_p

    MyISAM と InnoDB の SELECT パフォーマンスの話 - kazuhoのメモ置き場
  • InnoDB におけるカラムの格納 - kazuhoのメモ置き場

    カラムサイズが768バイトを超えると16KB単位になるってのは重要。 Question: How much space InnoDB allocates for each blob outside of the page? HT: For each column that InnoDB needs to store ‘externally’, it allocates whole 16 kB pages. That will cause a lot of waste of space if the fields are less that 16 kB. The ‘zip’ source code tree by Marko has removed most of the 768 byte local storage in the record. In that source code tr

    InnoDB におけるカラムの格納 - kazuhoのメモ置き場
  • MySQL (Tritonn) の動作について - kazuhoのメモ置き場

    最新tritonnで SELECT MATCH(col1, col2, col3) AGAINST('W.... query' IN BOOLEAN MODE) AS score Where MATCH(col1, col2, col3) AGAINST('W.... query' IN BOOLEAN MODE) ORDER BY score DESC; が異常に遅いのはなんでなんでしょう。 http://mt.endeworks.jp/d-6/2007/12/tritonn.html MySQL のオプティマイザは MATCH(...) 内に指定された各カラムのデータが MySQL コア内での演算に必要だと判断し、Tritonn のストレージエンジンに対して、行データの読み込みを要求します。つまり、上のクエリでは、条件に合致する全行について、行データの読み込みが発生します。そして、読み

    MySQL (Tritonn) の動作について - kazuhoのメモ置き場