NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
データベース設計におけるNULL - kawasima
NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
DB設計時のサイズ見積もり - よねのはてな
ここのところ、javaccとawsに魅了されている米林です。 よく使うDB(Oracle/MySQL/PostgreSQL/SQLServer)における設計時のサイズ見積もりで使うサイトの備忘録。 あとは、OracleからのPython情報。 Oracle Oracle 物理設計 http://www.oracle.com/technology/global/jp/columns/skillup/oracle9i/index.html 領域サイズ見積もり http://otn.oracle.co.jp/document/estimate/index.html OTNにログインする必要ありますがオンラインで見積もりが出来ます。 アカウント持っていない人は、この見積もりツールを使う目的でアカウントを作ってみてはいかがでしょうか。 OLTP系とDWH系においてブロックサイズを考慮し、DWH系はブ
Railsらしいデータベース管理システム·rbDB MOONGIFT
Webベースのシステム開発でMySQL管理を行うとすればphpMyAdminが選択されることだろう。確かに優秀なWebアプリケーションだ。だがちょっと待って欲しい。時代は常に変わっている、時には新しいものに触れてみるのも良いのではないだろうか。 Rails製のデータベース管理システム Ruby on Railsの開発者であれば、データベースももちろんRailsで管理しよう。使うのはrbDBだ。 今回紹介するフリーウェアはrbDB、Ruby on Rails製のデータベース管理システムだ。ソースコードは公開されているが、ライセンスは明記されていなかったのでご注意いただきたい。 rbDBは既存のアプリケーションの中に組み込むという訳ではなく、MySQL全体の管理を行うWebアプリケーションだ。とは言え、最適化等ができる訳ではなく、データベースの作成やテーブルの作成、データのメンテナンス等が主な
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
MySQLの最適化
限りなく眠気を誘うPHP Internalsのセッションから逃げる。こっちの 講師はMySQL.comの人。講演慣れしていて、ずっとまともでプロフェッショナルな 感じ。午前中を逃したのが惜しいが、詳しいプレゼン資料は後日公開される らしい。 DELETEのコストはかなり高い 読みだしがすごく多い場合は無効化を示すフィールドを作りUPDATEすべき、 index更新のコストが馬鹿にならないSHOW STATUSの表示結果の解析方法 起動ごとに初期化、全データベースに共通rnd と rnd_next の割合Key_reads : Key_read_requests 、ディスクから読まれた回数：総回数 この割合が1:100より悪くなったら要注意Key_write_requests:Key_writes 総書き込み要求回数：ディスクに書き込ま れた回数 キャッシュの効果などMax_used_con
MOONGIFT: » Hyper Estraier作者による新型DBM「Tokyo Cabinet」:オープンソースを毎日紹介
枯れた技術は完成度が高いが、だからといって完璧な訳ではない。技術は常に刷新され、磨かれていくべきだ。そのため、他の実装が出てくるのは重要だ。 DBMと言えば、キーと値を持つごくシンプルなデータベースだ。これは昔から存在し、Berkeley DBやQDBMで完成度が高まっている。だが、さらにそれを乗り越えるソフトウェアが生み出されている。 今回書介するオープンソース・ソフトウェアはTokyo Cabinet、日本発のDBM実装だ。 Tokyo CabinetはあのHyper Estraierの作者である平林幹雄氏（以下mikio氏）によるソフトウェアで、Hyper Estraierの内部で利用されているQDBMよりも高速に動作するらしい。前方一致や数値の範囲検索、さらにトランザクションも利用できる。 ハッシュは便利だが、実行されるごとになくなってしまうのが不便だ。これをTokyo Cabin
１人で稼ぐ日記 | MySQL：１台しかない環境でエセ負荷分散
MySQLのネタ。 １台しかない環境でエセ負荷分散を行う。 MySQLで負荷分散を考えたとき、 １台目にマスターのＤＢサーバー、 ２台目以降をスレーブのＤＢサーバーとして用いる。 マスターは更新系のみのＳＱＬ文を、 スレーブは参照系のみのＳＱＬ文を投げる。 こんな負荷分散を１台のサーバーで行う必要が出てきた。 現在１台でやっていて、ディスクＩＯが追いつかずに捜し求めた結果、下の形で落ち着いた。 １つのテーブルでインデックスを含めたサイズが 30MB〜100MBほどで安定している、という条件があるのですが かなり負荷下がります。 ※上記サイズは搭載メモリサイズによって変わります -------------------------- ■やりかた 負荷が高いテーブルをＡとする １：Ａと同じテーブル構成で、エンジンをMEMORY(he
[ThinkIT] 第6回：データベースの負荷分散とまとめ (1/3)
Webサーバーも順調に増えた、となると次はデータベースが悲鳴を上げる頃です。データベースの増設と行きましょう。 はてなではデータベースにはMySQLを利用しています。MySQLは組み込みでレプリケーションをサポートしているので、これを使わない手はありません。レプリケーションを行い、マスターDBのコピーであるスレーブDBサーバーを作り2台構成にします。 レプリケーションは、データベースを複数台に増やし、且つその複数のデータベースが保持するデータを同期させるための仕組みです。レプリケーションされたデータベースのうち、元々あったデータベースが親、それ以外が子という親子関係になります。 親はマスター、子はスレーブと呼ばれ、マスターへの更新処理と同じ処理をスレーブに伝播させることでデータの同期が行われます。実際にはマスターからスレーブへ処理が伝播するのではなく、スレーブがポーリングを行ってマスターと
Magic Multi-Connections
→ Ruby on Rails → ActiveRecords WARNING Despite the 1.0.0 version number, various people have experienced problems using this tool. I haven’t yet found a solution (I haven’t really been looking though), so please subscribe to the forum or RubyForge news for any updates on a solution. What ActiveRecord models are allowed one connection to a database at a time, per class. Ruby on Rails sets up the d
[O] Railsで複数DBを使い分けるためのライブラリ magic_multi_connections
「magic_multi_connections」というRailsで複数DBを使い分けるためのラ イブラリについて、まとめている記事がありました。 Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築:TKMR.blog.show 最近、2.0な方々の間でTwitterが話題になってる。で、そのTwitter自体 も面白いんだけど、TwitterについてDHHがブログを書いてRailsでの大規 模サイト構築が話題になってるのが面白い。 基本一つのDBを見るRailsを、複数DBを使えるようにできるようです。 さらに、acts_as_readonlyableという同じように複数DBを使うための ライブラリについても言及されていました。そのうち使うと思うのでメモ。 [2007-04-27]：追記 この話題に対する言及を見かけました。 みかログ: DBの分散方法 2種類
DBの分散方法 - みかログ
Rails って，結構人気があるから，既にそういう機能もあるのではと思っていたけど，無かったらしい． 簡単に実装できるから，誰も公開していなかっただけなのかもしれないけど．(^^; Scaling to multiple databases with Rails (Loud Thinking) Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築 2種類のモジュールがあるようだけど，readonlyable 方式はすぐ問題が出てきそうな気がする． たとえば，ユーザ登録時にIDの重複判定をするような場合，read_only 指定をしていると，masterからslaveへの更新反映が遅延するため，正しく重複判定出来ない可能性が出てしまいそう． かといって，read_only 指定をしないと，アクセスが多そうなユーザ情報のテーブルが分散されない． その辺を考えると，多少
Scaling to multiple databases with Rails (Loud Thinking) - Matzにっき(2007-04-16)
<< 2007/04/ 1 1. エープリルフール 2. [Ruby] オブジェクト指向機能を取り除いた Ruby-- が登場!? 2 1. [教会] セミナリー１日目 2. LMLML 3. [Ruby] 最速配信研究会 - なんだかいろいろ申し訳ない気分になった話 4. [Ruby] Headius: ActiveRecord 100%, Performance Doubling, Java Support Improving 3 1. [Ruby] Bitwise Magazine:: What's Right With Ruby? 2. [OSS] オープンソースソフトウエアがビジネスの成長を加速 3. Passion For The Future: なぜ株式投資はもうからないのか 4 1. [Ruby] Rails 1.2と1.1、速いのはどっち? - Railsbenchによる
Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築:TKMR.blog.show
最近、2.0な方々の間でTwitterが話題になってる。で、そのTwitter自体も面白いんだけど、TwitterについてDHHがブログを書いてRailsでの大規模サイト構築が話題になってるのが面白い。 Twitter trouble (Loud Thinking - DHH) まずTwitterの高負荷について言及、Twitterは11,000リクエスト/秒 の高負荷で問題となっているらしい。 そしてスケーラビリティの鍵はDB分割だ、と言っている。Railsは基本一つのDBを見るのでスケーラビリティの問題になる （確かにWebサーバはロードバランサがあればいくらでもスケールするしね、Sessionの共有だけ気を付ければ） ↓ Dr Nic » Magic Multi-Connections: A “facility in Rails to talk to more than o
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る：CodeZine
IDEA * IDEA
リレーショナル・データベースの世界
現場指向のレプリケーション詳説
railsmyadmin - Google Code