開発メモ: オンメモリDB＋スナップショットで爆速永続キャッシュ
Kyoto Tycoonに自動スナップショット機能が実装され、オンメモリDBでも永続化できるによになり、高速性と永続性を両立できるようになったよという話 自動スナップショットとは 「永続化したキャッシュサーバ」としてのコンセプトを掲げるKyoto Tycoonだが、それはメモリ上でなくファイル上でデータベースを表現するからである。今回の自動スナップショットによる永続化は、それとは異なる。オンメモリDBの中にあるレコードを定期的にファイルに書き出すことで永続化するのだ。 ファイルDBの場合、データベース内のレコードは常にファイルに書かれている。よって、サーバプロセスを再起動してもレコードは消えない。その代償として、ファイル上で更新された領域をディスクに書き込むためのIO処理にかかるオーバーヘッドが無視できない。ファイルシステムのページキャッシュによって緩和されるとはいえ、IO処理がランダムア
Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase comparison :: Software architect Kristof Kovacs
Hello, I’m Kristof, a human being like you, and an easy to work with, friendly guy. I've been a programmer, a consultant, CIO in startups, head of software development in government, and built two software companies. Some days I’m coding Golang in the guts of a system and other days I'm wearing a suit to help clients with their DevOps practices. While SQL databases are insanely useful tools, their
機能的には、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
Another NoSQL Comparison: Evaluation Guide
The requirements were clear: Fast data insertion.Extremely fast random reads on large datasets. Consistent read/write speed across the whole data set. Efficient data storage. Scale well.Easy to maintain. Have a network interface.Stable, of course.The list of NoSQL databases to be compared: Tokyo Cabinet, BerkleyDB, MemcacheDB, Project Voldemort, Redis, and MongoDB, not so clear. The methodology to
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ページを開く
