NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
その分析、Hadoopなら速く安くできます
ビジネスデータを分析するビジネスインテリジェンス（BI）分野の新たなプラットフォームとして注目されているHadoop。Hadoopでは、どのようなデータ分析が可能なのでしょうか？ 現在、Hadoopビジネスの牽引役であるClouderaのJeff Hammerbracher氏が、Hadoopでデータ分析が可能なビジネス上の課題を示した「10 Common Hadoop-able problems」（Hadoop化可能な10の一般的課題）と題したプレゼンテーションを公開しています。 Hadoopにとって得意な処理とは、複雑で複数のデータソースからなる大量のデータの分析であり、それをバッチ処理の並列実行によって実現することです。 従来は、データがあまりに複雑だったり膨大だっために、計算時間やコストなどの理由で実現が難しかった処理でも、Hadoopによる低コスト化、計算時間の短縮、高い柔軟性など
key-value stores: Anti-RDBMS: A list of distributed key-value stores | Richard Jones, Esq.
Please Note: this was written January 2009 - see the comments for updates and additional information. A lot has changed since I wrote this. Perhaps you’re considering using a dedicated key-value or document store instead of a traditional relational database. Reasons for this might include: You're suffering from Cloud-computing Mania. You need an excuse to 'get your Erlang on' You heard CouchDB was
Leo's Chronicle: ぜひ押さえておきたいデータベースの教科書
先日のエントリで少し話したのですが、僕が在学していたときの東大にはデータベースを学ぶためのコースというものがありませんでした（DB関係の授業は年に１つか２つある程度。現在はどうなんだろう？）。そんなときに役だったのは、やはり教科書。読みやすいものから順に紹介していきます。（とはいってもすべて英語の本です。あしからず） 一番のお薦めは、Raghu Ramakrishnan先生 (現在は、Yahoo! Research) の「Database Management Systems (3rd Edition)」。初学者から研究者まで幅広く使えます。データベース管理システム（DBMS）の基本概念から、問い合わせ最適化、トランザクション管理など、これらを実装・評価するために必要な、「DBの世界での常識」が、丁寧な語り口でふんだんに盛り込まれています。この1冊を読んでおけば、DBの世界で議論するための
基礎から理解するデータベースのしくみ（12）
両すくみで処理が停止することも ロック機能は複数のユーザーが利用するデータベース・アプリケーションには不可欠なのですが，新たな問題の元にもなります。それは「デッドロック」と呼ばれる現象です。 先の銀行口座間の振り込みの例で次のような場合を考えてください（図3[拡大表示]）。トランザクション1は，口座番号10の口座から口座番号20の口座に1万円を振り込もうとしています。一方，トランザクション2は，これとは逆に口座番号20の口座から口座番号10の口座に5000円を振り込みます。ここで仮に，トランザクション1が，(1)口座番号10のレコードを変更してから，トランザクション2が(2)口座番号20のレコードを変更したとしましょう。この時点で，トランザクション1は口座番号10のレコードを，トランザクション2は口座番号20のレコードを排他ロックします。これらのレコードは，トランザクションが終了するまでロ
基礎から理解するデータベースのしくみ（9）
図10●レコード・クラスタリングの仕組み。ハッシュ値にしたがって，empとemp_histの二つのテーブルで同じenoを持つレコードを一つのテーブルに格納している RDBMSが備えるさまざまな高速化手法 RDBMSは，ここまで説明してきた基本的なデータの格納のしかたや操作方法に加え，高速化のための手法をいろいろ用意しています。Part2の最後に，これらの手法をざっと紹介しておきましょう。 ●ハッシュ・インデックス キャッシュ・バッファのサイズや使われ方にもよりますが，一般にBツリー・インデックスを使って巨大なデータベースにアクセスする際には，ルート・ノードだけがキャッシュ・バッファにあるのが普通です。そのため，レコードにたどりつくまでにブランチ・ノード，リーフ・ノード，データベース・レコードと何回もディスクにアクセスしなければなりません。これを1回のアクセスでレコードを取得できるようにしよ
基礎から理解するデータベースのしくみ（5）：ITpro
SQL文を実行する際のパフォーマンスに大きな影響を及ぼすものとして，もう一つ，インデックスがあります。インデックスについては，どう定義すべきかというデータベース設計上の問題と，インデックスを有効に使うためのSQL文をどう書くべきかというコーディング上の問題があります。 ここではテーブル設計上の問題を主に取り上げます。SQL文のコーディングについては囲み記事「SQL文を最速にする11のポイント」を参照してください。 インデックスは，テーブルの検索速度を向上させるためのものです。それぞれのSQL文に対して最適なインデックスを定義するのが理想的ですが，実際にはある程度限られたインデックスで，必要なパフォーマンス要件を満たすようにインデックスを定義する必要があります。加えて，どんなSQL文が実際に発行されるのかがあらかじめわかっていない場合は，適当な想定に基づいてインデックスを定義しておかなくては
基礎から理解するデータベースのしくみ（4）
図4●ネスト・ループ結合アルゴリズム。テーブルAの各レコードについてテーブルBのすべてのレコードと比較します データベースの統計情報は定期的に更新する 基本的には，ほとんどの場合にコスト・ベース・アプローチに基づくオプティマイザは最適な実行計画を選択してくれると考えてさほど問題はありません。ただ，コスト・ベースの基になるコストの計算は，テーブルのフィールドの値が均等に分布していると仮定して行います。そのため，データの分布に極端な偏りがある場合などは，実際には全件走査のほうが処理は早く終わるのに，インデックス検索を選択してしまうような場合もあり得ます。 コスト・ベース・アプローチを使って効率の良い実行計画を立てるには，定期的に統計情報を更新することが重要なポイントとなります。統計情報は，あくまでもそれを作成したときのデータベースの状態を反映しています。したがって，統計情報を作成した後にデータ
基礎から理解するデータベースのしくみ（3）
図3●Oracle付属のSQL＊Plusで実行計画を表示したところ。画面下部のインデントは図2のツリーの親子関係を表します 効率の良い実行計画を作成する 次は，実行計画の作成です。こちらも例を挙げて説明したほうがわかりやすいでしょう。Oracleに付属するサンプルの従業員テーブル（emp）と部署テーブル（dept）から，従業員の一覧を取り出す以下のようなSQL文を実行するとします。 SELECT ename, job, sal, dname FROM emp, dept WHERE emp.deptno = dept.deptno テーブルdeptでは部署番号deptnoが主キーで，インデックスpk_deptnoが定義されています。一方テーブルempでは，deptnoが外部キー＊5になりますが，これに対してインデックスは定義されていません。 オプティマイザは，このSQL文に対して（図2[拡
基礎から理解するデータベースのしくみ（2）
図1●リレーショナル・データベース管理システム（RDBMS）が，受け取ったSQL文を実行するまでの処理の流れ SQL文を記述してデータベースを操作することはそれほど難しいことではありません。しかし，リレーショナル・データベース管理システム（RDBMS）が問い合わせを実行する速度は，SQL文の書き方によって大きく異なります。ちょっとした記述の違いによって，応答時間が何倍も違うことはめずらしくありません。 では，速いSQL文を書けるようになるためには，どうすればいいのでしょうか。その答えは，「RDBMSがSQL文を内部でどのように処理しているのか」を理解することです。RDBMSは，プログラマが記述したSQL文を基にさまざまな処理を行ってから実際にデータベースにアクセスします。その過程を知ることで，アクセスのしかたをコントロールできるようになるのです。 例えば，CUSTOMERS（顧客）テーブル
特集:基礎から理解するデータベースのしくみ - 特集:基礎から理解するデータベースのしくみ：ITpro
「データベースはブラックボックス。どんなSQL文を投げたらどんな結果が返ってくるかさえ知っていればよい」---そう思っている人も多いかもしれません。 しかし，本物のソフトウエア・エンジニアを目指すのであれば，データベースが動く仕組みを学ぶことは避けて通れません。パフォーマンスなどに問題が生じたときどこから手を付けていいのか皆目見当がつかない，といった事態に陥りかねません。 市販のRDBMSの内部はかなり複雑ですが，基本的な部分を理解するのはそれほど難しくありません。この特集でデータベースの動く仕組みを理解してください。 イントロ ●ブラックボックスのままでいいの？ 基礎から理解するデータベースのしくみ（1） Ｐａｒｔ１ ●SQL文はどのように実行されるのか 基礎から理解するデータベースのしくみ（2） 基礎から理解するデータベースのしくみ（3） 基礎から理解するデータベースのしくみ（4） 基
Sequoia: Check Out Our New Community Site!
As of August 28 2008, the contents of sequoia.continuent.org have moved to http://community.continuent.com/community/sequoia∞. The new site has been completely redesigned and has many new facilities like forums, wiki courtesy of MediaWiki∞, and better security. Continuent.org will remain up until we are satisfied that all content has been properly moved. Meanwhile, please enjoy the new site! Welc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Oracle Database オンライン・ドキュメント 10g リリース2 (10.2)