第5回Pacemakerを運用してみよう![保守運用編(2)] 岡和田拓也 2011-05-12
![Pacemakerでかんたんクラスタリング体験してみよう! 記事一覧 | gihyo.jp](https://cdn-ak-scissors.b.st-hatena.com/image/square/7241c583676d54fc052c4388a6edd25e4c7f280b/height=288;version=1;width=512/https%3A%2F%2Fgihyo.jp%2Fassets%2Fimages%2Fgihyojp-ogp.png)
第5回Pacemakerを運用してみよう![保守運用編(2)] 岡和田拓也 2011-05-12
データベース研究者の大御所、マイケル・ストーンブレイカー氏が開発し、NoSQLデータベースをも上回る性能を発揮するリレーショナルデータベース「VoltDB」。前回の記事では、その特徴と、NoSQLデータベースのCassandraとのベンチマーク比較を紹介しました。 今回はVoltDBのアーキテクチャについて調べたことをご紹介しようと思います。基本的にはVoltDBのWebサイトやリンク先の内容を基にしています。また、ブログ「独り言v6」のエントリ「VoltDB登場 – RDBMSのようでRDBMSではない新システム」も参考にさせていただきました。 シェアドナッシングな分散インメモリデータベース VoltDBのアーキテクチャは、FAQのページで以下のように説明されています(英語を訳したものを引用しています。以下同じです)。 VoltDBは、シェアドナッシングなサーバ群から構成されるスケーラブ
「多くのOLTPデータベースは30年前の設計を基にしており、今日の“Webスケールな”データベースの負荷を想定していない。これら伝統的なデータベースは、処理時間の90%以上がログ、ロック、ラッチ、バッファ制御といったオーバーヘッドに費やされ、しかもそれらによって限られた性能やスケーラビリティしか実現できていない」 Ingresの開発者でありInformixのCTOなどデータベースベンダの要職を歴任したデータベース研究者の大御所、マイケル・ストーンブレイカー氏が開発したVoltDBはプレスリリースでこのように既存のリレーショナルデータベースの欠点を示した上で、インメモリデータベースをベースにこれらのオーバーヘッドを除去し、ACIDによるデータ一貫性を維持しつつ大きな性能向上とスケーラビリティを実現したと説明されています。 SourceForge.jpの記事「「NoSQL」を上回る性能を目指す
首藤 一幸 Last-updated: January 5, 2010 注: このページの文章は Software Design 誌 2010年 2月号に掲載された以下の記事の元原稿です。 Software Design 誌編集部の了承の元に、本ウェブページに掲載しております。 首藤一幸: "key-valueストアの基礎知識", Software Design 2010年 2月号, p.14-21, (株)技術評論社, 2010年 1月 18日 クラウド、特にPaaS向けのソフトウェア開発が現実のものとなり、 そこではリレーショナルデータベースとは違ったデータベースが 勢いを増しています。 その代表であるkey-valueストアを解説します。 もくじ key-valueストアとは なぜkey-valueストアか key-valueストアの使いどころ key-valueストアとNoSQLの
分散Key-Valueストア kumofs を、本日オープンソースソフトウェアとしてリリースしました! kumofs@SourceForge kumofs関連資料まとめ kumofsとは? kumofs(クモエフエス)は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装
8月に入社した佐々木です。こんにちわ! 入社してからはHadoopを使うことが多く、日々、大規模データと格闘しています。大変ではありますが、個人ではなかなか触ることが出来ないような大規模データを触れるのは楽しいです。 さて、Hadoopは最近色々なところで使われ始めてきていると思うんですが、実際に利用してみて困った事やtipsなど、実践的な情報はまだあまり公開されていません。その辺の情報をみんな求めているはず…!! そこで、僕が実際に触ってみて困った事やHadoopを使う上でポイントだと思ったことなどを社内勉強会で発表したので公開してみます。Hadoopを使っている(使いたいと思っている)方の参考になれば幸いです。 [slideshare id=2711363&doc=20091214techblog-091213183529-phpapp02] Hadoopの利用はまだまだ試行錯誤の連続
TISは10月27日、東京エレクトロンデバイスが総代理店を務める米グリーンプラムのデータウェアハウス用エンジン「Greenplum Database」の販売代理店契約を締結したことを発表した。TISはGreenplum Databaseのシステムインテグレーションを提供し、関連ビジネスにおいて3年で33億円の売上を目指す。 Greenplum Databaseはオープンソースとして提供されているPostgreSQLを拡張したデータウェアハウス用エンジン。分散ノードがそれぞれストレージを持つシェアード・ナッシング型で構成されている。米国では100を超える顧客が利用しており、その利用者の20%が100テラバイトクラスの大規模データウェアハウスを構築している。 グリーンプラム製品の日本での販売は、TISがシステムインテグレーションおよび導入支援を、東京エレクトロンデバイスが技術サポートおよび営業
こんにちは。中村です。 MySQLにはMyISAM、InnoDB、CSVなどのいくつかストレージエンジンがありますが、皆さんはSpiderというストレージエンジンを聞いたことはありますでしょうか。Spider Storage Engineは斯波健徳さんにより作成されたDatabase Shardingを可能にするストレージエンジンでMySQL 5.1で利用可能です。 先日、某集まりで斯波さんとお会いしたときにSpiderを作っているということを教えてもらったので、早速詳しい内容を教えてもらうことにしました。 ※Spiderについての説明資料はMySQLカンファレンス 2009にて斯波さんが発表されたときのスライドがあります。スライドの直リンク(zip) Spider Storage Engine について posted by (C)フォト蔵 Spider Storage Engineとは?
大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名:アプリケーションレベルパーティショニング/レベル2分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加(とそれにともなう負荷の再分散)が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く