グーグル、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コマンドリファレンスを翻訳しました - YAMAGUCHI::weblog
はじめに こんにちは、Python界のはみだし刑事純情派です。さて、最近 id:a2c と @shibukawa ととりかかっていたRedisドキュメントの翻訳プロジェクトですが、自分が担当していたコマンドリファレンスがようやく翻訳完了したのでここにお知らせします。 翻訳したもの とりあえず自分が翻訳したのはコマンドリファレンスとデータ型について コマンドリファレンス — redis 2.0.3 documentation データ型 — redis 2.0.3 documentation そもそもRedisってなんですか？ 「翻訳したのはわかったけど、とりあえずRedisって何よ？」って方には下記をご参照あれ。 id:Voluntas お疲れ様です。 redis 使ってますか？ - Twisted Mind すげーざっくり言えばKVSだけどもmemcachedよりは機能がたくさんあるんじゃ
第23回 InfoTalk 分散ストレージの資料を公開いたしました | GREE Engineers' Blog
はじめまして。グリーの田尻です。 先日、10月15日に産業技術大学院大学で行われた第23回 InfoTalk 分散ストレージにて、弊社kgwsが登壇させていただきました。 第23回 InfoTalk 分散ストレージ 講演資料を公開して欲しいとのご意見をいただきましたのでグリーエンジニアブログにて公開させていただきますね。 Gree大規模分散ストレージ戦略 ご意見・ご感想は公式ハッシュタグまでお願いいたします。#nanofs グリーの大規模分散ストレージ戦略(nanofs) グリーの大規模分散ストレージ戦略(nanofs) Vol.1 グリーの大規模分散ストレージ戦略(nanofs) Vol.2
グリーの大規模分散ストレージ戦略(nanofs) Vol.2 | GREE Engineering
はじめに グリー株式会社でエンジニアをしておりますkgwsと申します。 今回は、前回に引き続き分散ストレージ(nanofs)のHTTPメソッド毎の処理を紹介させていただければと思います。 nanofsは5つのHTTPメソッド(GET、PUT、DELETE、HEAD、MKCOL)をサポートしております。今回は主なGET、PUT、DELETEの3つについてご説明させていただきます。 まずは構成のおさらい nanofsは、主に3つのプロセスで構成されております。 nanofsd(dispatcher) アプリケーションサーバからリクエストを受け取り実際に保存されているnanofsnに振り分ける 5つのHTTPメソッドをサポートしている(GET、PUT、DELETE、HEAD、MKCOL) データベース（KVS）に保存したデータの情報を送る queueに処理の指示を送る nanofsw(worke
開発メモ: Kyoto Tycoonベータ版リリースすた
ここのところ必死こいて作り込んでいたKyoto Tycoonだが、主要機能を実装しきって文書もそこそこ書けてきたので、ベータリリースということにした。プロジェクトページもちゃんと作ってある。 公式には英語の文書しか作らない方針なのだが、それだと国内ではなかなか使ってもらえないので、この場でチュートリアルを書いてみる。 Kyoto Tycoonとは プロセス組み込み軽量データベースライブラリであるKyoto Cabinetをネットワーク越しに利用できるようにするためのツールキットである。KCのデータベースを内部に持ったサーバプログラムと、それに接続してデータベースを操作するためのクライアントライブラリからなる。また、コマンドラインからサーバにアクセスするためのユーティリティもついてくるので、簡単に使い始められる。 製品コンセプトは、「永続的キャッシュサーバ」もしくは「memcachedの永続
mixi大規模障害について 解明編 - mixi engineer blog
こんにちは、システム本部技術部たんぽぽGの森本です。 先日のmixi大規模障害の原因となったmemcachedの不具合の詳細な解明ができました。 再来週まで発表を見合わせようと思ったのですが、早くお伝えしたほうがいいと思いましたので公開発表致します。 memcachedとlibevent memcachedはlibeventというライブラリを使用してクライアントからの要求(接続、コマンド送信)を処理しています。 libeventを使用するにはevent_baseという構造体を用います。 main threadはmain_baseを使用します。 static struct event_base *main_base; ... int main (int argc, char **argv) { ... main_base = event_init(); ... /* enter the ev
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ファイルのフォーマットを変更しない（変更するとしても後方互換性を維持する） なるべく機能追加
54行で分散KVSを実装する（レプリケーション機能付き） - Blog by Sadayuki Furuhashi
Ruby と MessagePack-RPC があれば、簡単なkey-valueストレージは簡単に作れます。54行で書けます（レプリケーションと負荷分散機能付き。サーバー38行、クライアント16行）。 簡単なKVSをベースにして、ログ集計や遠隔デプロイ、遠隔管理機能などの機能を追加していけば、ちょっと便利なサーバープログラムをサクサク自作できるハズ。 この分散KVSは、（keyのハッシュ値 % サーバーの台数）番目のサーバーにkeyを保存します。また、サーバーの名前順でソートしたときの「次のサーバー」と「次の次のサーバー」にデータをレプリケーションします。 すべてのサーバーで同じ設定ファイルを使います。サーバーごとの設定は引数を自分のホスト名に書き換えるだけなので、デプロイが容易です。 MessagePack-RPC for Ruby を使うと、分散しないkey-valueストレージ*1は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
