データベースの世界でいま注目されているのがNoSQL。特にキーバリュー型データストアは、グーグルのBigTable、FacebookやTwitterが内部で利用しているCassandraやAmazonクラウドが提供しているSimpleDBなど、すでに実際に使われ始めています。 ではそのNoSQLをリレーショナルデータベースの代わりに使ってシステムを構築するとどうなるのか？ 身をもって体験したことを記したShinya Kawanaka氏によるプレゼンテーション「間違った方向にCassandraを使ってみた」が公開されています。 NoSQLを用いたシステム構築は、リレーショナルデータベースによる構築どう違うのか？ とても分かりやすくまとめられています。ご本人の承諾もいただいたので、その内容を紹介しましょう。 NoSQLを使ったときに起こる恐ろしい事例 プレゼンテーションのテーマは「NoSQLを

はじめに 真理値と論理演算の重要性 プログラマやSEのみなさんは、真理値（真偽値）というものをご存じのことと思います。ほとんどの言語が持っている基本的なデータ型で、数学者George Booleの名前にちなんで「BOOL型」とか「BOOLEAN型」とも呼ばれています。コンピュータを利用していると、BOOLEAN型が持つtrue（真）とfalse（偽）の2つの値と、NOT、AND、ORという3つの演算子だけから成るシンプルな演算（論理演算）を行うことが多くあります。これはプログラミング言語だけでなく、コンピュータの回路の基礎にもなっている演算です。 SQLにおける真理値と論理演算 SQLにも、真理値と論理演算が存在します。存在するどころか、WHERE句やHAVING句は、それ全体が論理演算のカタマリです。だから真理値はSQLの根幹をなす重要な要素と言っていいのですが、それにもかかわらず、SQ

分散Key-Valueストア kumofs を、本日オープンソースソフトウェアとしてリリースしました！ kumofs@SourceForge kumofs関連資料まとめ kumofsとは？ kumofs（クモエフエス）は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装

実験エントリです。 予習してみる 「転置インデックス」というキーワードで検索して、しばらく勉強してみます。 転置インデックス - Wikipedia mixi Engineers’ Blog » 転置インデックスを実装しよう ASCII.jp：悟空、秘剣「転置インデックス」を手に入れる ｜Googleはなぜ的確に探せるのか？ [を] 転置インデックスによる検索システムを作ってみよう！ 転置インデックスで学ぶ検索エンジンの中身アプリ - 睡眠不足？！ うーんなるほど。分かったような分からないような。 作ってみる とりあえず、Twitter4Jを使ってこんなデータを用意しました。ちなみに人選は漢(オトコ)のコンピュータ道: MySQLerのTwitterアカウントまとめ。を参考にさせていただきました。 5707049458,2009-11-14 20:28:34,sakaik,@hbstudy

Song of Cloudで送金のトランザクション処理パターンが紹介されていました。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 同様のpython版がこちら Distributed Transactions on App Engine - Nick's Blog 上記のやり方で基本的には問題はないのですが、バージョン管理による楽観的排他制御を行っていないので、送金だけを考えるなら、残高を差分で更新しているので大丈夫ですが、これを一般的なパターンに拡張しようとすると、楽観的排他制御は必要になります。 楽観的排他制御とは、エンティティにバージョン番号を持たせておいて、メモリ読み込んだときのバージョン番号と書き込むときのバージョン番号が等しいことを確認する方法で、RDBMSの場合は、次のようなSQLを実行することで実現しま

MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ

MySQL Clusterのデータノードであるndbd（もしくはndbmtd）プロセスは、内部的にはマルチプルステートマシン（ブロック）がシグナル（もしくはメッセージ）を交換するという構造になっており、高い同時実行性を実現しているということについては前回述べた通りである。今日は、ndbd内部にどのようなカーネルブロックが存在するかということについて大まかに説明しよう。前回の話を踏まえて読んで頂ければ、何となくイメージだけでも掴めるのではないかと思う。まずは次の絵を見て頂きたい。これは俺の脳内から引っ張り出したndbdの構造のイメージ図である。 矢印はブロック同士の相関関係（シグナルの送受信など）を示すのだが、この絵に描かれているものは非常に省略されたものであり、実際にはもっと複雑に絡み合っているのだということを覚えておいて欲しい。例えばQMGRやDBDICTといったブロックは、他のブロック

サロゲートキーVSナチュラルキー DBエンジニアの方なら、サロゲートキー（代理キー）という言葉をご存じでしょう。これは、テーブルへの入力データにある列を主キーとせずに、システム側で独自に割り当てるキーのことです（一般的には連番が使われます⁠）⁠。これに対して、入力データ自体の列を主キーにする場合はナチュラルキー（自然キー）と呼びます。 サロゲートキーは、基本的には不要なものです。入力データに一意なキーが存在していればそれを主キーとして使うことで、普通は問題ありませんし、オートナンバリングの機能も長らく標準SQLには存在していなかったからです（そのため、今でも実装ごとにやり方はバラバラです⁠）⁠。しかし、以下のような業務要件の場合には、サロゲートキーを使うことを考えます。 ① そもそも入力データに主キーにできる項目がなく、データが重複している場合 ② 主キーの値が使いまわされる場合 ③ 主キ

素朴なBigtable、できること できないこと：分散Key-Valueストアの本命「Bigtable」（2）（1/2 ページ） RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 あまりにもRDBとは異質な「Bigtable」 前回の「もう1つの、DBのかたち、分散Key-Valueストアとは」では、連載第1回目として、クラウドコンピューティングにおける新しい潮流である「リレーショナルデータベース（RDB）から分散Key-Valueストア（分散KVS）への移行」が、どのようなパラダイムシフトをもたらすのかを解説しました。今回からは、グーグルが運用する代表的な分散KVS「Bigtable」の内部構造を紹介し、クラウドの本質をより深く掘り下げます。 前

2週間ほど前に「インメモリデータベースがクラウド時代の主流になるという期待」というエントリを書きました。ハードディスクに代わり、メモリをデータベースの永続化手段とするインメモリデータベースは、超高速なアクセスとスケールアウトを実現する、クラウド時代のデータベースの主役になるのではないか、という内容です。 この記事に関して、TechVisorの栗原さんと次のようなやりとりをしました。 確かに、Oracle Real Application Cluster（以下、Oracle RAC）でデータベースが全部載るくらい十分にキャッシュ用のメモリを割り当てれば、メモリ上でデータベースを操作するインメモリデータベースと同じことではないのか、とも思います。 両者の違いは何かあるのでしょうか？ 調べてみることにしました。 インメモリデータベースは1000倍速い 調べてみるとすぐに、両者には明確な性能差があ

クラウドの伝道師といえるほど熱心にクラウド関係の講演や執筆を行っている早稲田大学 丸山不二夫教授は、クラウドの技術的な発展について次のような見通しを、UNIX magazine 2009 springの37ページに書いています。 筆者は、データのパーシステンシの担い手が、ディスク上のファイルシステムからメモリに移ろうとしていることが、クラウドシステムの技術的な発展方向だと考えている。 僕は今年の1月の丸山氏が登壇したセミナーでこの考えをはじめて聞いたとき、ハッとしました。 クラウドのアーキテクチャでは、クラウドを構成するいずれかのマシンが故障しても大丈夫なように高い冗長性が保証されています。それだけ高い耐障害性を備えているなら、データの永続性を保つためにデータをメモリに置いたままでいいではないか、という斬新かつクラウドのアーキテクチャに沿った考え方に感銘を受けたためです。 実際に長期にわた

データベースのデータはさまざまな業務で利用されています。データベースに障害が発生すると多くの業務やサービスが止まり、ビジネスに大きな影響を及ぼしてしまいます。しかし、どのようなデータベースシステムであれ、障害が発生する可能性はゼロではありません。このリスクを最小限にとどめるためには、「障害は起こり得る」と想定した対策が必要です。 そこで今回は、データベース障害対策の基礎として、障害の備えと、復旧（リカバリー）の仕組みをおさらいします。 データベース障害の種類 データベースシステムには、以下のような障害が発生する可能性があります。 サーバ障害によるメモリ上のデータ損失 ネットワーク障害によるトランザクションの異常終了 ユーザーの誤操作によるデータ損失 自然災害による物理的な破損　など このように、データベースシステムに発生し得る障害と、その原因や影響範囲は多岐にわたります。本稿では、障害の中

株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 まともな議論になっています。炎上というのはコメントをつけてくれた方々に失礼かもしれませんが、何回も炎上してきたし、何回も同じことを書いてきたし、それどころか10年言い続けてるし……。 がしかし、この業界のお客様から、このようにご意見を頂戴した（わたしが猛烈に望んでいたコメントなんですけど自作自演じゃないからね）。 http://el.jibun.atmarkit.co.jp/g1sys/2009/06/vb6-8111.html#comment-24715757 そこで、以前からの蒸し返しですが、「上流の技術者はSQLを高いレベルで習得すべき」と改めて一度、声を大にして言いたい。 その前に余談ですが、VB6と.NET（とSQL）について。 どっかでコメントしまし