[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

タグ

MySQLとperformanceに関するHashのブックマーク (6)

  • MySQL 5.6のパラレルレプリケーションの効用はいかほど?(The Percona Performance Blogより) | Yakst

    MySQL 5.6のパラレルレプリケーションの効用はいかほど?(The Percona Performance Blogより) 高負荷時のリードレプリカ遅延に対する改善方法の1つとしてパラレルレプリケーションが考えられる。どの程度改善するのかはMySQL 5.6では、スキーマ間の書込み負荷の分布に依存しこれを大雑把に見積もる方法をご紹介する。 この質問を今までとても良く受けてきた。"負荷が高い時には、リードレプリカがしばしば遅延し始める。N個のスキーマを利用しているが、MySQL 5.6のパラレルレプリケーションを使うとどのくらい性能が改善するのだろうか?"ここでは潜在的な効果を、素早く大雑把に見積もる方法をご紹介する。 基的な考え方 MySQL 5.6では、スキーマレベルで並列処理が行われる。従って理論上は、N個のスキーマがあり、N個の並列スレッドを利用すれば、レプリケーションは最大N

    MySQL 5.6のパラレルレプリケーションの効用はいかほど?(The Percona Performance Blogより) | Yakst
    Hash
    Hash 2015/08/25
    ふーむ
  • パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog

    下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で

    パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog
  • mk(pt)-query-digestをもっと活用しよう! - 筋トレとともに生きるDBAの雑記

    もはやこれが無くては障害対応ができないぐらい中毒になっているmk-query-digestさんについてです。 mk-query-digest - Analyze query execution logs and generate a query report, filter, replay, or transform queries for MySQL, PostgreSQL, memcached, and more. 例えばこんなことが起きたときは、何を差し置いてもまずtcpdumpを取りに行きます。 状況がおさまってしまってからでは遅いのです。 Load Averageの高騰 Too Many Connections lock wait timeout tcpdump -i bond0 -s 65535 -x -n -q -tttt 'port 3306' > tcpdump.out

    mk(pt)-query-digestをもっと活用しよう! - 筋トレとともに生きるDBAの雑記
  • Loading half a billion rows into MySQL

    We have a legacy system in our production environment that keeps track of when a user takes an action on Causes.com (joins a Cause, recruits a friend, etc). I say legacy, but I really mean a prematurely-optimized system that I'd like to make less smart. This 500m record database is split across monthly sharded tables. Seems like a great solution to scaling (and it is) -- except that we don't need

  • パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合

    MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、 インデックスをつけるだけでカバー出来る場合が多い。 パーショニングを使わずに、単にテーブルを分けてしまえばいい。 テーブルが巨大にならないとあまり効果を実感できない。 使い方を間違えると性能が落ちてしまう。 などの問題があるからだろう。 そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。今日は一つ目、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日語に訳すと濃度とか訳されるが、要は値の種類(分散具合)のことである。例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を

    パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合
  • 2008-06-29

    mysqlを利用していて、indexをちゃんと張っているのにパフォーマンスが出ない。 explain でも type = ref / key = INDEX 等が表示されているのにすごくクエリーが遅かったりする。 思い切って index を消したら逆にパフォーマンスが改善した! why? データ件数が数万件を越えたあたりからパフォーマンスが劇的に下がった。 と、悩んでいたりしませんか? そんな悩みのひとつの解決策になってくれるかもしれません。 テストは vmplayer 上の debian etch で行います。 ホスト環境 intel Q6600 メモリ2Gの WindowsXPです。 クエリーをキャッシュされないように、クエリキャッシュを 0 にします。 /etc/mysql/my.cnf query_cache_size = 0 #no cahce debug swapで遅くなると困

    2008-06-29
  • 1