第32回 PostgreSQL 勉強会(2015年10月10日)の資料です https://www.postgresql.jp/wg/shikumi/pgstudy_32/view
本日、 gh-ost のオープンソース・リリースを発表します。GitHubの、トリガーレスなMySQL向けオンライン・スキーマ・マイグレーション・ツールです。 gh-ost は、MySQLテーブルの修正が必要な、進行中の継続的なプロダクション変更に伴って私たちが直面する問題に答えるために、ここ数ヶ月で開発されました。 gh-ost は、負担が小さく、制御しやすく、監査しやすく、操作が簡単なソリューションを提供することによって、現在のオンライン・テーブル・マイグレーションのパラダイムを様変わりさせます。 MySQLテーブルのマイグレーションは、よく知られた問題で、2009年からはオンライン・スキーマ変更ツールによって対処されてきました。ハイペースで成長するプロダクトに伴って、データベース構造の変更が必要になります。列やインデックスなどの追加・変更・削除は、デフォルトのMySQLの動作を妨げる
こんにちは、三苫です。 この記事はTECHSCORE Advent Calendar 2014、5日目の記事です。 近年、Rails複数DB Casual Talksが開催されるなど、Railsでも複数・異種データベース混在したシステム構成は何ら特別でなものではなく通常の開発でカジュアルに選択される構成だぞという機運が高まっています。 togetterで参加者の反応を見ても、「establish_connectionは基本」「前にも見たぞこのスライド」など、おおむね知見が業界全体に広まりつつある事がわかります。 本記事はRails複数DBがまだカジュアルではない時代、マルチテナントシステムのデータベースをMySQLからPostgreSQLに、各サブシステムは縮退しつつも、システム全体としては無停止で移行を行った記録を共有するためのものです。 移行したシステムの前提 マルチテナントシステム
Auroraがそこそこ浸透してきたように感じなくもないですが、そのわりに情報がまだ少なめなのは、それだけ従来のMySQLと変わりなく扱え、性能も十分満足いくものだろう、という証なのでしょうか。 中の人も、パラメータチューニングは済んでいるので、基本的にはスケールアップで対応してください、と申しているように、かなり良い調整がされているようです。しかし、インフラエンジニアというかエセDBAたるもの、何がどう調整されているかを具体的に確認しなくては気がすまないため、整理してみたわけです。 デフォルトの設定 パラメータグループについて Auroraのパラメータは従来と異なり、ノード毎の設定である『DB Parameter Group』と、クラスタ内共通の『DB Cluster Parameter Group』の2つに設定が分かれます。 必要に応じてクラスタの方に、文字コードやレプリケーション周りな
欲しいデータを取得するくらいにはSQL書けるし、システム要件を満たすくらいにはテーブル設計は出来る、そんな僕が中級者を脱するために勉強している内容を備忘録的に書き綴ります。 予約語は大文字 その他は小文字で記述しています。 あー、インデックスね、はいはい。作ると参照が速くなるやつでしょ? そのくらいの知識でしたが、INDEXを適切に運用する上で原理など理解していないと、意味の無いINDEXを作ってしまう事があるので勉強しました。 INDEXとは 今回は多くのRDBMSでサポートされているB-TreeINDEXについて解説します。 B-Treeは以下のような形式でデータを保持しています。 ヘッダブロックでは大まかな値の範囲を保持しており、ブランチブロックではさらに細かい範囲を保持 リーフブロックでは実際の値と行への物理的な位置を保持しています。 INDEXが作成されている事で並び替えが速くな
コードレビューで土日に安寧を ソーシャルゲームは、ユーザアクセス集中と、それに伴うユーザデータ増加によって劇的に負荷が上がり、(主に土日に)サービスに影響を与えがちです。 問題があるコードは、たとえ負荷テストを行っても、作成したシナリオによっては見つけられない可能性もあります。 そういった見えない不安を払拭するという意味でも、コードレビューは重要だと思っています。 【ステキポイント】 ・ ソースを見ることにより、時限爆弾が土日に爆発するのを解除 ・ スキル共有によってメンバーがレベルアップすることにより、土日に爆発する時限爆弾の設置確率低下 まぁまとめると これに尽きます(4歳の息子談) 今は、gitのプルリクエストという強力なレビューツールもあり、敷居がかなり低くなったのでオススメです! チェックするポイントは5つ コードレビューを行うにあたり、*「どんなところをチェックすればいいのか分
MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。 PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。
スケーリング=時速160㎞で走行しながら自動車の全ての部品を取り替えること -Mike Krieger Instagramの共同設立者@ Airbnb OpenAir 2015 Airbnbのピーク時のアクセス数は、毎年夏のピーク時で見ると年率3.5倍で増加しています。 2015年夏の旅行シーズンを前に、Airbnbの基盤チームは、夏季のアクセスで予想されるデータ通信量に対処するため、データベースのスケーリングで忙殺されていました。中でも特に全体への影響が大きかったプロジェクトが、特定のテーブルを、アプリケーションの機能に従ってそれぞれのデータベースに分割することを目的としたプロジェクトでした。これは通常、アプリケーション層のフォームの変更やデータ移行、データの整合性を保証する堅牢性テストなど、最小限のダウンタイムで多大な技術的投資を必要とするものです。何週間もかかるエンジニアリング時間
はじめに 研究室で借りているさくらのVPSがあって、研究で使うアプリケーション以外にgitlabとかjenkinsを動かしている。Dockerをローカルでしか動かしたことが無かったので、リスクの低いこういうところで実際にDocker使ってみる。 これまでは AnsibleGalaxyで人気のRole を探して中身も読まずにインストールしちゃっていたけど、さっき触ってたらどうインストールされてるのか混乱したのでDockerで分離できたら良さそうっていうのが2つ目の理由。 準備 環境はさくらのVPSにCentOS 6が入ってます。 https://docs.docker.com/installation/centos/ を参考にDockerをインストール。 # yum update # cat >/etc/yum.repos.d/docker.repo <<-EOF [dockerrepo]
自動化。 どうせ誰も見ないって。 show create table 見たほうが早いし。 mysqldump --no-data -uroot --database employees をリポジトリに入れてバージョン管理しとけば良いと思うけど、 何らかの文書化が必要な場合は毎回差分を修正するより全部出力した方がラク。 カラム名日本語がよければ適当に as で別名つけるとよい。 mysqlの場合 #!/bin/bash MYSQL="mysql -B -uroot" DBNAME="employees" TBLSQL=`cat << EOD SELECT TABLE_NAME, TABLE_COMMENT FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = '$DBNAME' AND table_name LIKE '%s' EOD` CO
今回のテーマはデータベースエンジニアの必須知識の1つである「正規化」です。正規化は、リレーショナル・データベースのテーブル設計を行ううえで非常に重要なテクニックであり、データベースを設計、実装したことのある方なら一度は正規化に触れているのではないでしょうか。 それほど基本的な知識であるにもかかわらず、正規化を説明できる人はなかなかいません。多く聞かれるのが「何となくテーブルを作ると自然に第3正規形になる」とか「実務上は第3正規化まで行えば問題ない」というものです。 ではなぜ「第3正規化まで行えば問題ない」のでしょうか。本稿ではひととおり正規化について確認しながら、あまり触れられることのない第3正規化より先の正規化を紹介して、この疑問に答えていきたいと思います。 正規化の位置付け 正規化は、データベース設計全般にかかわる基礎知識ですが、特に論理データモデリングの作業の中で必要になります。本稿
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く