『アメーバピグにおけるDB構成&対応記』
2ヶ月前にインフルエンザとウィルス性胃腸炎でひどくダメージを受けた増田(@masudaK)です。アメーバピグは2009年2月に始まったサービスで、FLASH・Javaで作られています。そして、データストアにMySQLを用いてます。本記事では、わたくしが2年ほど見続けているアメーバピグのDB環境について構成や、日々どのようにして問題と向き合っているかを紹介したいと思います。インフラ寄りの内容が多いため、アプリ寄りの話は弊社生沼の資料を御覧ください。 1. 構成と規模 1.1. 構成 まず構成ですが、読み書きはすべてマスターへ行うようにしています。そのため、スレーブには参照を向けず、ホットスタンバイとして使っています。バージョンに関しては2012年中旬までは5.0を使ってましたが、DC移転にあわせて5.5にあげました。ロック機能を用いたシャード構成をしてまして、2014年3月現在6シャードにな
要導入検討！PHP用のDBマイグレーション·Phinx MOONGIFT
PhinxはPHP製、MIT Licenseのオープンソース・ソフトウェアです。 Ruby on Railsを使っていて他の言語に戻れない一つの理由がデータベースのマイグレーションです。一般的に煩雑になりがちなデータベースのスキーマ管理が適切に管理されるようになります。そんなマイグレーション管理をPHPに提供してくれるのがPhinxです。 最初にinitを実行して初期化します。DB接続情報を記したYAMLファイルが生成されます。 マイグレーションファイルはこのようにPHPのコードになっています。 実際の書き方の例。 テーブルを取ってきて、addColumでフィールドを追加し、saveを実行したタイミングでSQLが実行される仕組みです。upとdownを書くことでDB構造変更を差し戻すことができます。環境も複数定義でき、MySQLまたはPostgreSQLをサポートしています。 MOONGIF
PHPMigrate - PHPでマイグレーションツールを作った - オープンソースこねこね
デプロイツールに引き続き、今度はPHPでMigrationツールを作りましたので、記事を書きます。 PHPMigrate - https://github.com/kohkimakimoto/phpmigrate フレームワークとMigration 最近のWebアプリケーションフレームワークを使えば、まあだいたいMigrationの機能ついてくるんですよね。でもフレームワークに組み込まれているものだと、Migrationを実行するためにアプリを実行環境にデプロイしないとならなかったりします。Migrationとメインのアプリのコードがひとつのプロジェクトとしてフレームワークで規定された構造にパッケージされているので、Migrationのコードだけデプロイするというのはなかなか難しいものがあります。 Migrationで変更するDBのスキーマは実運用上だいたいカラムの追加やテーブルの追加がほ
PHPで気軽にテーブルスキーマをマイグレーションするツール - Qiita
マイグレーション？ マイグレーションは一般的には 移行する という意味になります。 WEB開発界隈では一般的にマイグレーションツールというと、 テーブルスキーマの更新などをソースコードレベルで管理運用できるようにするツールのことを指すことが多いです。 Ruby on Railsで開発を行った事がある人などは馴染みが深いかもしれません。 PHPでは？ 大丈夫です、PHPにもちゃんとあります。 symfonyが利用するコンテナ doctrin にはmigration機能が用意されています。 cakePHPだってbundleとしてmigrationツールは用意されています。 今流行りの高速フレームワークphalconにもdevtoolsという開発ツールの中に用意されています。 それぞれ使い方などは異なりますが、ソースコードレベルでテーブルスキーマを管理することが可能です。 そんな有名なPHPフレ
初心者による初心者のためのdoctrine : tech.kayac.com - KAYAC engineers' blog
初めまして。社内にいるほとんどのプログラマーがpropelの中いきなりdoctrineを学んだピチピチ平成生まれ(20歳)、新卒のitaniです。 symfonyを学んだときに、こんな記事があったらいいなぁと思ったので書くことにしました。 というわけで、symfonyを触ってまだ間もない僕が、今回はdoctrineを使ってDBの基本操作を紹介します。 ※symfonyのversionは1.4を使用します。 DBの準備 まずはDBの準備をします。 symfonyを使ってDBを作るにはまずスキーマを作らなければいけません。 スキーマを作る方法は２つあります。 １、自分でschema.ymlを書く config/doctrine/schema.ymlにテーブルの構造をYAMLフォーマットで書きます。 //今回使うDBのschema.yml User: columns: name: { type:
RDBMSに関する典型的な誤解が絶えないという現実
新入社員必読、データベースの基本を理解しよう - データベースはなぜ必要なの？：ITproという記事に対するブクマで次のようなIDコールが来た。（現在はコメント返しへのお礼が入っているので、文字数制限のためオリジナルのコメントは少し切り詰められている。） "リレーショナルデータベースはすべてのデータを2次元の表形式で表現"こういうのもリレーションが2次元構造という誤解の一種なんだろうか。id:nippondanjiさんが書いてたような。 さて、この疑問に対する正解は如何なるものだろうか？ つい先日「7つのデータベース 7つの世界」の書評で書いたばかりだが・・・ 言うまでもなくその通りである。 リレーションが2次元的な構造を持っているというのは典型的な誤解だ。（ちなみにリレーションの次元は属性の数に等しい。n個の属性があるリレーションはn次元。）リレーショナルモデルについてちゃんと学習してい
ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift
最近発売された技術評論社のムック「データベース徹底攻略」に寄稿しました。 この本は、データベースのための本ということで、データベース設計、SQL、MySQL、Redis、MongoDB、Redshiftという代表的な要素技術についてのまとめとなっています。各プロダクト(MySQL、Redis、MongoDB、Redshift)については、現場で実際に本格的に使われている方々による記事なので大いに参考になると思います。 私は冒頭のまとめ記事を寄稿しました。詳細はぜひお手に取って読んでくださればと思います。ここでも自分が各技術を現時点でどのようにとらえているか、本ではいささか書きづらい内容について、最近流行りの言葉でもある「技術的負債」という観点も踏まえて書いておこうと思います。 ・MySQL (RDBMS) 私はMySQLの中の人でもありましたし、これまで至るところで話してきたので省略します
ユーザとユーザを多対多で関連付けるモデルを共通化する - Hidden in Plain Sight
思いのほか前回のRailsプチ・デザインパターンの紹介に反応があったので、こういう小ネタも出していったほうがいいのかな、ということで第二弾。 ソーシャル系アプリだと、ユーザとユーザを関連付ける多対多のモデルがたくさんでてきます。たとえば、一般的なところではフォローとかブロックとか足あととか。さらにデーティングサイトになると、ウィンクだったり、Secret admirer（こっそりlikeするけど両思いだったらおめでとうって通知がくるってやつ）だったり、いろいろなモデルがこのパターンにあてはまります。 この場合、「AがBをフォローしている」「BがAをフォローしている」「AとBがお互いにフォローしている」という3つの状態があるわけですが、相互フォローの状態は「AがBをフォローし、かつBがAをフォローしている」と読み替えてSQLでも記述可能なので、以下ではシンプルに単方向のグラフで全てを扱うもの
プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight
おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ
MySQLをインストールしたら、必ず確認すべき10の設定 | Yakst
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
MySQL 5.5の秘伝のタレが5.6では腐っていたはなし | GMOメディア エンジニアブログ
もう寒の入りを過ぎましたね。DBAのたなかです。 GAからもうすぐ1年、社内ではもう相当カジュアルにMySQL 5.6をインストールしています。今までは新規サービス(や、新規機能)での導入がほとんどだった5.6を、このたびトラフィックガンガンのサービスにアップグレードで導入しました（と、偉そうに言っていますが私でない別のDBA氏が主担当のサービスです） 主な理由はInnoDB Compressedを使っていたのでその性能アップに期待…というところだったんですが、弊社DBAが神代の時代より試行錯誤を重ねたどり着いた究極のmy.cnf(?)、いわゆる秘伝のタレが 残 念 な が ら 腐 っ て お り 夜を徹してアップグレード作業をしていた担当DBA氏が青い顔(推定。チャットだった)で ス ロ ー ク エ リ ー が 1 0 倍 く ら い に な っ た ん だ け ど … と訴え、彼はその
Redmineで使うデータベースを変更する
Redmine.JP Blog オープンソースのプロジェクト管理ソフトウェアRedmineに関するニュースや、より活用するためのtipsなどを掲載します Redmineで使用するデータベースはMySQL, SQLite, PostgreSQLから選択可能です。このうちSQLiteは導入が簡単で手軽に使い始めることができますが、本格的な運用を始めるとパフォーマンスが問題になってきて、MySQL等に移行したくなる場合があります。 このようなときに利用できるのが yaml_db というRailsプラグインです。yaml_dbを使うと、RedmineなどRuby on Railsベースのアプリケーションのデータベースの内容をYAML形式のファイルに書き出すこと、そしてYAML形式のファイルに書き出した内容をデータベースに取り込むことができます。移行元のデータベースの内容をファイルに書き出し、移行先
Dbup - UPコマンドだけのPHP製シンプルマイグレーションツール
Dbup の特徴 Dbup はPHPで書かれたシンプルなマイグレーションツールです 準備はdbup.pharをダウンロードするだけ up コマンドしかありません。down コマンドは存在しません マイグレーションの記述は親しみあるSQLそのままです。ORMやDSLを新しく覚える必要はありません PHP標準のPDOクラスを利用しています マイグレーションのステータス管理のためにデータベースに専用のテーブルを作る必要がありません DBの設定ファイルはiniフォーマットです。いろんな言語に優しくPHPに依存していません 動作条件 PHP 5.4.0 以降 PDO エクステンション 更新履歴 githubのCHANGELOG.mdを参照してください とりあえず動かしてみる // dbup.pharをダウンロードする $ cd your_repo_root/repo_name $ wget http
第1回 全文検索エンジンgroongaを紹介します！ | gihyo.jp
今回から始まった隔週連載groongaでは、groongaを使いたくなるような情報を隔週毎にお届けします。 groongaとはGitHubで公開されているオープンソースの全文検索エンジンです。大量にある文書の中から目的のキーワードを持つ文書を高速に見つけることができます。 groongaのロゴ©groongaプロジェクト 第1回目である今回は、この連載についてとgroongaの特徴を紹介します。 この連載について まず、この連載について説明します。 この連載は「読者の皆さんがgroongaを使いたくなる！」ことを目指しています。そのために、次の2点の情報を次回から交互にお届けします。 groongaの利用事例の紹介 利用事例に関連した役立つ情報の紹介 利用事例を紹介することで、「あそこでも使っているなら自分も使ってみようかなぁ」とか「こんな使い方をしているなら自分も使ってみようかなぁ」と
DB設計の難しさ
今日は徒然なるままにDB設計について思っていることを並べてみようと思う。 ようやくWEB+DB Pressの次号の原稿を書き終えた。2年間の連載であるが、来年はプライベートが忙しくなる予定なので、連載はこれにて終了とさせてもらうつもりである。 「なぜ人はリレーショナルデータベースを使いこなせないのか」 このところ執筆や講演を通じてリレーショナルモデルについて説明する機会を色々頂いているが、それらの活動の根源となっているのが、この素朴な疑問である。その疑問をパワーにしてこれまで活動を行なってきた。 現時点での自分の回答は「データベース設計が難しいから」である。もちろんリレーショナルモデルそのものの難しさというのもあるが、それよりは「適切な使い分けができていない」ということが大きいように思う。言葉を変えると、リレーショナルモデルを適用すべきデータとそうでないデータの判断ができていないからDB設
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLite: SQLiteデータベースを読み書きするMySQLストレージエンジン
Cloud Computing Services | Google Cloud
https://jp.techcrunch.com/2014/02/12/20140211googles-cloud-sql-hits-general-availability-gets-an-sla-encryption-and-support-for-larger-databases/
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
IBM Developer
