いま注目のFusion-ioの速さの理由
Fusion-ioも登場！「DB Online Day」9月11日開催！ ストレージが早くなればサーバーの稼動率が上がりコストも削減できる 増え続けるデータを効率的に処理できれば、データセンターのコストを大幅に削減できる可能性がある。たとえば、データセンターにあるサーバー群、たくさんあるサーバーの稼動率は平均すると20％程度と言われている。稼動率を上げられれば、サーバー数が減らせ、それに伴うソフトウェアライセンスや設置スペース、当然ながら電力や光熱費が削減できる。 サーバーの効率を上げるために仮想化技術を活用する話を、数年前からよく耳にするようになった。仮想化を利用すれば確かにサーバーの稼動率は向上させられるだろう。しかし、それでもまだビッグデータを処理する場合は、うまくいかないこともある。 その原因となるのが、CPUのパフォーマンスがムーアの法則で著しく向上するのに対し、ビッグデータを格
A5:SQL Mk-2 - フリーの汎用SQL開発ツール/ER図ツール
A5:SQL Mk-2は複雑化するデータベース開発を支援するために開発されたフリーのSQL開発ツールです。 高機能かつ軽量で、使い方が分かりやすいことを目標に開発されています。 SQLを実行したり、テーブルを編集するほかに、SQLの実行計画を取得したり、ER図を作成したりすることが出来ます。 特徴・機能 OCI接続・直接接続・ADOまたはODBCを介したDBへの接続 Oracle DatabaseはOCI経由の接続・直接接続が出来ます。 PostgreSQLとMySQLは直接接続が出来ます。 Microsoft SQL Serverは、OLE DBプロバイダを直接呼び出した接続ができます。 IBM DB2は、ODBCドライバを直接呼び出した接続ができます。 その他のデータベースは、ADOまたはODBCを利用して接続します。 Oracle, PostgreSQL, MySQLは、A5:SQL
mysql:12071 階層化されたデータをMySQLで扱う
From: zen kishimoto <zen kishimoto <zen@xxxxxxxxxx>> Date: Sat, 03 Sep 2005 09:24:15 -0700 Subject: [mysql 12071] 階層化されたデータをMySQLで扱う （Managing Hierarchical Data in MySQL） http://dev.mysql.com/tech-resources/articles/hierarchical-data.html （図はこのサイトを参照のこと） Mike Hillyer著 初めに 多くのユーザーは一回くらいはSQLデータベース内で、階層化したデータを 扱ったことがあると思います。そのときはリレーショナル データベースは階層化したデータ用に開発されなかったと考えたと思います。 リレーショナルデータベースのテーブルは階層化されておらず
RDBで階層構造を扱う方法 - プログラミング探して！
RDBで階層構造を扱う方法 † カテゴリーとか階層構造を持ったデータをMySQLで扱いたい。 どうすりゃいいのさ？ ↑ リンク † まずは、Google検索！ MySQL 階層構造 - Google検索 いろいろヒットしました！ リレーショナル・データベースの世界 http://www.geocities.co.jp/mickindex/database/idx_database.html http://mickindex.sakura.ne.jp/database/idx_database.html SQLで木と階層構造のデータを扱う（１）――入れ子集合モデル http://www.geocities.co.jp/mickindex/database/db_tree_ns.html http://mickindex.sakura.ne.jp/database/db_tree_ns.htm
データを扱うアプリケーションの注意点
ここでは主に業務アプリケーションで、データを扱うときに、注意する点について述べます。 削除パターン 親子関係にあるとき、親が削除されたときに子をどうするか決めておきます。 RESTRICT 子があるとき削除できない CASCADE 子もすべて削除される SET NULL 子の参照をNULLにする 論理削除 削除フラグを立て子はそのままにする 論理削除を行なう場合の注意点 データを削除する際、実際物理的にはデータベースから削除せずに見かけ上消す論理削除がしばしば用いられます。この利点は、誤削除しても復活させる手立てを残しておくことや、削除されたものを後で参照できることなどがあります。削除というよりは無効化という方が適切な場合があります。 例えば、案件テーブルに担当者を入れる項目があったとしてます。論理削除であれば、担当者が退職した場合でも、あとで誰が担当者であったかを分かるようになります。一
削除フラグのはなし
6. id name pass is_deleted 1 ryu xxx FALSE 2 ken xxx FALSE 3 honda xxx TRUE 8. id name pass is_deleted 1 ryu xxx FALSE 2 ken xxx FALSE 3 honda xxx TRUE 3 honda xxx FALSE
信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという
信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AndroidのNFC機能でFeliCaの読み書きをする | −ゆめログ− | ゆめみスタッフブログ