2015/08/22 YAPC::Asia Tokyo 2015 Lightning Talk 2016/01/13 update about default_password_lifetime will be 0Read less
2015/08/22 YAPC::Asia Tokyo 2015 Lightning Talk 2016/01/13 update about default_password_lifetime will be 0Read less
かねてから予告していた通り、OSC広島と中国地方DB勉強会(第5回)に参加させて頂いた。両方のイベントがこの土日で連続して行われたので、いずれのイベントにも遠方からの参加者がたくさんいて盛況だったように思う。OSC広島ではデモマシンの展示を、中国地方DB勉強会ではスライド(MySQLのトラブルシューティングについて)の発表をそれぞれやらせて頂いたので、今日はその報告をさせて頂こう。 OSC広島に持っていったデモマシン既にツイッターやFacebookで目にされた方もいらっしゃるかも知れないが、今回展示したマシンのコンセプトは「持ち運べるMySQL Clusterのデモ環境」というものだ。MySQL Clusterを動作させるためのBeagle Bone Black 6台と、コンソール用のRaspberryPi、100Mbpsのネットワークスイッチ、薄型のモバイルモニター、トラックポイントつき
https://mariadb.com/kb/en/optimizer-switch/にあるように、MariaDBのオプティマイザはかなり改良されている。 では、MariaDBのオプティマイザ/エクゼキュータはどの程度優秀か、4つのSELECT文の実行を通してMySQLと(ついでにPostgreSQLと)比較してみる。 (2014.12.3追記:オプティマイザについては省略してますが、こんな本がでます。) 結論を先にいえば「MySQLは検索が速い」というのは都市伝説。MariaDBはがんばってるけどPostgreSQLにはまだまだ及ばず。 *念のため。これはベンチマークじゃないよ、オプティマイザ/エクゼキュータの機能比較です。 自分で再確認したい場合はこちらにスクリプト群と実験のやり方を簡単に書いたので参照のこと。 調査環境 同一マシンにMySQL5.6.14、MariaDB10.0.4、
(2014.12.3追記:このblogの内容は、以下の書籍にも反映させた。) SQLレベルの差異 MariaDB5.5とMySQL5.5ではSQLレベルでの違いはほとんどなかった。autoincrementの最大値の扱いくらい。 ただし、MariaDB10.0でREGEXPがマルチバイト対応になったので、アプリ側は注意。 項目 MySQL MariaDB Autoincrement 最大値に達すると、以降は最大値を繰り返す。Warningのみ。エラーにならない。tinyintなら…,125,126,127,127,127… 最大値-1まで。以降はエラーを返す。tinyintなら…,125,126,ERROR,ERROR,… EXPLAIN文 JSON形式 バージョン5.6から 未対応 Optimizer Trace バージョン5.6から 未対応(ただし、MariaDBのほうがオプティマイザ
Page: 1 MySQLのプロトコル解説 とみたまさひろ 日本MySQLユーザ会 MyNA会 2013/07/29 MySQLのプロトコル解説 Powered by Rabbit 2.1.1 Page: 2 自己紹介 とみた まさひろ MySQLユーザ会 (名ばかり代表) 長野県北部在住 プログラマー (Ruby & C) http://tmtms.hatenablog.com http://twitter.com/tmtms https://github.com/tmtm/ruby-mysql MySQLのプロトコル解説 Powered by Rabbit 2.1.1 Page: 3 趣味 誰も使わないRubyライブラリを作ったり MySQL の yacc ファイル読んだり マンガ読んだり 聖悠紀 / 佐々木淳子 / 岡崎二郎 / 星野之宣 / 長谷川裕一 / 島本和彦 / 桑田乃梨子
MySQL5.6は5.5よりもベンチマーク性能が落ちるという話がここ最近見受けられます。 My MySQL is faster than your MySQL Is MySQL 5.6 slower than MySQL 5.5? MySQL5.6の検証は半年程前から本格的に開始して、大量データに対して、JOINやLIMIT、INDEXが不十分なクエリに対して、productionデータで試してみたところ、完全に新規パラメータの設定やデフォルト値の変更を適用していない状態でも性能向上が出ていたので、安定性のテストをしていたのですが、上の記事などを読んでsysbenchやsql-benchを試してみました。 これは基本的なクエリを流すので、複雑な処理を高速化しているとかはあまり考慮されません。 ついでに、RDSもベンチマークを測ってみました。 MySQ5.5と5.6は基本的な設定内容は同一に
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
カスタマイズ可能なポータルサービスを提供するフランスの「NetVibes」は、バックエンドデータベースとしてミクシィの平林幹雄氏が開発し、同社内でも利用されているNoSQLデータベースの「Tokyo Tyrant/Tokyo Cabinet」(以下Tokyo Tyrant)を採用しているそうです(追記:平林氏は7月末でミクシィを退職されるとのこと)。 なぜNetVibesはTokyo Tyrantを採用したのか、その理由がmyNoSQLの記事「Netvibes: A Large Scale Tokyo Tyrant Deployment Case Study」で紹介されています。NetVibesは、Hadoop、CouchDB、Tokyo Tyrant、File system、MySQLを評価した上でTokyo Tyrant/Tokyo Cabinetを採用したとのこと。 NetVibes
グーグルでMySQLエンジニアリングチームを率いたのち、現在はFacebookに在籍しているMark Callaghan氏がブログ「High Availability MySQL」にポストしたエントリが発端になって、MySQL+Memcachedの時代は過ぎたのか? という議論が巻き起こっています。 元グーグルMySQL担当エンジニアが弱気な発言? Callaghan氏がポストしたエントリ「Plays well with others」は次のような一文で始まり、MySQLについてややシニカルに書かれているように読めます。 A few years ago MySQL+memcached and PostgreSQL+memcached were the only choices for high-scale applications. That has changed with the ar
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます TwitterがMySQLデータベースからCassandraに移行する。同社エンジニアRyan King氏が米国時間2月23日、MyNoSQLのインタビューに応じ、決定に至るまでに検討した内容などを明らかにした。記事によると、同社はクラスタ化したMySQLサーバとメモリキャッシュシステムを運用してきたが、データ量の拡大に伴い、運用管理にあたる人件費の拡大に悩まされるようになってきたという。そのため、高可用性を保ちながら、成長に伴う作業を自動化する方法を模索した。
誰の口から飛び出したのかは定かではないが、巷ではMySQLにまつわる様々な「都市伝説」がまことしやかに囁かれているようだ。恐らくMySQLに対する理解が低い人や、MySQLがあまり好きではない面々によってFUDっぽく言われているのだと思うが、世の中にはそのような「都市伝説」を真に受けてしまう人が居るのもまた事実であである。MySQLにおける昨今の開発スピードには目覚ましいものがあり、MySQLは性能・安定性・使い易さ共に進化し続けている。(特に先日リリースされたMySQL 5.5は性能・安定性・使い易さを両立している優れたバージョンだ!!)しかし「都市伝説」で語られることは総じて「MySQLはダメな子ちゃん」であるという烙印を押すものばかりであり、MySQLerとしてはそのような言われ無き汚名を全身全霊をもって晴らさなければならない使命を背負っている。そこで、今日はMySQLについて語られ
オラクルのサン買収に関し、MySQLのオリジナル開発者の Monty こと Michael Widenius 氏が、MySQLユーザに向け、支援を要請するメッセージを出しました。 http://monty-says.blogspot.com/2009/12/help-saving-mysql.html (1)これまでに起こったこと(要約) (2)オラクルが約束「しなかったもの」は何か (3)これまでのオラクルの、オープンソースへのふるまい (4)この情報を広めて欲しい (5)EUへの email のサンプル が書かれています。 オラクルによるサン買収が発表された後、これまでにも何度となくメッセージを発信してきた Monty ですが、今回のメッセージはこれまでになく強いメッセージであるという印象を受けました。 以下簡単ですがまとめてみます。あくまで参考程度にしていただくことにして、正確なこと
MySQL Cluster開発者の一人であるFrazer Clement氏がその歴史についてとても興味深いエントリを自身のブログで綴っているのだが、いかんせん英語の長文で日本人には辛いかも知れないので今日はその日本語訳を皆さんにも紹介しようと思う。進化の歴史とその結果生じた構造を知ることにより、MySQL Clusterの仕組みに興味を持って頂けると幸いである。(わかり辛いところにはところどころ訳者による注釈を入れてある。ただし翻訳は結構大ざっぱなので、英語が達者であれば細かいニュアンスなどはオリジナルのエントリを参照して頂きたい。なお、日本語訳をすることに関してはFrazer氏の了解を得ているのであしからず。) NDB(MySQL Clusterの略称。元々はNetwork DBという名称であった。)の開発の正確な歴史について、きっと他の誰かのほうが上手く解説できると思うのだが、限られて
先月発売された書籍「Linux-DBシステム構築/運用入門」は、なかなか上々の売れ行きとなっているようです。Amazonではしばらく「1-2ヶ月待ち」の状態が続いてしまっていたのですが、最近になってようやく解消され、容易に入手できるようになっているようです。Amazonの在庫切れ問題がひと段落したところで、これからは書籍のサポート的な情報を書いていくことにします。 まず、本書を購入された皆さまありがとうございました。結構な数の方がBlogやTwitter等で、この本をほめてくださっていることに大変感謝しています。まだ本自体の認知度が低い(存在自体を知らない顧客も多い)ので、普及活動をしつつ、これからも読者の期待に応えられる記事を書いていきたいと思っています。 最初は、よく見かけることの多い「メモリ管理」の話題を取り上げようと思います。第12章では、メモリ管理とスワップ領域に関する解説をして
来年も作りたい!ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く