開発メモ: Kyoto TycoonでテーブルDBを実現する
Kyoto Tycoonで、RDBMSのテーブルのように複数のコラムを持ったレコードを扱ったり、特定のコラムを対象にセカンダリインデックスを張ったりすることもできるという話。 テーブルDB Tokyo CabinetおよびTokyo Tyrantでは、テーブルDBという実装があった。最も率直なKVS（永続化連想配列）の実装としてお馴染みのTC/TTではあるが、valueに構造を持たせることによってマルチコラムを実現し、さらに更新処理にフックをかけてセカンダリインデックスを自動的に管理できるようにもしていた。結果として、「ドキュメント指向DB」とか「スキーマレスDB」とかいったような、ゆるふわな感じの用途で便利に使えるツールになっていると思う。 しかし、KyotoシリーズではテーブルDBは実装しない方針である。多機能すぎてメンテが大変だからだ。アプリケーション寄りの機能を提供するということは
開発メモ: スナップショットを使ったレプリケーション管理
前回述べた自動スナップショット機能は、今後は「バックグラウンドスナップショット」と呼ぶことにする。今回は、それを使ってオンメモリデータベースサーバのレプリケーションを簡単に管理する方法について解説する。 レプリケーションの基本 KTのレプリケーション機構は、マスタサーバが自分のDBに対する更新ログを記録しておき、それをスレーブサーバが吸い出して自分のDBに対して適用することで、二つのDBの状態を同期させるという機構である。更新ログを吸い出す際には、「既にどこまでの更新ログを読んだか」というタイムスタンプを管理して、レプリケーションを停止したり再開したりできるようにしている。 障害対応や負荷増大への対応などで、スレーブサーバを増設する際には、直近のバックアップのDBファイルと、それを作成した瞬間のタイムスタンプを記録したRTSファイルをスレーブのマシンに設置してから、サーバを起動する。そうす
開発メモ: もし自営業の男子プログラマがKVSで「ブログサービス」を書いたら
Webサービスの典型例でありCMSの典型例であるブログサービス。それを実装するための指針が示せれば、その他のサービスを開発する際にも大いに参考になることだろう。 データ構造 単純なブログサービスのデータノードとしてKyoto Tycoonのサーバ群を用いることを想定する。ブログの個々の記事は以下の属性を持つものとする。 著者のユーザID（uint32） 投稿日時（uint32） 題名（text） 本文（text） コメントリスト（シーケンス） 各コメントは、コメントした人のユーザIDと本文からなる データノードに対する問い合わせは、「あるユーザの最新記事を降順で5件くれ」というのが典型である。「降順で」という順序に対する要求があるのでB+木を選択し、連想配列のキーは、ユーザIDと投稿日時を連結したものとする。単純化のために、各々を10桁の10進数文字列をコロンで区切って並べて、全体で21バ
libkyototycoon をつかって 5分で C++ で RPC サーバーを書く方法 - tokuhirom's blog
ちょっとした RPC サーバーを C/C++ でかきたいな、なんてケースはままあるわけですが、そんなときに便利なライブラリがあったので紹介します。 KyotoTycoon をつかうと、TSVRPC over HTTP な RPC サーバーが超簡単にかけて便利だった。libkyototycoon は GPL だけど、それが問題にならない場合なら、とてもいいとおもう。商用ライセンスかえるならそれもいいとおもう。 RPC サーバーとしては他にもいくつか実装があるんだけど、HTTP の上で実装されているから、デバッグが容易だったりとか、直接 telnet ではなしたりとか tcpdump できたりして、いろいろ便利なので、よいとおもう。 SConstruct でビルドルールをかいてから e = Environment() e.Program('ktechoserver', ['ktechoserv
開発メモ: DBサーバのnoreplyオプションによる高速化
Kyoto Tycoonやmemcachedにてnoreplyオプションを使ってパフォーマンスを上げる話。 noreplyの功罪 DBに対する更新操作はその成否を真偽値などとして呼出側に返すのが通常であるが、それを省略することでパフォーマンスを上げることができる。memcachedではnoreplyオプションとして知られている。KTの最新版からは、memcachedプラグインと独自バイナリプロトコルでもnoreplyオプションをサポートすることにした。 noreplyを有効にするとなぜ高速化するのか。クライアントはクエリをsendしただけで、recvをせずに次の処理に移れるからだ。sendシステムコールに渡したデータはカーネルが非同期に処理するので、カーネルとアプリケーションは並列に処理を進めることができる。recvをした場合にはその時点で両者の待ち合わせが発生してしまうのだが、それをしな
開発メモ: KTのプラガブルデータベース
Kyoto Tycoonのストレージ層もプラガブルにして、任意のストレージエンジンを利用できるようにした。 背景 みんな大好きMySQLの利点の一つとして、ストレージエンジンがプラガブルであることが挙げられる。InnoDBやMyISAMやその他のエンジンを、システム全体の機能要件や性能要件に合わせて使い分けられるということだ。既存のエンジンから選択するだけでなく、自分で新しいエンジンを実装して組み込むこともできる。 KTでもMySQLと同じように複数のストレージエンジンを使い分けることができるように従来からなっているが、ユーザ独自のエンジンを組み込むことはまだできなかった。今回、ストレージ層をプラガブルモジュールにすることで、ユーザ独自のエンジンを組み込めるようになった。この仕組みをプラガブルデータベースと呼ぶことにする。 CSVファイルにデータを入れる「CSVデータベース」や、OpenO
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
