開発メモ: memcachedメッセージキューの詳しい使い方
memcachedプロトコルでメッセージキューが実現できるという話を前回したが、今回はその具体的な使用方法を解説してみる。 サーバを起動する まずはサーバを起動しないと始まらない。典型的には以下のコマンドで立ち上げるとよい。 $ ktserver -th 1 -ls \ -plsv /usr/local/libexec/ktplugservmemc.so \ -plex 'port=11211#tout=30#thnum=16#opts=fq#qtout=10' \ 'casket.kct#ktopts=p' 「-th 1」でメインサーバのスレッド数を1にしている。最新版からはデフォルトで16スレッドを立てるのだが、アプリ側からはメインのサーバにはアクセスしないだろうから、1個あればよい。「-ls」はログレベルをSYSTEMに設定。「-plsv ...」では、memachedプラガブルサー
開発メモ: memcachedプロトコルでメッセージキューを実現する
前回の記事にて、Kyoto Tycoonでメッセージキューを実現する方法について述べた。今回は、それを実運用にて使いやすくするための諸機能について説明する。みんな大好きなmemcachedプロトコルでメッセージキューを実現してみよう。 ジョブキューとメッセージキュー どうでもいい話ではあるが、ジョブキューおよびメッセージキューという用語はよく混同して使ってしまう。俺定義では、ジョブキューは「ジョブ管理機能」という目的をたまたまキュー構造に基づいて実装しているものであり、メッセージキューはキュー構造に基づく非同期メッセージング機構であって用途は特に限定しない。つまりメッセージキューをジョブキューを実装するのに使うこともあるが、それ以外の用途にもメッセージキューは使われる。またジョブキューをメッセージキューに基づかないで同期的に実装することもできる。 きっと偉い学者さんがどこかでちゃんとした定
開発メモ: KVSとシグナル機構でジョブキューを実現する
いわゆるkey-value storeを使っている際に、レコードの挿入もしくは更新を検知して即座に何らかの処理を行いたくなることはないだろうか。俺はあんまりないけど、結構そういう質問が来るので、きっと巷にはそういう要求があるのだろう。Kyoto Cabinetでそれを実現してみた。 ジョブキュー もうちょい具体的な例を挙げると、ジョブキューである。ここで、「foo」という名前のタスクを考えてみる。読み出し側（ワーカ）は、適当な名前をつけた条件変数を常に監視していて、そこにシグナルが飛んできたら即座にレコードを取得して処理を行いたい。しかし、「一定の間隔毎にレコードの検索を繰返して発見したら処理を行う」というポーリングスタイルにはしたくない。操作にどうしてもタイムラグが出るし、ポーリングのための無駄なトラフィックが発生するからだ。 シグナル待機処理と該当レコードの取得処理を行う擬似コードは以
Kyoto Tycoonの運用TIPSなどなど - （ひ）メモ
チャオ！みんな、Kyoto Tycoonライフをエンジョイしてるかい！？ 今日はKTライフを満喫してるミーからの運用TIPSアンドソーオンをお届けするＹＯ！ kchashmgrとktremotemgrコマンドの補完 人間の脳活動のピークは22歳の今日このごろ、みなさんいかがおすごし？ もうね、ミーは全然コマンドオプションとか覚えられないからシェル(bash)で補完しまくってるＹＯ！ kchashmgrとktremotemgrだけだしオプション網羅してないし補完ルールもアレだけどオープン＆シェアなマインドとガッツで気になる人はfork & push！ Nagiosで死活監視 ナギオス！みんな使ってるよね？ ミーはcheck_httpでKTのHTTP RPCのechoにアクセスしてデッドオアアライブの監視してる！ define command { command_name check_kyot
memcached(プロトコル)のデータレプリケーション - （ひ）メモ
国内だけでなく国外(なぜか主に中国語)でもまだrepcachedについて言及してるのをちらほら見かけるのですが、repcachedはmemcached 1.2.8ベースですし(memcached 1.4.5に対応してる人もいるようですが)いまならKyoto Tycoon使えばいいんじゃないかと思うのです。 Kyoto Tycoonなら: memcachedプロトコルプラグインを使えば、Kyoto Tycoonがそのままmemcachedの代替になる（memcachedプロトコルを喋るクライアントコードはそのままでよい） Tokyo Tyrantと違ってexpireもOK memcachedの代替が目的なら、速いオンメモリDB(StashDBとか)でOK 非同期レプリケーションもできる ホットスタンバイ側のサーバリソースが無駄に思うなら、keyに応じてmodとかでリクエストするサーバを2台の
開発メモ: Kyoto TycoonでテーブルDBを実現する
Kyoto Tycoonで、RDBMSのテーブルのように複数のコラムを持ったレコードを扱ったり、特定のコラムを対象にセカンダリインデックスを張ったりすることもできるという話。 テーブルDB Tokyo CabinetおよびTokyo Tyrantでは、テーブルDBという実装があった。最も率直なKVS（永続化連想配列）の実装としてお馴染みのTC/TTではあるが、valueに構造を持たせることによってマルチコラムを実現し、さらに更新処理にフックをかけてセカンダリインデックスを自動的に管理できるようにもしていた。結果として、「ドキュメント指向DB」とか「スキーマレスDB」とかいったような、ゆるふわな感じの用途で便利に使えるツールになっていると思う。 しかし、KyotoシリーズではテーブルDBは実装しない方針である。多機能すぎてメンテが大変だからだ。アプリケーション寄りの機能を提供するということは
KyotoTycoon の PHP 版を作った - Memo
KyotoTycoon の PHP のライブラリを作った。 このライブラリは Perl の Cache::KyotoTycoon を移植したもの。 自分の Perl の勉強を兼ねていて、Perl 版の詳細は id:tokuhirom さんのポストを参照。 http://d.hatena.ne.jp/tokuhirom/20101012/1286864973 Perl のは名前空間が Cache や TSVRPC だが、PHP は id:cocoiti さんの Net_TokyoTyrant に合わせて、KyotoTycoon は Net パッケージに、TSVRPC は HTTP パッケージにしている。 TSV-RPC のクライアントが HTTP_Request2 を使用している関係から HTTP_Request2 に依存している。 Zend_Http の方が好みだったが、ちょっと依存モジュ
Kyoto Tycoon Guide in Japanese
This document discusses messaging queues and platforms. It begins with an introduction to messaging queues and their core components. It then provides a table comparing 8 popular open source messaging platforms: Apache Kafka, ActiveMQ, RabbitMQ, NATS, NSQ, Redis, ZeroMQ, and Nanomsg. The document discusses using Apache Kafka for streaming and integration with Google Pub/Sub, Dataflow, and BigQuery
開発メモ: スナップショットを使ったレプリケーション管理
前回述べた自動スナップショット機能は、今後は「バックグラウンドスナップショット」と呼ぶことにする。今回は、それを使ってオンメモリデータベースサーバのレプリケーションを簡単に管理する方法について解説する。 レプリケーションの基本 KTのレプリケーション機構は、マスタサーバが自分のDBに対する更新ログを記録しておき、それをスレーブサーバが吸い出して自分のDBに対して適用することで、二つのDBの状態を同期させるという機構である。更新ログを吸い出す際には、「既にどこまでの更新ログを読んだか」というタイムスタンプを管理して、レプリケーションを停止したり再開したりできるようにしている。 障害対応や負荷増大への対応などで、スレーブサーバを増設する際には、直近のバックアップのDBファイルと、それを作成した瞬間のタイムスタンプを記録したRTSファイルをスレーブのマシンに設置してから、サーバを起動する。そうす
開発メモ: オンメモリDB＋スナップショットで爆速永続キャッシュ
Kyoto Tycoonに自動スナップショット機能が実装され、オンメモリDBでも永続化できるによになり、高速性と永続性を両立できるようになったよという話 自動スナップショットとは 「永続化したキャッシュサーバ」としてのコンセプトを掲げるKyoto Tycoonだが、それはメモリ上でなくファイル上でデータベースを表現するからである。今回の自動スナップショットによる永続化は、それとは異なる。オンメモリDBの中にあるレコードを定期的にファイルに書き出すことで永続化するのだ。 ファイルDBの場合、データベース内のレコードは常にファイルに書かれている。よって、サーバプロセスを再起動してもレコードは消えない。その代償として、ファイル上で更新された領域をディスクに書き込むためのIO処理にかかるオーバーヘッドが無視できない。ファイルシステムのページキャッシュによって緩和されるとはいえ、IO処理がランダムア
開発メモ: DBサーバのnoreplyオプションによる高速化
Kyoto Tycoonやmemcachedにてnoreplyオプションを使ってパフォーマンスを上げる話。 noreplyの功罪 DBに対する更新操作はその成否を真偽値などとして呼出側に返すのが通常であるが、それを省略することでパフォーマンスを上げることができる。memcachedではnoreplyオプションとして知られている。KTの最新版からは、memcachedプラグインと独自バイナリプロトコルでもnoreplyオプションをサポートすることにした。 noreplyを有効にするとなぜ高速化するのか。クライアントはクエリをsendしただけで、recvをせずに次の処理に移れるからだ。sendシステムコールに渡したデータはカーネルが非同期に処理するので、カーネルとアプリケーションは並列に処理を進めることができる。recvをした場合にはその時点で両者の待ち合わせが発生してしまうのだが、それをしな
開発メモ: もし自営業の男子プログラマがKVSで「ブログサービス」を書いたら
Webサービスの典型例でありCMSの典型例であるブログサービス。それを実装するための指針が示せれば、その他のサービスを開発する際にも大いに参考になることだろう。 データ構造 単純なブログサービスのデータノードとしてKyoto Tycoonのサーバ群を用いることを想定する。ブログの個々の記事は以下の属性を持つものとする。 著者のユーザID（uint32） 投稿日時（uint32） 題名（text） 本文（text） コメントリスト（シーケンス） 各コメントは、コメントした人のユーザIDと本文からなる データノードに対する問い合わせは、「あるユーザの最新記事を降順で5件くれ」というのが典型である。「降順で」という順序に対する要求があるのでB+木を選択し、連想配列のキーは、ユーザIDと投稿日時を連結したものとする。単純化のために、各々を10桁の10進数文字列をコロンで区切って並べて、全体で21バ
libkyototycoon をつかって 5分で C++ で RPC サーバーを書く方法 - tokuhirom's blog
libkyototycoon をつかって 5分で C++ で RPC サーバーを書く方法 ちょっとした RPC サーバーを C/C++ でかきたいな、なんてケースはままあるわけですが、そんなときに便利なライブラリがあったので紹介します。 KyotoTycoon をつかうと、TSVRPC over HTTP な RPC サーバーが超簡単にかけて便利だった。libkyototycoon は GPL だけど、それが問題にならない場合なら、とてもいいとおもう。商用ライセンスかえるならそれもいいとおもう。 RPC サーバーとしては他にもいくつか実装があるんだけど、HTTP の上で実装されているから、デバッグが容易だったりとか、直接 telnet ではなしたりとか tcpdump できたりして、いろいろ便利なので、よいとおもう。 SConstruct でビルドルールをかいてから e = Environ
Kyoto Tycoon に MessagePack-RPC をプラグインして Java から使う - Blog by Sadayuki Furuhashi
Tokyo Cabinet を始めとする Tokyo シリーズの作者として知られる平林幹雄さんですが、Tokyo シリーズに続く新製品として、Kyoto シリーズがリリースされています。 Kyoto Tycoon（以下KT）は、ネットワーク経由で使えるデータベースサーバで、Tokyo Tyrantの後継製品に当たります*1。 KT は HTTP ベースのプロトコルで操作することができますが、別のプロトコルを追加することもできます。 実際に memcached プロトコルのプラグインが標準でバンドルされています。（memcachedプロトコルをKTにプラグインする） と言うわけで、KT を MessagePack-RPC で使えるようにするプラグインを書いてみました。github からダウンロードできます。 kt-msgpack kt-msgpack downloads MessagePac
開発メモ: memcachedプロトコルをKTにプラグインする
高効率キャッシュサーバ兼データベースサーバであるKyoto Tycoonのネットワーク通信機構をプラグインで切り替えられるようにして、memcachedプロトコルにも対応したというお話。 プラガブルサーバ Apacheは、様々なモジュールを後付けのプラグインで組み込むことで、非常に柔軟に機能追加を行えるようになっている。MySQLもストレージエンジンをプラグインで切り替えられるようになっていて、非常に柔軟なソリューションが提供できるようになっている。そのようなプラグインできるモジュールをプラガブルモジュールと呼ぶことにしよう。 同じように、KTでもストレージエンジン（DBM層）をプラガブルモジュールにする予定ではあるが、今回はストレージエンジンの話ではない。逆に、ネットワーク層をプラガブルモジュールにしてしまうのだ。そうすると、任意のプロトコルでデータベースを操作できるようになる。 DBM
開発メモ: memcachedとKyoto Tycoonの空間効率
Kyoto CabinetおよびKyoto Tycoonに新たに導入された「StashDB」を使うとmemcachedよりも空間効率を向上させられるという話。 StashDBとは 前回の記事で説明したように、Kyoto CabinetではローカルMapReduceのキャッシュとしてTinyHashMapというクラスを実装して省メモリ化を図っている。丁寧にシリアライズしてデータを詰めていくとかなりメモリを節約できるものなのだ。 同じ構造をDBMのインターフェイスにしたのがStashDBである。ProtoHashDB, ProtoTreeDB, CacheDB, GrassDB, HashDB, TreeDB, DirDB, ForestDBに続く第9番目のDBMということになる。もちろん、マルチスレッドセーフにして、レコード単位の粒度でロックを施して一貫性を確保し、VisitorやCurso
node-kyoto-tycoon - SWDYH
node-kyoto-tycoon http://github.com/swdyh/node-kyoto-tycoon KyotoTycoonのNode.js用ライブラリを作りました。まだだいぶ荒削りな状態で、KyotoTycoonのAPIを簡単にラップした感じのものです。APIも変わるかもしれないし、バグもたぶんあると思いますが試してみてください。 Node.jsが新しめでないとHTTPのKeep-Aliveが使えないので、古いNode.jsを使っている場合は、新しいNode.jsを入れて使ってください。(Keep-Aliveが使えなくても動きますが、カーソル関連は使えないと思います) インストール npmを使う % npm install kyoto-tycoonソースから % git clone http://github.com/swdyh/node-kyoto-tycoon.gi
開発メモ: Kyoto Tycoonベータ版リリースすた
ここのところ必死こいて作り込んでいたKyoto Tycoonだが、主要機能を実装しきって文書もそこそこ書けてきたので、ベータリリースということにした。プロジェクトページもちゃんと作ってある。 公式には英語の文書しか作らない方針なのだが、それだと国内ではなかなか使ってもらえないので、この場でチュートリアルを書いてみる。 Kyoto Tycoonとは プロセス組み込み軽量データベースライブラリであるKyoto Cabinetをネットワーク越しに利用できるようにするためのツールキットである。KCのデータベースを内部に持ったサーバプログラムと、それに接続してデータベースを操作するためのクライアントライブラリからなる。また、コマンドラインからサーバにアクセスするためのユーティリティもついてくるので、簡単に使い始められる。 製品コンセプトは、「永続的キャッシュサーバ」もしくは「memcachedの永続
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://kyoto-client.org/
fallabs.com