Apache Cassandra（アパッチ カサンドラ）は、オープンソースの分散データベース管理システムである。元はFacebook社において大規模データの格納のために開発されたものである。Facebookのデータチームを率いるJeff HammerbacherはCassandraをAmazon DynamoDBのようなインフラストラクチャ上で動作するBigTableデータモデルであると表現している。 Cassandraはイベンチュアル・コンシステンシーにより構造化されたキー・バリュー型データストアを提供する。キーは複数の値にマッピングされ、これらはcolumn familyとしてグルーピングされる。column familyはCassandraデータベースが作成される際は固定されているが、後にfamilyに対し列を追加することは可能である。さらに、列は特定のキーにのみ追加されるので、どの
以前から、Scala には DB アクセス用の API が用意されているが（lib/scala-dbc.jar）、情報が少なくドキュメント等で使い方を紹介されているのを見たことが無い。 ということで、前から気になっていたので試しに使ってみた。 簡単に使ってみた限りでは、PostgreSQL 用の Vendor クラスしか用意されていない等、洗練されていない部分も多く、未完成の印象が強い。（dbc2 があるようで、見た感じはそちらの方が使い易そうな印象） 今のところ、使いこなすにはソースを参照するしか無さそうだが、暗黙の型変換（Implicit Conversions）等を理解していないと読み解くのが困難だと思う。 今回、使用した環境は以下の通り。 Scala 2.7.5 Select 文の実行 今回は以下のような MySQL 上のテーブルの全レコードを出力してみることにする。 custom
この表では言及していませんが、Consistent Hashingやshardingによって分散させやすいというのはすべてのNoSQLデータベースが備えている特徴でしたね。 検証用サーバの準備 では実際のパフォーマンスを比較してみましょう。比較のため、10,000件のデータの書込み/読込みを行います。実行にあたり各種サーバを起動します。 リスト1 検証用サーバの起動コマンド # memcached memcached -u nobody -d # TokyoTyrant sudo ttserver -pid /var/ttserver/pid -dmn /var/ttserver/bench.tch # MongoDB mongod --dbpath ~/tmp/mongodb & # HBase sudo /etc/init.d/hadoop-0.20-namenode start su
分散KVS（キーバリューストア）は、RDBMSの代わりになると思ってはいけない。RDBMSでは当たり前だった機能の一部は、あきらめる必要がある。このため、重要なデータをむやみやたらと分散KVS上に置くのはやめた方がよい。 分散KVSであきらめなければならない機能には、次の四つがある、 ・トランザクション機能 ・排他制御機能 ・読み取り一貫性を保証する機能 ・スプリットブレイン対策機能 逆にいえば、これらを取り込まないことで、分散KVSはRDBMSではかなわなかった、無尽蔵なスケーラビリティーや、極端に短いレイテンシー（要求が返ってくるまでの遅延時間）による高パフォーマンスを実現できたわけだ。 ところが、使い方を間違えれば、たちまち問題が生じてしまう。とりわけ、業務システムにおける重要なデータを分散KVS上に置く場合は注意が必要だ。 トランザクション処理に支障 重要なデータとは、不整合や損失
クラウド時代の新しいデータベースとして、非リレーショナルな構造を持つNoSQLデータベースが話題になっています（NoSQL＝Not Only SQL。命名の経緯はこちら）。そのNoSQLの中で、もっとも注目されているデータベースの1つがApacheのCassandraです。 Cassandraは、Facebookで大規模データ処理のために開発され、その後オープンソースとなり、現在ではApache Software Foundationのプロジェクトとして開発されています。 現在、CassandraはFacebookやDiggなどで使われている、もしくは使うことが検討されているとされ、Twitterでも（ツイートデータの格納には使われないようですが、それ以外の用途で）利用されています。 TwitterとDiggがNoSQLの「Cassandra」を選ぶ理由 Twitterが、Cassandr
データベース研究者の大御所、マイケル・ストーンブレイカー氏が、「SQL URBAN MYTHS」（SQL都市伝説）というWebセミナーを、自身が創設した会社VoltDBで公開しています。 一般にリレーショナルデータベースに対して言われている「SQLは遅すぎる、トランザクションのコストは高すぎる」といった評価について、SQLが遅いのではないし、トランザクション以外のコストが高すぎるのだ、と反論する内容。 これらは同氏が以前から主張してきた内容ではありますが、最近流行しているNoSQLデータベースに対する反論にもなっているため、多くのエンジニアに刺激になる内容となっています。 SQLに関する6つの都市伝説 都市伝説1：SQLは遅すぎる。NoSQLのような低レベルなインターフェイスを使うべき 都市伝説2：キーバリュー型が有望で、SQLは問題外 都市伝説3：SQLデータベースはスケーラブルではない
はじめに 今回からタイプ毎に代表的なNoSQLデータベースを扱っていきます。まず今回は、揮発性key-valueストアの代表としてmemcachedを取り上げます。 なお、利用したコードやプログラムはgithubに置いてあります。適宜参照してください。 どんなところに使える？ memcachedの特徴は、何といってもデータの揮発性（memcachedサーバを停止すると全データが消えてしまうこと）です[1]。そのため、データが消えても影響が小さいところに利用シーンは限られてきます。一方、連想配列（ハッシュ）のように使えて扱いやすいこと、様々なサイトでの事例があること、などから導入はしやすいです。 具体的な利用シーン memcachedの具体的な利用シーンとしては、以下の事柄が考えられます。 RDBMSから取得したデータのキャッシュ 消えても大きな影響の無いデータの保存 一般的には（1）のよ
PortaBaseはWindows/Mac OSX/Linux向けのオープンソース・ソフトウェア。メモやタスク管理、アドレス帳などコンピュータでは蓄積系のデータを扱うことが多々ある。それ専用のソフトウェアも多いが、ほんのちょっと自分好みでない場合も多い。 データ定義 そんな時には自作してみるのも手だろう。もちろん一から全て作成するのではあまりに手間がかかってしまう。ただデータを蓄積するだけであれば、PortaBaseを使ってみると良いだろう。PortaBaseは汎用的なデータベースソフトウェアだ。 PortaBaseは一つのテーブルを扱うデータベースソフトウェアで、項目は文字列/整数/真偽/ノート/日付/時刻/計算値/画像などが扱える。デフォルト値を付けることも可能だ。定義が終われば後は実際にデータを登録していくだけだ。フィールドの定義によってカレンダーが出たり、ファイル選択ダイアログが表
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
各種インフラ技術(OS、ストレージ、ネットワーク)やオラクル製品といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります DB使いであれば、ACID(Atomicity、Consistency、Isolation、Durability)は当たり前の考えかと思います。実は、DBMSならACIDが当たり前というのは、思いこみと言っても良いのです。少なくとも、ACID以外の考え方が存在するのは事実です。 今回は、そんな考え方である、BASE(Basically Available、Soft state、Eventually consistent)を紹介します。クラウドなどの世界で徐々に広がりつつある、トランザクションの考え方です。 この記事は、「BASE: An A
DBT-2とはTPC-Cライクなオープンソースのベンチマークソフトで、OLTP系の負荷を擬似的に作り出すように設計されている。細かい更新系の処理を測定したい時には便利なベンチマークツールである。しかしながら、DBT-2の実行手順は多少面倒くさく、さらにREADMEには偽の（？）情報まで含まれている上にDBT-2の実行手順はあまりWeb上では解説されていない。そこで、今日は簡単ではあるがDBT-2によるベンチマークのやり方を紹介しよう。（以下の例では利用するデータベースをMySQL、DBT-2のバージョンを0.40であると仮定している。） 1. ダウンロード次のページからDBT-2をダウンロードしよう。 http://osdldbt.sourceforge.net/ 2. 補助パッケージのインストール以下のperlパッケージ類はconfigureスクリプトでは「足りないよ」と言ってくれないの
Yet another OSS DB：Firebird（1） Firebirdのアーキテクチャと特性、歴史 Firebird日本ユーザー会のはやしつとむです。今回からFirebirdについて連載をさせていただくことになりました。第1回に当たる今回は、Firebirdとはどんなデータベースで、誰が作ってきたのかなどを中心にまとめています。今後の予定は、Firebirdのデータベースファイルの内部構造、標準関数、User Defined Functionの作成について、といった流れを予定しています。この連載を通じて、Firebirdのファンが1人でも増えてくれることを願っています。 Firebirdのインストールから起動まで さて、firebirdとはいったいどんなRDBMSだろう？ 今回は、手始めに導入の手順はもちろんだが、Firebirdが生まれた背景や、アーキテクチャの特性にも触れたいと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く