運用3年目から始めるパフォーマンス改善 ~モニタリング・MySQL・Fastly・アプリケーション~
です。マンションマーケットエンジニアブログは今回からMediumに移行し、これが移行後1本目のエントリーです! 今回は直近2–3ヶ月ほど取り組んでいるパフォーマンス改善のお話です。 概要現在のマンションマーケットのサイトは初期バージョンのリリース後、リニューアルのためにスクラッチで作り直されており、 現在のメインリポジトリへの最初のコミットは2015/4/4でした。 開発開始から約2年半が経過したプロジェクト、ということになります。 今回のポストでは、運用3年目を迎えた私達のプロダクトがパフォーマンス面で直面した悩みを紹介した後、 実際にアクションに移した以下4つの施策についてご紹介します。 1. アーキテクチャの理解 2. モニタリング・監視 3. アーキテクチャ・ミドルウェアレベルでの改善(MySQL・Fastly) 4. プロファイリング~アプリケーションの改善(非同期化・Redis
PostgreSQL and MySQL: Millions of Queries per Second
This blog compares how PostgreSQL and MySQL handle millions of queries per second. Anastasia: Can open source databases cope with millions of queries per second? Many open source advocates would answer “yes.” However, assertions aren’t enough for well-grounded proof. That’s why in this blog post, we share the benchmark testing results from Alexander Korotkov (CEO of Development, Postgres Professio
サイトを37倍に高速化した7つの手法 - オールアバウトTech Blog
今回はオールアバウトのnnmrが弊社サイトAll About Japanの速度を高速化した経緯についてまとめます。 All About Japanとは そもそもAll About Japan（以下AAJ）とは何かといいますと、弊社が提供している訪日外国人向けの日本紹介サイトです。 外国人向けサイトで、英語、中国語（繁体字）、中国語（簡体字）、タイ語、韓国語の5か国語に対応しております。 「Anime」「Izakaya」「Ninja」といったような特集や、実際に観光する人向けのモデルルート記事が特色です。 ■ 特集 (url : http://allabout-japan.com/en/tag/sushi/ ) ■ モデルルート記事 (url : http://allabout-japan.com/en/article/222/ ) 技術的な紹介 LAMP環境です。 （サーバー構成は後に記述
MySQLの最先端を行く現場人が集う MySQL Casual Talks #6に行ってきた！ - もぐめぽろぐ
TokuDBとはTokutekが作ったFractalTree(R)Indexを実装したストレージエンジン 特徴 オンラインALTER TABLE(ADD INDEX, ADD COLUMN)に対応 圧縮がイケてる 断片化しない クラスターインデックスを複数作れる infromation_schema, show engine tokuDB で情報みれるがなれるのに時間かかる foreign keyは対応してない How TokuDB Fractal TreeTM Indexes Work ランダムライトなインデックスの構築が早い InsertのTPSはいつまでもスループットが変わらない テストケース twitterみたいなことをやろうとした テーブルをクロスしてtimelineテーブルを作る timelineテーブルは6億件 ファイルサイズ図ったらinnodb compactは60G弱、
MySQLのパーティショニングのハマリ所 - sakaikの日々雑感～(T)編
今までマニュアルを斜め読みした程度で「MySQL 5.1 から使えるようになったパーティショニング。便利そうだな」などと思っていたのですが、このたび実際に使いたいシーンが出てきたので、利用を前提に調べてみました。 そしたら、ハマることハマること。やりたいことは、日付カラムで１日ごとのパーティションにしたいだけだったのですが（向こう２年分くらいパーティション作っておいて、運用で「古いパーティション削除→新しいのを追加」でいいかなと考えていました）、これができない。 ハマりの原因は「パーティショニングの条件は、プライマリーキーの一部でなければならない」という制約。 http://dev.mysql.com/doc/refman/5.1/ja/partitioning-limitations.html 今回使用を検討したテーブルはプライマリーキーが重要だったので、 CREATE TABLE pt
MySQLのパーティショニングで必要そうな工夫 - cloned.log
MySQL 5.1のパーティショニングを試してみた。マニュアルはMySQL :: MySQL 5.1 リファレンスマニュアル :: 15 パーティショニングを参照のこと。試してみた環境は、MacのParallels Desktop上のCentOS 5。 まずはMySQL 5.1をソースからインストール。マニュアルには次のように書かれている。 ソースからコンパイルする場合には、--with-ndbcluster、--with-partitionオプションとともにconfigureを実行して下さい。 MySQL :: MySQL 5.1 リファレンスマニュアル :: 15 パーティショニング この通りにすると、ここの記載のように非推奨オプションだと言われてしまうので、--with-pluginsを使って指定するようにした。今回の味見configureオプションは次の通り。 ./configur
パーティショニングの使用例 - http session情報
今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする（たぶん昨日の例よりも）もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDB（MySQL Cluster）ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン
MariaDB(MySQL) - パーティショニング！
mk-mode.com Linux, Debian, IT, Server, PG, Ruby, Rails, Python, C++, Fortran, PC, MariaDB, math, GIS, etc... MySQL 5.1 から導入されたテーブルのパーティショニング（１テーブルの分割管理）についての備忘録です。 パーティショニングすることにより主に以下のようなメリットがあると考えられます。 対象のパーティションのみ参照するようになるため、高速化が見込まれる。 パーティションごと削除が可能であるため、管理が楽になる。 （以下、乱文ご容赦ください） 0. 前提条件 MariaDB(MySQL) 5.5 系、5.6 系での作業を想定。 （5.1 以降ならパーティショニング可能であるが、RANGE で date 型, datetime 型がそのまま使用できるのは 5.5 以降） 1.
MySQLパーティショニングの設定、追加、削除、再構成 - Qiita
まずこんなテーブルを作るとします。ここに毎月10万件以上のレコードが入ってくる予定です。 1レコードが57byteなので、月に5.7Mbyte、プライマリーキーを入れると60Mbyteくらいが入ってきます。 年間にすると720Mbyteなので、まぁデータ量的には余裕だと思うのですが、 100万レコードを超えるとレスポンスが鈍化するという印象があります。 というわけで、MySQLにあるパーティショニング機能を使い、データを振り分けたいと思います。 【参考】DB設計時のサイズ見積もり | よねのはてな テーブル作成 注意する点として、パーティショニングのキーにしたいカラムを、プライマリーキーに含める必要があるようです。 なので、オートインクリメントのカラムがあるテーブルだと辛い。構成を考えなおした方がいいかも。 CREATE TABLE `list_rtx` ( `member_id` var
MySQL Connector/Jにおける大量INSERTのチューニング - SH2の日記
ピンポイントチューニング講座です。まずは結果から。 このグラフは、以下のテーブルに50,000レコードINSERTしたときの処理時間を示したものです。性能に70倍以上もの差が出ているのはなぜか、見ていきたいと思います。 CREATE TABLE `loadtest` ( `id` int(11) NOT NULL, `data` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 方法1 ベースライン conn = DriverManager.getConnection(JDBC_URL, JDBC_USER, JDBC_PASS); pstmt = conn.prepareStatement("insert into loadtest (id, data) values (?
Storing UUID Values in MySQL
Please note, a more up-to-date follow-up post is here: Storing UUID and Generated Columns A few years ago Peter Zaitsev, in a post titled ““There is timestamp based part in UUID which has similar properties to auto_increment and which could be used to have values generated at the same point in time physically local in BTREE index.” For this post, I’ve rearranged the timestamp part of UUID (Univers
Amazon Auroraを真に理解するための性能検証 | 外道父の匠
今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照／更新クエリを実行しています デ
MySQLのスレッドとか接続数とか
最大接続数設定 mysql> show global variables like 'max_connections'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 150 | +-----------------+-------+ 1 row in set (0.00 sec) 起動してからの累積接続数 mysql> show global status like 'Connections'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Connections | 11862 | +---------------+-
開発者のためのSQLパフォーマンスの全て
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
MySQL インデックスのチューニング : きょうもぼへぼへちゃんがゆく
2010年05月31日 16:23 カテゴリMySQL MySQL インデックスのチューニング Posted by ashibuya0128 No Comments No Trackbacks この本の第8章、第9章の「インデックスのチューニング（前編・後編）」を読みましょう Linux-DB システム構築/運用入門 (DB Magazine SELECTION) 著者：松信 嘉範 販売元：翔泳社 発売日：2009-09-17 おすすめ度： クチコミを見る この本、読めば読むほど、第2のバイブル化してきました。 MySQLを使って開発している人は、この2章だけは読んだほうがいいですね。 性能の支配要因は処理しなければならないレコード数とランダムI/O回数なので スキャン範囲を絞る I/O回数を軽減すること です。 まず、インデックス構造とデータヒットのメカニズムを本書では詳しく解説してくれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Zaim 500万ユーザに向けて〜Aurora 編〜
MySQLで簡単にランダムなテストデータを作成する方法 - Qiita
ヤフー社内でやってるMySQLチューニングセミナー大公開
FFRKを支えるWebアプリケーションフレームワークの技術
Lv1から始めるWebサービスのインフラ構築
