単なるキャッシュじゃないよ！？infinispanの紹介え、まって。その並列分散処理、Kafkaのしくみでもできるの？ Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理NTT DATA Technology & Innovation
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
Kyoto Cabinet 1.0.0リリース！ - mixi engineer blog
夏が近づくとウキウキしてくるmikioです。昨日ついにリリースされたKyoto Cabinet 1.0について今回は報告します。 1.0の位置づけ コミュニティ毎や製品毎にバージョン番号割り当ての方針は異なるわけですが、私の個人的なポリシーでは、1.0には特別な意味があります。すなわち、0.xのバージョンはbeta版的な位置づけで、「実サービスに使うのはちょっと待った方がいいですよ」ということを意味します。一方で、1.xはstable版的な位置づけで、「よろしければ実サービスでも使ってみてください」ということを意味します。私がstable版に設定する原則を以下に列挙します。 安定稼働を至上命題とする（バグがあればその修正を最優先する） APIを変更しない（変更するとしても後方互換性を維持する） DBファイルのフォーマットを変更しない（変更するとしても後方互換性を維持する） なるべく機能追加
WTF is a SuperColumn? An Intro to the Cassandra Data Model — Arin Sarkissian
For the last month or two the Digg engineering team has spent quite a bit of time looking into, playing with and finally deploying Cassandra in production. It’s been a super fun project to take on – but even before the fun began we had to spend quite a bit of time figuring out Cassandra’s data model… the phrase “WTF is a ’super column’” was uttered quite a few times. If you’re coming from an RDBM
NoSQLデータベースを40種類以上リストアップ、キーバリュー型にもいろいろある
Webスケールのデータを扱うためにさまざまなデータベースが登場してきている、ということを昨日のエントリ「データベースは目的別に使い分けるべし」で紹介しました。 特にリレーショナルモデルをベースとしない、非SQL系（NoSQL）と呼ばれるさまざまな種類のデータベースが登場してきています。非SQL系のデータベースは以前からオブジェクトデータベースやドキュメントデータベース、階層型データベースなどが存在していましたが、最近注目されているのがキーバリュー型データストアと呼ばれるデータベース。 ブログ「High Scalability」にポストされたエントリ「A Yes for a NoSQL Taxonomy」では、これら非SQL系のデータベースを詳細に9分類し、それぞれの分類に属するデータベースをリストアップしています（基になったのは「NoSQL is a Horseless Carriage」
A Yes for a NoSQL Taxonomy - High Scalability -
NorthScale's Steven Yen in his highly entertaining NoSQL is a Horseless Carriage presentation has come up with a NoSQL taxonomy that thankfully focuses a little more on what NoSQL is, than what it isn't: key‐value‐cache memcached, repcached, coherence, infinispan, eXtreme scale, jboss cache, velocity, terracoqa key‐value‐store keyspace, flare, schema‐free, RAMCloud eventually‐consistent key‐value‐
OPC Diary: Key-Value Store(s)という流れ
« CanonはCAPTプリンタの64bit版ドライバーを出せ!! | メイン 2009年02月27日 Key-Value Store(s)という流れ はじめは大規模なWebサービスを提供する現場の工夫に始まった分散キャッシュ技術、これが最近ではキャッシュのみならずデータのレプリケーション、永続化も可能となりKey-Value Store(KVS)と言われるようになった。 実質的にOracleやIBMのくそ高いインメモリデータベースにかなり近づいてきているが、それらがメモリ上にRDBMSを構築する物であるのに対し、KVSはキー値とデータというもっと単純なデータ構造を持つのが大きな違いだ。 スケールアウトによる負荷分散を前提とする大規模なWebサービスやユーティリティコンピューティングにとってRDBMSを前提とするOLTPの考え方はそれがボトルネックになり、パフォーマンスと冗長性に
ウノウラボ Unoh Labs: Tokyo Tyrantを使ってみて
yamaokaです。 通常のデータベースとしてではなく、Key-Valueストアの選択肢として Tokyo Tyrantを少しずつ使ってみています。 実際に運用するにあたって、いくつか行ったことを書いておきます。 ちなみに、現在の構成は1台のみでの運用です。 マルチマスター構成やレプリケーションなどは行っていません。 PHPのクライアント Tokyo Tyrantを利用するのはPHPのアプリケーションからです。 最初はmemcachedプロトコルを利用して PECL::memcacheを使っていましたが、 データの大量更新を連続で行うとデータの取得が正常に行えなくなる現象が発生したため、 Net_TokyoTyrantを一部改変したものをライブラリとして利用しています。 パフォーマンスではPECL::memcacheに負けますが、クリティカルな処理をしていないこともあり、 今のところ問題に
kumofsはなぜスケールするか - Blog by Sadayuki Furuhashi
先日、分散Key-valueストア kumofs を公開しました。 多く方から反響とフィードバックをいただいています。ありがとうございます。 今回は、kumofs はなぜスケールするのか、なぜスケールすると言えるのかーということについて紹介したいと思います。 ところでスケーラビリティとは何か？ スケーラビリティとは、利用者や仕事の増大に適応できる能力・度合い とされています（端的！）*1 。Scalability を日本語にすると、拡張性 と訳されるようです。 ただ一口でスケーラビリティと言っても、様々な側面があります。ITシステムでは主には処理性能と運用に関することを指す場合が多いと思いますが*2、その中にも様々な側面があります。 なぜスケーラビリティが必要か スケーラビリティは システムなどが持つべき望ましい特性 であって、高いに越したことはありません。しかし、高いスケーラビリティはタ
kumofsはなぜ落ちないか - Blog by Sadayuki Furuhashi
前回は、kumofsはなぜスケールするかということについて紹介しました。その中で最後に、耐障害性もスケーラビリティにとって重要だーと述べました。 そこで今回は、kumofsはなぜ落ちないのか、なぜ耐障害性が高いと言えるのかーということについて紹介したいと思います。 分散システムはテストが難しいことに定評がありますが（たぶん^^;）、その中でも耐障害性の検証は最上級に困難な部類です。 耐障害性は実際のところ、アルゴリズムの設計以前に実装上のバグが大きく影響するので、設計上は耐障害性が高いと言っていても、実際に使ってみると良く止まるという話はありがちな話です。（個人で開発している場合など、開発リソースが小さい場合はなおさら） そのため耐障害性の高いシステムを実現するためには、実装しやすくバグが入り込みにくい設計も重要かなーと思います（もちろん、アルゴリズムも重要ですが）。 分散システムには複雑
Key Value Store勉強会に行ってきました by kumofsのひと - Blog by Sadayuki Furuhashi
※分散Key-Valueストア「kumofs」を公開しました！ 先日開催されたKey Value Store勉強会に行ってきました。私の発表資料は↓ここからダウンロードできます。 kvs-kumofs.pdf 合わせて読むと理解が深まるかもしれない： スマートな分散で快適キャッシュライフ - mixi Engineer's Blog：Consistent Hashについて バイナリシリアライズ形式「MessagePack」：kumofsのプロトコル。高速なストリームバッファとストリームデシリアライザの実装も含まれています。 Protocol Buffersは遅い：MessagePackのベンチマークとProtocol Buffersとの比較。タイトルは釣り。 memstored：IOアーキテクチャのプロトタイピング マルチコア時代の高並列性IOアーキテクチャ Wavy memcached
memcachedを超える成果も、Interopで若手技術者がクラウドを支える技術を競う
「日本でゼロからクラウドを生み出すムーブメントを作り出したい」（実行委員長 門林雄基氏）---“クラウドを支える技術”の開発力を競う「クラウドコンピューティングコンペティション」が2009年6月11日、Interop 2009の会場で開催された（写真1）。企業や大学・大学院の研究者、そして高校生を含む若手エンジニアが、新しいアイディアと技術力で作り上げたクラウドコンピューティングの基盤ソフトウエアを披露した。 クラウドコンピューティングコンペティションは、奈良先端科学技術大学院大学の門林雄基准教授らの呼びかけで実現したイベント。若手のエンジニアがP2P（ピア・ツー・ピア）技術や分散データ処理技術といったクラウドコンピューティングの基盤技術を開発し、その成果を競う。検証環境として、情報通信研究機構（NICT）が運用するクラスタ環境「StarBED」のコンピュータを最大1000台まで使用可能で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.cidrdb.org/cidr2011/Papers/CIDR11_Paper32.pdf