FoundationDB is Open Source
Published April 19, 2018The next chapterStarting today, FoundationDB starts its next chapter as an open source project! FoundationDB is a distributed datastore, designed from the ground up to be deployed on clusters of commodity hardware. These clusters scale well as you add machines, automatically heal from hardware failures, and have a simple API. The key-value store supports fully global, cross
細かすぎて伝わらないmdbm
おまけ話として、mdbmはLinear Hashingと呼ばれるハッシュアルゴリズムの影響を強く受けています。 Linear Hashingの詳細はwikipediaをご覧ください。 http://en.wikipedia.org/wiki/Linear_hashing このアルゴリズムによりmdbmは、扱うデータサイズが大きくなれば、動的にHashTableを拡大することができる非常に便利な特性を持っています。 しかし、冷静になって考えてみてみましょう。このLinear Hasingの管理用のテーブルを走査する計算コストは可能なら避けるべきです。 mdbmをはじめ、多くのKVSでは最終的なデータのサイズの予想がつくのであれば、あらかじめ大きめのサイズでデータベースファイルを作成する方が好ましいでしょう。 この辺の話に興味がありましたら、コードの「hashval_to_pagenum()」
人間とウェブの未来 - mrubyのHashとmruby-{Redis,Vedis,Memcached}でSET/GETの簡易ベンチマークしてみた
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 mrubyでKey-Value Storeにアクセスできるクライアントをこれまでいくつか作ってきたので、VedisやHashの性能が見たいというのと、その他ちょっとした興味でそれぞれのKVSのSET/GETを投げてみて速度の比較をしてみました。 といっても、それぞれの良さを考慮したベンチマークではなくソフトの良し悪しを測るものではないので、この条件だとこういう結果になるという参考程度に見て頂ければと思います。 比較対象は、mrubyのHash、Redis、Vedis（In-Memory）、Vedis（On-Disk）、Memcachedです。それぞれ、Fedora19のyumでインストールした後にserviceコマンドで起動させただけの状態で
yrmcds 0.9.0 リリース - Cybozu Inside Out | サイボウズエンジニアのブログ
@ymmt2005 こと山本泰宇です。 今回は memcached 互換で冗長構成を簡単に組める自社製 KVS である yrmcds のリリースをご案内します。 ... この Redis 全盛なご時世になんで？とか、repcached や Kyoto Tycoon があるじゃない、といったツッコミの嵐が聞えてきそうです。わかってます、わかってますから物を投げないで！ 順を追って説明しますので、批判はそれからにしてください！ 何が欲しいのか 私は日頃 cybozu.com のインフラで動作するソフトウェアを開発しています。リリース後もうすぐ２年になりますが、お蔭様で 4,000 社以上にご利用いただくまでになりました。商売繁盛で嬉しいのですが、運用側は日々増えるデータとアクセスを捌くべく奮闘しています。 ここのところ問題になっていたのが、MySQL に保存しているセッション情報でした。アプリ
NoSQL Data Modeling Techniques
NoSQL databases are often compared by various non-functional criteria, such as scalability, performance, and consistency. This aspect of NoSQL is well-studied both in practice and theory because specific non-functional properties are often the main justification for NoSQL usage and fundamental results on distributed systems like the CAP theorem apply well to NoSQL systems. At the same time, NoSQL
HbaseとHadoopMR - 急がば回れ、選ぶなら近道
Hbase勉強会のまとめの延長として 今後の考え方をまとめておきます。 まずは前提として <一般論> Hbaseにかぎらず、NoSQL系一般に言えることではあるが Usecaseを意識して利用する事が必要だ、ということだと思う。 最近の傾向としては、Googleでも顕著だけど、 一定の用途をターゲットにして 特定のミドルを開発するという方法が結構多い。 Hbaseもその流れはあるので、 そのあたりは意識する必要はあるかもしれない。 Hbaseついては、注目するとすればFacebookになるかな。 http://www.cloudera.com/resource/hw10_hbase_in_production_at_facebook いずれにしても、割とうまくいっているUsecaseの情報の有用性は 他の技術よりも高いと思う。 基本的に単純に分散KVSを使いたいならHbaseにこだわる必要
グーグル、NoSQL軽量ライブラリ「LevelDB」を公開。ChromeブラウザのIndexedDBとして採用
LevelDBはSQLをサポートせず、クライアント／サーバ型でもなく、シングルプロセスからアクセスされることを想定したいわゆるNoSQLの高速なキーバリュー型データストアを実現するためのライトウェイトなライブラリだと説明されています。 ChromeブラウザでHTML5の仕様として策定中のIndexedDBを実装するものとして開発されたようです（ドキュメントに明記されていないのですが）。 LevelDBを開発した理由 LevelDBのWebサイトによると、LevelDBは以下の主な機能を備えています。 基本的な操作は、Put(key,value), Get(key), Delete(key) 1つのトランザクションとして複数の変更操作が可能 データは自動的に圧縮し保存される Hacker Newsの記事によると、当初はLevelDBを開発する代わりに平林幹雄氏が開発したTokyo Cabin
redisのサービスへの投入
こんにちわ、ミツバチワークス stoneです。 今回は、前回、ベンチマークをとったredisをサービスに投入した、その方法について、ご紹介します。 1 redisのセットアップ 1.1 redisをインストールredisは、2.0.2を使用しました。 redisのインストールは、 # tar zxvf redis-2.0.2.tar.gz # cd redis-2.0.2 # make install ですんなり出来ました。 コンパイルされたバイナリは、/usr/local/bin/以下にコピーされています。 1.2 コンフィグDECOLOGでは、ApacheとMySQLを除いて、daemontoolsを利用して運用しています。 そのため、redisのコンフィグは、デフォルトのredis.confから、以下の項目を修正してあります。 (デフォルトのredis.confは、redis-2.0
NoSQL redisとMySQLのベンチマーク比較
という構成です。 サーバーAベンチーマークを取るサーバー このサーバー上で、abを走らせます サーバーBApache + PHPのサーバー DECOLOGで、実際にサービスしているWebサーバーと 同じセットアップをしてあります。 関係ありそうなソフトのバージョンを上げておくと。。。 Apache 2.2.x(MaxClients 200) PHP 5.2.x(APC 3.0.x) MySQLへの接続 PEAR::DB Redisへの接続1 owlient-phpredis-2.0.4-5 Redisへの接続2 Rediska0.5.0 と、なっています。 サーバーCMySQLサーバー バージョン: 5.0.x ストレージは、InnoDB、BlackHole、Archiveを使用しました。 InnoDBのパラメーターのうち、スピードに関係ありそうなモノのは、 こんな↓感じで設定しています。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - ujihisa/distributed-kvs-consistent-hashing: It assumes you have 3 servers, and 2 servers are always working perfectly fine.
GitHub - pankona/orochi: Like a distributed KVS
GitHub - twitter/fatcache: Memcache on SSD