MySQL 8.4 LTS登場！！
記事を書くのが遅くなってしまったが、先日MySQL 8.4シリーズが登場したので紹介をしておこうと思う。新機能の解説については機会を改めて書くとして、今回は主にアップグレードにまつわる重要なポイントを書き記しておく。 LTS = Long Term Support 以前の記事でも紹介した通り、MySQL 8.4はLTS = Long Term Supportのバージョンとなっている。長期間サポートするために互換性を最大限保証するバージョンである。前のメジャーバージョンであるMySQL 8.0シリーズのように、シリーズの途中で互換性が破壊されるような変更が入ることは基本的に無い。「バグ修正のためにどうしても仕様を変えなければならない」というような事態が生じる可能性はゼロではない。なので絶対に互換性が保たれるとは言い切れないところであるが、基本的には仕様変更はない方向で今後リリースされていくこ
残業は悪か？あるいは日本人の生産性が低い最大の理由
最近、残業をするのは社員が悪いというような記事を見たので、一言言っておこうと思う。 残業常習者が会社を壊す｜トンデモ人事部が会社を壊す｜ダイヤモンド・オンライン なぜ残業が常習化するか 最初に結論を言ってしまうと、経営が悪いからだ。経営と言っても事業戦略ではなく、組織運営という意味での経営だ。残業が常態化しているということは、組織運営ができていないことの証拠だと言っていいだろう。 なぜ残業の常態化が経営の失敗だと言えるのか。残業が常態化しているということは、組織がこなすべき仕事に対して人員が足りないことが原因として上げられる。人材の確保に失敗しているのは、経営側の失敗だ。 もし社員がダラダラと残って働いているのだとしたら、社員が何をすべきかということがトップダウンで明確に指示されていない兆候かも知れない。何をもってその日の業務が終わりだ判断とすれば良いのか。それは上司からの指示、つまり担当
MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
MEANスタックは破壊的か
最近、MEANがイイという話をチラホラと耳にする。先日も次の記事がはてブで話題になっていた。 MEAN(MongoDB, Express, AngularJS, Node.js)スタックが優れている理由 - Mozilla Open Web Day in Tokyoを終えて - albatrosary's blog この記事の冒頭では、MEANはLAMPに変わる技術として紹介されているが、果たしてそれは正しいのだろうか。（この記事では、LAMPを例にとりつつJavaがどうのという記述があるので、恐らくはLAMPではなく既存のリレーショナルデータベースを用いたアーキテクチャ一般について述べたいのではないかと思う。）MEANについて少し思うところがあるので、今日はMEANの可能性について書き綴っておこうと思う。ただし、私自身MEANスタックと呼ばれるシロモノは使ったことがなく、構造を理解した上
開発スピードアクセル全開ぶっちぎり！日本よ、これがMySQL 5.6だッ！！
米国で行われているMySQL Connectというイベントで、ついにMySQL 5.6 RC（リリース候補版）が発表された。リリース候補版ということは、これが次の正式版になるということだ。MySQL 5.5は5.1から凄まじい進化を遂げたバージョンであった。だが、MySQL 5.6はさらにそれを上回る進化を遂げている！正直ここまでの進化を誰が予想しただろうか、いや誰も出来なかったであろう。これまで、α版が出たときから何度か新機能について紹介してきたが、今回改めてMySQL 5.6の新機能を振り返ってみようと思う。すべてまとめるともの凄い内容だ。興奮して夜も眠れなくなること請け合いだ。MySQLの進化が止まるのでは？などという心配は吹き飛び、もはやもうちょっと小出しにしなくて良かったのか？と心配してしまうレベルである。 それではMySQL 5.6の新機能について紹介していこう。 InnoDB
GUI開発におけるコロンブスの卵 - KSCS
先日、とあるUI技術がひっそりとデビューした。このUI技術 - KSCS - を手がけたコンサルタントは友人なので、以前彼の取り計らいでKSCSについて話を聞く機会があった。KSCSは「なるほど！」と唸らされるアイデアを用いていながら、デビューしたにも関わらず巷であまり話題になっていないようなので、このブログで皆さんに紹介しようと思う。 KSCSの凄いところは、ズバリその言語構造そのものである。プログラム言語の紹介と言えばやはりまずはHello Worldからだろう。というわけで以下のソースコードを見て欲しい。 K(_hello){ U{ R(#m,"???") Rb("Push"){ Bs{ #m?="Hello, world!"; } } } } 恐らくこのソースコードを見て、プログラマ諸氏は「ナンジャコリャァァァーーーッ？！」と思うのが素直な感想ではないだろうか。私も初めて見た時はさ
そもそも日本のIT業界が残念だ。
梅田望夫氏のインタビューに対して様々な反応が上がっている。 日本のWebは「残念」 梅田望夫さんに聞く（前編） (1/3) - ITmedia News Web、はてな、将棋への思い 梅田望夫さんに聞く（後編） (1/3) - ITmedia News 俺に言わせてみれば、Webだけでなく日本のIT業界そのものが残念だ。 俺は、2000年に大学院を卒業してからSun Microsystemsの門を叩いた。なぜSun？という疑問は色々とあるだろうが、いずれにしても外資系が良かった。日本企業に勤める気にはならなかった。なぜか？ 日本のIT業界が残念なことになっていたからだ。 周りを見渡してみよう。一体どれだけの（人気のある）コンピュータ製品が日本製だろうか。俺は今、MacBookでこのブログを書いている。組み立てはどこの国で行われたかは知らないが（たぶん台湾あたりか？）設計したのはアメリカの企
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
プログラマ35歳定年説に喝！
DevMeetingで感じたことなのだが、MySQLの開発者にあまり若い人は居ない。日本では「プログラマ35歳定年説」などという俗説がまことしやかに囁かれているが、逆に35歳以下のプログラマを見つける方が難しいという様相である。かのJim Starkey氏などは60歳の手前であるが、今でも現役でプログラムをガンガン書いている。（正直言って驚異的ですらある。。。） 歳を取ると身体に無理が利かなくなるなどのディスアドバンテージはあるが、その代わりこれまでに培った経験を活かすことが出来るであろう。特にRDBMS のような複雑なプログラムにおいては、そのソースコードについてよく精通している必要がある。ソースコードはおよそ100万行ほどあり、一人ですべてを網 羅するのはほぼ不可能である。しかし開発の過程においては、特に性能改善やバグ修正、機能追加などでは、既存のソースコードを参照する必要が多々ある。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
