開発メモ: Kyoto Tycoonによる高可用性DBサーバの構築
Tokyo Tyrantで実装していた非同期レプリケーションをKyoto Tycoonでも実装したので、高効率かつ高可用性を備えるデータベースサーバとして使えるようになったよという話。 高可用性の実現に向けて ハードウェア障害をはじめとする予期せぬ事態が起きても正常にサービスを運用し続けられる能力のことを高可用性（high availability）と呼ぶ。Tokyo Tyrantの記事で薀蓄を書いたのでそちらをご覧いただきたい。要は、ホットバックアップと更新ログとレプリケーションを使うと、大規模Webサービスの負荷にも耐えられる高可用性のデータベース運用ができるようになるということ。 KTの開発当初はプロクシを使ったレプリケーションを計画していたのだが、更新ログが重すぎるので分離したいニーズよりも、まずは普通に1対1の非同期レプリケーションをしたいというニーズの方が多いと判断して、TTと
FreeBSDでKyotoTycoonを使ってみた｜perl｜@OMAKASE
KyotoTycoon とは？ KyotoTycoonはプロセス組み込み軽量データベースライブラリであるKyoto Cabinetをネットワーク越しに利用出来るようにするKVSのサーバです。同じKVSで有名なmemcachedの場合データベースを全てオンメモリで処理しているため電源を落としたりプロセスを再起動させると保存していたデータが全部初期化されてしまう特徴があります。 KyotoTycoonはファイルにデータを書き込み永続的なデータ保存ができる「memcachedのデータ永続化版」の特徴を持っています。 またサーバの起動オプションでmemcachedと同じようにオンメモリに高速にデータストアーできるように設定することも可能な特徴も合わせ持っているようです。また付属するプラグインを利用する事によりmemcachedのプロトコルを解釈する事ができるためプログラムシステムを全く変更すること
開発メモ: memcachedプロトコルでメッセージキューを実現する
前回の記事にて、Kyoto Tycoonでメッセージキューを実現する方法について述べた。今回は、それを実運用にて使いやすくするための諸機能について説明する。みんな大好きなmemcachedプロトコルでメッセージキューを実現してみよう。 ジョブキューとメッセージキュー どうでもいい話ではあるが、ジョブキューおよびメッセージキューという用語はよく混同して使ってしまう。俺定義では、ジョブキューは「ジョブ管理機能」という目的をたまたまキュー構造に基づいて実装しているものであり、メッセージキューはキュー構造に基づく非同期メッセージング機構であって用途は特に限定しない。つまりメッセージキューをジョブキューを実装するのに使うこともあるが、それ以外の用途にもメッセージキューは使われる。またジョブキューをメッセージキューに基づかないで同期的に実装することもできる。 きっと偉い学者さんがどこかでちゃんとした定
tokyocabinetwiki [licensed for non-commercial use only] / 45_BenchmarkingVariousLocksPartTwo
各種ロックのベンチマークその弐 ID: 45 creation date: 2009/12/03 16:42 modification date: 2009/12/03 16:42 owner: mikio Benchmarking various locks Part 2 前回に引き続きロックの性能テストを行った。 This is part 2 of the series. The part one is here. スロットロック ハッシュDBにおいて個々のバケットに連なるチェーンのレースコンディションを回避するにはその個々のバケットを単位としてロックをかける必要がある。このように集合の個々の要素にロックをかけられる機構をスロットロックと呼ぶことにする。 バケット数は1000万とか1億とかの莫大な数になるので、その全てに対応するロックオブジェクトを作るわけにはいかない。x86_64のL
kyototycoonのVisitorインタフェースでレコードレベルロックを試す | ホゲホゲロック
Kyoto Tycoon + Luaスクリプティング拡張 = 最強で紹介されている様に、Kyoto Tycoon +Kyoto Tycoon + Luaスクリプティング拡張 = 最強で紹介されている様に、Kyoto Tycoon + Luaを使うとかなり自由な粒度でロックを用いた処理を実現できる。特にレコードレベルのロックを簡単に実現できるのは個人的に非常に嬉しい。 ここでは簡単なカウンタを例にレコードレベルのロック処理を試す。 2つのクライアントから別々のキーを持つレコードのカウントアップ処理をVisitorインタフェースを用いて行った。 テスト用のLuaスクリプト visitor.lua kt = __kyototycoon__ db = kt.db -- クライアント1がコールする関数 function visitTest1(inmap, outmap) -- Visitor f
Kyoto Tycoon
This document describes how to use command line utilities. They are useful to manage database contents and to test the library and its applications. ktserver : to run the database server. ktutiltest : to test the utility functions. ktutilmgr : miscellaneous utilities. ktutilserv : to test the server tool kit. kctimedtest : to test the timed database. kctimedmgr : to manage the timed database. ktre
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台の
開発メモ: 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やCur
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://webcache.googleusercontent.com/search?q=cache:AsvH5YYJfkkJ:fallabs.com/blog-ja/promenade.cgi%3Fid%3D108+&cd=1&hl=ja&ct=clnk&gl=jp
Google Code Archive - Long-term storage for Google Code Project Hosting.
開発メモ: 各種ロックのベンチマークその弐
開発メモ: Kyoto Tycoon + Luaスクリプティング拡張 = 最強
Kyoto Tycoon Guide in Japanese
Amazon LinuxにKyototycoonをインストール - massatの日記