タグ

mysqlに関するrindenlabのブックマーク (71)

  • mixiの生みの親“バタラ氏”が語るMySQLの意外な利用法 - TechTargetジャパン

    日記だけで4億件のデータ ミクシィが運営するSNS「mixi」は、2007年7月末段階でユーザー数が1110万人。人が12人集まれば、1人はmixiユーザーというわけだ。ユーザーのアクティブ率(ログイン間隔が3日以内)は約62%と高く、2007年4月から6月の月間平均ページビューは117.5億に達した。日記だけでも4億件以上に上るなど、蓄積するデータ量も莫大。2004年3月のサービス開始から、わずか3年半で現在の巨大コミュニティーへと発展したのだ。 ミクシィは、「LAMP(OSのLinux、WebサーバのApache、DBMSのMySQL、開発言語のPerlPHPPython)」と呼ばれるWebシステム向けの標準的なオープンソースソフトウェア(以下、OSS)でシステムを自社開発し、安価なPCサーバを1000台以上連ねる超分散構成でmixiのサービスを支えている(広告配信など周辺機能では

    mixiの生みの親“バタラ氏”が語るMySQLの意外な利用法 - TechTargetジャパン
  • やってはいけない!!MySQLに悲鳴をあげさせる10の方法

    いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ?固まったか?」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。

    やってはいけない!!MySQLに悲鳴をあげさせる10の方法
  • MySQLによるデータウェアハウス構築

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、オークション事業部のWangです。 データウェアハウス(以下DWH)という言葉になじみのない方は検索していただいたほうがよいかもしれません。 検索するのがめんどい、という方は、かみ砕いた表現ができなくて恐縮ですが、 基幹系システムから抽出したデータを目的をもって再構成し、 使用可能な状態に保管されたデータの集合体、とお考えください。 オークションでは、具体的には出品、入札、落札などのトランザクションデータや、 それをいろいろな単位で集計したデータなどが該当します。 ここでいう単位というのはたとえば、日ごと、週ごと、月ごとや、以前の記事でも紹介されている カテゴリといったものになります。 こういったデータは、運用、運営、

    MySQLによるデータウェアハウス構築
  • MyISAMからInnoDBへ切り替えるときの注意点

    MySQLを使い始めて間もない人がよく陥る罠の中に、気づくと使ってるストレージエンジンがMyISAMだった!ということがある。デフォルトのストレージエンジンはMyISAMなので、MySQLに詳しくない人たちが比較的陥りやすい罠なのだ。そもそもストレージエンジンという概念自体がMySQL独自のものなので仕方のない話である。MyISAMは素晴らしいストレージエンジン(たとえばこのYahoo!の中の人による投稿で言われているように)であるが、長所もあれば短所もある。例えば、 トランザクション対応ではない。 クラッシュセーフではない。 更新と参照が入り乱れた場合の同時実行性能がよくない。 テーブルが大きく(数億行とか)なるとINSERTの性能が劣化する。 などなど。特に前者の2つが問題で、アトミックな操作が必要なところでロジックを実装出来なかったり、サーバがクラッシュした時にデータがお亡くなりにな

    MyISAMからInnoDBへ切り替えるときの注意点
  • MySQL、新ストレージエンジンMaria投入 - InnoDBは? | エンタープライズ | マイコミジャーナル

    CTO at MySQL, Founder and original developer of MySQL, Michael Widenius氏は27日(米国時間)、自身のブログにおいてMySQLの新しいデータベースエンジンMariaを公表した。MariaはGuilhem氏、Sanja氏、Sergei氏、Widenius氏によって2年間にわたって取り組まれた新しいストレージエンジン。ただしフルタイムで開発が実施されたのは直前の4ヵ月間だとされている。 今回公表されたMaria 1.0系はbitkeeper経由で公開されている。バイナリでの配布は時期をみて実施されるようだ。1.0はクオリティ向上を主目的としたブランチで、開発者にはMaria 1.0を試してバグを報告してほしいと報告されている。 MySQLは複数のデータベースエンジンを使える。今回公開されたMariaはストレージエンジンとして

  • [ThinkIT] 第4回:CSVとBlackhole (3/3)

    テーブルを作成する際、CREATE TABLE文のENGINE句に"BLACKHOLE"を指定することにより、Blackholeテーブルを作成することができます。Blackholeテーブルを作成すると、そのデータベースのディレクトリ内に、どのようなカラム構成にてできているかなどのテーブル構造のデータが格納された「テーブル名.frm」のみが作成されます。 次に示すは、「Blackhole_TEST」データベース内に「TEST00」という名前のBlackholeテーブルを作成した時のファイル一覧です。「Blackhole_TEST」ディレクトリ内に「TEST00.frm」ファイルのみが存在していることがわかると思います。

  • [ThinkIT] 第2回:MyISAMとInnoDB (1/3)

    今回は、MySQLのストレージエンジンの中でも特に有名な「MyISAM」と「InnoDB」の2つを取り上げます。MyISAMはMySQLのデフォルトストレージエンジンで、ストレージエンジンを指定せずにテーブルを作成するとMyISAMが選択されます。もう一方のInnoDBエンジンは、MySQLに豊富なトランザクション機能を提供するストレージエンジンとして有名です。 まずはそれぞれのテーブルファイルの構造について解説し、最後にInnoDBのトランザクションについて解説します。 各ストレージエンジンのファイル構造を説明する前に、前知識としてMySQLのディレクトリ構造について説明します。 MySQLのデータベースディレクトリには、バイナリログと呼ぶデータベースの更新情報を格納するファイルと、2つのサブディレクトリが存在します(図1)。 「mysql」ディレクトリには権限テーブルと呼ばれるMySQ

  • [ThinkIT] 第1回:MySQLストレージエンジンの概要 (1/3)

    連載で取り上げるMySQLは、非常に人気の高いオープンソースのRDBMSです。このMySQLの大きな特長は、ストレージエンジンを選択できるところにあります。そこで連載では、MySQLのストレージエンジンに焦点をあて、様々なストレージエンジンの特長や構造を解説していきます。最後まで、お付き合いください。 MySQLの概要についてはご存知の方も多いと思いますが、復習の意味も込めて簡単に紹介します。 MySQLは、MySQL社を中心として開発が進められているRDBMSで、オープンソースの標準的なプラットフォームを意味する「LAMP」という言葉(Linux/Apache/MySQLPHP)に採用されるほど有名なオープンソースです。ライセンスとしては、GPLと商用ライセンスのデュアルライセンス形態で提供されています。バージョン5.0よりストアードプロシージャやトリガなどをサポートし、他のRDB

  • なぜMySQLのサブクエリは遅いのか。

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

    なぜMySQLのサブクエリは遅いのか。
  • シンプルなPHPとMySQLの最適化方法「当たり前を積み重ねると特別になる」

    前回の負荷MAX、サーバ陥落寸前ですよ騒動のとき、最終的には自分で最適化する必要があるのかも知れない…と思っていたときに見つけたページです。 MySQLPHPで同じ処理をする際にどういうふうにすればより軽いのか、という基的な対策ばかりを集めてあります。どれもこれもあちこちで既出のものばかりですが、1カ所にまとまっているので読みやすいです。中には知らないのもあったりするかもしれません。 dublish.com - Simple Optimization for PHP and MySQL http://www.dublish.com/articles/10.html MySQLで書かれている方は割と読んだことがあるようなのが多かったですが、PHPの方は言われてみればそうかも、というようなのが多い。上記ページのコメント欄にもいろいろと有用な意見があるので、読み進めると楽しい。 そういえば以

    シンプルなPHPとMySQLの最適化方法「当たり前を積み重ねると特別になる」
  • GIGAZINE最大の挑戦、LoadAverage「86」から「3」へ

    というわけで、再び負荷を下げる方法を模索した、戦いの記録。 1.MySQLの設定を変更して高速化 2.Zend Optimizer 3の導入 3.ionCube PHP Acceleratorの導入 4.テンプレートの見直しでクエリーを減らす 5.robots.txtでクロールする間隔を制御する 6.MySQLの設定を負荷を低くする設定に変更 7.キャッシュを有効化する 前回解説した「GIGAZINEのLoadAverageを「27」から「2」へ下げた方法」から約3週間後、6月20日(火)の夜、気がつくと負荷の15分平均は「25」をコンスタントに吐き出すようになり、さらに訪問者は急増、ついに6月28日(水)12時45分、負荷対策の効果がほとんど出ないまま、LoadAverage15分平均は「86」に…。 何か対策が根的に間違っているのだろうか?それとも、もうGIGAZINEサーバのハード

    GIGAZINE最大の挑戦、LoadAverage「86」から「3」へ