こんにちは。谷口です。 ITエンジニアの転職やプログラミング学習に関する仕事をしている私ですが、学生の頃は文系の学部に所属し、プログラミングには全く触れたことがありませんでした。 新卒の時はそんな状態で、自分に特性があるのかどうかもよく分からないまま、面接をしてくれた人事担当者の「プログラミングは研修を受ければできるようになるから大丈夫」の言葉を信じて、受託開発をしている企業に入社しました。 そして新人研修で生まれて初めてプログラミングに触れ、勉強する中で、一歩進もうとする度につまずき、進んだと思ったら二歩前に覚えたことを忘れ、ということを繰り返しながら、何とか働いてきた時期がありました。 プログラミングのプの字も知らなかった新人の頃にどこでつまずいてきたかを思い出しながら書いてみたいと思います。 ■代表的なつまずきポイント ◆1.Hello Worldの段階からつまずく 研修で最初に勉強

今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照／更新クエリを実行しています デ

Amazon Aurora 東京ローンチイベント 10/Nov/2015 発表資料 - RDS for MySQL から Aurora への移行に関する共有 事前に読んでおくべき資料 - Amazon re:Invent (DAT405) Amazon Aurora Deep Dive http://www.slideshare.net/AmazonWebServices/dat405-amazon-aurora-deep-dive - AWS Black Belt Tech Webinar シリーズ 2015 - Amazon Aurora http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-2015-amazon-aurora - RDS for AuroraとRDS for MySQL5.6のPar

この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン