開発メモ: オンメモリ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
XMLDBやKVSは破壊的技術になり得るか？ （1/2）- ＠IT
夏が迫ってきましたね。今月はMySQL 5.5、Club DB2に登場したミックさん、それからVoltDBなどについてお伝えします。 性能と利便性ともに向上 MySQL 5.5 2010年4月にアメリカで開催されたMySQL Conference ＆ Expoの基調講演で「MySQL 5.5」が紹介されて以来、次第にMySQL次期バージョンの姿が明らかになりつつあります。MySQLはオープンソースではありますがエンタープライズ版もあり、オープンソースと商用の2つの顔を持つRDBともいえますね。 さて現在開発中のMySQLについて。現行のGA（Generally Available）版は5.1です。少し前に5.4も出ましたが、現在は5.5で開発が進んでいます。「5.4はどこへ？」と心配しなくても大丈夫。5.5にはInnoDBの性能を向上させた5.4の改善事項も盛り込まれています。 まだ開発中
kumofsをベースにRDBMS用ストレージエンジンって作れないものか | 独り言v6
まだ自分でインストールして確かめていないが、kumofsに興味津々である。何が興味深いかというと、まあスケーラブルで且つ耐障害性に優れるところだ。もちろんそれだけなら分散KVSということである程度予想された機能である。個人的な興味としては「この種のKVSを使ってRDBMSもどきが作れないか」というところにある。 この構想は 超 並列RDBMSは成立するか – L.star的デザイン（１） でずいぶん前から暖めているものであるが、ここでいうリソースノードをkumofsで代用できないかというものだ。引用して、機能的な実装の必要でないものを除くと リソースノード storage engineである DDL的には、テーブルスペースに近い位置づけとして定義可能であると考えている。 sequential scan, index scan, seq scan+sortを行い、その結果を返すDBである。M
Comparing VoltDB to Postgres
I've been asked a few times recently for my opinion on VoltDB, the new database server architected by the 'father' of Postgres, Dr Michael Stonebraker so rather than repeating myself over and over again it seems like a good idea to write it all down. VoltDB is an in-memory, lockless relational database that maintains ACID compliance, has a SQL interface and claims to offer massive performance incr
Volt Active Data and YCSB - Volt Active Data
As benchmarks go YCSB has been very successful, with over 45 separate database platforms currently supported. Since Volt Active Data’s strength is millisecond range ACID transactions at scale, we didn’t really see the need for close integration with the ‘official’ benchmark when it first appeared, as it didn’t do the kind of complicated transactions we excel at. Because we can do an arbitrary amou
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
NoSQLについて知っておくべき10の事柄
TechRebublicに「10 things you should know about NoSQL databases」（NoSQLデータベースについて知っておくべき10の事柄）という記事が掲載されています。NoSQLデータベースについての現状がよくまとまっている内容でしたので、見出しとポイントをまとめて紹介したいと思います。 10の事柄は前半と後半の2つに分かれていて、前半の5つではNoSQLの利点について説明されており、後半の5つは課題について説明されています。原文はそれなりに長い説明がされているので、詳しくは原文をぜひ見てみてください。以下はそれを1行程度に要約したものです。 5つのNoSQLの利点 Five advantages of NoSQL 1：Elastic scaling （弾力性のあるスケーラビリティ） NoSQLデータベースでは、ノードの追加による拡張性に柔軟に対
逆襲のLua - mixi engineer blog
こんにちは。開発部最後の良心、mikioです。今回はLua処理系の並列化とそこでのKyoto Cabinetの利用法についてご紹介します。 サーバサイドスクリプティングといえばLua Kyoto CabinetのLuaバインディングは後回しにしてKyoto Tyrant的なサーバの設計を進めていたのですが、やはりそのサーバにもスクリプティング機能を持たせたくなりました。つまり、サーバがデフォルトで提供する機能群だけでなく、ユーザがスクリプト言語で記述した任意の機能を追加して利用できるようにするということです。 Tokyo TyrantではLua拡張と呼ばれる機能を用いてそれを実現しています。サーバの起動時にLuaのスクリプトを記述したファイルを読み込ませて、そこで定義した関数をリモートから呼び出せるようにしています。そこで実行されるLuaの処理系にはTTが管理するデータベースを操作するため
key-valueストアの基礎知識
首藤 一幸 Last-updated: January 5, 2010 注: このページの文章は Software Design 誌 2010年 2月号に掲載された以下の記事の元原稿です。 Software Design 誌編集部の了承の元に、本ウェブページに掲載しております。 首藤一幸: "key-valueストアの基礎知識", Software Design 2010年 2月号, p.14-21, (株)技術評論社, 2010年 1月 18日 クラウド、特にPaaS向けのソフトウェア開発が現実のものとなり、 そこではリレーショナルデータベースとは違ったデータベースが 勢いを増しています。 その代表であるkey-valueストアを解説します。 もくじ key-valueストアとは なぜkey-valueストアか key-valueストアの使いどころ key-valueストアとNoSQLの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分散Key-Valueストアの本命「Bigtable」