米オラクルはエンタープライズ向けNoSQLデータベース「Oracle NoSQL Database 11g」の公開を発表。評価版の無償ダウンロードを開始しました。オープンソースライセンスに基づくコミュニティ版も準備中（10月26日現在、ライセンス承認待ち）とのことです。 Oracle NoSQL Databaseは、同社のキーバリューストアであるOracle Berkeley DB Java Editionをベースに、分散処理機能、ロードバランス、管理機能、マルチノードバックアップ機能などを追加したもの。大規模なデータを高速に扱うことができ、高い可用性とスケーラビリティを実現すると説明されています。 分散キーバリューストアで単一障害点を排除 NoSQL Databaseの基本的なアーキテクチャは、プライマリキーのハッシュによって指定されたノードにキー／バリューのペアを書き込む分散キーバリュ
読みました。ムック「ビッグデータを征すクラウドの技術 Hadoop&NoSQL」発売されます - developer’s delight好評だった雑誌の内容をまとめたもののようです。Amazon.co.jp： ASCII.technologies (アスキードットテクノロジーズ) 2011年 01月号 [雑誌]: 本私はHadoopの特集は読んでいたのですが、後半のNoSQLについての記事は初めて読みました。NoSQLデータベースファーストガイドで軽くしか触れられていなかったHBaseやCassandraについても詳しく載っていて、ちょうど相互に補完しあっているような感じです。NoSQLの導入的なところでも、「レプリケーションとシャーディングの機能を備えること」「CAP定理による分類」など明快に書かれています。雑誌には@issayさんらの事例が載っていたのですが書籍からは省かれていました。
2011年04月28日19:00 NoSQL 執筆 「NoSQLデータベースファーストガイド」を執筆しました 最近あまりブログを書けていなかったわけですが、実は初めて本の執筆をしていました。こちらです！でで〜ん！！(＊ﾟ∀ﾟ)っ NoSQLデータベースファーストガイド NoSQLデータベースについて書かれた 国内初 の入門書です！（多分） 最近では NoSQL というキーワードがバズワードになりつつあり、「いったい NoSQL って何だろう？」とか「リレーショナルデータベースとどう違うの？」と疑問に思われている方も多いのではないかと思います。が、勉強しようにも最初の一歩を踏み出すのってなかなか大変ですよね。何かいっぱい種類があるし。そこで、本書をきっかけとしていただけたら、、＞＜ NoSQLデータベースは細かいチューニングを行い「リレーショナルデータベースでは扱えないような大規模な処理を扱
NoSQL=キーバリューストア(KVS)でまとめられて紹介されてたり、KVS、列指向データベース、 ドキュメント指向データベースを分けてるものがあったり、混乱する・・・ 名前を見ても、NoSQLなのか、Twitterのクライアントなのか、わからなくなってし。 それは、HootSuiteとHadoopを混同してるだけかｗ。 ウィリアムのいたずらの開発日記 NoSQLの位置づけを分類してみると、下に記載した参考のURLを見て、追加してみた。 太文字は以前から知ってた(聞いたことがある程度含む)もので、他意はない。 データベース NoSQL キーバリューストア (Key-Value Store、KVS) Berkeley DB Chordless Coherence(Oracle) Dynamo（Amazon) Dynomite(Amazons DynamoのOSS) Flare(GREE) g
前回の記事では、Hadoopが膨大なデータをバッチ処理するための「インフラ」としての性質を備えていること、情報爆発時代の新たなインフラとして普及しつつあることを説明しました。その中で、情報爆発時代に必要とされるインフラは、「スケール・アウトが可能であること」という条件を備えていなければならないことを示しました。サーバーの台数を増やすことで容易にシステムの処理性能が増やせることは、Hadoopの重要な特徴です。今回は、Hadoopがどのようにしてスケール・アウトを可能にしているかを、「分散ファイル・システム」と「MapReduceフレームワーク」の2つの観点から解説します。 スケール・アウトとは？ コンピュータ・システムを新たに構築するときは、必ず「運用」のことを考えておく必要があります。システム・トラブルが発生した場合の対応策を決めたり、将来の仕様変更に備えてプログラムに拡張性を持たせたり
データを「キー」と「バリュー（値）」の組み合わせとして保存する「キー・バリュー型データストア」は、クラウド時代におけるデータベース技術の主流になろうとしている。20年以上にわたって主流であったリレーショナルデータベース管理システム（RDBMS）と仕組みを比較しながら、向く用途、向かない用途を考察しよう。 「RDBMSはクラウドで役割を減らしつつある」―。米IBMの「DB2」や米マイクロソフトの「SQL Server」のアーキテクトだったジェームズ・ハミルトン氏（現在の所属は米アマゾン・ウェブ・サービシズ）が、中国・上海で3月に開催された「SMDB 2009」（自己管理型データベースシステムに関するワークショップ）で発表した資料のタイトルだ。 ハミルトン氏がRDBMSに代わる存在として挙げるのは、米グーグルの「MapReduce」やそのオープンソース版「Hadoop」、アマゾンの「Simpl
データベース研究者の大御所、マイケル・ストーンブレイカー氏が、「SQL URBAN MYTHS」（SQL都市伝説）というWebセミナーを、自身が創設した会社VoltDBで公開しています。 一般にリレーショナルデータベースに対して言われている「SQLは遅すぎる、トランザクションのコストは高すぎる」といった評価について、SQLが遅いのではないし、トランザクション以外のコストが高すぎるのだ、と反論する内容。 これらは同氏が以前から主張してきた内容ではありますが、最近流行しているNoSQLデータベースに対する反論にもなっているため、多くのエンジニアに刺激になる内容となっています。 SQLに関する6つの都市伝説 都市伝説1：SQLは遅すぎる。NoSQLのような低レベルなインターフェイスを使うべき 都市伝説2：キーバリュー型が有望で、SQLは問題外 都市伝説3：SQLデータベースはスケーラブルではない
どんなところに使える？ HBaseやCassandraはどちらもRDBMSで扱いきれないような大規模なデータの扱いに力を発揮します。強力なスケーラビリティも備えているため、データが増えても処理速度はそれほど低下しません。また、列指向データベースの強みを活かして、大量のデータを更新するようなバッチ処理のストレージとして利用しても有用でしょう。 具体的な利用シーン 大規模なデータをスケーラブルに処理する必要がある場合 大量データをバッチ処理する際のストレージとしての利用 HBaseのインストール 本稿では、実際にHBaseを使ってみましょう[1]。 まずは1台のサーバ上で環境を整えます。わかりにくかもしれないので、以下の手順を参考にしてください。JDK6およびHadoopのインストールが必要です。 プロンプト1 HBaseのインストール＆起動の手順 # http://java.sun.com
「多くのOLTPデータベースは30年前の設計を基にしており、今日の“Webスケールな”データベースの負荷を想定していない。これら伝統的なデータベースは、処理時間の90％以上がログ、ロック、ラッチ、バッファ制御といったオーバーヘッドに費やされ、しかもそれらによって限られた性能やスケーラビリティしか実現できていない」 Ingresの開発者でありInformixのCTOなどデータベースベンダの要職を歴任したデータベース研究者の大御所、マイケル・ストーンブレイカー氏が開発したVoltDBはプレスリリースでこのように既存のリレーショナルデータベースの欠点を示した上で、インメモリデータベースをベースにこれらのオーバーヘッドを除去し、ACIDによるデータ一貫性を維持しつつ大きな性能向上とスケーラビリティを実現したと説明されています。 SourceForge.jpの記事「「NoSQL」を上回る性能を目指す
今やリレーショナルデータベース全盛の時代である。 どんなシステムもRDBなしには成り立たなくなっている。 しかし、RDBは本当に便利なのだろうか？ 例えば、いまはやりのSNSを考えてみよう。 それぞれのユーザーは他のユーザーとネットワーク的につながりをもっている。 そして、そのつながりは友人関係だったり仕事仲間だったりする。 RDBではそれぞれの表の属性もあらかじめ定義される必要があり、後で属性を追加することは難しい。 しかし、SNSのような人間関係を表現するようなもので事前にデータ構造を予測することができるだろうか。 例えば最初は仕事で知り合った人間でも友人になることがあるし、恋人同士だったのが別れてしまって他人同士になってしまうこともあるだろう。 このようなダイナミックなデータ構造はRDBでは表現するのが難しいだろう。 しかし、グラフDBはこのような用途に向いたDBである。 例えば、T
原文(投稿日：2010/05/12)へのリンク はじめに データモデルにはいろいろあるが、80年代以降、主流になっているのはリレーショナルモデルだ。このモデルにはOracle、MySQL、MSSQLなどの実装があり、RDBMS（リレーショナルデータベース管理システム: Relational Database Management System）と呼ばれることもある。しかし最近になって、リレーショナルデータベースを使うことで問題が起こるケースが増えている。リレーショナルモデルによるデータモデリングには弱点と問題があり、複数サーバに及ぶ水平方向のスケーラビリティと膨大なデータの扱いに制約があるためだ。これらの問題の要因には、世界中のソフトウェアコミュニティが注目している2つのトレンドがある。 ユーザ、システム、センサーによって生み出されるデータの指数的な増加。Amazon、Google、その他
「クラウドでパケ死」。 5月中旬、こんな言葉がTwitterで発信された。米Amazon Web Servicesのクラウドサービス「Amazon EC2」と「Amazon EBS」を使ったことろ、わずか5日ほどで利用料が25万円を超えてしまったのだという。ご本人のTwitterをたどると、原因は容量が30テラバイトの巨大な仮想ストレージを3台も借りてしまったことにあるようだ。このストレージに、データベースソフト「Cassandra」を使って1兆件を超えるレコードを登録したのだという。 Cassandraとは、米Facebook社が自社のサービス基盤向けに開発したデータベースソフトである。現在はOSSとして公開され、Apache Software Foundationが開発を進めている。特徴は、複数のノードにデータを分散管理できることで、ノードを追加するだけで容易に処理性能を高められる仕組
はじめに NoSQL（Not Only SQL）という言葉が注目を集めています。これは「RDBMSが得意なことはRDBMSで、不得意なところにはRDBMSにこだわらず、用途に合ったデータストアを使いましょう』という考え方です。最近では、いわゆるNoSQLデータベース （key-valueストアや各種データベース） が次々と登場してきています。 そこで今回から数回に渡り、それぞれのNoSQLデータベースの特徴や具体的な使い方について紹介していきます。 RDBMSの強みとは そもそも、MySQLやPostgreSQLなどのRDBMSの弱みを補うため、様々なNoSQLデータベースが登場してきたわけですが、RDBMSにはたくさんの強みがあることも忘れてはいけません。 RDBMSの強み データの一貫性 （トランザクション） 更新時のコストが少ない（JOINが前提でテーブルが正規化されている）
オブジェクト指向言語「Ruby」の開発者である、まつもとゆきひろ氏が語る日経Linuxの連載記事「技術を斬る」で最近、「BASE」という概念がよく登場する。BASEとは、「Baseically Available」（不整合は滅多に発生しないので可用性を重視し）、「Soft-state」（状態の厳密性を追求せず）、「Eventually Consistent」（途中はともかく最終的につじつまが合えばよい）、という考え方だ。 実は、クラウドを支えているのは、この“ゆるい”考え方にほかならない。 トランザクションはもう古い？ BASEは、トランザクションの概念が大量の情報を処理するシステムには適さない、という考えから登場してきた。データを正しい状態で維持するために必要なACID特性、すなわちA（原子性）、C（一貫性）、I（独立性）、D（永続性）を、大規模な分散処理では維持できないという「CAP定
これまでの連載を通して、CouchDBの基本的な概念と使い方、アプリケーションの作成方法までを解説してきました。ここからはさらに一歩踏み込んで、CouchDBをDBサーバやAPサーバとして実際に運用するときに役に立つ機能を紹介していきます。具体的には、次の3つのテーマを取り扱います。 全文検索を導入すれば、CouchDB内にあるすべてのドキュメントを対象に、特定のキーワードを指定して検索できます。ユーザー認証では、例えばDBの管理者権限を特定のユーザーのみに付与できます。ユーザー認証はまだ充実しているとはいえないレベルですが、現時点ではどのような選択肢があるかを紹介していきたいと思います。最後にCouchDBへの負荷を分散させる方法として、CouchDBのインスタンスをノードとして複数用意し、各ドキュメントを分散して配置するやり方を紹介します。これらの手段を目的に応じて生かすことができれば
ドキュメント指向なKVSってことと、字面が似ていると言うことぐらいしか比較する意味がなさそうなCouchDBとMongoDBだけど、ここ2，3ヶ月で両方をそれなりに突っ込んで見てきたので比較してみた。実装面やパフォーマンス、ということよりはどちらかというと(私が感じる)思想的なものや、ユーザ側からの視点での比較。 共通するところ これはもう簡単に、 ドキュメント指向データベース - RDBMSのようなカラムと言ったものを持たずにスキーマレスで好きな情報を入れられる Javascript/JSONを使用 - データ自体もJSONというJavascript由来のフォーマットで持ち(MongoDBはJSONを元にしたBSONというものだが)、データベースのアクセスにはJavascriptを使用する スケールアウトするように考えられている NoSQLな流行 CouchDBの特徴 機能を限定している
随時更新予定。 ツールなど 2010-01-08 kumofsの死活監視はこんな感じでNagiosでやってます - (ひ)メモ 検討と検証 2010-04-01 kumofsに10MBのvalueを入れるとどうなるか実験してみた - sdyuki-devel 2010-02-24 KVS(NoSQL)のまとめと「これから」の設計手法 - どっかのBlogの前置きのような 2010-02-01 kumofs その４・速度比較してみた - とあるWEBプログラマの軌跡（仮） 設計とアーキテクチャ 2010-04-26 hbstudy#10「ずばり動く！kumofs と ずばり動かないケース」 2010-04-25 丸レク2010「分散Key-valueストアkumofsの思想と設計」 2010-02-09 kumofsはなぜ落ちないか 2010-01-26 kumofsはなぜスケールするか 2
Working with hugedomains.com was a quick and easy process. We got to speak to multiple real people located in Colorado without having to wait on hold! Our only complaint was we felt we had to overpay more than this particular domain was worth, and we weren't able to negotiate it down to a level that we felt was fair. However, payment and delivery were seamless, and within a few hours we had all of
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
