http://activetokyocabi.rubyforge.org/ ActiveTokyoCabinet 0.1.1をリリースしました。 これは何? ActiveRecordのTokyo(Cabinet|Tyrant)のテーブルデータベースのアダプタです。 TokyoTyrantをActiveRecordのように使えるMiyazakiResistanceもあるんですが、アダプタとして実装した方がよりシームレスだろうと思って作ってみました。 使い方 database.ymlの書き方は次の通り。 TykyoCabinetでは1ファイルを1テーブルとしています。 また、TokyoTyrantではサーバ1台を1テーブルとしています。 # TokyoCabinet development: adapter: tokyocabinet database: path_of_database_di
ActiveRecord の TC/TT アダプタ AR 上で動作するので全てのAPIが利用可能 インストール 1 % gem install activetokyocabinet サーバの起動 1 % ttserver -port 11114 db.tct & ポート(11114)は何でもよい ファイル名も何でもよい (拡張子はtct) セットアップ 1 require 'active_tokyocabinet/tdb' 2 3 ActiveRecord::Base.establish_connection( 4 :adapter => 'tokyotyrant', 5 :database => { 6 :englishes => {:host => 'localhost', :port => 11114}, 7 } 8 ); adapter 名は 'tokyotyra
kumofs での Data::Model の使い方 スケート頑張りすぎて足首が痛いYappoですみなさまウインタースポーチュしてますか? 本日kumofsが公開されたので、折角なので Data::Model から kumofs を実際にどうつかっているかを紹介しようかとおもいます。 kumofs については 分散Key-Valueストア「kumofs」を公開しました! - 古橋貞之の日記 を Data::Model::Driver::Memcached については dann さんによる Data::Model::Driver::Memcachedで超効率データ保存 - JPerl Advent Calendar 2009 を別途参照すると良いでしょう。 スキーマ定義 では実際に kumofs をつかった場合のスキーマ定義を下記に貼ります。 ちなみに、それらしいような定義をしてますが全部フ
Python Hackathon #3で、今手元で作っているモノのバックエンドに使えないかなぁと思ってRiakを調べてみたのでメモ。Riakは、bashoが作っているDynamoクローンにHTTP/JSONなインターフェースを出して、MapReduceもできるようにしたというキワモノ。でもConsistent HashingとMapReduceって激しく相性悪いと思うんだけどどうなっているんだろうという辺りが疑問点。 とりあえずインターフェースはJSON/HTTPだけど、Erlang APIもある。 Riak's primary programming interface is JSON over (RESTful) HTTP, which is as close as you can come these days to a universal language and protocol
「クラウドでパケ死」。 5月中旬、こんな言葉がTwitterで発信された。米Amazon Web Servicesのクラウドサービス「Amazon EC2」と「Amazon EBS」を使ったことろ、わずか5日ほどで利用料が25万円を超えてしまったのだという。ご本人のTwitterをたどると、原因は容量が30テラバイトの巨大な仮想ストレージを3台も借りてしまったことにあるようだ。このストレージに、データベースソフト「Cassandra」を使って1兆件を超えるレコードを登録したのだという。 Cassandraとは、米Facebook社が自社のサービス基盤向けに開発したデータベースソフトである。現在はOSSとして公開され、Apache Software Foundationが開発を進めている。特徴は、複数のノードにデータを分散管理できることで、ノードを追加するだけで容易に処理性能を高められる仕組
NoSQLを知る〜kumofsから学ぶNot only SQLの技術 と題して、Developers Summit 2010で発表しました。 twitterの#devsumi2010 kumofsを見る限りでは大変ご好評をいただいたようで、ひとまずほっとしています。 プレゼンテーションの資料を公開しました。内容はどれも同じですが、クリックで進むムービー版がオススメです。 クリックで進むムービー(クリック/矢印キーで進む) PDF Keynoteファイル(Keynote '09が必要) NoSQLを知るView more presentations from frsyuki. Consistent Hashingとdouble-hash-spaceアルゴリズムの紹介は、68ページ以降にあります。 第101回 カーネル読書会 2月25日に楽天タワーで行われるカーネル読書会でも、kumofs関連
ドキュメント指向なKVSってことと、字面が似ていると言うことぐらいしか比較する意味がなさそうなCouchDBとMongoDBだけど、ここ2,3ヶ月で両方をそれなりに突っ込んで見てきたので比較してみた。実装面やパフォーマンス、ということよりはどちらかというと(私が感じる)思想的なものや、ユーザ側からの視点での比較。 共通するところ これはもう簡単に、 ドキュメント指向データベース - RDBMSのようなカラムと言ったものを持たずにスキーマレスで好きな情報を入れられる Javascript/JSONを使用 - データ自体もJSONというJavascript由来のフォーマットで持ち(MongoDBはJSONを元にしたBSONというものだが)、データベースのアクセスにはJavascriptを使用する スケールアウトするように考えられている NoSQLな流行 CouchDBの特徴 機能を限定している
先日、分散Key-valueストア kumofs を公開しました。 多く方から反響とフィードバックをいただいています。ありがとうございます。 今回は、kumofs はなぜスケールするのか、なぜスケールすると言えるのかーということについて紹介したいと思います。 ところでスケーラビリティとは何か? スケーラビリティとは、利用者や仕事の増大に適応できる能力・度合い とされています(端的!)*1 。Scalability を日本語にすると、拡張性 と訳されるようです。 ただ一口でスケーラビリティと言っても、様々な側面があります。ITシステムでは主には処理性能と運用に関することを指す場合が多いと思いますが*2、その中にも様々な側面があります。 なぜスケーラビリティが必要か スケーラビリティは システムなどが持つべき望ましい特性 であって、高いに越したことはありません。しかし、高いスケーラビリティはタ
Over the last couple years, we see an emerging data storage mechanism for storing large scale of data. These storage solution differs quite significantly with the RDBMS model and is also known as the NOSQL. Some of the key players include ... GoogleBigTable, HBase, Hypertable AmazonDynamo, Voldemort, Cassendra, Riak Redis CouchDB, MongoDB These solutions has a number of characteristics in common K
Ruby と MessagePack-RPC があれば、簡単なkey-valueストレージは簡単に作れます。54行で書けます(レプリケーションと負荷分散機能付き。サーバー38行、クライアント16行)。 簡単なKVSをベースにして、ログ集計や遠隔デプロイ、遠隔管理機能などの機能を追加していけば、ちょっと便利なサーバープログラムをサクサク自作できるハズ。 この分散KVSは、(keyのハッシュ値 % サーバーの台数)番目のサーバーにkeyを保存します。また、サーバーの名前順でソートしたときの「次のサーバー」と「次の次のサーバー」にデータをレプリケーションします。 すべてのサーバーで同じ設定ファイルを使います。サーバーごとの設定は引数を自分のホスト名に書き換えるだけなので、デプロイが容易です。 MessagePack-RPC for Ruby を使うと、分散しないkey-valueストレージ*1は
8月1日から8月31日までの1ヶ月間、PFI夏期インターンに行ってきました。 はてなインターンの 講義・課題・チーム 形式とは趣を異にして、個々人が何か1つのプロジェクトに取り組む方針で進みました。取り組むテーマは 新たに取り組みたい/今取り組んでいる 内容を前提に、既存の問題の中から近いテーマを見つけます(あるいはこじつける^^;)。 インターンの期間中の1ヶ月か2ヶ月の間に成果を出すのが目標! 取り組むテーマはスムーズに決まりました。何か自社で製品を作っていれば普通かと思いますが、探せば問題はいくらでもあるモノです^^ ちなみにPFIの製品は、全文検索エンジンやレコメンドエンジンなどです。 私は以下の4つのプログラムを実装しました: 既存の実装に代わるRPCフレームワーク MessagePack-RPC for PFI クラスタ管理ツール clx プロセス管理ユーティリティ daemo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く