クエリキャッシュを切ったほうがいイカ？ ベンチマークしてみた - 酒日記 はてな支店
カジュアル！(挨拶) このエントリは MySQL Casual Advent Calendar 2011 の18日目の記事です。 昔、専ら PostgreSQL を使っていた頃、MySQL のクエリキャッシュって簡単に性能上がるしみたいだし羨ましいなあ、と思っていました。そのため、1年ほど前から業務で MySQL を使うようになっても、クエリキャッシュは当然のごとく有効にしておりました。 ところが先日 DSAS開発者の部屋:クエリキャッシュは切ったほうがいいんじゃなイカ？ というエントリを読みまして、クエリキャッシュはグローバルロックを獲得するとのこと。これはちょっと検証してみなければなるまい、ということでベンチマークをしてみました。 ベンチマーク結果 結果は別ページにまとめました benchmark script と my.cnf ざっくりと説明しますと、 平均 260 byte/行、1
MySQLがおかしい！あなたならどうしますか？ – MySQL Casual Advent Calendar 2011 - As a Futurist...
しわっす！DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい＞＜ MySQL がおかしい！ 03:14 hidek: なんかエラー出まくってるんだけど！ 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね？ね？ね？こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう？既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま
【DB概論】データベース設計の重要性とデータ中心アプローチ
第4回へ これまで、データベース設計に関する話を中心に説明してきましたが、システム構築の全体工程を見る中で、他の開発工程との関連を見ておきます。 次の図で、システム構築の際の全体工程の概要を見ることができます。 データベース設計の工程が他の工程とどのように関わっているかを確認します。 システム構築工程の他工程との関係で、特にデータベース設計と関係が深いところを説明します。 システム化計画でシステム全体の方向性を鳥撤した上で、データベース設計の概念設計に入ります。ここは、トップダウンでシステムの全体像をつかんだ上でデータベースの設計をする重要な工程です。システム化計画で出た企業の経営層の戦略などをインプットにして、将来のシステム像をにらんだ設計を行う必要があります。一方、現行業務に沿った、アプリケーション開発の要件定義、概要設計工程と同期を取りながら、データベースの概念設計を進めていきます。
データベースアプリケーションのパフォーマンスにおける7つの大罪
パフォーマンス分析は一筋縄ではいかないことが多いのですが、それは可変要素が非常に多く、ハードウェアの特性、ワークロード、物理的データベース設計、およびアプリケーション設計など、あらゆる要素を検討する必要があり、またこれらの要素の間にトレードオフや副作用が存在するからです。これが正解、と言えるものが見つからないのが普通です。 少し前、SQL AnywhereのコンサルタントであるBreck Carterが、「How to Make SQL Anywhere Slow（SQL Anywhereを遅くする方法）」という記事を書きました。これは今までに読んだ記事のなかでも最大のお気に入りの1つです。Breckはこの記事の中で、パフォーマンスの低下につながる38の異なるデータベース設計、アプリケーション設計、およびサーバ構成設定を列挙しています。この記事を受けて、今後しばらくは「データベースアプリケ
データベースの内部動作を知る
SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基本的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの？ Part 1：SQL文はどのように実行されるのか SQL実行までの
RDBの機能をNoSQLで実現する（2）
前回は、NoSQLデータベースを使って、RDBMSが備えるデータの絞り込みや並べ替えの機能を実現する方法を考えてみました。今回は、NoSQLを使いながら、テーブル結合やデータ集計の機能を実現する方法を考えます（編集部） テーブル結合やデータ集計に挑戦 前回は「リレーショナルデータベース管理システム（RDBMS）が提供しているさまざまな読み取り処理の機能を、NoSQLデータベースで実現するには？」をテーマに、KVS型のNoSQLデータベースで検索処理や並べ替えを実現する方法を紹介しました。 分散環境で性能を発揮できるようシンプルさを追求したNoSQLデータベースには、RDBMSのように便利なデータ加工処理機能はありません。RDBMSが相手なら、SQL文を書くだけで簡単に使えた検索処理や並べ替えも、「データベースにお任せ」というわけにはいかず、アプリケーション側での工夫が必要になります。今回も
基礎から理解するデータベースのしくみ（5）：ITpro
SQL文を実行する際のパフォーマンスに大きな影響を及ぼすものとして，もう一つ，インデックスがあります。インデックスについては，どう定義すべきかというデータベース設計上の問題と，インデックスを有効に使うためのSQL文をどう書くべきかというコーディング上の問題があります。 ここではテーブル設計上の問題を主に取り上げます。SQL文のコーディングについては囲み記事「SQL文を最速にする11のポイント」を参照してください。 インデックスは，テーブルの検索速度を向上させるためのものです。それぞれのSQL文に対して最適なインデックスを定義するのが理想的ですが，実際にはある程度限られたインデックスで，必要なパフォーマンス要件を満たすようにインデックスを定義する必要があります。加えて，どんなSQL文が実際に発行されるのかがあらかじめわかっていない場合は，適当な想定に基づいてインデックスを定義しておかなくては
Microsoft Azure: クラウド コンピューティング サービス
Azure を探索 Azure について 安全かつ将来を見据えた、オンプレミス、ハイブリッド、マルチクラウド、エッジのクラウド ソリューションについて調べる グローバル インフラストラクチャ 他のどのプロバイダーよりも多くのリージョンを備える持続可能で信頼できるクラウド インフラストラクチャについての詳細情報 クラウドの経済性 Azure の財務上および技術的に重要なガイダンスを利用して、クラウドのビジネス ケースを作成する 顧客イネーブルメント 実績のあるツール、ガイダンス、リソースを使用して、クラウド移行の明確なパスを計画する お客様事例 成功を収めたあらゆる規模と業界の企業によるイノベーションの例を参照する
リレーショナルデータベースはNoSQLを取り込み始めた。NewSQLの登場とNoSQLの終わり、という予想
リレーショナルデータベースはNoSQLを取り込み始めた。NewSQLの登場とNoSQLの終わり、という予想 MySQLの次期バージョンとPostgreSQLの次期バージョンにどのような新機能が追加されるのか、昨日、一昨日の2本の記事で紹介しました。 MySQLの次期バージョンはMemcached APIを備える！ MySQL Conference & Expo 2011基調講演 PostgreSQLの現状と次期バージョン9.1の新機能。MySQL Conference & Expo 2011 この2つのデータベースの次期バージョンに共通しているのが、NoSQLの機能を取り込んでいることです。NoSQLに対するリレーショナルデータベースによる反撃が始まっています。 リレーショナルデータベースがNoSQLを取り込み始めた MySQLの次期バージョンであるMySQL 5.6に搭載予定の新機能の1
素早く正規形を見抜く実践テクニック（1/4） － ＠IT
今回のテーマはデータベースエンジニアの必須知識の1つである「正規化」です。正規化は、リレーショナル・データベースのテーブル設計を行ううえで非常に重要なテクニックであり、データベースを設計、実装したことのある方なら一度は正規化に触れているのではないでしょうか。 それほど基本的な知識であるにもかかわらず、正規化を説明できる人はなかなかいません。多く聞かれるのが「何となくテーブルを作ると自然に第3正規形になる」とか「実務上は第3正規化まで行えば問題ない」というものです。 ではなぜ「第3正規化まで行えば問題ない」のでしょうか。本稿ではひととおり正規化について確認しながら、あまり触れられることのない第3正規化より先の正規化を紹介して、この疑問に答えていきたいと思います。 正規化の位置付け 正規化は、データベース設計全般にかかわる基礎知識ですが、特に論理データモデリングの作業の中で必要になります。本稿
MeCabで古文の形態素解析 - ならば
中古和文UniDicという形態素解析辞書を使うと、MeCabで古文の形態素解析ができる。 UniDic/中古和文UniDic - 言語データベースとソフトウェア 辞書のアーカイブを適当な場所に解凍して、mecabの-dオプションでその場所を指定すれば、すぐに試せる。 $ echo "思ひつつ寝ればや人の見えつらむ夢と知りせば覚めざらましを" | mecab -d ./UniDic 思ひ 動詞,一般,*,*,文語四段-ハ行,連用形-一般,オモウ,思う,思ひ,オモイ,オモヒ,和,思ふ,オモウ,オモフ,オモウ,*,*,*,*,*,*,2,C1,* つつ 助詞,接続助詞,*,*,*,*,ツツ,つつ,つつ,ツツ,ツツ,和,つつ,ツツ,ツツ,ツツ,*,*,*,*,*,*,*,動詞%F4@1,* 寝れ 動詞,一般,*,*,文語下二段-ナ行,已然形-一般,ネル,寝る,寝れ,ヌレ,ヌレ,和,寝,ヌ,ヌ,ヌ,
ランキングのつくりかた:Kenn's Clairvoyance
遅ればせながら、あけましておめでとうございます。 先週には、ベイエリアの友人たちがやっているEchofonがPostUpに買収されるなど、幸先のよい新年のスタートとなりました。 さて、最近ホットなマーケットといえばソーシャルゲームですが、ゲームといえばリーダーボード。ハイスコアのランキングで友人や見知らぬ人たちと競うのは、ビデオゲームが誕生した1970年代から欠かせない要素でした。 ところが、インターネット経由で100万人規模のプレイヤーがつながるようになってきた現在、その全体をランキングづけするのは、技術的にも大きなチャレンジとなってきました。 今回は、そのリーダーボードのつくりかたについて、ぼくらの作っているソーシャルゲーム・プラットフォームであるPankiaの運用で得られた知見を共有したいと思います。 自分の順位を知る方法 リーダーボードの基本的な考え方はシンプルで、それはつまり「ユ
ソーシャルゲームのためのMySQL入門その２ | BLOG - DeNA Engineering
こんにちはこんにちは。11インチMacBook Airが欲しくてたまらないiwanagaです。 前回の記事 が幸いにもご好評を頂けた様で非常にうれしいです。嬉しくなって、ついがんばって第２弾を書いてしまいました。引き続き、ソーシャルゲームでよく使われるテーブルタイプ毎にちょっとしたテクニックを紹介していきます。 今回はちょっとライトな感じ＆読み物になってしまっていますが「ユーザID単位で1つだけ持つデータ」と「パラメータなどのマスターデータ」についてご説明したいと思います。ちなみに次回はInnoDBのデータ構造の簡単な説明と複合プライマリーキーのデータについて、その次で紹介し損ねたちょっとマニアックなテクニックや性能管理のための手法を紹介することを予定しています。 その前に。。。 先日行われた JAPAN INNOVATION LEADERS SUMMIT で弊社松信が「ソーシャルゲームの
第4回 クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか（2） | gihyo.jp
まずは、レコードを全件取得するクエリの実行計画を見てみましょう。 SELECT * FROM Shops; Oracle、PostgreSQL、MySQLの3つのDBMSで取得した実行計画を掲載します（リスト1～3）。 リスト1 シーケンシャルアクセスの実行計画（Oracle） 実行計画 ---------------------------------------------------------- Plan hash value: 2761254732 ② ① ③ ------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------
開発メモ: オンメモリDB＋スナップショットで爆速永続キャッシュ
Kyoto Tycoonに自動スナップショット機能が実装され、オンメモリDBでも永続化できるによになり、高速性と永続性を両立できるようになったよという話 自動スナップショットとは 「永続化したキャッシュサーバ」としてのコンセプトを掲げるKyoto Tycoonだが、それはメモリ上でなくファイル上でデータベースを表現するからである。今回の自動スナップショットによる永続化は、それとは異なる。オンメモリDBの中にあるレコードを定期的にファイルに書き出すことで永続化するのだ。 ファイルDBの場合、データベース内のレコードは常にファイルに書かれている。よって、サーバプロセスを再起動してもレコードは消えない。その代償として、ファイル上で更新された領域をディスクに書き込むためのIO処理にかかるオーバーヘッドが無視できない。ファイルシステムのページキャッシュによって緩和されるとはいえ、IO処理がランダムア
いますぐ使える無料のクラウドデータベース「ClearDB」
クラウド上にホスティングされ、バックアップもメンテナンスもしてくれるので運用の手間がかからないリレーショナルデータベース。そんなサービスを開始している提供しているのが「clearDB」です。 1つ前の記事では企業向けのマイクロブログ「Yammer」を紹介し、競合となりそうなセールスフォース・ドットコムのChatterも無料サービスを開始すると紹介しましたが、今回のClearDBも、セールスフォース・ドットコムが発表したばかりの「Database.com」と同様のサービスです。狙ったわけではないのですが……。 clearDBのWebサイトから、どのようなサービスなのかを紹介します。 クラウド上で100％ACID対応のリレーショナルデータベース clearDBは100％ACIDに対応し、自動的にバックアップされたスケーラブルなデータベースだと説明されています。「What is ClearDB?
第6回 まとめとDBMSの今後 | gihyo.jp
前回までのまとめ 前回までで、RDBMSとNoSQLの比較と、NoSQL（TokyoCabinet/TokyoTyrant)を実際に動作させてみました。また、分散環境（kumofs）と組み合わせることで、アベイラビリティとスケーラビリティに特化したDBシステムを構築できることがわかりました。 しかしその反面、複雑なスキーマに対応できなかったり、正確な結果が求められる会計処理などには向かないこともわかりました。また、データにアクセスするための言語がSQLのように統一されていないため、それぞれのNoSQLでアクセス方法を学習する必要がありました。 RDBMSは現在の主流ですが、課金処理などのビジネスシーンにおいては今後も主流として、開発現場で使用されていくと思われます。反面、厳密なACIDのサポートが必要ではないシーンや、膨大なデータを扱いたいシーンにおいてはNoSQLが本領を発揮するのではな
"トランザクション処理--概念と技法--" を読むためのページ - Transaction Processing: Concepts and Techniques
"トランザクション処理--概念と技法--" を読むためのページ last update: June 10, 2002 何ですか、この本は？ データベース業界の第一人者であるJim Gray氏とAndreas Reuter氏が書いた 大著と言いますか、はっきり言ってバイブル的存在ですが、 "Transaction Processing: Concepts and Techniques"の翻訳が、日経BP社から 喜連川優氏監訳でタイトル"トランザクション処理-- 概念と技法-- 上・下巻"として2分冊でやっと出ました。とにかく、 原著も分厚い(48mm: 刷が進むほど紙の質が薄くなり、やっと48mmまで下がっ た!)が、翻訳はもっと分厚い(原著の紙質よりも厚いため、上下巻合わせて 96mmもあります)。 タイトルにはトランザクション処理となっていますが、もっと平たく言う と、データベースの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【DB概論】データベース設計の目的・まとめ
リスト・プロパティを含むエンティティの永続化