『アメーバピグにおけるDB構成&対応記』
2ヶ月前にインフルエンザとウィルス性胃腸炎でひどくダメージを受けた増田(@masudaK)です。アメーバピグは2009年2月に始まったサービスで、FLASH・Javaで作られています。そして、データストアにMySQLを用いてます。本記事では、わたくしが2年ほど見続けているアメーバピグのDB環境について構成や、日々どのようにして問題と向き合っているかを紹介したいと思います。インフラ寄りの内容が多いため、アプリ寄りの話は弊社生沼の資料を御覧ください。 1. 構成と規模 1.1. 構成 まず構成ですが、読み書きはすべてマスターへ行うようにしています。そのため、スレーブには参照を向けず、ホットスタンバイとして使っています。バージョンに関しては2012年中旬までは5.0を使ってましたが、DC移転にあわせて5.5にあげました。ロック機能を用いたシャード構成をしてまして、2014年3月現在6シャードにな
MySQL5.5でパーティショニング使って時系列のデータを分散する - 256bitの殺人メニュー
はい、乙カレーさまです。寒い日が続きますね。 そしてMySQLも続きそうな私です。 前回はトリガをやってみましたが、今度はパーティショニングをしてみます。 パーティショニングとは パーティショニングは、特定のカラム情報を使って、テーブルを論理的／物理的に自動で分ける事で管理を簡単にしたり、パフォーマンスを確保する機能のことです。例えば今回は、更新日時でパーティショニングを行うことで、特定期間のデータを削除する等の運用が簡単になります。 パーテションの設定 プライマリキーの設定 まず既存のテーブルの場合は最初にパーテションを行うカラムがプライマリキーが含まれていないといけないので貼り直します。 mysql> ALTER TABLE usermaster_cs DROP PRIMARY KEY, ADD PRIMARY KEY(user_id, upd_datetime); 新規テーブルの場合
DB設計の難しさ
今日は徒然なるままにDB設計について思っていることを並べてみようと思う。 ようやくWEB+DB Pressの次号の原稿を書き終えた。2年間の連載であるが、来年はプライベートが忙しくなる予定なので、連載はこれにて終了とさせてもらうつもりである。 「なぜ人はリレーショナルデータベースを使いこなせないのか」 このところ執筆や講演を通じてリレーショナルモデルについて説明する機会を色々頂いているが、それらの活動の根源となっているのが、この素朴な疑問である。その疑問をパワーにしてこれまで活動を行なってきた。 現時点での自分の回答は「データベース設計が難しいから」である。もちろんリレーショナルモデルそのものの難しさというのもあるが、それよりは「適切な使い分けができていない」ということが大きいように思う。言葉を変えると、リレーショナルモデルを適用すべきデータとそうでないデータの判断ができていないからDB設
MySQLを使ったアプリケーションを作るエンジニアが知るべきMySQLの内部構造とは？ | Yakst
MySQLを使ったアプリケーションを作るエンジニアが知るべきMySQLの内部構造について、データベースコンサルティング会社PalominoDBを経営するLaine Campbell氏による回答。MySQLを知るためには何をポイントに学習すればよいのかがよくわかる、DBAや開発者にとっても役立つ内容。 1. ストレージエンジン ストレージエンジンと、永続性、ロック機構、トランザクション処理の振る舞いや分離レベルといったストレージエンジンの基礎となる動きについての理解なしに、MySQL自体やモデルデータのコードをいじるべきでない。それに加えて、InnoDBのクラスタ化されたプライマリキーや、MyISAMの全文検索インデックスのようなコア要素も、極めて重要な情報だ。 2. インデックスのコンセプト 特に以下のような点について。 カバリングインデックス 連結インデックス インデックスを使ったソート
SQLインジェクション対策に正解はない
最近、SQLインジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ まとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。 攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ
タグ検索するならPostgreSQLで決まり！
(Last Updated On: 2018年8月13日)PostgreSQL Advent Calender 2013、13日目のエントリです。 表題の通り「タグ検索するならPostgreSQLで決まり！」です。 追記：JSONの場合はPostgreSQLのJSONB型を利用してタグ検索を行うを参照 RDBはタグが苦手 WebアプリではRDBでは取り扱いづらいデータを取り扱う事がよくあります。タグの管理・検索はその一つです。 RDBはタグ情報の管理・検索をしっかりやれますが、どちらかと言うと苦手な分野です。しかし、PostgreSQLの 配列 GIN（Generalized Inverse Index – 転置インデックス） を使うと簡単かつ高速に処理できます。 PostgreSQLを使うとタグ検索が簡単・高速に実現できますが、Googleで「タグ検索 PostgreSQL」と検索しても
MySQLでカラムやインデックスの追加、削除をするときのロックの話など - (ﾟ∀ﾟ)o彡 sasata299's blog
2013年12月12日14:03 MySQL MySQLでカラムやインデックスの追加、削除をするときのロックの話など すっかり2013年も終わりに近づいてきましたね。さて、今回はMySQLでカラムやインデックスの追加、削除をするときに知っておいた方がいいかなーと思った注意点の話です。 カラムやインデックスの追加、削除を行う際にはテーブルが共有ロックされる まず、カラムやインデックスの追加、削除といったいわゆる ALTER TABLE に相当する処理を行うとテーブルが共有ロック（読み込みのみ受け付け、更新処理は受け付けないというロック）されるという話です。 この辺の話は @nippondanji さんが詳しく書かれています。 漢(オトコ)のコンピュータ道: ALTER TABLEを上手に使いこなそう。 1. テーブルをTL_WRITE_ALLOW_READロックする。このロックは特殊なロック
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
その選択、ちょっと待った！NoSQLデータベースへ乗り換える前に検討すべき3つのポイント
最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。本当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い！！絶対にだ！！」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの
MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店
前回の記事 MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか の続きです。 master : slave = 1 : 1 で参照を slave に分散してもまったく美味しくないわけですが、では参照の負荷分散を行いたい場合の slave は何台で構成するとよいのか考察してみます。具体的には slave 2台の場合と 3台の場合でどちらがお得か。 台数を増やすということは、どこかに障害が発生する確率が高まる、ということです。1台の slave に障害が発生してダウンした場合のことを考えてみます。 slave * 2 → 残り 1台で処理継続 生き残った1台あたりの処理が 2倍になる slave * 3 → 残り 2台で処理継続 生き残った1台あたりの処理が 1.5倍になる たとえば 1台あたり最大 1000qps の処理能力があるとします。sla
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
DBエンジニアのための技術勉強会で発表したスライドを公開しました。
DBエンジニアのための技術勉強会というイベントで、リレーショナルモデルにおけるDB設計について話す機会を頂いた。リレーショナルモデルは非常に重要であるにも関わらず、現場ではないがしろにされてしまっている。その結果、アプリケーションのロジックを上手くクエリで表現できず、開発現場では非効率な開発が行われ、多くの人がデスマ的な状況に追い込まれている。そういう危機意識について、これまで何度か本ブログでも書いてきたし、WEB+DB Pressで連載している動機もその点にある。リレーショナルデータベースはやはりリレーショナルデータベースとして使うべきだ。そのための鍵となるのが、DB設計である。 今回はなんと約2時間の持ち時間を頂いた。リレーショナルモデルについてはこれまで何度か話す機会を頂いたが、2時間というのは最長記録である。それに合わせてスライドもボリュームたっぷりのものになった。過去のスライドと
@nippondanji 氏の「データベース設計徹底指南！！」は神プレゼン！脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件！ - #garagekidztweetz
ツイート今日は、第 1 回のSQL アンチパターンの回から良コンテンツを提供しまくりなエンバカデロ・テクノロジーズさん主催の第 3 回 DB エンジニアのための勉強会に参加してきました。 今回は 漢(オトコ)のコンピュータ道で有名な漢の中の漢、 @nippondanji 氏がデータベース設計を徹底指南してくれるということで、元々 DB エンジニアがバックグランドのわたしとしてはいかないわけにはいかんだろう、と喜び勇んでいってきました！ 内容はというと下記の概要をカバーする内容でした。 リレーショナルデータベース（以下RDB）は登場してからかなりの時間が経っています。その名が示すように、RDBはリレーショナルモデルをベースに考案されたソフトウェアです。しかしながら、未だに現場ではRDBが使いこなされているとは言いがたく、リレーショナルモデルへの理解も進まず、誤った常識が跋扈しているのが現状で
データベースのmasterとslaveの使い分けの話。2014年版 - Hateburo: kazeburo hatenablog
社内で少し話題になったので。 運用上の話はfujiwaraさんの MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店 MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店 をみてください。 最近、新しくサービスができたり、新規機能でデータベースを追加する際には必ず全ての参照をmasterに向けてもらっています。理由は上記のエントリを読んでください。このような構成が取れるのはもちろん性能的にそれで問題ないからです。 新しいハードウェアに、設定されたMySQL、問題のないように書かれたSQLであれば、数千QPSは余裕に、また少し頑張れば数万QPSを一台で賄えます。なので大体のサービスはmaster一台で十分です。 さらにこの考え方を進めて、Webアプリケーションの中で sub d
負荷をかけたままのOracle RACをライブマイグレーションさせたら、トランザクションやクライアントとの接続は無事か？
いまや多くの業務アプリケーションが仮想サーバ上で稼働するようになってきていますが、仮想環境で稼働させるのは難しいと考えられているのがデータベースです。 » Live Migration of Monster Oracle RAC Nodes without Client Disruption? Easy as VMware vSphere! Long White Virtual Clouds データベースに負荷をかけたままVMwareのライブマイグレーションを実行した場合、クライアントからの接続を含めて問題なくトランザクション処理が継続できるのか、ライブマイグレーションにはどれだけ時間がかかるのでしょうか。 それを実際に試してみた記事が、企業向けにアーキテクチャコンサルタントをしているMichael Webster氏のブログLong White Virtual Cloudsに「Live M
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
ストレージエンジンであそんでみた
こうなるはずだったんですがlightningのVGA変換アダプタとmini display portの変換アダプタを間違えて持って行ってしまいましたorz 次回から忘れないように全部まとめてキーホルダーに付けようと思います（´・ω...:.;::..
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
カジュアルにMySQL Clusterを使ってみよう@MySQL Cluster Casual Talks 2013.09
InfluxDB & LevelDB Inside-out
データベース設計徹底指南
