プログラミングの勉強にと思ってTwitterボットを作ってみたら、ことあるごとに「あっ、これもボットになってたら便利そう」と思うようになってしまって、さらにいくつか作るという流れ。それなりに便利なのができると、ほっといてもフォロワーが増えていくのが楽しくなってしまう。今まで作ったボットのまとめ。
TLでフォロワーのみなさまと盛り上がったのがきっかけで、初めて作ったTwitterボット。ボットをフォローしているユーザが深田久弥の著書「日本百名山 (新潮文庫)
」に含まれる山名を含んだつぶやきをすると、同書の中からその山の特徴などを表した部分をリプライする。また、1日1回7：00にはランダムに抜粋をつぶやく。
最初はPHPで書いたのだがいつの間にかうまく動かなくなったりして、Rubyで書き換えた。ソースコードはGithubに上げてある。作った頃はRubyのエコシステムが良く分かってなくて、bundler使わずにやってたりして、自分でもどうやって動いてるのか理解してなかったなあｗ リプライする山名にどういう傾向があるのか気になったので、山名ごとにリプライ数を集計する仕組みも作ってみた。基本的に富士山がダントツに多いのだが、例えば最近だと吾妻山や蔵王山(火山活動活発化)、立山(アルペンルート開通)といったように、急にリプライ数が増えた山があると、大体そこでは何かあったということが分かって面白い。
毎朝7：30前後に、その週末に天気がいい(登山日和になりそうな)山を地域ごとにツイートする。 土曜と日曜それぞれ分けて判断するようになっている。祝日などの連休にも対応させたいが、めんどくさそうなので先送りしてしまっている。
山名を含んだメンションを送ると、少し詳しい天気予報をリプライしてくれる。
こちらも最初はPHPで作ったが今はRuby製。天気が一覧で見れるページも定期的に生成している。 深田久弥botと違ってうざくない作りなのもあってか、フォロワーが4600以上(2015年5月)もいて、自分の作ったボットの中では一番多い。
はてなブックマークが一定数以上付いた日本語以外の(正確には、タイトルと本文に全角文字を含まない)記事をツイートする。Yakstという主に英語のブログ記事などを翻訳して公開するサイトを解説しているのだが、そのネタ探しの足しになるかと思って作った。
誰得なのかよく分からないボットなので、フォロワーは少ないw
仕事でAWSを本格的に使い始めたので、手軽にAWSのステータス情報を知れる手段がないかと思ったのだが、いい感じのボットがなかったので作った。時刻を日本時間に直し、定型的な文言はなるべく日本語に翻訳するようにしている。GCPとかのボットもなければ作ってみようかな。
ちなみに、プロジェクトでHipchatやSlackなどのチャットツールを使っている場合、それぞれのTwitter連携機能を使ってこのボットのツイートを拾うようにすれば、AWSの障害情報が流れてくるようになって便利。
ボットを作ると、プログラミングの基礎もだが、Twitter APIやスクレイピングのテクニックなど、作るボットに応じて色々な技術が必要とされるので、新しい言語を覚える人とか、そもそもプログラミング初心者にはもってこいの課題になる。オススメです。
題の通り、「SQLパフォーマンス詳解」(原文タイトルSQL Performance Explained)という本を翻訳しました。PDF版と印刷版が上記サイトから購入できます。
(追記 2017年9月から、渋谷のBOOK LAB TOKYOさんでも印刷版を販売していただいています。輸送コストの関係で、サイトから購入するより若干安くなっています)
リレーショナルデータベースにおいて、SQLとインデックスがどのように関連し、どのようにすればSQLのパフォーマンスを良くできるのかを解説した本です。特定のデータベース製品に焦点を当てた本は多数ありますが、この本ではOracle Database、PostgreSQL、MySQL、SQL Serverの4つのメジャーなリレーショナルデータベース製品を同時に扱っていて、それぞれのクセや特徴も分かるように書かれている点が非常にユニークになっています。また、ORMが生成するSQL文の違いなどにも言及されています。
前書きにもあるように、データへのアクセスパスを知っているのは他ならぬ開発者なので、開発者自身がSQLとインデックスについての知識を深めなければ本当の高速化はできない、というのが著者の考えのようですが、もちろんアプリ開発者だけでなくインフラエンジニア、データベースエンジニアの方々にもおすすめできる内容だと思います。
目次とそれぞれの内容は以下の通りです。
- 第1章 インデックスの内部構造
- インデックスとはそもそも何か、インデックスはどのような仕組みか
- 第2章 where句
- where句とインデックスの関連、例えば=を使った場合、likeを使った場合など演算子の違いによるインデックスの活用方法など
- 第3章 パフォーマンスとスケーラビリティ
- インデックスの作り方の違いによるパフォーマンスとスケーラビリティの違い
- 第4章 結合処理
- 第5章 データのクラスタリング
- データのクラスタリング(HAクラスタなどではなく、いわゆるクラスタリングインデックスのこと)
- 第6章 ソートとグルーピング
- ソート(order by)やグルーピング(group by)とインデックスの関連
- 第7章 部分結果
- MySQLで言うlimitやPostgreSQLのfetch firstのような、結果の一部分を取得するSQL文とインデックスの関連
- 第8章 データの変更
- update, insert, deleteといった更新処理とインデックスの関連
- 付録A 実行計画
- 各データベース製品での実行計画の表示方法とその読み方
既にご存知の方もいるかもしれませんが、Use The Index, Lukeという名でほぼ全文がWeb上で公開されています。とはいえWeb上で通しで読むのはかなり辛いですし、PDFあるいは印刷版を購入いただければ、作者・訳者とも嬉しい限りです。
私は、Yakstというサイトで海外のブログ記事などを翻訳して公開するというのをやっているのですが、原著者(Markus Winandさん)が書かれたブログ記事を翻訳させてもらったのがきっかけで、この本の翻訳をやることになりました。オンライン販売だけの予定なので書店に本が並ぶわけではないとは言え、自分が訳した本が人に読まれることになるというのは、不思議な感覚です。Markusさんはオーストリア人で英語のネイティブスピーカーではないこともあり、原文は非常に分かりやすい英語で書かれているのですが、それでも翻訳の難しさ、自分の未熟さをひしひしと感じました。素晴らしい本を書いてくださった原著者のMarkusさん、私のつたない訳を丁寧にレビューしてくださった@matsuuさん、ありがとうございました！
訳の問題など、ご意見ご感想ありましたら@dblmktまでいつでもご連絡ください。
ちなみに、海外の有益な技術系ブログを翻訳して公開しているYakstで、翻訳を一緒にやっていただける仲間も募集しておりますので、良かったらそちらも是非よろしくお願いします。
ふう、MySQL Casual Talks Vol. 7行って参りました。前回は自分が発表者でもあったので、正直なところ他の人の発表を聞く余裕はなく(汗) 今回は、同僚の発表もあったので楽しみにしていったら、相変わらずの濃ゆい話が盛りだくさんで、非常に楽しめました。毎度の事ながら、@myfinderさん始め、会場提供・準備していただいたLINE
のみなさま、Oracleのみなさまに感謝です。
- GAから半年なのに誰も使ってない
- アメリカのイベントでは、MySQL Fabricだけに布がプレゼントされた(白目
- Fabric対応コネクタが各種言語向けに用意されてる
- yokuさん謹製fabric対応mysqlクライアント
- fabricとConnector/C経由で通信する
- ro(スレーブ、分散される)とrw(マスタ、当然1台)のモードがある
- マスタを落とすとちゃんと切り替わりますよ(デモ)
- 3年ぐらい運用、結構消耗
- MHA組んでおく
- ENIをつけておいて、マスタ切り替えはそれを付け替える
- Mackerelでモニタリング
- バックアップスレーブでsnapshotとってる
- スレーブ作る
- snapshotから作る
- dumpから作る
- 落ちたら捨てる前提(信頼性落とす、ダウンしたら捨てる)
- 取りあえず2セット作って入れ替える、が可能なのがよい
- スレーブのオートスケールは結構難しい
- warmup難しい
- 5.7はできそう(buffer poolリストア)
- データはEBSに置いている
- IOできなくなって死ぬことがある
- ヘルスチェック工夫しよう
- RDSはちょっと高いけど楽
- フェイルオーバーが長い
- 可用性がちょっと微妙でやめた(2012年ぐらいの話なので古いかも)
- ELBはDNSベースなのでちょっとってことでhaproxyで分散している
- もはや自前でMySQL運用する時代じゃないよね
- Oracle(200セット), MySQL/Percona(300セット)を運用中
- Percona Live 10月にロンドンで開催されたのに参加してきた
- XtraDB Cluster
- ActiveActiveの構成、高い冗長性
- ヨーロッパでは広く普及
- OpenStackのバックエンドに使われている
- 本家のGroup Replicationと似てる
- どのノードに書いても同期レプリされる
- MySQL Clusterよりは本家MySQLに近くてハードル低い
- Writeのスケールはできない(MySQL Cluster使おう)
- SST(丸ごとコピー)、IST(差分)でDonorからデータを送る
- ノードへの分散はHAProxyとか使う
- ヘルスチェックの仕組みもXtraDB型に準備されてる
- 書き込みは楽観的ロック
- コミットしてノード間の情報が食い違ってるとコミット時にエラー
- 従って書き込みはできるだけ1台がいい
- オンラインalterはできない(今後サポート予定)ので、ローリングで変更していく
- ブログ記事
- 2005年 4.0.25 -> 9年 -> 5.0.96にバージョンアップ
- @tnmt 氏がカジュアルに5.6バージョンアップを指示するイシューを投げたところから始まった
- しかしやる事になった時は何にも知識ありませんでした
- たくさんの爆弾が仕込まれていた。。
- マスタとスレーブの食い違いなどなど
- ハードもソフトも古い
- 検証の過程で色んなバージョンをインストールしたので、MySQL-AllStarというbox提供してます(4.0から5.6まで全部入り)
- 結局5.0まで上げることに
- 6/20 イベントがあるとレンタルサーバのアクセスが減るからwという理由でメンテ実施
- ダンプからリストア、切り替えまで同じタイミングでやった
- insertを実行するとbinlogが壊れることが発覚
- 失敗として切り戻し
- 5.0系を特定のgccでコンパイルすると起きるバグ？
- gccの最適化のレベルによってテストが通ったり通らなかったり
- その後別のバグ発生
- rpmbuild中に必要なファイルが消える
- 邪魔してたパッケージ消してビルド成功
- 8/22無事バージョンアップ成功
- 4.0に入っていたデータの一部がリカバリできなかったのは手動で戻した
- ブログ記事
- ギフトとかカードの情報が増えまくる
- 1日数十GB、論削だけで物理削除してなかったり
- 削除するのではなく、必要なデータだけをINSERT SELECTで抽出してテーブルを作り直すと速い
- deleteしてもテーブル容量減らない(MVCCのバージョン管理のため)
- pt-online-schema-changeでテーブル再構築
- レプリ遅延
- truncateすると遅れる(deleteより遅い)
- バッファプールを大きく使ってると遅くなるというバグ
- 結局deleteしました
- ブログ記事
- パーフェクトRuby出しました
- Rubyの人はRedis使う人多い(sidekiqで)けどQ4M
- shinq
- ActiveJobを利用
- Rails 4.2に入る予定のキュー機能
- ブログ記事
- DBのバックアップだけじゃなくてリストアも繰り返しやって、復旧可能性を担保
- バァーン、バァーン、バババァーン
@ijin さん ConsulでMySQLのフェイルオーバー
- 元ネタのブログ記事
- consulはraftを使ってcap定理のcpを実現している
- MHA発動時に実行されるfailover scriptでconsulのAPIを叩いてマスタのDNS名を変更する
- consul event
- eventをノードに伝えると伝播される(no guarantee)
- watchで検知してスクリプトを動かす
- consul templateを使いましょう
- my.cnfをチューニングする
- innodb_flush_log_at_trx_commit=2で結構上がる
- innodb_flush_method=nosync/O_DIRECTでも上がる
- この2つのオプションさえちゃんとやっておけばおk
- データ量に応じてinnodb_buffer_pool_sizeも
- ブログ記事
- 圧縮効いて8〜6割の性能
- 容量的には半分ぐらいに圧縮できた
- 圧縮伸長でCPU食う(元々ioDriveではCPUバウンドだけどさらにきつくなる)
- いつもの
- 特に進捗なし
- Raspberry piでN:1 replication動きましたw
