Amazon DynamoDB 用 NoSQL Workbench のプレビュー版の発表
AWS では本日付けで Amazon DynamoDB 用 NoSQL Workbench を発表しました。当ツールを使用することにより、開発者はスケーラブルでハイパフォーマンスなデータモデルを構築し、クエリの作成およびテストを行うための工程を簡素化できます。NoSQL Workbench は無料でご利用いただける Windows および macOS 用のクライアントアプリケーションです。 DynamoDB は、高速で予測可能なパフォーマンスとシームレスな拡張性を特長とするフルマネージド NoSQL データベースサービスです。非リレーショナルデータベースを使用するにあたっては、スケーラブルで柔軟性のあるデータモデルを設計することが重要になります。しかし、特にユーザーのデータアクセスパターンが不明な新しいアプリケーションを構築する場合、データモデルの設計が容易でないことがあります。NoSQL
データベースについてのそもそも論
先月のはじめのほうで、「リレーショナルデータベースとの上手な付き合い方」というタイトルで、2回発表をした。ひとつは「まべ☆てっく Vol.1」であり、もうひとつは「Hacker Tackle（ハカタクル？）」である。 「リレーショナルデータベースの開発・運用に纏わるもろもろの話をして欲しい」というような内容の話をしてくれないかという同じような依頼を、ちょうど2日違いのイベントで頂いた。9/8のまべ☆てっくと、9/10のHacker Tackleである。そうなると必然的に話す内容も、同じようなものになってくる。同じ人物（＝私）が話すのだから、テーマも同じで時期も同じであれば、内容が同じようなものになるのが自然である。もし違うものになってしまっているのであれば、片方はウソをついているということになるはずだ。今日は発表に使用したスライドを紹介しつつ、なぜデータベースを使うべきなのか（あるいは使う
もう1つの、DBのかたち、分散Key-Valueストアとは
分散KVSが苦手なトランザクションの「ACID特性」 RDBのように、テーブルとテーブルを結合（SQLでいうJOIN文）して複雑な条件検索や集計処理を一発でこなすような芸当はできません。また、トランザクションによる「ACID特性」の確保も分散KVSが苦手な分野です。 RDBが不得意な分散／拡張 そのため、これらの不足をアプリケーション側で補うためのさまざまな工夫やフォローが必要となります。その一方で、分散KVSはデータストア全体をいくらでも多くのサーバに分散（スケールアウト）できるのが最大の特徴です。 一方でこれは、RDBが最も不得意とするところです。RDBでは、その長所であるテーブル結合やACIDの確保がボトルネックとなり、複数のサーバにスケールアウトさせることが「原理的」に容易ではありません。そのため、負荷分散や高可用性を低コストで実現することが困難です。 RDBで負荷分散させようとす
NoSQL登場の背景、CAP定理、データモデルの分類
その例としてBeck氏自身が過去に取り組んできた生命保険会社のアプリケーションを例に挙げます。そのアプリケーションでは毎日のようにスキーマが変化するため、SQLとORM(Object-Relational Mapping）では対応できず、オブジェクトデータベースのGemstoneを利用することで対応できたと述べています。 こうしたSQLだけでは満たせないさまざまな要件、上記の図にあるようにスキーマの可塑性、スケーラブルなデータ読み込み、書き込み、処理の柔軟性などを満たすために、リレーショナルデータベース以外のNoSQLな製品が開発された。これがNoSQLの登場の背景にあるとBeck氏は解説します。一方で、こうしたさまざまなNoSQLを、NoSQLという言葉で表すのは適当ではないという憂慮も示しています。 Here is where the futility of defining NoSQ
クラウド上のリレーショナルデータベースはなぜ難しいのか？ BASEとCAP定理について
今週18日からマイクロソフトがラスベガスで「MIX09」を開催します。Windows 7やWindows Azureが発表された昨年秋のPDC（Professional Developers Conference）とは異なり、MIXはWebデザイナーとWebデベロッパー向けのイベントです。 ところで、デザイナーとデベロッパー向けのイベントといえばアドビシステムズのイベントが有名。その名称はたしか「MAX」ですよね......。 さて。MIX09ではWindows Azureの料金体系の発表があるかもしれないといわれています。もし発表されれば、IT系メディアのヘッドラインを飾ることでしょう。 僕が注目しているのは、先日「マイクロソフトがクラウドでリーダーシップを握る可能性が高まる」で書いた、SQL Server完全互換の「SQL Data Services」（SDS）についての具体的な内容の
データベースのスケーラビリティをどうやって向上させるか
これまでPublickeyではデータベースのスケーラビリティに関するさまざまなトピックを取り上げてきました。クラウド時代にはスケーラブルなデータベースのニーズがこれまでになく高まっているためです。 この記事では、これまで取り上げてきたデータベースのスケーラビリティに関する技術を少しまとめて紹介しようと思います。 従来のリレーショナルを拡張 従来のリレーショナルデータベースに対して、技術的工夫を凝らすことでスケーラブルなデータベースを実現しようというアプローチにも、さまざまなものがあります。 データベース研究者の大御所、マイケル・ストーンブレイカー氏は、リレーショナルデータベースは決して遅くないと主張。リレーショナルデータベースが遅い原因はロック、ラッチ、リソース管理にあるとして、それらを極力排除した「VoltDB」を開発しています。 NoSQLを上回る性能のVoltDB、そのアーキテクチャ
〜うまく動かすMongoDB〜仕組みや挙動を理解する - doryokujin's blog
@doryokujinです。この業界で非常に強い影響力を持つ@kuwa_tw氏が某勉強会でMongoDBについてdisられており、このままではMongoDB自身の存続が危ういと思い、急遽ブログ書きました。（冗談ですよ） ザ・ドキュメント〜うまくいかないNoSQL〜 View more presentations from Akihiro Kuwano MongoDBを使っているときに出会うトラブルをうまくまとめてくださった「MongoDBあるある」的な良い資料だと思います。今日はここで書かれているトラブルの解決方法を提示したいと思います。恐らく@kuwa_tw氏は全ての解決方法を知っていながら、同じトラブルへ悩む人のためにあえてdisったのだと思います。 MongoDB はデータベースもコレクションも存在しなければ自動作成してくれる mongoシェルを起動する場合、たいていは $ mong
第31回 RubyistのためのMongoDB入門（1） | gihyo.jp
はじめに ここ最近、NoSQLというキーワードが注目を集めています。 リレーショナルデータベースは、一般的にスケールアウト（サーバの台数を増やして性能向上を図る手法）が難しく、特に大規模サービスにおいてパフォーマンス上のボトルネックとなりえます。また、タグやグラフ構造のようなデータは関係モデルに馴染みにくいため、それらを扱う際にはアプリケーションコードもぎこちないものになりがちです。 これらの問題を背景に、何にでもリレーショナルデータベースを使うのではなく、用途に応じてKVSなど他のデータストアを選択する流れが広まりつつあります。このムーブメントがNoSQL（Not Only SQL）と呼ばれているものです。 今回は、NoSQLなデータベースの1つであるMongoDBをご紹介します。 MongoDBとは MongoDBは高いパフォーマンスとスケーラビリティを特徴とするドキュメント指向型デー
SQLの都市伝説。マイケル・ストーンブレイカー御大が斬る！
データベース研究者の大御所、マイケル・ストーンブレイカー氏が、「SQL URBAN MYTHS」（SQL都市伝説）というWebセミナーを、自身が創設した会社VoltDBで公開しています。 一般にリレーショナルデータベースに対して言われている「SQLは遅すぎる、トランザクションのコストは高すぎる」といった評価について、SQLが遅いのではないし、トランザクション以外のコストが高すぎるのだ、と反論する内容。 これらは同氏が以前から主張してきた内容ではありますが、最近流行しているNoSQLデータベースに対する反論にもなっているため、多くのエンジニアに刺激になる内容となっています。 SQLに関する6つの都市伝説 都市伝説1：SQLは遅すぎる。NoSQLのような低レベルなインターフェイスを使うべき 都市伝説2：キーバリュー型が有望で、SQLは問題外 都市伝説3：SQLデータベースはスケーラブルではない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
結果整合性（Eventual Consistency）についての分かりやすいプレゼン資料