OSC 2012 Hokkaidoの発表で使用したスライド資料「大規模ソーシャルゲームを支える技術～PHP+MySQLを使った高負荷対策～」｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
OSC 2012 Hokkaidoの発表で使用したスライド資料「大規模ソーシャルゲームを支える技術～PHP+MySQLを使った高負荷対策～」 先日の2012年6月16日(土)に、札幌市で「オープンソースカンファレンス 2012 Hokkaido」が開催されました。 弊社は今年も協賛企業として参加させていただいておりまして、今年もセミナー発表1コマと、午後の企画セッションに参加させていただきました。 弊社が作ったソーシャルゲームの裏側がどうなっているのかという点や、作る上で気をつけているところ、身につけたノウハウなどをまとめた資料です。 資料はslideshare上で公開しておりますし、Ustream上から発表の録画も見ることができます。 よろしければどうぞご覧ください。 スライド資料:
MySQLで特定日（月初・月末）を求めるクエリ | お名前.com、さくらのVPS等のサーバーでの開発・設定メモ
・基本 ●先月の末日 DATE( DATE_SUB(NOW(), INTERVAL DAYOFMONTH(NOW()) DAY) ) 現在 – 今月の今までの日数 = 先月末日の現時刻 で、DATEで日付に丸める。 ●今月の初日 DATE( DATE_SUB(NOW(), INTERVAL DAYOFMONTH(NOW())-1 DAY) ) 現在 – (今月の今までの日数-1) = 今月初日の現時刻 で、DATEで日付に丸める。 ●今月の末日 LAST_DAY(NOW()) ●Nヶ月前の初日 DATE( DATE_SUB( DATE_SUB(NOW(), INTERVAL DAYOFMONTH(NOW()) -1 DAY), INTERVAL N MONTH)) ●Nヶ月前の末日 LAST_DAY( DATE( DATE_SUB( DATE_SUB(NOW(), INTERVAL DAY
MySQL InnoDBストレージエンジンのチューニング（前編）
本連載では、３回にわたってチューニングの要であるオプティマイザについて説明してきた。オプティマイザは論理的な表現であるクエリを物理的にどう処理するかということを決めるRDBMSの心臓部であると言える。しかしながら、人体が心臓だけで機能しないのと同じように、RDBMSもオプティマイザだけで成り立つわけではない。実際に手足となりデータを操作するのはストレージエンジンだ。今回は、MySQLの代表的な（実質的にはデファクトスタンダードの）ストレージエンジンであるInnoDBの基本的なチューニングについて解説しようと思う。クエリのチューニングとは全くストラテジーが異なるので、これまで連載を読んで頂いている方は、ここで頭を切り替えて欲しい。 InnoDBを使おう！ もし本稿を読まれている方で、特に明確な意味もなくまだMyISAMストレージエンジンを使ってらっしゃるという方には、全力でInnoDBをオス
mysqlのストアドプロシージャの便利さをアピールしてみる - (ﾟ∀ﾟ)o彡 sasata299's blog
2009年02月10日01:50 MySQL mysqlのストアドプロシージャの便利さをアピールしてみる 今日はストアドプロシージャの話でも(*･ω･)ノ ■ストアドプロシージャとは？ 一連のSQL文や処理を名前をつけてサーバ側に保存し、関数呼び出しのように使用できるもの。 ■ストアドプロシージャを使うメリットは？ ・アプリ側の言語を選ばない。（MySQLで実装されていて、呼ぶだけなので） ・アプリサーバの負荷が減る。（複雑な処理はMySQL側で実行されているため） ・・といったところでしょうか。 少し前に書いたトリガーもそうですが、便利！・・ですけどメンテナンスがしにくいとか良くないところもあると思うので、メリット、デメリットを考えて、上手に使っていきたいですね。 あ、よく似たのに、ストアドファンクションってのもあります。 どっちも大体同じ。返り値の有無と、呼び出し方の違いくらいです。
MySQL: 文字列の結合に||（パイプ）を利用できるようにする方法 | QK
MySQLで文字列結合を利用する場合、concat関数しか使えないと思っておりましたが、他者DBMSのように、パイプ(||）で表現することが可能なことを発見してしまいました。 知らなかった・・。 IBM DB2などで文字列結合するようなSQLを発行する場合、基本的には文字列の結合は、|| （パイプ）を利用します。 たとえばこんな感じで書くと思います。 db2 => SELECT 'TABLE NAME' || ' is ' || TABNAME from syscat.tables fetch first 10 rows only 1 ------------------------------------------------------------------------------------ TABLE NAME is ATTRIBUTES TABLE NAME is BUFFE
MySQL Spiderエンジンを使ってみた。〜データベースシャーディング(sharding)とは〜 - 気ままに書いてみました日記
もしかしたら使うかもしれないので調べてみた。 shard 日本語に訳すと(ガラスや貝殻の) 「破片」といったような意味 データベースをshardに分解して複数のサーバに分散して運用するのがDB sharding データベースパーティショニングとも言えるのかしら？ 単一のサーバのDBテーブルを複数のファイルに分割するのをパーティショニングとも呼ぶが、「パーティショニング」という言葉を使ってDB shardingのことを言っているブログ等もちらほら見かけます。 より突っ込んでみたい人は「shared nothing」でぐぐってネ。 なぜデータベースを分散処理するのか 横軸にはサービス運用開始からの時間経過を設定し、縦軸には「DBの応答時間」、「DBへの問い合わせ数」、「DBサイズ」の各数量をとります。サービスが順調に利用されていっているものとし、「DBサイズ」や「DBへの問い合わせ数」は時間経
cloudpackブログ - EC2でMySQL(運用編 VP＋Spiderで無停止負荷分散)
前回はEC2でMySQL(運用編 VPで無停止ALTER)を紹介しましたが、同じ様に通常のInnoDBテーブルをSpiderシャーディングに無停止で移行することも可能です。 そこで今回は、この方法を紹介します。 初期テーブルは以下のとおりです。 mysql> create table gift( id int auto_increment, name varchar(255), description text, created_at datetime not null, primary key(id) )engine=InnoDB; Query OK, 0 rows affected (0.02 sec) 上記をSpider化していきますが、今回は定期的にデータを投入しながらSpider化を行ってみます。 まず、以下のようなシェルを実行し、常にデータの投入がされている状態を作ります。 $
cloudpackブログ - EC2でMySQL(Spider編1 Spiderってなんじゃ？)
今回はEC2上での、MySQLとSpiderについての記事になります。 MySQLでの負荷分散となるとレプリケーションが主でしたが、参照系の負荷は分散できても更新処理は分散することが難しく、それがボトルネックになっていましたが、このSpiderを利用すると、更新も参照も負荷分散することができます。 Spiderは斯波健徳さんが開発したMySQLのストレージエンジンで、MySQLでのシャーディングという、データを分散して保存することで負荷を分散する処理を行うことができます。 尚、Spiderには以下の機能と特徴があります。 異なるMySQLインスタンスのテーブルを同一インスタンスのテーブルのように扱うことが可能になります。 XAトランザクションを含むトランザクションをサポートしているため、更新系DBのクラスタリングに 利用することが可能です。 テーブルパーティショニングをサポートしているため
BirdLab | php研究所
名前 : コメント (2023-05-04 22:41:02) 名前 : コメント (2023-05-04 22:41:01) 名前 : コメント (2023-05-04 22:41:01) 名前 : コメント (2023-05-04 22:41:00) 名前 : コメント (2023-05-04 22:40:59) 名前 : コメント (2023-05-04 22:40:58) 名前 : コメント (2023-05-04 22:40:57) 名前 : コメント (2023-05-04 22:40:56) 名前 : コメント (2023-05-04 22:40:56) 名前 : コメント (2023-05-04 22:40:55) 名前 : コメント (2023-05-04 22:40:54) 名前 : コメント (2023-05-04 22:40:53) 名前 : コメント (2023-
MySQL SELECT文
MySQLのSELECT文で使用できる構文について説明します。 なお、基本程度の構文については説明していません(DISTINCTなど)。 table references FROM句で指定するテーブル名に、いくつかのオプションを付ける事が出来ます。 AS テーブルに別名を付けます。なお、ASは省略できます。 SELECT T1.name FROM table_a T1; USE INDEX Select時に使用するインデックスを指定します。 SELECT * FROM table_a USE INDEX (use_index_name); IGNORE INDEX Select時に使用しないインデックスを指定します。 SELECT * FROM table_a IGNORE INDEX (ignore_index_name); FORCE INDEX USE INDEX と似たような動作を
MySQL 日付別パーティショニングの運用 - 130単位
MySQL :: MySQL 5.1 リファレンスマニュアル :: 15 パーティショニング http://dev.mysql.com/doc/refman/5.1/ja/partitioning.html 実験的にやってみただけでノウハウとして固まってはいないのですが、現状の知識をまとめてみたいと思います。 前提 MySQL 5.1以降 検証した環境は5.1.47 日付ごとにパーティショニング カラムは一意な"id"と作成日付の"created"があるとする 準備 idとcreatedを複合でプライマリキーにする パーティショニングの条件はプライマリキーに含める必要がある idがAUTO_INCREMENTであればPRIMARY KEY (id, created)の順のみ createdをTO_DAYS()してパーティショニングする 大枠と個別のパーティションの両方でTO_DAYS()す
MySQLのパーティショニングのハマリ所 - sakaikの日々雑感～(T)編
今までマニュアルを斜め読みした程度で「MySQL 5.1 から使えるようになったパーティショニング。便利そうだな」などと思っていたのですが、このたび実際に使いたいシーンが出てきたので、利用を前提に調べてみました。 そしたら、ハマることハマること。やりたいことは、日付カラムで１日ごとのパーティションにしたいだけだったのですが（向こう２年分くらいパーティション作っておいて、運用で「古いパーティション削除→新しいのを追加」でいいかなと考えていました）、これができない。 ハマりの原因は「パーティショニングの条件は、プライマリーキーの一部でなければならない」という制約。 http://dev.mysql.com/doc/refman/5.1/ja/partitioning-limitations.html 今回使用を検討したテーブルはプライマリーキーが重要だったので、 CREATE TABLE pt
おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました
まずは、ライブドアの皆様、素晴らしいイベントの提供本当にありがとうございました。めちゃくちゃ楽しかったです。 Kayacのエンジニア3人 @fujiwara @sugyan @songmu の3人でチームfujiwara組を結成し、結果優勝することができました。 実際は周りの認識通り、@fujiwaraさんに優勝させてもらったようなもので、@sugyanと僕は手を動かしていただけです。まあ、空気にならずには済んだので、そこは安堵しています。 修正したisuconソースはフォークしてGithubに置きました。プログラムの修正部分のみで、my.cnfの修正なんかはここには反映されていません。 さて、@fujiwaraのコンテストでの動きや、帰宅後のBlogアップまであらゆる仕事が速くてビビるんですけど、詳しくは、#isucon で優勝してきましたを見てもらうとして、 どういうドタバタがあったの
ウノウラボ Unoh Labs: Q4Mを触ってみる
yukiです。そろそろクリスマスですね。みんな浮かれていればいいと思います！最近急に目が悪くなって、ツリーの赤色電球と居酒屋の赤提灯の色が判別出来なくなってきました。嘘です。 今回は、みんな大好きメッセージキュー、Q4Mを触ってみた感想を今更ながらレポートします。 公式ページはこちらhttp://q4m.31tools.com/ Q4Mはサイボウズラボの奥 一穂氏が開発されており、MySQLの5.1以上でストレージエンジンとして利用できるメッセージキューで、MySQLプラグインとしてGPLライセンスで配布されております。 特長 MySQLのストレージエンジンとして利用できるので、テーブル作成時にストレージエンジンを指定するだけで利用できます。 CREATE TABLE hoge ( ... ) ENGINE = QUEUE キューの作成(enqueue)は通常のレコード操作と同様にINSE
ricollab Web Tech Blog » Blog Archive » MySQLパーティショニングについて（その1：基本知識編）
初めまして、リコーの濱田です。このたび私も本ブログを担当することになりました。今後ともよろしくお願いいたします。 本エントリではデータベースに関する技術トピックとして、MySQL 5.1 から導入された機能であるパーティショニングについて書こうと思います。少し長くなりそうなので、「基本知識編」「性能検証編」の2回に分けて書くことにします。 今回は「基本知識編」として、パーティショニングの概要と基本的な使い方について紹介します。 パーティショニングの概要 パーティショニングとは、事前に設定されたルールに従ってデータをパーティションと呼ばれる部分的なテーブルに分割する仕組みです。 データ挿入時には、設定ルールに従ってデータが該当するパーティションに自動的に振り分けられます。データ参照時には、オプティマイザがクエリから必要なパーティションを判断し、該当するパーティションのみにアクセスします。これ
MySQLのRANGEパーティションを使う | 村式流 イッパシエンジニアへの道
MySQLのRANGEパーティションのお話です。 MySQL5.1からサポートされているパーティショニングですが、ログテーブル等、レコード数が多くなりがちなテーブルに日付でパーティショニングしてます。 最初から遠い未来までのパーティションを切るのは気持ち悪いし、長く運用されるサービスの場合は忘れる可能性もあるのでバッチを回すのがいいと思いますが追加する場合の手順と注意点です。 ・まずはパーティションを作成 CREATE TABLE `mura`.`test1` ( `date` DATE NOT NULL , `name` VARCHAR( 40 ) NOT NULL , `contents` VARCHAR( 255 ) NOT NULL , `created_at` DATETIME NOT NULL ) ENGINE = InnoDB PARTITION BY RANGE (TO_
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.s-quad.com/wordpress/?p=696
MySQLのMemory（HEAP）テーブルを使ってみる » オープンソース研究室
http://linux.mini13i.com/?MySQL%2F%BA%C7%C5%AC%B2%BD%2F%A5%B5%A1%BC%A5%D0%A5%D1%A5%E9%A5%E1%A5%BF
IDEA * IDEA
