MySQL(InnoDB)でカーディナリティの低いカラムにINDEXを張る - Qiita
RDBMSのテーブルにINDEX（セカンダリINDEX）を作成する場合、よく「カーディナリティが低いカラムには作るな」と言われます。 どんな場合でも当てはまるのか、少し実験して確かめてみます。 カーディナリティとは 今さら解説するまでもないかもしれませんが、「あるカラムにおける、取りうる値の種類」のことです。 ER図など、DBに絡む場面で別の意味で使われることもありますが、ここではこの意味で使います。 例えば、性別を表すカラムがあり、必須で値を入れなければならない場合は、「男性」「女性」の2種類、です。 「カーディナリティが低いカラムにINDEXを張るな」の意味 先に挙げた「性別」の場合、もし対象となる全レコードで男女の比率がほぼ１：１であれば、INDEXで絞り込める範囲は1/2程度です。絞り込みの効果があまりありません。 このような場合は、わざわざセカンダリINDEXを使うのではなく、テ
本当にあったやらかしDB設計シリーズ一覧 - Qiita
本当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています 初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としています もしここに載っていないパターンを経験したことのある方がいたら是非教えてください 本当にあったやらかしDB設計①【R無しRDB】 本当にあったやらかしDB設計②【囚人番号テーブル】 本当にあったやらかしDB設計③【ロジカルクエリー】 本当にあったやらかしDB設計④【テストチューニング】 本当にあったやらかしDB設計⑤【第三正規化病】 本当にあったやらかしDB設計⑥【見えない削除フラグ】 本当にあったやらかしDB設計⑦【ステートフルDB】 本当にあったやらかしDB設計⑧【ファンクションDB】 本当にあったやらかしDB設計⑨【文字列日付】
MySQLでビッグデータ（１億レコード以上のデータ）を作って遊ぼう - Qiita
MySQL(RDBMS)でビッグデータを扱う ビッグデータというのは、概ね通常単一のPCでは扱いきれないデータ量のレコード数のデータのことを言います。 一般的にはDBなどに蓄積されているデータよりも蓄積はされても参照されることのないログファイルを指してビッグデータと呼ばれるようですが、通常参照されることのないデータをわざわざ検索することにそれほど価値や意味を見出すことには疑問が残ります。 また、ログファイルといえどもそうそう１億行にも達するようなデータというものはwebサービスを運営していたとしても早々お目にかかれるものでもありません。 なので、「ワイもビッグデータを扱ってみたい！」とふと思った少年少女そのほかおじさんなどに向けた「手軽に作れるビッグデータ」の方法を記述していこうかと思います。 本記事を試行するにあたって必要なシステム 本記事ではMySQL5.5を利用していますが、5.1以
scikit-learnでDBSCAN(クラスタリング) - Qiita
クラスタリングアルゴリズムの一つであるDBSCANの概要や簡単なパラメータチューニングについて， 日本語記事でまとまっているものがないようでしたのでメモしました。 DBSCANの概要は，wikipediaの(雑な)和訳ですのでご容赦ください。 DBSCANとは Density-based spatial clustering of applications with noiseの略 クラスタリングアルゴリズムの一つ アルゴリズムの概要 1.点を３つに分類する Core点 : 半径ε以内に少なくともminPts個の隣接点を持つ点 Reachable点(border点):半径ε以内にminPts個ほどは隣接点がないが，半径ε以内にCore pointsを持つ点 Outlier : 半径ε以内に隣接点がない点 2.Core点の集まりからクラスタを作成し，Reachable点を各クラスタに割り当て
MySQLパフォーマンスチューニング -クエリキャッシュ適用状況の確認- - Qiita
花粉真っ盛り。 もれなく花粉症MAXな日々を過ごしております。 まみーです。 前回のエントリーからの続きになります。 MySQLパフォーマンスチューニング -my.cnfの見直し- 今回は、前回の設定結果の中から、クエリキャッシュの効き具合を測定・検証していきます。 概要 my.cnf に設定した内容のうち、クエリキャッシュについて検証します。 前回の設定変更から1週間経過した時点での値の比較となります。 目的 設定されていなかったクエリキャッシュが適切に効いているのかを検証し、設定が妥当かどうか判断します。 問題点 サービスの運用上、以下の問題点があります。 変更できない テーブル構成 リクエストごとに増え続ける ログレコード 必要な リアルタイム検索機能 状況 クエリキャッシュ設定前の状況は以下でした。 リアルタイム検索を 複数実行するとサーバーが落ちる 1プロセスでも 応答に30秒
MySQLパフォーマンスチューニング -my.cnfの見直し- - Qiita
※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「
第四章 キーレスエントリ（外部キー嫌い） - Qiita
# 親行を参照するバグレポートがあるか確認 SELECT bug_id FROM Bugs WHERE reported_by = 1; # 子行がなかったらアカウント親を消すことができる DELETE FROM Accounts WHERE account_id = 1; ・もし、account_id=1の利用者が知らないところで作業をしていて、上記の削除作業中に新しいバグレポートを登録していたら…？親のない不正な子レコードがBugsテーブル上にそのまま残ってしまう！ →対処策はBugsテーブルを明示的にロックしながらチェックを行い、アカウント削除後にロックを解除すること。 しかしこの種のロックを必要とするアーキテクチャでは同時接続ユーザーが増え、スケーラビリティ（システムの利用者や負荷の増大に応じて、柔軟に性能や機能を向上させられること）が求められるようになるにつれ、様々な問題に直面し
MySQLのスロークエリをslackに通知できるようにする - Qiita
やりたいこと こんな感じで、MySQLでボトルネックになりそうなslowクエリをslackに通知させて、 継続的に、クエリチューニングできるようにしたい。 なので、Mysqlで出力されたスロークエリログをfluentdで取得し、 そのクエリに対して、explainを実行させて、クエリの内容と一緒に、 explainの結果をslackに通知できるようにする。 1. 準備 slackの投稿先webhookURLを用意する IncomingWebHookのキー発行は以下から取得する https://xxx.slack.com/services/new 参考URL: http://qiita.com/vmmhypervisor/items/18c99624a84df8b31008 2. 環境構築 fluentd インストール
MySQL 5.5系で slow queryを見張る設定 - Qiita
私は出力先がTABLEのほうがいろいろツブシがきいて好きなのだが、ファイルにする場合にはパスなどもあわせて設定すること。 long_query_timeを0に指定すると全部slow query扱いになる。0.3という指定もここでは独断と偏見でしているが、プロジェクトの要求仕様に応じても最初から厳しい値にしておいたほうがいい。0.1とか。 見る select * from mysql.slow_log order by start_time desc limit 10 などすれば、どんなクエリが遅かったのかを確認できる。 muninで見張る mysqlのプラグインがあるので見張る。とても便利。サンプルとして2枚ばかり貼る。 前述した見る、だと、どうしても手間がかかるので、本番が近くなってくると、こういうので確認し、つぶしていくとよい。 運用が始まったら始まったで、DBが原因で遅いのか？など確
PostgresのRDSチューニング - Qiita
Wantedlyは今までRDSを初期設定のまま使っていました。ごめんなさい。 今回ちゃんとチューニングしてみたのでやってみた過程と結果を書きます。 ちなみにWantedlyはDBを幾つか持っていて、その中のDBの一つの最適化結果です。 NewRelic での測定の結果、平均31ms ぐらいかかっていたのが、 平均23ms ぐらいになっているので25％ぐらいの改善になりました。 インスタンスタイプ 使っているDBのインスタンスタイプです モデル: r3.4xlarge vCPU: 16 メモリ: 122GB SSDストレージ: 1 x 320G デフォルト値 RDSはパラメータグループを調節します。 それぞれのデフォルト値は書かれてないですが、以下のSQL出だすことができます。 => SELECT name,setting,unit FROM pg_settings; name | sett
コネクションプールのチューニング - Qiita
TL;DR 負荷の変動が激しい環境でコネクションプールの設定のチューニングをさぼるためによくやるハックを紹介します。 問題 Go から https や mysql など外部のリソースにアクセスする場合、一般的にコネクションプールを使うことになります。 コネクションプールは、利用が終わった (idle) コネクションをプールしておき、次に使いたい時に再利用するものです。 (idle コネクションのプールを以後 free pool と呼びます。) ほとんどのコネクションプールの実装には、 idle なコネクションの最大数を制限するオプションがあります。 また、利用中の (active) コネクションと idle なコネクションを合計した全体を制限するオプションを持つものもあります。 例えば net/http パッケージの Transport は MaxIdleConnsPerHost というフ
N+1問題は1+N問題 - Qiita
N+1というからほわっつ？ってなって、1+Nって言われると理解しやすいと思った。 このページ非常にわかりやすい。 http://www.techscore.com/blog/2012/12/25/railsライブラリ紹介-n1問題を検出する「bullet」/ 上のページでいう、PrefectureとShopが一対多の関係になっているときに、Shopの方から、eachの中でshop.prefecture.name みたいにすると、shopの数だけprefecture探すSQL文が発行されることになる。 このページ（参考）では、N+1問題をシンプルに、「全レコードの取得に一つ＋各レコード分だけ SQL を発行してしまう問題」と定義していて、要はただこれだけの問題だと感じた。 例えば100万レコードあったら100万回SQL発行されるのかって考えると、さすがにだれでもやばみ感じると思う。 実際にサ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
