開発メモ: オンメモリDB＋スナップショットで爆速永続キャッシュ
Kyoto Tycoonに自動スナップショット機能が実装され、オンメモリDBでも永続化できるによになり、高速性と永続性を両立できるようになったよという話 自動スナップショットとは 「永続化したキャッシュサーバ」としてのコンセプトを掲げるKyoto Tycoonだが、それはメモリ上でなくファイル上でデータベースを表現するからである。今回の自動スナップショットによる永続化は、それとは異なる。オンメモリDBの中にあるレコードを定期的にファイルに書き出すことで永続化するのだ。 ファイルDBの場合、データベース内のレコードは常にファイルに書かれている。よって、サーバプロセスを再起動してもレコードは消えない。その代償として、ファイル上で更新された領域をディスクに書き込むためのIO処理にかかるオーバーヘッドが無視できない。ファイルシステムのページキャッシュによって緩和されるとはいえ、IO処理がランダムア
機能的には、File＜Redis＜RDBS 気軽さはその逆 - When it’s ready.
そろそろKVSからRDBSへの回帰が起こっている今日この頃。季節も恐るべし速度で冬化して暖房や冬服が必要な時期ですね。 データの永続化にはいろんな方法がありますが、redisのご紹介です。Fileでは機能的に物足りなくてRDBSだと作業が重すぎるそんな要件たくさんありますよね？ね？ sqliteとかでもいいかと思うんですが、冗長性に疑問符が付いたりするわけです。そこでredisはいかがでしょうか？ ubuntuであれば aptitude install redisでインスコ終了です。設定もあまりするところはないです（良くも悪くも） 相当数の各種言語Bindingもあるので、あなたのご使用の言語でも利用出来るはずです。 Ruby Python PHP Erlang Tcl Perl Lua Java Scala Clojure C# C C++ Javascript IO Haskell G
GAE/Python でフルテキストサーチ実装した。 redisを使ったインチキバージョン - When it’s ready.
GAEにどんどん機能が追加されていく中、なかなか実装されないのが全文検索。品詞がとれるセグメンターだけでも提供してくれたら全然便利だと思うんだけどそんなアナウンスはまだ有りません。 なきゃ作ればいいじゃんという事で、全文検索もどきを実装してみました。ひとつ前のエントリー通りTriGramです。 以前、恵比寿のイケメン イアンさんと一緒に作ったmisopotetoというモジュールをベースにしています。 今回のポイントは、転置インデックスをredisサーバに送っているところ、GAE（とうかDB全般）は、インサートがめちゃくちゃ遅いので、Ngramでgram毎にエントリーIDをappendしていくというのは辛いです。Twitterの検索結果15個ｘ100文字位をTriGramでインデックスを作ろうとすると、1500個くらいをgetしてappendして、putする必要があります。以前は、TaskQ
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
