ソーシャルゲームのような高負荷がかかるWebアプリケーションにおいては、何十, 何百台ものサーバーでスケールアウトするのが当然の時代になりました。特にDBサーバーでは垂直分割、水平分割による複数のDBへの負荷の分散が行われ、アプリケーション側でハンドリングすべきことが増してきています。 今回は、G…
![Ruby on Rails & Vitessによる
DBスケールアウト](https://cdn-ak-scissors.b.st-hatena.com/image/square/e01063c500392474b555e99ddfcc4f64535bd68c/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Ff01ed7288ee243aa972e7f7b7d460ae2%2Fslide_0.jpg%3F5863874)
RailsのChangeLogを読んでいたらkamipoさんの ActiveRecordへのコミットがRails5から使えるようになってるものがたくさんあったのでまとめてみました。 PostgreSQLでExpression IndexとOperator Classをサポート create_table :users do |t| t.string :name t.index 'lower(name) varchar_pattern_ops' end MySQLでPrepared statesmentsをサポート config/database.ymlでprepared_statements: trueとすると利用できるようになります。mysql2 0.4.4以降が導入されていないと使えないようです。 Schema dumperがcreate_tableブロックの中でindexを定義するよう
技術部の小野(taiki45)です。クックパッドではこれまで様々なデータベースの負荷対策を行ってきましたが、シャーディングは行われていませんでした。しかし先日クックパッドの認可サーバーが利用している MySQL サーバーの負荷分散のためにクックパッドで初めてのシャーディングを行ったので、Rails アプリケーションでのシャーディングの事例のひとつとしてその際の手法をご紹介したいとおもいます。 構成 Before データベースは1マスター、1ホットスタンバイ、バッチ用の1リードレプリカで構成されています。Read オペレーションのほとんどはキャッシュ層に逃しています。 After データベースの各ロールにつきそれぞれ1台ずつマシンが増えています。 シャーディングが必要になった背景 認可サーバーのアクセストークンの作成・削除時の Write オペレーションが急増し、レコード数自体も急増していて
2015/05/16 23:06 I/F修正 以前、MySQL Casual Talks vol.6に参加したとき、kamipoさんというすごいかた作のMySQLCasualLog.pmというPerlライブラリの発表がありまして、「いーなーいーなー、うらやましーなー。Railsでも使いたいなー」と思っていたのですが、GWで時間に余裕があったのでRubyにそれっぽく移植してみました。 あ、MySQLCasualLog.pmはやばめなexplainの結果に色づけしてわかりやすくしてくれるものです。 ふつうのWeb開発者のためのクエリチューニング Mysql2QueryFilter https://github.com/winebarrel/mysql2_query_filter とりあえずDBIx::QueryLogっぽくSQL実行をフックできるライブラリが欲しかったのでMysql2Query
2014年12月12日現在、rails 4.2.0.rc2でもうすぐ4.2.0がリリースされそうですね! ここ最近MySQL向けパッチをいっぱいPRしたんですけど4.2.0には入れれなかったので、MySQL向けパッチを4.x向けにバックポートしたgemを作りました。 activerecord-mysql-awesome | RubyGems.org | your community gem host kamipo/activerecord-mysql-awesome とりあえず2014年12月12日現在では以下のパッチがバックポートされています。 Add SchemaDumper support table_options for MySQL. #17569 Add charset and collation options support for MySQL string and tex
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる で、日本語が分かる人には utf8_unicode_ci のヤバさを感じてもらえたと思うんですけど、この挙動はドキュメントによると UCA というアルゴリズムによるものらしい。 MySQL implements the xxx_unicode_ci collations according to the Unicode Collation Algorithm (UCA) described at http://www.unicode.org/reports/tr10/. The collation uses the version-4.0.0 UCA weight keys: http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt. Currently,
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
超久しぶりの更新 大丈夫生きてます。 色々あって今iPhoneアプリを作っていて そのアプリで絵文字を使いたくて結構はまったので、対応したメモを残しておく。 ユーザーがDBに突っ込んでくるテキストに絵文字が入っていてrailsとDBはmysqlを使ってる。 Mysql2 railsでmysql2を使ってるが、gem mysql2がutf8mb4に対応していないので 下記を参考にbundleで入れたmoduleに手を入れた。 AWS - Rails + Mysql(utf8mb4) on Amazon RDS - Qiita add utf8mb4 charset · f535df8 · brianmario/mysql2 · GitHub mysql2の更新が待たれる。。。 Gemfileに下記を追加してもいいかも gem 'mysql2', :git => 'git://github.c
Rails複数DB Casual Talks - connpass お疲れさまでした。 当日は準備不足で資料がただのリンク集だったのを公開用に当社比800%ぐらい加筆したので、当日参加できなかった人が見ても内容がわかるようになってると思います。 MySQLとActiveRecord @ryopekoさんのツイートふぁぼってたらみんなが複数DBの話するなかでひとりだけMySQLの話するとか公開処刑なのでは!?と思ったけど、ちょうどみんなestablish_connectionの話でおなかいっぱいでしたからね、楽しんでもらえたようでよかったです。 @kamipo fav されたということはレールズで DB 周りのつらい話、何か話してくれると思って大丈夫ですか?— 複数DB (@ryopeko) October 3, 2014 YAPC のときに kamipo さんと HUB で話した時に、レー
MySQLには文字列の照合順序(collation)というのがあって、MySQL側でのcharset utf8のときのデフォルトの照合順序はutf8_general_ciです。 ActiveRecord::Migrationでは明示的に照合順序を指定しない場合、charset utf8で照合順序utf8_unicode_ciのデータベースを作成しますが、これは少なくとも日本語圏では多くの人が期待する挙動ではないと思われるので注意が必要です。 たとえば、以下のようなファミリーテーブルをrake db:migrateすると # coding: utf-8 class CreateFamilies < ActiveRecord::Migration def change create_table :families do |t| t.string :name t.string :relation
技術部の鈴木 (@eagletmt) です。 クックパッドでは8月に本体アプリケーションや API サーバ等で使われている Rails のバージョンを 3.2 から 4.1 へ順次アップグレードを行いました。 アップグレードは主に松田さん (@amatsuda) と私で進めました。 この記事ではアップレードの際に遭遇した問題の一部を紹介します。 MySQL strict mode の有効化 MySQL を使っている場合、Rails 4.0 からデフォルトで @@SESSION.sql_mode = 'STRICT_ALL_TABLES' が最初に実行されるようになりました (Ruby on Rails 4.0 Release Notes) 。 これを無効化するために database.yml で strict: false という設定が用意されています。 しかし、同じく Rails 4.0
なぜ MySQLは、WITH RECURSIVE文をサポートしていないため、たとえば以下のような自己参照テーブル “comments” +------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------+--------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | parent_id | int(11) | YES | | NULL | | | body | varchar(255) | YES | | NULL | | | created_
ActiveRecordは基本ずっと接続をはりっぱなしにします。 なので長時間接続をはりっぱなしにするため タイムアウト等で接続がきれると問題がでます。 MySQLでDBの接続がきれるタイミング 状況別 Railsの場合 HTTPリクエストのあるたびに接続が切れてないかを確認します。切れてる場合は再接続するようになっているので問題なさそうです。 バッチ、デーモン等 ActiveRecordを使った場合はずっとつなぎっぱなしになるため、途中で接続が切れるとエラーになります。 reconnectオプションは危険 じゃあバッチ等の場合自動で再接続してくれればと思うと MySqlのクライアントライブラリレベルでリコネクトの概念がありました。 railsで使うにはdatabase.ymlに:reconnect = trueで指定できます。 が!! railsの実装ではデフォルトはOFFになっています
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く