タグ

mysqlに関するkakkunpakkunのブックマーク (32)

  • 分割と整合性と戦う

    え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理NTT DATA Technology & Innovation

    分割と整合性と戦う
  • datetime型のカラムから日付データを引っ張ってくる際の高速化 - 適当な日々

    フリーランスでwebの仕事をしながらwebサービスとかを作ったり作らなかったり、成長と挫折の記録・・・かもしれないちょっとMySQLのチューニングをしたらすごく早くなったので、メモメモ。 datetime型のカラムから日付のみをwhere訳にデータを引っ張ってくることはよくあります。 で、レコードが数万行になってくるとけっこう遅くなったりする。 そしてカラムにインデックスを張っても全然速度があがらなかったりします。 これはクエリーがインデックスを使用していないからなんですね。 苦しまぎれにdate型のカラムを作って日付だけを入れるという手法もありますが、ちょっとスマートじゃないです。 datetime型を維持したままで高速化できます。 例えばこういうクエリー [sql ruler="true" lang_name="true"] select * from item wher

  • パーティショニングの使用例 - http session情報

    今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする(たぶん昨日の例よりも)もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDBMySQL Cluster)ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン

    パーティショニングの使用例 - http session情報
  • MySQLのパーティショニングのハマリ所 - sakaikの日々雑感~(T)編

    今までマニュアルを斜め読みした程度で「MySQL 5.1 から使えるようになったパーティショニング。便利そうだな」などと思っていたのですが、このたび実際に使いたいシーンが出てきたので、利用を前提に調べてみました。 そしたら、ハマることハマること。やりたいことは、日付カラムで1日ごとのパーティションにしたいだけだったのですが(向こう2年分くらいパーティション作っておいて、運用で「古いパーティション削除→新しいのを追加」でいいかなと考えていました)、これができない。 ハマりの原因は「パーティショニングの条件は、プライマリーキーの一部でなければならない」という制約。 http://dev.mysql.com/doc/refman/5.1/ja/partitioning-limitations.html 今回使用を検討したテーブルはプライマリーキーが重要だったので、 CREATE TABLE pt

    MySQLのパーティショニングのハマリ所 - sakaikの日々雑感~(T)編
  • MySQLのEXPLAINを徹底解説!!

    以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約?を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか?そのためにはまず現在どのようにクエリが実行さ

    MySQLのEXPLAINを徹底解説!!
  • サーバ監視に超使える〜topコマンドのまとめ:phpspot開発日誌

    サーバ監視に超使える〜topコマンドのまとめ サーバを運用しているとよく使うtopコマンドですが、標準のtop以外にも色々便利なものがあるのでまとめてみました。 ボトルネックといえば、ネットワーク、ディスクIO、スワップ、CPU、メモリといったものが関連しますが、ツールで視覚化することでより分かりやすい対策がとれますね。 htop こちらも、通常のtopよりもさらに多数の情報を表示してくれるツール。 CPUやメモリの状態が視覚的にグラフで表示されていたり、複数CPUがある場合もそれぞれに利用率を表示してくれてわかりやすいです。 pstreeで表示するようなツリー+topコマンドのような表示も t を押せば切り替えられます。 公式サイト上にある128コア積んだマシンのhtop結果が面白い。 次のようにすべてグラフで表示されているため、128コアあったとしても瞬時に負荷が把握できますね。 io

  • @IT Special PR:600億PVもMySQLで! モバゲーのインフラ底力

    携帯向けサイト「モバゲータウン」の勢いが止まらない。2010年3月の会員数は約1800万人、月間ページビュー(PV)600億という"モンスターSNS"に成長している。意外なことに、これだけのアクセスをさばくのに、memcachedをはじめとするKVS(Key-Value Store)系のインフラ・ソフトはあまり使っておらず、MySQLで十分だという。モバゲータウンのインフラ担当者に話を聞いた。 モバゲータウンを運営するDeNA(ディー・エヌ・エー)は、もともと1999年に開始したオークションサイト「ビッダーズ」で知られている。その後、オークションに加えてECサイトを開始し、auとの提携により「auショッピングモール」などで急速に成長した。 ビッダーズだけでも、数千万PV規模の大規模サービスだが、最近はモバゲータウンの成長が著しい。 「特に2009年9月から順次リリースした自社製のソーシャル

  • ソーシャルゲームのためのMySQL入門 | BLOG - DeNA Engineering

    こんにちはこんにちは。最近お腹痛いばっかり言ってることで有名なiwanagaです。 DeNAは外部的にはプラットフォーム的な部分の方がフィーチャーされることが多いですが、実はソーシャルゲームの提供も行っています。怪盗ロワイヤルとか、どこかで聞いたことがあるのではないでしょうか。 僕はDeNAでソーシャルゲームが誕生した辺りからずっとサーバサイドを見てきましたが、そんな運用の中で自分が貯めてきた知見とかTIPSをご紹介したいと思います。 かれこれ10タイトル近くはレビューしたり運用したりしてるため結構言いたいことはいっぱいあるので、小出しにしつつ評判よければ次も書きます。 ソーシャルゲームのためのMySQL入門一覧 ソーシャルゲームのためのMySQL入門 - Technology of DeNA ソーシャルゲームのためのMySQL入門2 - Technology of DeNA 「MySQL

    ソーシャルゲームのためのMySQL入門 | BLOG - DeNA Engineering
  • 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万クエリ/秒を実現
  • login

    ナップザックは、システム開発/ソフトウェア開発の設計・開発事務所です。 株式会社ナップザック © 2013-2018 NAPZAK Inc.

  • レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ

    MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台+1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う!」「ここがおかしい!」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基構成、方針 2台+1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ

    レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ
  • countよりもcount_by_sqlの方がいいかも - おもしろwebサービス開発日記

    前書いた書きかけのメモを発見したので加筆して載せてみます。ちなみにこの話はMysql(InnoDB)利用時限定です。 モデルのcountメソッドは SELECT count(*) AS count_all FROM `blogs` のようなSQL文を発行します。このようなSQL文では、基的に主キーインデックスによる全索引検索が行われます。通常、インデックスだけを読み込む全索引検索のほうが、テーブルだけを読み込む全表検索よりもI/O回数が少なくなるため高速になりますが、InnoDBの主キーインデックスは他の列値と直結している仕様で(この場合は)余計な列値を読み込むことになるため、あまり高速になりません。主キー以外のインデックスを利用した方が高速になるようです。 実際に試してみた rails2.3.2(たぶん), mysql5.0.77で試しました。 適当なrailsプロジェクトを作成し、s

    countよりもcount_by_sqlの方がいいかも - おもしろwebサービス開発日記
  • MySQLレプリケーションを安全に利用するための10のテクニック

    MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA(高可用性) ディザスタリカバリ(サイト間レプリケーション) BI(レポーティングetc) という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション

    MySQLレプリケーションを安全に利用するための10のテクニック
  • [MySQLウォッチ]第43回 MySQL5.1リリース,改善されたレプリケーション

    ついに,MySQL 5.1.30 GA(GeneralAvailability)がリリースされた。MySQL5.0から3年の歳月をかけて,多くの新機能を搭載した意欲的なバージョンとなっている。 しかし,現時点では,多く(約180)のバグが残されている。そのため,番システムに適用するには細心の注意が必要だ。米Sun Microsystemsでは,十分なテストを実施した上での番システムへの適用を呼び掛けている。 MySQL 5.1はパーティショニング,イベントなど多くの新機能を搭載しているが,注目したい点は,レプリケーション機能の強化だ。今回は,MySQL5.1で信頼性の高い機能に成長したレプリケーション機能を紹介する。 MySQL 5.0までのレプリケーションと問題点 MySQLには,手軽なレプリケーション機能が搭載されている。構築が容易でレスポンスが高いことが特徴だ。これにより,データ

    [MySQLウォッチ]第43回 MySQL5.1リリース,改善されたレプリケーション
  • 漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法

    ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基中の基であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_

    漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
  • Kazuho@Cybozu Labs: フレンド・タイムライン処理の原理と実践

    « MySQL のクエリ最適化における、もうひとつの検証方法 | メイン | MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話 » 2008年06月09日 フレンド・タイムライン処理の原理と実践 MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話に続きます。 Twitter が注目されるようになって久しい今日この頃ですが、友人の投稿を時系列に並べて表示する、というのは、Twitter に限らず Mixi の「マイミクシィ最新日記」やはてなブックマークの「お気に入り」等、ソーシャルなウェブサービスにおいては一般的な手法です。ですが、この処理 (以下「フレンド・タイムライン」と呼ぶ) は、一見簡単そうに見えて、実装には様々な困難が伴います。記事では、「フレンド・タイムライン」を実現する、プッシュ型とプル型の二種類の手法について、その原

  • パーティショニングを使うためのmysql5.1インストール - d2mrの日記

    ソースからインストールする場合は以下のような感じでオプションに --with-partition ってしておく。 バイナリをインストールする場合には気にしなくてもOK。 # ./configure --prefix=/usr/local/mysql --with-charset=utf8 \ --with-extra-charsets=all --with-mysqld-user=mysql --with-innodb --with-partition

    パーティショニングを使うためのmysql5.1インストール - d2mrの日記
  • MacPortsを使ってMacにMySQLをインストール - 拡張現実ライフ

    来年も作りたい!ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…

    MacPortsを使ってMacにMySQLをインストール - 拡張現実ライフ
  • acts_as_tritonn - R日記

    前回MySQL+Sennaを簡単に扱えるプラグインを作って公開するとか言っておきながら忙しくて放置してました^^; このまま放置しようかと一瞬思ったのですが、はてなスターも付いてることだし、折角なので公開します なお、全文検索クエリを簡単に使うことを目的としているため、細かくSenna演算子をつかったり、適合率でソートはできません^^; インストール ※githubに引っ越しました script/plugin install http://ryu.rubyforge.org/svn/acts_as_tritonn git clone git://github.com/ryu00026/acts_as_tritonn.git 使い方ですが、 class Post < ActiveRecord::Base acts_as_tritonn end 普通の検索 Model.find_fulltex

    acts_as_tritonn - R日記
  • テーブルの構造を調べる方法あれこれ - Affamative Way

    ちょっと色々と調べていたのでメモ変わりにエントリー テーブルの構造を取得する MySQL AB :: MySQL 5.1 リファレンスマニュアル :: 12.3.1 DESCRIBE 構文 mysql> DESC user; +-----------------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-----------------+-------------+------+-----+---------+----------------+ | id | int(4) | NO | PRI | NULL | auto_increment | | nick_name | varchar(30) | NO | | | | |

    テーブルの構造を調べる方法あれこれ - Affamative Way