開発メモ: Kyoto Tycoonベータ版リリースすた
ここのところ必死こいて作り込んでいたKyoto Tycoonだが、主要機能を実装しきって文書もそこそこ書けてきたので、ベータリリースということにした。プロジェクトページもちゃんと作ってある。 公式には英語の文書しか作らない方針なのだが、それだと国内ではなかなか使ってもらえないので、この場でチュートリアルを書いてみる。 Kyoto Tycoonとは プロセス組み込み軽量データベースライブラリであるKyoto Cabinetをネットワーク越しに利用できるようにするためのツールキットである。KCのデータベースを内部に持ったサーバプログラムと、それに接続してデータベースを操作するためのクライアントライブラリからなる。また、コマンドラインからサーバにアクセスするためのユーティリティもついてくるので、簡単に使い始められる。 製品コンセプトは、「永続的キャッシュサーバ」もしくは「memcachedの永続
blog.katsuma.tv
当然のごとくmemcachedが最速だろう。。。と思いきや、そうでもない結果に。むしろ一番遅い結果に。なんだこれーーーと思って調べ続けていたのですが、バインディングのgemのコードを追いかけるかぎり、どうもこれはmemcache-clientの実装が原因のよう。 これは、memcache-clientの実装はpure-rubyで実装されているのに対して、TokyoCabinet/TokyoTyrantのバインディングの実装はnativeコードで実装されてあるのが原因のようです。事実、TokyoTyrantはmemcacheプロトコルを実装しているので、memcache-clientを利用してTokyoTyrantにアクセスすると両者はこんな結果になりました。 user system total real
Membase vs memcached vs TokyoTyrant vs Redis - #詰んでる日記
Membaseを入れてみたので、実際にどれくらいの速度が出るのか試してみました。 memcached vs TokyoCabinet vs TokyoTyrant vs Redis - blog.katsuma.tv この記事のパクリですね。これにMembaseを加えてみた感じです。 クライアントによって速度が変わるのが嫌だったので、すべてPythonのmemcachedクライアントを使って、1万回setを行いその時間を計測してみました。 Membase 1.18884205818 memcached 0.683738946915 TokyoTyrant 0.788640022278 Redis 0.642278909683 思ったよりMembaseが遅い…。って言うかRedis速い。 まとめ 使おう！Redis！APIも豊富だし、レプリケーションとかも簡単らしいよ！ ちなみに今回計測に使
memcached互換のNoSQLデータベース「Membase」がオープンソースで登場
memcachedの開発者らが中心となって今年の3月に立ち上げた企業NorthScaleが、memcached互換のNoSQLデータベース「Membase」のオープンソースプロジェクト「membase.org」を6月23日に発表しました。 MembaseはWebアプリケーションのバックエンドに使われることを想定したキーバリュー型データストア。高速かつ高いスケーラビリティを目指したもの。 主な機能として、将来にわたってmemcachedとプロトコルの互換性を保証しつつ、ディスクへの永続性機能（データのディスクへの書き込み）、階層型データストア管理、データレプリケーション、稼働状態での設定変更とノード間のリバランシング機能なども備えると説明されています。 Membaseの特徴はmemcached互換とスケーラビリティ MembaseのWebサイトの情報を基に、特徴を紹介しましょう。 動的なノー
NoSQLの本命となるか？ memcachedの開発者らが新たなオープンソースプロジェクト「membase」を立ち上げ | OSDN Magazine
Webインフラ企業の米NorthScaleは6月23日（米国時間）、オープンソースのNoSQLプロジェクト「membase.org」を立ち上げたことを発表した。プロジェクトのサイトでは、「Membase 1.6」ベータ1のバイナリとソースコードを公開している。 NorthScaleは分散メモリキャッシュシステム「memcached」の主要開発者が立ち上げたベンチャー企業で、memcachedをベースにした「NorthScale Membase Server」や「NorthScale Memcached Server」などの製品を開発・提供している。今回、membaseの早期ユーザーである米Zynga、韓国NHNの2社と共に、オープンソースプロジェクトとしてmembase.orgを立ち上げた。今後は、membase.orgをオープンソースプロジェクトとし、商用版としてMembase Serv
ウノウラボ Unoh Labs: Tokyo Tyrantを使ってみて
yamaokaです。 通常のデータベースとしてではなく、Key-Valueストアの選択肢として Tokyo Tyrantを少しずつ使ってみています。 実際に運用するにあたって、いくつか行ったことを書いておきます。 ちなみに、現在の構成は1台のみでの運用です。 マルチマスター構成やレプリケーションなどは行っていません。 PHPのクライアント Tokyo Tyrantを利用するのはPHPのアプリケーションからです。 最初はmemcachedプロトコルを利用して PECL::memcacheを使っていましたが、 データの大量更新を連続で行うとデータの取得が正常に行えなくなる現象が発生したため、 Net_TokyoTyrantを一部改変したものをライブラリとして利用しています。 パフォーマンスではPECL::memcacheに負けますが、クリティカルな処理をしていないこともあり、 今のところ問題に
Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性
Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の技術担当バイスプレジデント Jeff Rothschild氏が、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Massive Scale-Lessons learned at Facebook」の内容を再構成して紹介します。 （この記事は「Facebookが大規模なスケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題」の続きです） キャッシュがスケーラビリティに大きな役割を果たしている Facebookの主な役割は、ユーザーが簡単に（友人たちの）情報を集めることがで
第1回 Kaiとは？ ─Kaiのコンセプトとメカニズム | gihyo.jp
今回から数回にわたり、Kaiという分散Key/Valueストアについて解説させていただきます。 まず、第1回では井上がKaiのコンセプトをご紹介します。次回以降は、Kai開発者の一人である幾田さんがKaiの利用方法について解説します。最終回では、gooホームでKaiを運用している橋本さんから、Kaiの運用方法について紹介していただく予定です。なお、本連載が対象とするKaiのバージョンは0.4です。 Kaiとは Kaiとは、分散型のKey/Valueストアです。Amazon.comが2007年に発表したDynamoというシステムに触発されて、そのオープンソース版として開発されています。Kaiをバックエンドに据えてWebサイトを構築することで、高いスケーラビリティやアベイラビリティを実現できます。2009年5月には、gooホームのバックエンドに導入され、運用実績も高まってきました。 Kaiは多
全文検索エンジンgroongaをテストリリースしました。 - グニャラくんのグニャグニャ備忘録@はてな
全文検索エンジンのgroongaをテストリリースしました。 groonga 本日開催された、key-value store勉強会で発表させていただきました。 今まで、Sennaには Tritonn経由で使った場合、MySQL側のインデックスとの併用が難しく、Senna本来のパフォーマンスが発揮できなかった。 従来のインターフェースでは、トークナイザの切り替えなどの柔軟性がなかった。 といった問題がありました。 groongaは、それに対する返答です。 自分でデータベース書けばいいんじゃね？ 柔軟なAPI用意すればいいんじゃね？ ってことですね。 データベースは、key-valueストアを組み合わせたcolumnストア的な感じになっています。 詳細については、今後別エントリやドキュメントで述べます。 今後は、Sennaはバグ修正のみ行うメンテナンスモードに移行します。 実際使ってみよう 今回
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
ウノウラボ Unoh Labs: PHPライブラリ Net_TokyoTyrantの紹介
皆さんopenpearしてますか！ 最近、インフルエンザの予防接種を受けたKeitaです。 ずいぶん前にですが、PHPからTokyoTyrantをネイティブに操作するライブラリをopenpearにてリリースしたので、簡単に紹介したいと思います。 Net_TokyoTyrantとは？ PurePHPで書かれた、TokyoTyrantのネイティブなインターフェースを叩くライブラリです。 memcache互換のインターフェースなどとは違い、TokyoTyrantのLUA拡張などTokyoTyrant本来の機能をほぼすべて使えるというのが特徴です。 インストール PEARライブラリとして公開されているので非常に簡単にインストール可能です。 openpearのチャンネルを追加します。 pear channel-discover openpear.org PEARコマンドでインストールを
MemcachedではなくRepcachedをセッション管理に使用する（ついでにTokyo Tyrantについても少し）
森川です。 複数台のWebサーバでセッション管理をする場合、NFS・DB・Memcachedなんかが一般的ですが、今回はMemcachedじゃなくてレプリケーションができるRepcachedを使ってみよう！というお話です。 まずは、Repcachedの話です。といってもMemcachedにレプリケーション機能が追加されたものというものです。 RepcachedはKLab株式会社さんのクラブラボで公開されています。インストール方法などについては、リンク先のページを見ればわかると思います。 今回のエントリで重要なのは、 ・高速であること （Memcachedと遜色ない） ・レプリケーションができること （１台が落ちてもデータが失われない） ・Memcachedのクライアントが使えること（設定を変更する必要がない） ということです。 ただし、割り当てたメモリを超えてデータを保存した場合には、デー
Google App EngineとMemcache API - mixi engineer blog
こんにちは、某Perl界隈のIRCチャンネルでPythonがマイブーム的なKY誤爆をしてしまったtmaesakaです。 先日、以前から興味のあったGoogle App EngineとMemcache APIについて少し調べ、こちらに英文で報告したのですが、今日は日本語で要約したまとめを紹介します。 まず軽く前置きですがGoogle App Engine (GAE)とは、Googleが提供しているウェブアプリケーションをGoogleのインフラ上でスケーリングや冗長化など、ある程度のノウハウや資金を要求される面倒な事を気にせずに運営できるプラットフォームです。つまり、典型的なPaaSの例であり、サービスの運営コストをelastic（伸縮）にします。昨今バズワード化しつつあるクラウドコンピューティングの一種でもあります。 GAEのインフラはGoogleより提供されているAPIセットを用いて利用し
tokyo tyrantでPHPのセッションサーバやろうとおもって失敗した話 - cocoiti's diary
PHPには、memcacheをセッションハンドラにする機能があります。 shimookaさんが簡単にご紹介されています 一方Tokyo Cabinet(以下TC)をネットワーク越しで使うTokyo Tyrant(以下TT）は、memcache互換のインターフェースがあります。 「・・・・もしかして、Tokyo Cabinetをストレージにできるんじゃね？そしたら永続化できるんじゃね」とおもったのが夕方。 仕事がおわってさっきためしてみました。 TCとTTはとりあえず、RPMを作ったんですが、ちょっと煩雑なので、id:perezvonのTTはじめましたの記事のコンパイル方法参考にするといいかとおもいます。 TTのサーバを立ち上げて、（TTの1.0だとttservctlというスクリプトがありました。) ttservctl start php側の設定で、 php.iniに session.sav
repcachedのメモ。 - hideden.hatenablog.com
ある程度でかいサービスでDailyCount的な事をやらなきゃいけなくなって、DBに突っ込むとログのお掃除や負荷が大変だからmemcachedでやりたいけど、落ちたらウザいしなー・・・って考えてたらrepcachedを思い出した。YAPC2008でもmixiのkazeburoさんが紹介してたみたい。まぁ寝坊して聞けなかったんだけど。。。 で、ちょっと色々やってみたメモ。まださほど検証してない。 Installとかはほとんど公式のとおりに。memcachedと共存させるためにバイナリ名かえてみた。 ./configure --enable-replication --program-transform-name=s/memcached/repcached/ make make installで、起動。console2つ開いて-vつけて情報表示させつつ。 repcached -v -m 64
たけまる / Kai - Amazon's Dynamo communicating with memcache protocol
_ Kai - Amazon's Dynamo communicating with memcache protocol [kai][dynamo][erlang] だいぶ前 [2008-02-25-1] に，Perl (POE) で Amazon Dynamo っぽいもの を作りかけて放置していました． Erlang で書き直して，それなりに動くことを確認したので公開します．名 前は Kai といいます．今回は，memcache プロトコルでデータをやり取り できるようにしました． Dynamo とは，Amazon で使われているスケーラブルなハッシュテーブルで す．詳しくは [2008-01-31-1] に書きましたが，次のような特徴を持って おり，Amazon の巨大なサービスを支えています． - 簡単にスケールアウトできる - 障害に強い (マシン障害どころかラック障害にも耐える)
mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「
cagraのα版試してみたよ（ビルド編） - @takuma104 log
cagra: Reliable and Flexible Distributed Storage System 分散ストレージエンジンテクニカルデモ α版リリース あの上野 (nyaxt) 氏と、あの古橋 (frsyuki/viver) 氏 共作の cagra*1。cagra は分散ストレージシステムで、memcached の分散版というとちょっと語弊があるけど、memcached位のお手軽さで使えるストレージ（現在はオンメモリのみ）です。ストレージという意味では、MogileFS に近いのでは？というご指摘もいただきました。現在 24 ノード (24台) 位でもちゃんと動いているようです。（もちろん、1ノードでも動くよ） しかもデフォルトで Ruby バインドが付属です！memcached を簡易 DB 代わりみたいに Ruby から使っている僕としては、これは試すしかない！ということで
repcached-2.0リリースのお知らせと、超簡単なサンプルコード : DSAS開発者の部屋
repcached-2.0(memcached-1.2.5ベース) をリリースしましたのでお知らせします。 http://lab.klab.org/modules/mediawiki/index.php/Repcached (日本語) http://repcached.lab.klab.org/ (英語) 今回の目玉はマルチマスタ構成のサポートです。 以前のバージョンはマスタ/スレーブ構成だったので、必ずマスタへ書き込まなければいけませんでした。そのため、接続先のサーバがマスタなのかどうかをクライアントが判別しなければいけなかったり、keepalivedなどと併用するなどの工夫が必要でしたが、今回のバージョンではその必要がなくなります。両方のサーバに対してデータを書き込むことができるようになったので、かなり使いやすくなったと感じています。 repcachedはパフォーマンスを最重視している
PHP＋memcache＋Repcachedを試してみた - Do You PHP はてブロ
KLabラボから公開されているRepcachedですが、フェイルオーバーした際の挙動とかを確認したくて、サックリ試してみました。 環境はCentOS4.6 on VMwareで仮想NICは1枚、NAT接続でIPアドレスは192.168.98.128です。PHPのバージョンは5.2.5です。 Repcachedのインストールはこんな感じ。 $ wget http://www.monkey.org/~provos/libevent-1.4.2-rc.tar.gz $ tar zxf libevent-1.4.2-rc.tar.gz $ cd libevent-1.4.2-rc/ $ ./configure $ make $ sudo make install $ cd ../ $ wget http://downloads.sourceforge.net/repcached/memcached
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
