kyoto-client.org
Developing Android and iOS Applications for Teenagers – In the era of technology that continues to grow rapidly as it is now, the use of mobile applications is becoming increasingly common among teenagers. In this context, an understanding of Android and iOS application development is invaluable. This book is especially designed for teenagers who want to learn how to develop applications for popul
開発メモ: もし自営業の男子プログラマがKVSで「ブログサービス」を書いたら
Webサービスの典型例でありCMSの典型例であるブログサービス。それを実装するための指針が示せれば、その他のサービスを開発する際にも大いに参考になることだろう。 データ構造 単純なブログサービスのデータノードとしてKyoto Tycoonのサーバ群を用いることを想定する。ブログの個々の記事は以下の属性を持つものとする。 著者のユーザID（uint32） 投稿日時（uint32） 題名（text） 本文（text） コメントリスト（シーケンス） 各コメントは、コメントした人のユーザIDと本文からなる データノードに対する問い合わせは、「あるユーザの最新記事を降順で5件くれ」というのが典型である。「降順で」という順序に対する要求があるのでB+木を選択し、連想配列のキーは、ユーザIDと投稿日時を連結したものとする。単純化のために、各々を10桁の10進数文字列をコロンで区切って並べて、全体で21バ
開発メモ: memcachedプロトコルをKTにプラグインする
高効率キャッシュサーバ兼データベースサーバであるKyoto Tycoonのネットワーク通信機構をプラグインで切り替えられるようにして、memcachedプロトコルにも対応したというお話。 プラガブルサーバ Apacheは、様々なモジュールを後付けのプラグインで組み込むことで、非常に柔軟に機能追加を行えるようになっている。MySQLもストレージエンジンをプラグインで切り替えられるようになっていて、非常に柔軟なソリューションが提供できるようになっている。そのようなプラグインできるモジュールをプラガブルモジュールと呼ぶことにしよう。 同じように、KTでもストレージエンジン（DBM層）をプラガブルモジュールにする予定ではあるが、今回はストレージエンジンの話ではない。逆に、ネットワーク層をプラガブルモジュールにしてしまうのだ。そうすると、任意のプロトコルでデータベースを操作できるようになる。 DBM
HBaseとはどんなNoSQLデータベースなのか？ 日本語で読める情報を集めてみた
Facebookが新しいサービス「Messages」の基盤として、NoSQLデータベースの「HBase」を選択したことを、先日の記事「Facebookが新サービスの基盤にしたのは、MySQLでもCassandraでもなく、HBaseだった」で紹介しました。 HBaseは、Facebookによると次のような特徴を備えていると説明されてます。 負荷に対して非常に高いスケーラビリティと性能を発揮 CassandraよりもシンプルなConsistency Model（一貫性モデル）を備えている 自動ロードバランス、フェイルオーバー、圧縮機能 サーバーごとに数十個のシャードを割り当て可能、などなど このHBaseはどのようなデータベースなのでしょうか？ 情報を集めてみました。 HBase入門のプレゼンテーション 最初に紹介するのは「HBaseエバンジェリスト」Tatsuya Kawano氏のプレゼン
Net_KyotoTycoon - Openpear
Net_KyotoTycoon Subversion Repository: http://openpear.org/repository/Net_KyotoTycoon / Latest Release: no release Kyoto Tycoon client library for PHP. System requirement. PHP5.3 HTTP_Request2 PHPUnit3.5 Usage <?php require_once 'Net/KyotoTycoon.php'; $kt = new \Net\KyotoTycoon(array('port' => 19780)); $kt->set('test_php', 'Hello KyotoTycoon!!'); var_dump($kt->get('test_php')); // Hello KyotoTYco
はじめてのRuby(Rack)挑戦記録 - クリティカルスピード開発日誌
5:07 おはようございます。 今日は今までやろうやろうと思って放置していたRubyに初挑戦します。 perl使いなので書き方や考え方がperlに偏っているかもしれませんがご了承下さい。 5:10 まずはRubyのインストール sudo apt-get install librack-ruby 5:13 hello world 参考にしたのはこのページ http://route477.net/d/?date=20080716 mkdir rack cd rack vi criticalspeed.rb rbというのはperlでいうところのpmなのだろうか？ →plのようなものらしい(by IRC) criticalspeed.rb require 'rubygems' require 'rack' class CriticalSpeed def call(env) [200, {"Cont
ヽ( ・∀・)ノくまくまー(2010-09-15)
● [KVS][Scala] Scala で Tokyo Cabinet 我が師ウォーズマンは言った。 「get操作において、Tokyo Cabinet は RDB の100倍速い。100倍パワーだ！だが、Tokyo Tyrantにすることで1/10、つまり100/10 = 10倍パワー！そして、テーブルDBにすることでさらに1/3、つまり10/3 = 3.3倍パワーだっ！！」 ダメじゃん。いつの間にかもう紛れて逆転しうる接戦レベルじゃん。反省すべきはネットワーク対応。やはり、TCはシステムに直接組み込んでこそだ。その圧倒的なパワーをフルに活かすために、Scalaから直接TCを使ってみる。 必要な知識 Scala, Tokyo Cabinet インストール tokyocabinet-java-1.23 http://fallabs.com/tokyocabinet/javapkg/ Ubu
Technical Memo: Memory Saving Associative Array by Kyoto Cabinet and MessagePack
Kyoto Cabinet features on-memory database which can be used as associative array of strings. MessagePack is a binary-based efficient object serialization library. Combination of the two provides you associative array to contain generic objects. Space Efficiency of Kyoto Cabinet Let's suppose that we should manage 1 million simple records whose key and value are 10 bytes strings. The following is a
Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server
UPDATE: Oracle officially released memcached daemon plugin that talks with InnoDB. I'm glad to see that NoSQL+MySQL has become an official solution. It's still preview release but will be very promising. Let's try it to make it better! Most of high scale web applications use MySQL + memcached. Many of them use also NoSQL like TokyoCabinet/Tyrant. In some cases people have dropped MySQL and have sh
開発メモ: Kyoto Tycoonのプロトコル仕様
TTではpure Ruby版とpure Perl版のクライアントライブラリを自分で実装していたが、KTでは各種pure実装は自分では書かないことにする。私はC++版のクライアントライブラリを作成しメンテナンスするが、その他の言語に関しては、その言語で生活していて腕に覚えのある方々にお任せしたい。その前提として、プロトコルを明らかにしておく必要がある。英文の仕様書を後で書くが、そのたたき台としてまずは日本語で書いてみる。 ---- 概要 KTのサーバプログラム（ktserver）は、HTTPに基づいてクライアントと通信を行う。デフォルトのサービスポートは1978番だが、ユーザの設定によって変わることもある。サーバは、HTTP/1.0およびHTTP/1.1のリクエストを解釈することができ、それに対応するレスポンスを返す。 HTTP/1.1のリクエストにおいてContent-Typeヘッダの値が
開発メモ: Kyoto Tycoonベータ版リリースすた
ここのところ必死こいて作り込んでいたKyoto Tycoonだが、主要機能を実装しきって文書もそこそこ書けてきたので、ベータリリースということにした。プロジェクトページもちゃんと作ってある。 公式には英語の文書しか作らない方針なのだが、それだと国内ではなかなか使ってもらえないので、この場でチュートリアルを書いてみる。 Kyoto Tycoonとは プロセス組み込み軽量データベースライブラリであるKyoto Cabinetをネットワーク越しに利用できるようにするためのツールキットである。KCのデータベースを内部に持ったサーバプログラムと、それに接続してデータベースを操作するためのクライアントライブラリからなる。また、コマンドラインからサーバにアクセスするためのユーティリティもついてくるので、簡単に使い始められる。 製品コンセプトは、「永続的キャッシュサーバ」もしくは「memcachedの永続
A few key problems in Redis persistence
Today I read this article about Redis with interest. It's a legitimate point of view on databases, you may agree or not, but the author has a solid idea about what he is looking for and about the database scene. I don't agree with everything, but there is something I especially like about this article: it actually identifies very well what I think are actually the strength and deficiencies of Redi
MySQLからフォークし、クラウド用に最適化したDrizzleがベータ版公開
MySQLを再デザインしてクラウドのような大規模分散環境に最適化し、モジュラー構造にした「Drizzle」。そのベータ版が公開されたとAdrian Otto氏のブログのエントリ「Drizzle is now BETA」で報告されています。 クラウド環境に最適化したデータベース Drizzleの開発が始まったきっかけは、米クラウドベンダRackSpcaceのCTOが、MySQLの主要な開発者の1人であったBrian Aker氏に、「memcachedやGearmanを内部的に組み合わせて使える、スリムダウンしたMySQLを作ろうと思ったことはないのか？」と聞いたことだったそうです（＠IT「Drizzleプロジェクトの目指すもの、その先を読む」から引用）。 DrizzleのWebサイトには、その主旨（Charter）とスコープが宣言されています。以下がその訳です。 主旨 クラウドインフラストラ
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
開発メモ: Kyoto Tycoonの設計 その壱
memcachedのように一時的なデータを高速に扱えながらもデータをファイル上に永続化できるサーバとして、「Kyoto Tycoon」という製品を開発することにした。もちろん、Kyoto Cabinetをストレージにしたネットワークサービスを提供するものである。実のところ、決まっているのはその点と名前だけで、設計は何も決まっていない。ここにあーだこーだ書きながら詰めていこう。 背景 先に明言すべきは、これはKyoto CabinetをストレージにしたTokyo Tyrant相当の製品ではない。TTはキャッシュサーバではないので、memcachedで言う所のexpireをサポートしていない。しかし、Kyoto Tycoonはキャッシュサーバとしての利便性を追求し、もちろんexpireをサポートするとともに、レプリケーションなどの重量級の機能は割愛する。 なぜこれを作るかという理由は大きく二つ
ほぼまっさらなCentOS5.5にkumofsをインストール - DenkiYagi
いくらでも情報があるんですが、自分用の備忘録。 方針とか この手順では32bitマシンを対象にする ソースから入れるパッケージはとにかくcheckinstall ネットワーク周りやiptablesの設定は各自やってね 準備するもの CentOS 5.5をインストール済みのマシン 全部デフォルト設定でインストール（インストーラ任せ） アップデート済み（yum -y update） 手順 Development Toolsのインストール そもそもgccとか入ってなかったので、インストール。 yum -y groupinstall "Development Tools" rpmforgeを使えるようにする checkinstallをインストールしたいのだが、rpmforgeじゃないとパッケージが置いてないのでrpmforgeを使えるようにする。x64の人はAdditionalResources/
kumofsはなぜ落ちないか - Blog by Sadayuki Furuhashi
前回は、kumofsはなぜスケールするかということについて紹介しました。その中で最後に、耐障害性もスケーラビリティにとって重要だーと述べました。 そこで今回は、kumofsはなぜ落ちないのか、なぜ耐障害性が高いと言えるのかーということについて紹介したいと思います。 分散システムはテストが難しいことに定評がありますが（たぶん^^;）、その中でも耐障害性の検証は最上級に困難な部類です。 耐障害性は実際のところ、アルゴリズムの設計以前に実装上のバグが大きく影響するので、設計上は耐障害性が高いと言っていても、実際に使ってみると良く止まるという話はありがちな話です。（個人で開発している場合など、開発リソースが小さい場合はなおさら） そのため耐障害性の高いシステムを実現するためには、実装しやすくバグが入り込みにくい設計も重要かなーと思います（もちろん、アルゴリズムも重要ですが）。 分散システムには複雑
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kyoto Cabinet: Kyoto Cabinet: a straightforward implementation of DBM
High Availability MySQL: MySQL versus MongoDB - fetch by secondary index
http://1978th.net/tech/promenade.cgi?id=80