This document is a technical summary of Kumofs, an open-source distributed key-value store. It shows Kumofs outperforming Memcached on throughput tests, handling over 3 million requests per second. Kumofs uses consistent hashing to distribute data across server nodes, and can scale horizontally by adding more servers. It also demonstrates high performance on Linux servers with Intel and AMD CPUs.R
分散Key-Valueストア kumofs を、本日オープンソースソフトウェアとしてリリースしました！ kumofs@SourceForge kumofs関連資料まとめ kumofsとは？ kumofs（クモエフエス）は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装
2年前にPHPのセッション管理に使う箱選び 4で、セッションストレージとしてはMySQLのInnoDBを使用するのが良いと結論付けた。 当時は主にセッション数が増えていった場合のパフォーマンスについて調べて結論を出したものの、実際にMySQLをセッションストレージとして使用すると、さらに負荷が高くなった場合のパフォーマンスや可用性の部分にちらほら課題が見えてくる。 つまり、大規模なセッションストレージとして使うにはMySQLは高機能過ぎて重く、さらに冗長構成になっていても障害発生時の対応は手動が基本になってしまう。(自動化できないわけではないと思う) MySQL :: MySQL 5.6 リファレンスマニュアル :: 17.3.6 フェイルオーバー中にマスターを切り替える セッションデータの集中管理をやめる*1というのも手だけれど、それはそれで大変なので別のセッションストレージにする方向で
カスタマイズ可能なポータルサービスを提供するフランスの「NetVibes」は、バックエンドデータベースとしてミクシィの平林幹雄氏が開発し、同社内でも利用されているNoSQLデータベースの「Tokyo Tyrant/Tokyo Cabinet」（以下Tokyo Tyrant）を採用しているそうです（追記：平林氏は7月末でミクシィを退職されるとのこと）。 なぜNetVibesはTokyo Tyrantを採用したのか、その理由がmyNoSQLの記事「Netvibes: A Large Scale Tokyo Tyrant Deployment Case Study」で紹介されています。NetVibesは、Hadoop、CouchDB、Tokyo Tyrant、File system、MySQLを評価した上でTokyo Tyrant/Tokyo Cabinetを採用したとのこと。 NetVibes
採用情報RECRUIT "ミチを切り拓く"強い意志と覚悟を持ち、仲間として共に切磋琢磨し、挑戦していける、そんな人材を求めています。 プレスリリース 2012年2月9日 株式会社VOYAGE GROUP VOYAGE GROUP、クレイジーワークス社の電子書籍事業「Androbook」を事業譲受 ～Android Marketにおける電子書籍市場へ参入～ 事業開発会社である株式会社VOYAGE GROUP(東京都渋谷区、代表取締役CEO：宇佐美 進典)は、2012年2月8日付けで、株式会社クレイジーワークス(東京都渋谷区、代表取締役総裁：村上 福之)より、Android Market向け電子書籍事業「Androbook」を事業譲受いたしました。これによりVOYAGE GROUPは、新たにAndroid Marketにおける電子書籍事業に参入いたします。 「Androbook」は、Andro
2010/09/07 KVS（キー・バリュー・ストア）に分類されるオープンソースのRedisの新バージョン、「Redis 2.0.0」が2010年9月5日にリリースされた。Redisはmemcachedと同様にキーと値のペアをメモリ上に保持するKVSの一種だが、3つの際立った特徴がある。1つはハッシュ以外のデータ構造もサポートしていることで、リスト型、集合型、順序付き集合型などのデータ構造が扱え、サーバ側でコレクションに対するpush/pop、コレクション同士のunion/intersection、数値のincr、decrなどの操作がアトミックに行える。バージョン2.0では複数の操作を1つにまとめてアトミックに操作するコマンドも増えている。 もう1つのRedisの特徴は、マスター・スレーブによるレプリケーション設定ができ、リード側のスケールアウトが容易にできること。 そして3つ目の特徴は、
memcachedとredisのKVS 速度対決をやってみて，やっぱり低遅延性というかレイテンシではmemcachedの勝ちという結果が出たのですが， KVS最速テスト第二弾（memcached V.S. Redis） - なぜか数学者にはワイン好きが多い 逆に圧倒的にredisの方が速いという結果を提示しているブログがありました． Redis vs Memcached | /sys/toilet As you can see here, Redis came up short by a range of 20-26% the speed of memcache. memcacheよりredisの方が2割ほど早いようだ． ただし環境設定が結構違うので，単純にこちらのベンチと上記のベンチのどちらが正しいというのは言えないので，少し考えてみました． 違いは沢山あります． こちらはPocoライブ
最速KVS研究第4弾 - なぜか数学者にはワイン好きが多い どこまでも続きます． 目的が全く違う2者ですが，敢えて比較してみました． もちろん，Google LevelDBと似たコンセプトのものとの比較も今後進めますが．．． とりあえず，キー長はmd5ハッシュの長さ固定，バリュー長を変化させ，かつ同時アクセス数をスレッドアクセスで変化させて読み書き時間を測ってみました． まず，バリューの長さが100バイトと短い場合のベンチ． 同時アクセス数を表すスレッド数が少ないときはLevelDBの書き込みが爆速，読み込みはなぜか遅い．．．redisはスレッド数に関わらず安定して読み書きとも中間な感じです． 次，バリューの長さが1000バイトの中間的ベンチ． やはりLevelDBはスレッドが1だと書き込みが最も速く，同時アクセス数が増えると遅くなる． 読み込みの方は，redisよりは遅いものの同時アクセ
次世代通信規格「5G（第5世代）」を使う大きなメリットは、4Gよりも高精細で遅延の少ない映像を配信できる点だ。この特徴を生かし、建設機械や医療機器を遠隔操作しようとする取り組みが広…続き 5Gがやってくる つながる機器は100万台 ［有料会員限定］ ５Ｇでロボット遠隔操作や遠隔医療、ドコモが公開
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
