ソーシャルゲームのためのデータベース設計
2. 自己紹介 MySQL/Linux周りのスペシャリスト 2006年9月から2010年8月までMySQL本家(MySQL/Sun/Oracle)で APAC/US圏のMySQLコンサルティングに従事 主な著書に「現場で使えるMySQL」「Linux-DBシステム構築/ 運用入門」「Javaデータアクセス実践講座」 DeNAでの主な役割 安定化/パフォーマンス/運用周りの中長期的な改善活動 L3サポート/運用/トラブルシューティング – 難度の高いMySQL周りの問題の根本原因の特定と解決 多くのプロジェクト支援 社内勉強会/トレーニング – MySQLやデータベース周りのベストプラクティスを社内で共有し、 技術スキルを底上げする 技術マーケティング – 国内外のカンファレンスや、技術雑誌等
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 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
PHP と MySQL と サーバサイド プリペアードステートメント - do_aki's log
少し前のお話なのだけど、せっかくなので書いておくことにする。 MySQLのクエリログを見ていたら、 prepare に相当するログが一切流れていないことに気づいたので、PDO(mysql)でサーバサイドプリペアードステートメントが利用されていないんじゃないか疑惑が浮上。 php のバージョンは 5.2.11 mysql は 5.0 系 以下、検証してみた結果と、その対応です。 検証 簡単なソースコードを実行してみて、そのクエリログを見てみることにした。 PDO を利用 $p = new PDO('mysql:dbname=dbname;host=localhost', 'user', 'password'); $stmt = $p->prepare("SELECT * FROM table_name WHERE id=?"); $stmt->execute(array(1)); $stmt
ここギコ！: mysqlの空間拡張対応が進んでいるよ！（C/W：Postgres使うならPostGIS使おうよ）
2009年07月08日 mysqlの空間拡張対応が進んでいるよ！（C/W：Postgres使うならPostGIS使おうよ） 同僚が見つけてくれたネタ、パクる感じで申し訳ないのですが...。 mysqlの空間拡張と言えば、空間インデックスでMBR（最小外接矩形）ベースの絞込みができるくらいで、後は沖電気さんがユーザ関数でdistance_sphere開発されたりとか、そういう感じだったんですけれども、裏ではまだベータ版ながら、大分いろんな機能が追加されてるみたいですね。 Categories: MySQLDevelopment | Software Preview | GIS Functions BUFFER(g1 geometry, d numeric) returns a Geometry defined by buffering a distance d around g1 where
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
ここギコ！: GoogleMapsと連動したいならPostGISの他にmysqlという選択肢も出てきた あとジオメディアサミット関西も
2008年11月13日 GoogleMapsと連動したいならPostGISの他にmysqlという選択肢も出てきた あとジオメディアサミット関西も 随分以前に、GoogleMapsと連動したいなら幾何データ型よりPostGISという記事を書いたけど、徐々にmysqlという選択肢も出てきつつある、という話。 特にGoogleMaps連動に限った話ではなく、位置情報を扱う場合、ということだけど、その辺は前記事を踏襲してみた。 ネタは最近行ったFOSS4G 2008 OSAKAで仕入れたもの。 FOSS4Gに関しては、OSAKAだけでなくTOKYOも行ったので、遅れたレポートに意味があるのかはともかくまたレポートまとめたいと思っているのだけれど、忙しいわ、今指の調子がぶっ壊れてるわで余裕がない。 とりあえずこのネタだけ先に書く。 話としては、沖電気さんが発表した、mysqlに、PostGIS
SQLエスケープにおける「\」の取り扱い
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2008年6月2日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 昨日のエントリ(徳丸浩の日記 - そろそろSQLエスケープに関して一言いっとくか - SQLのエスケープ再考)は思いがけず多くの方に読んでいただいた。ありがとうございます。その中で高木浩光氏からブクマコメントを頂戴した。 \がescape用文字のDBで\のescapeが必須になる理由が明確に書かれてない。\'が与えられたとき'だけescapeすると…。自作escapeは危うい。「安全な…作り方」3版で追加の「3.失敗例」ではDBで用意されたescape機能しか推奨していない このうち、まず「\」のエスケープが必
1:nなデータを検索しやすくDBに入れたい (2008-03-20)
手元に資料があるもので適当に問題を置き換えたので例が悪いが、とにかくこういうデータをどういうスキーマで格納するかを考える。教科書どおりに沿って考えると、このデータは正規化されていないので、正規形に変える必要があるだろう。 夜行バス ID名前行き先片道運賃 1
「PostgreSQLは遅い」は本当か？：OSSデータベース比較 - CNET Japan
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます LAMPやLAPPといった言葉が示しているように、オープンソースソフトウェア（OSS）での代表的なリレーショナルデータベース管理システム（RDBMS）といえば、「MySQL」と「PostgreSQL」だ。この2つのRDBMSは同等であるかのように思われているが、しかしPostgreSQLのユーザー団体「日本PostgreSQLユーザ会」で理事長を務める片岡裕生氏によれば、「PostgreSQLはあまり信用されていない」ということがあるそうだ。 「十分にチューニングされたMySQLとチューニングしていないPostgreSQLを比較したり、反対にチューニングされたPostgreSQLとチューニングしていないMySQLを比較したり、あるいは比
ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」：ITpro
ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」 YAPC::Asia 2006 Tokyo 東京都大田区で開催されているPerl技術者向けカンファレンス「YAPC::Asia 2006 Tokyo」で2006年3月29日，日本最大のソーシャル・ネットワーキング・サイト（SNS）である「mixi」を運営するミクシィのBatara Kesuma（バタラ・ケスマ）取締役最高技術責任者（CTO）が，増え続ける膨大なトラフィックにどのように対処してきたのかについて講演した。カギとなるのは「データベース分割」である。 mixiのシステムはもともとBatara氏が1人で作り上げたものだ。2003年当時，米国でFriendsterなどのSNSがはやっており，同氏が会社（現在のミクシィ，当時はイー・マーキュリー）にSNSを作りたいと提案したところ認められたという。同氏が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『Loading...』へのコメント
MySQL FULLTEXT Ngram : LIKE検索より数十倍高速な、お手軽 日本語全文検索 について｜blog｜たたみラボ
http://blog.thebadtiming.com/archives/002335.htm