Facebook、新しいMySQL用ストレージエンジン「MyRocks」をオープンソースで公開。フラッシュに適したデータの書き込みと圧縮効果
Facebook、新しいMySQL用ストレージエンジン「MyRocks」をオープンソースで公開。フラッシュに適したデータの書き込みと圧縮効果 FacebookはMySQL用の新しいストレージエンジン「MyRocks」をオープンソースで公開しました。同社のエンジニアである松信嘉範（Yoshinori Matsunobu）氏がFacebookのブログに投稿した記事「MyRocks: A space- and write-optimized MySQL database」で紹介しています。 MySQLのデータベースエンジンとして使われているInnoDBは優れているものの、フラッシュストレージと組み合わせたときに書き込まれるデータ量の効率性などに課題があったため、MyRocksに取り組んだと説明されています。 InnoDB is great for performance and reliabil
MySQL 5.7の新機能完全リスト | Yakst
MySQL 5.7には150を超える新機能がある。 MySQLのマニュアルはとてもいいものだが、少し長すぎる。これは、新機能の箇条書きリストだ。それぞれの機能について1つずつまとめるように頑張ってある。なので、 InnoDBのネイティブパーティショニング については、InnoDBの項かパーティショニングの項のどちらかにだけ載っている。 MySQL 5.7.8 RC2はここからダウンロードできる それか、yumかaptのリポジトリーからもインストール可能だ。 レプリケーション関連 マルチソースレプリケーション(訳注: 1スレーブに複数マスターを設定可能になった) [ 1 ] オンラインでのGTIDの有効化 [ 1 2 3 ] 準同期レプリケーションの性能向上 [ 1 2 ] ロスレス準同期レプリケーション [ 1 2 ] 準同期レプリケーションでいくつのスレーブからACKが返ってくるまで待つ
MySQL 5.6と5.7のInnoDBバッファプールウォームアップのおはなし | GMOメディア エンジニアブログ
こんにちは、DBAです。 MySQL 5.6でInnoDBのバッファプールウォームアップが機能追加されました。みなさん使ってますか？ MySQL 5.6では正常終了時のダンプも起動時のロードもオフ、対してMySQL 5.7では両方ともオンです。また、MySQL 5.7ではダンプするバッファプールのページ数は(デフォルトでバッファプール全体の25%だけ、となっています。 わたしのオススメ設定は↓です。MySQL 5.6, 5.7両方でも使えるように、loose-接頭辞付きでinnodb_buffer_pool_dump_pct(5.7にあって5.6にないパラメーター)を書いています。 [mysqld] loose-innodb_buffer_pool_dump_pct = 100 innodb_buffer_pool_dump_at_shutdown= 1 innodb_buffer_poo
挿入と参照ロックに疲れ果てた俺たちは - ichirin2501's diary
なかったらINSERTしたいし、あるならロック取りたいやん? from ichirin2501 www.slideshare.net 出来事 @ichirin2501 とりあえず何も考えずこの前のロックの話をSlideshareにあげてくれ！！— 柴崎優季 (@shiba_yu36) 2015, 8月 22 はじめに これは先日の社内勉強会で発表したもので、MySQLで特定の問題を解決したいときのノウハウ話です。特定の問題とは、アプリを書いてると「データがなかったINSERTしたい、あるなら排他ロックしつつ取得したい」という要望があったりします。例えば、あるユーザーアクションで初期値もパラメーターで渡されるケースで、データがないならそのままINSERT、既にデータがあるなら取得して状態に依存して更新処理を行いたい場合などです。見かけのロジックは単純に見えますが、MySQLでこれを実現しよう
MySQL 5.7の罠があなたを狙っている
2015/08/22 YAPC::Asia Tokyo 2015 Lightning Talk 2016/01/13 update about default_password_lifetime will be 0Read less
MySQLインデックスの基礎 : ひとつのテーブルに対するクエリの最適化法 | Yakst
MySQLのインデックスを効果的に使うにはどうしたらいいのかについての分かりやすい解説。そもそもインデックスの役割はとは何か、そしてどうすればその役割を果たしてくれるのかを説明する。 たとえ1つのテーブルだけに対して実行されるクエリでも、パフォーマンスが悪いというのはよくあることです。その理由は簡単で、インデックスの作り方がまずいため、実行計画がおかしくなってしまうのです。ここでは、1つのテーブルのみに対する色々なクエリを最適化するためのガイドラインを挙げてみたいと思います。 おことわり : あらゆる状況をカバーしようとはせず、一般的なガイドラインを提示するに留めるつもりです。ここで挙げたものがうまく適用できない例を簡単に見つけることができるのは間違いないでしょうが、ほとんどの場合はここに書いたことが十分なのも事実です。また、MySQL 5.6以上にあるIndex Condition Pu
YouTubeがMySQLをスケールアウトする「Vitess」をオープンソースで公開。Kubernetesに対応
YouTubeがMySQLをスケールアウトする「Vitess」をオープンソースで公開。Kubernetesに対応 Google Cloud Platformのブログに投稿された記事「Scaling MySQL in the cloud with Vitess and Kubernetes」で、Vitessは次のように説明されています。 At YouTube, we went on that journey as we scaled our MySQL deployment, which today handles the metadata for billions of daily video views and 300 hours of new video uploads per minute. To do this, we developed the Vitess platform,
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
我々(主語が大きい)は何故MySQLで外部キーを使わないのか
外部キー便利!!! MackerelではPostgreSQLで外部キーあり そのレコードがあることが保証される 各テーブルのidにアプリケーションレベル(Mackerelの場合Scala)で型付けをするとなお便利 MemberID型、MonitorID型 → idで誤ったテーブルを引くとかがない 本日のスキーマ CREATE TABLE `member` ( `id` INTEGER unsigned NOT NULL auto_increment, `earned_item_count` INTEGER unsigned NOT NULL DEFAULT 0, `name` VARCHAR(191) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4; CREATE TABLE `item`
MySQL Connector/J を利用するときは cacheServerConfiguration=true を設定する - tokuhirom's blog
MySQL Connector/J を利用するときは cacheServerConfiguration=true を設定する MySQL は一般に接続コストが低いことで知られており､コネクションプーリング等しなくても使えるので便利｡ だが､Java 用の MySQL Driver であるところの MySQL Connector/J はデフォルトでは数個のクエリを接続時に発行しており､デフォルトのままでは無駄に負荷がかかる｡ デフォルトでは以下のように4つの準備クエリが発行される! どう考えてもおかしいですよね!やばいっす! 150108 9:18:11 5 Connect root@localhost on test 5 Query /* mysql-connector-java-5.1.34 ( Revision: jess.balint@oracle.com-2014101416321
MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
MySQL InnoDB Pluginのデータ圧縮機能 - SH2の日記
InnoDB Pluginの面白い機能の一つに、データ圧縮機能があります。今回はその仕組みと効果について見ていきたいと思います。まずはグラフをご覧ください。 これはWikipedia日本語版のデータベースをダウンロードし、記事本文の格納されているtextテーブルをMySQL 5.1＋InnoDB Plugin 1.0の環境にロードしたものです。 元テキスト：今回利用したデータは2009/06/21版のものです(jawiki-20090621-pages-articles.xml.bz2)。元テキストはここからXml2sqlを用いてタブ区切りテキストを取り出したものを用いています。このファイルには1,167,411件の記事が格納されており、容量は3,436MBとなっています。 元テキスト gzip：元テキストをgzipコマンドで圧縮したものです。 MyISAM：記事をMyISAMのテーブルに
InnoDBのAUTO_INCREMENTが遅い問題は5.1でどう改善されたのか
MySQL5.1のGA版が出てから8ヶ月余りが経過しましたが、まだ5.0(あるいはそれ以前)をメインで使っている方も多いのではないでしょうか。5.1の何が良いのかいまいち分からないという方も多いかもしれません。そんな方にとって分かりやすい例の1つが、「5.1でInnoDBのAUTO_INCREMENT性能が大幅に改善された」という点です。私は仕事柄Web系の技術者の方と話をする機会もよくありますが、意外と知られていない改善なので(まさにトラフィックと同時接続数の多いWeb系システムのための改善なのに…)この機会に取り上げることにします。 簡単に言えば、AUTO_INCREMENTを持つテーブルに対してINSERTをするクライアント数が数十、数百と増えていった時に、従来はスループットが指数関数的に落ちてしまっていたのが、5.1では高速かつ安定するようになりました。以下にmysqlslapのI
COUNT(*) vs COUNT(col) in MySQL
All of Percona’s open source software products, in one place, to download as much or as little as you need.
MySQLバージョンアップのベストプラクティス | Yakst
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアによる、MySQLバージョンアップの様々なパターンと、その利点・欠点、手順の解説。バージョンアップ実施前の、事前調査とテストが重要であるとの指摘も。 MySQLのバージョンアップ(訳注 : 原文ではupgrade、以下同じ)はどこかで必要になるタスクだし、我々Percona SupportでもMySQLバージョンアップのベストプラクティスについての色々な質問を受け付けている。この記事では、色々なシナリオにおけるMySQLバージョンアップの推奨できる方法に焦点を当ててみたい。 MySQLのバージョンアップはなぜ必要になってしまうのか？その理由は色々だが、新機能が必要、パフォーマンスの改善、バグ修正などがあるだろう。しかし、アプリケーションと組み合わせた上で事前に広範囲なテストをしておかないと、リスクの大きい
大規模環境でMySQLのGTIDを適用して得られた教訓 | Yakst
MySQL 5.6からの機能であるGTIDを、Facebookの環境に適用した際の流れと主な不具合、そしてそれらの修正点について、Facebookのエンジニアによるまとめ。 by Evan Elias and Santosh Praneeth Banda Global Transaction ID (GTID)は、MySQL 5.6の新機能の中でも最も使わずにはいられない機能の一つだ。このおかげで、フェイルオーバやポイントインタイムリカバリ、階層を持ったレプリケーションなどに非常に有益だし、クラッシュセーフなマルチスレッドレプリケーションの必須条件にもなっている。この数ヶ月で、我々はFacebookの全ての本番用MySQLインスタンスで、GTIDを有効にした。その中で、この機能の適用方法や操作について、たくさんの知見が得られた。たくさんのサーバサイドの修正事項については、WebScaleS
[Q&A]MySQL開発でやってしまいがちな致命的ミス | Yakst
Percona MySQL Webinarsの発表(MYSQL開発でやってしまいがちな致命的なミスについて)のQAをご紹介します。 本発表はSQLアンチパターン著者のBill Karwinさんの発表です。 オリジナル: http://www.percona.com/resources/mysql-webinars/how-avoid-even-more-common-deadly-mysql-development-mistakes July 17, 2014 by Bill Karwin 水曜日に「MySQLを開発する上でよく起こる(そして致命的な)ミスをどのように回避するか」をPercona MySQL webinarsで発表した。お見逃の際は、ビデオとスライドを見る為に登録すればまだご覧にいただける。 参加いただいた皆様、そしてとりわけすばらしい質問をしていただきありがたく思っている
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
我々は何故RDBMSを使うのか
ソーシャルゲームでDB水平分散 #mdb_casual
Mobage を支える Ruby の技術 ~ 複数DB編 ~ : sonots:blog
