NoSQL登場の背景、CAP定理、データモデルの分類
その例としてBeck氏自身が過去に取り組んできた生命保険会社のアプリケーションを例に挙げます。そのアプリケーションでは毎日のようにスキーマが変化するため、SQLとORM(Object-Relational Mapping）では対応できず、オブジェクトデータベースのGemstoneを利用することで対応できたと述べています。 こうしたSQLだけでは満たせないさまざまな要件、上記の図にあるようにスキーマの可塑性、スケーラブルなデータ読み込み、書き込み、処理の柔軟性などを満たすために、リレーショナルデータベース以外のNoSQLな製品が開発された。これがNoSQLの登場の背景にあるとBeck氏は解説します。一方で、こうしたさまざまなNoSQLを、NoSQLという言葉で表すのは適当ではないという憂慮も示しています。 Here is where the futility of defining NoSQ
Bigtable: A Distributed Storage System for Structured Data - steps to phantasien t(2006-09-11)
2006-09-11 近況 今月は貧乏なので慎しく暮らしている. 週末もひきこもりとしてオンラインの記事を読んで過ごすことに. ウェブを眺めているといいタイミングで Google の新作論文が出ていた. ありがとう, Google の中の人. これ. GFS, MapReduce, Sawzall とつづく Google インフラ N 部作の 4 章が幕をあげた. 実はデータベースも作ってるんだぜ, という話. BigTable という名前だけは以前から O'Reilly Radar などに登場していた. ようやく公式な文書があらわれた. BigTable は GFS をはじめとする Google インフラの上に作られた分散データベース. 少し変わったデータモデルと, 運用までワンセットのヘビーな実装を持つ. 実装の話もまあ面白いんだけれど, それよりデータモデルが印象的だった. 先にその
坂本多聞のソフトウェア業界インサイドアウト GoogleがOracleとデータベース領域で衝突する日：Bigtable vs Berkeley DB
CNET Japan読者ブロガー sparklegateさんのエントリーRDBMSは本当に便利なのかは問題提起としてそして、いろいろ寄せられたコメントが非常に興味深く面白かった。CPUネックとディスクネックというボトルネックについて寄せられた両方の意見はRDBMSをどう使っているかという使い方の差でもあり、「何でも入る便利な入れもの」であるRDBMSの特長がよく現れている証左だろう。そして、あまりに便利すぎるがゆえに、苦手な領域にも使われてスケーラビリティ（拡大性）の問題にぶつかり、「本当に便利なのか」という素朴な嘆きに至るという状況は、皮肉なのか本気なのか、いずれにしろありがちなことだろう。 ひっそりと表に出てきたGoogleを支えるデータベース：Bigtable そんなおり、steps to phantasienの2006-9-11のエントリーでGoogleのインフラを支えるデータベー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
