Gabuchan.net Related Searches: Free Credit Report Designer Apparel Health Insurance Online classifieds 10 Best Mutual Funds music videos Healthy Weight Loss Related Searches: Free Credit Report Designer Apparel Health Insurance Privacy Policy
KVS を使って Web アプリケーションを作ることについて KVS を使って Web アプリケーションについて、一般論。 従来 KVS は、キャッシュや特に更新が激しいデータを保存することに主に用いられて、メインのストレージには RDBMS を使うことが多かったけど、 KVS をメインのストレージとするアプローチも最近いくつかある。 KVS にデータを保存するという場合、 Value にシリアライズしたデータをぶちこむというケースが多いのではなかろうか。そうすると、標準状態では、キーでしか検索出来ないので、インデックスを転置するということになる。 インデックスの転置先としては、 Facebook や SimpleResource でやっているように、 RDBMS に転置するというやり方や、 Cassandra 採用前の Twitter のように KVS に転置するというやり方があ
ROMAはRuby製のオープンソース・ソフトウェア。Webシステムで一般的に使われているRDBMSに対してここ一、二年で注目を集めているのがキー/バリュー型のデータベースシステムだ。シンプルに使えてスケールしやすく、大型のWebシステムでは導入が当たり前になりつつある。 そんなキー/バリュー型データベースとして有名なのはmemcachedやMogileFSなどが知られている。そこに独自のデータベースを開発したのが楽天だ。Ruby開発者であるまつもと氏をフェローに迎えて開発されたのがROMAになる。もちろんRubyで開発されておりごく手軽に利用できる。 ROMAはRuby1.9を使って動作する。インストールは簡単にでき、複数のインスタンスを簡単に立ち上げられる。そしてクライアントからはmemcachedと同様に接続が可能で、telnetでも接続することが可能だ。P2Pをもとして分散システムに
誰の口から飛び出したのかは定かではないが、巷ではMySQLにまつわる様々な「都市伝説」がまことしやかに囁かれているようだ。恐らくMySQLに対する理解が低い人や、MySQLがあまり好きではない面々によってFUDっぽく言われているのだと思うが、世の中にはそのような「都市伝説」を真に受けてしまう人が居るのもまた事実であである。MySQLにおける昨今の開発スピードには目覚ましいものがあり、MySQLは性能・安定性・使い易さ共に進化し続けている。(特に先日リリースされたMySQL 5.5は性能・安定性・使い易さを両立している優れたバージョンだ!!)しかし「都市伝説」で語られることは総じて「MySQLはダメな子ちゃん」であるという烙印を押すものばかりであり、MySQLerとしてはそのような言われ無き汚名を全身全霊をもって晴らさなければならない使命を背負っている。そこで、今日はMySQLについて語られ
■ インデックスとは データベースの世界で、インデックス(索引)とはテーブルに格納されているデータを 高速に取り出す為の仕組みを意味します。 インデックスを適切に使用することによってSQL文の応答時間が劇的に改善 される可能性があります。 インデックスにはB-Treeインデックスをはじめ、ビットマップインデックス、 関数インデックスなどの種類がありますが、ここでは最も一般的に使われ、かつ ほとんどのDBMSでサポートされているB-Treeインデックスについて解説します。 ※ CREATE INDEX文でオプションを指定しない場合は通常B-Treeインデックスが 作成されます。 ■ B-Treeインデックスのしくみ B-Tree(Balanced Tree)インデックスは次のようなツリー状の構造になっています。 ツリーの先頭はヘッダブロックと呼ばれています。ヘッダブロックでは、キー値の 範囲
Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL
最近は常にInnoDBを利用しているので,MyISAM vs InnoDB にちょっとコメントしてみる. まず「Webアプリならトランザクションはいらないか」について. Webアプリで,トランザクションの重要性が高くないといっても,無いよりはあった方が良いはず. ちょっとしたシステムでも,たとえばユーザのテーブル,プロフィールのテーブル,日記の記事のテーブルなどでわけるわけで,それぞれのテーブル間の整合性がとれていないと問題が生じてしまうと思う. ハードウェア障害などでクラッシュしたときに,ユーザのテーブルにはレコードがあるけど,プロフィールにはレコードが無いケースとか,そういうケースが発生することを考えると,トランザクションは利用すべきじゃないのかなと. というわけで,JOINを使うようなアプリケーションであれば,トランザクションは使うようにすべき,というのが持論. それ以外でInnoD
RailsによるアジャイルWebアプリケーション開発のp.151に載っているテストtest_validateがうちの環境ではFailしてしまいました。Rails(ActiveRecord)のテストがトランザクションモードを使うようになっていたのですが、MySQLがトランザクションに対応していないモードで動作していたのが原因でした。以下はその詳細と解決方法です。 うちの環境はこんな感じです。 OS: NetBSD 3.0 DB: MySQL 5.0.20 Ruby: 1.8.4 Rails: 1.1.2 Activerecord: 1.14.2 Failしたテストのコードは以下です。(39行目は本には"Should be positive"となっていましたが、モデル側で出しているメッセージは違うものだったのでそれにあわせて変更しました) 26 def test_update 27 a
MySQLのサーバにクライアントからリモートアクセスする方法。 1.クライアントとサーバ両方にMySQLをインストールします。 2.サーバ側で、二つのユーザを作成します。 ・ローカル向け grant all privileges on DB名.* to ユーザ名@localhost identified by 'パスワード' with grant option; ・リモートホスト向け grant all privileges on DB名.* to ユーザ名@'%' identified by 'パスワード' with grant option; ところが、どうやってもクライアントからサーバにつなげることができず、どはまりしました。 【確認したこと】 1・MySQLのポートは開いているか # netstat -tlpn|grep mysql tcp 0 0 0.0.0.0:3306 0.0
あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I
SitePoint: New Articles, Fresh Thinking for Web Developers and Designers MySQLはほかの多くのデータベースと違って複数のテーブルタイプを提供しており、用途に応じてテーブルタイプを使い分けることができるようになっている。デフォルトのテーブルタイプはMyISAMだが、ほかにもInnoDBを選択することもできる。SitePointに次の2つの記事が掲載されており、どちらを選択すべきかが簡潔にまとまっている。 MySQL: the Pros and Cons of MyISAM Tables MySQL: the Pros and Cons of InnoDB Tables 内容を要約すると次のようになる。 MyISAMの特徴と問題点 特徴: デフォルトのテーブルタイプ 特徴: シンプル 特徴: 高速に動作 特徴: フルテ
日頃より楽天のサービスをご利用いただきましてありがとうございます。 サービスをご利用いただいておりますところ大変申し訳ございませんが、現在、緊急メンテナンスを行わせていただいております。 お客様には、緊急のメンテナンスにより、ご迷惑をおかけしており、誠に申し訳ございません。 メンテナンスが終了次第、サービスを復旧いたしますので、 今しばらくお待ちいただけますよう、お願い申し上げます。
MySQLとSQLite(PrinCo.)という記事経由で、生まれ変わるPHP - Zend Engine 2、SQLiteの実力は?(MYCOM PC WEB)という記事を読んだ。 MySQL と SQLite で INSERT 時の処理速度が公開されている。 1000件のレコードのINSERTを実行し、それぞれにどれぐらいの時間がかかっているかを示しているのだ。 MySQLが 0.4秒、SQLite が 16秒だというのだが、これはあまりにもひどすぎる。しかも、結論としてどうやら大量データの連続挿入はSQLiteの不得意な処理のようだ。と書かれている。1000件程度でこんなにかかるんだったら、10000件だったら160秒ぐらいかかる(単純すぎ。)って事? 実はこれにはからくりがあって、SQLite の処理は トランザクション の中でないと著しく遅いのだ。おそらく、これが原因なのではない
Rubyスクリプトとしてデータベースのスキーマを記述し、それに従ってデータベースを作成する手法。 SQL構文によるスキーマ記述が不要になり、バージョン管理が可能になる。 以下のようにしてスキーマの雛型を作成する。作成された雛型は、RAILS_ROOT/db/migrate/1_スキーマ名.rb となる。 > script/generate migration SchemaName なお、Rails 1.1 からは generate model コマンドでマイグレーションの雛型ファイルを作成できることになった。通常はこちらの方法のほうがモデルファイルも作成されるため、推奨される。 もし既存のデータベーススキーマを利用したいならば、以下のコマンドで db/schema.rb に書きこまれる。 > rake db:schema:dump スキーマファイルを手動で訂正する。 class Initi
いまいちRailsの機能とActiveRecordの機能を区別できてない。create_tableでテーブル定義して# rake migrateなんかしても、Ruby的には意味不明みたいだ。これはたぶんRailsの機能。たぶん。おそらく。 マイグレーションは面倒そうだったのでまずはO/Rマッピングから攻めていくことにする。 RubyからSQLite3を操作する sudo apt-get install ruby1.8-dev sqlite3 とかsudo gem install sqlite3 active_recordしておく。準備が出来たらこう書く。 require "rubygems" require "sqlite3" sql=<<SQL CREATE TABLE students ( id INTEGER PRIMARY KEY NOT NULL UNIQUE, test_tex
Ruby on Rails構成するライブラリの中のActiveRecordだけを使用する方法を紹介します. インストール #sudo gem install activerecord 使い方 まず事前準備としてDBを作成しテーブルを定義しておきます. 次にコードの最初にActiveRecord::Base.establish_connectionを実行することでDBとの接続が確立しActiveRecordによるORマッパーが使用可能になります. require 'rubygems' require 'active_record' ActiveRecord::Base.establish_connection( :adapter => 'mysql', :host => 'host_name', :username => 'user_name', :password => 'password
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く