2011年 4月 24日 はてなブックマーク -
タグ: #MongoDB #KVS #Linux #CentOS

ジャーナリングが追加された「MongoDB 1.8」がリリース
2011年03月18日 14:14

 米10genは3月16日、オープンソースのドキュメント志向データベースシステム「MongoDB 1.8」を公開した。リクエストが多かったというジャーナリングなどの新機能が加わっている。

 MongoDBはドキュメント志向のKey-Valueストア型データベースシステムで、SQLを使わない「NoSQLデータベース」と呼ばれるものの1つ。Python、PHP、Ruby、Javaなどから利用するためのドライバも公開されている。

 最新版は2010年8月に公開されたバージョン1.6のフォローアップリリースとなる。最大の特徴は、新機能となるジャーナリングストレージエンジンの追加。これにより、クラッシュ時に普及作業が高速かつ安全に行えるという。

 このほか、1.6で導入された分散運用機能のシャーディングを改善し、スプリットやバランスなどが高速化し、全体のシステムへの影響が抑えられたという。同じく1.6で加わったレプリカセットでは、認証が加わった。Map/Reduceサポートも強化、差分アップデートオプションが加わった。

 Linux、Windows、Mac OS X、Solarisに対応、バイナリとソースコードはプロジェクトのWebサイトよりダウンロードできる。

MongoDB
http://www.mongodb.org/

「MongoDB 1.8」ダウンロード
http://www.mongodb.org/downloads

ジャーナリングが追加された「MongoDB 1.8」がリリース - SourceForge.JP Magazine : オープンソースの話題満載

MongoDBのjournaling1 —journalつけて起動すると、dbpathにjournalディレクトリができる。
クエリー実行の度にその操作記録がread/writeする前にjournalディレクトリ内のログに記録されて行く。正常なDBシャットダウンでこのディレクトリは削除される。


1年前 | | 2011年 4月 24日 | このエントリーを含むはてなブックマーク
2011年 4月 16日 はてなブックマーク -
タグ: #KVS #memcache

キャッシュとDB更新の戦略

KVSで登録したデータは、どうがんばっても「キャッシュ」であるとの割り切りが必要だと感じている。

Oracleのコンサルさんも入ってるのでいろいろヒントをもらった。

「ライトスルー/リードスルー/キャッシュアサイド/ライト・ビハインド」という基本的な更新/参照の設計パターンを知っておくだけでも有用だということで、

http://otndnld.oracle.co.jp/document/products/coherence/34/doc_cd/coh.340/B52977-01/readthrough.htm

たしかにこれはヒントになる。



リードスルーは、キャッシュを参照しようとしたエントリがキャッシュになかったときに自動的にDBからロードしてキャッシュに入れるやりかただ。

ライトスルーは、キャッシュ+DB更新が完了するまでput の結果を返さないことでで、更新速度を犠牲にしてでもDBとキャッシュの整合性を担保する方法だ。

キャッシュアサイドとは、DBとキャッシュの更新をそれぞれ別々にアプリケーションが管理するやりかたであり、DBとキャッシュの整合性は厳密には担保できない。


これらのパターンをどだいに、業務内容を分類する必要がある。


僕は、DBへの更新は速度を多少犠牲にするでもいいかと思い始めている。

つまり、まずはJDBCなりでトランザクションありでDBを更新する。

それからキャッシュへのエントリはトランザクションなしでとりあえずputする。

そうして、参照系のみがキャッシュの恩恵を受けるようなやり方をするのはどうだろうかと考えている。

念のためリードスルーでキャッシュミスをカバーする。

KVSの導入検討 - 山本大@クロノスの日記

更新速度を犠牲にしないなら、ACIDの厳密さを犠牲にするなど、KVSではトレードオフを我慢する必要がある。


1年前 | | 2011年 4月 16日 | このエントリーを含むはてなブックマーク
2011年 4月 16日 はてなブックマーク -

最近HandlerSocketの検証で手元のOSXにいれてみたので、その時の手順纏め。


MySQLはhomebrewでinstallしていることが前提
(いまさらmac portsはないよね?)


homebrewでインストールすると

~/Library/Caches/Homebrew

にinstallするときに使ったMySQLのソースコードがtar.gzでそのままあるので、
それをどっかの作業ディレクトリにコピーしましょう。

コーピーしたら、tarを解凍してconfigureします

$ ./configure --prefix=/usr/local LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include --with-mysql=/tmp/mysql-5.1.55 CFLAGS="-I/usr/local/include/mysql -I/usr/local/include" CPPFLAGS="-I/usr/local/include/mysql -I/usr/local/include"



こんなん。

つぎにHandlerSocketの最新版をgithubから取得し、
configure/make/make installします

$ ./configure --with-mysql-source=/tmp/mysql-5.1.55 --with-mysql-bindir=/usr/local/bin
$ make
$ make install

これでinstall自体は終了しているので一度mysql.server startでmysqldを立ち上げます。

たちあげたmysqlに接続し

mysql> install plugin handlersocket soname 'handlersocket.so';

と一発打ち込みます。

その後、my.cnfにhandlersocketの設定を書いてmysqldを再起動すれば完了です。
ちゃんとhandlersocketが立ち上がってるかは

mysql> show processlist;
+----+-------------+-----------------+---------------+---------+------+-------------------------------------------+------------------+
| Id | User        | Host            | db            | Command | Time | State                                     | Info             |
+----+-------------+-----------------+---------------+---------+------+-------------------------------------------+------------------+
|  1 | system user | connecting host | NULL          | Connect | NULL | handlersocket: mode=rd, 0 conns, 0 active | NULL             |
|  2 | system user | connecting host | handlersocket | Connect | NULL | handlersocket: mode=wr, 0 conns, 0 active | NULL             |
|  3 | root        | localhost       | NULL          | Query   |    0 | NULL                                      | show processlist |
+----+-------------+-----------------+---------------+---------+------+-------------------------------------------+------------------+

と出ておればOKです。

https://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL/blob/master/docs-ja/installation.ja.txt

このあたりを参考にすればハマることなくinstallできるとおもいます。


最新のHandlerSocketではSQLのIN相当のことが出来るように変更を入れてもらったので、
より幅広い使い方ができますね!

OSXにHandlerSocketを入れる

1年前 | | 2011年 4月 16日 | このエントリーを含むはてなブックマーク
2011年 1月 19日 はてなブックマーク -
タグ: #KVS
Kyoto Tycoonに、オンメモリDB用の自動スナップショット機能を実装した。Redisと違ってリストなどの複雑データ構造はないが、性能特性としてはRedis的に使えるようになったと思う。キャッシュをカジュアルに永続化したいなら自動スナップショットはオススメ。自動スナップショットとレプリケーションを併用して、爆速かつHAなソリューションを組んでみても面白いだろう。

開発メモ: オンメモリDB+スナップショットで爆速永続キャッシュ

オンメモリDBでも永続化できるにようになり、高速性と永続性を両立できるようになって素晴らしいですね


1年前 | | 2011年 1月 19日 | このエントリーを含むはてなブックマーク
2011年 1月 13日 はてなブックマーク -

2010-06-26

Membase vs memcached vs TokyoTyrant vs Redis

Membaseを入れてみたので、実際にどれくらいの速度が出るのか試してみました。

memcached vs TokyoCabinet vs TokyoTyrant vs Redis - blog.katsuma.tv

この記事のパクリですね。これにMembaseを加えてみた感じです。

クライアントによって速度が変わるのが嫌だったので、すべてPythonmemcachedクライアントを使って、1万回setを行いその時間を計測してみました。

Membase1.18884205818
memcached0.683738946915
TokyoTyrant0.788640022278
Redis0.642278909683

思ったよりMembaseが遅い…。って言うかRedis速い。

まとめ

使おう!Redis!APIも豊富だし、レプリケーションとかも簡単らしいよ!

Membase vs memcached vs TokyoTyrant vs Redis - とはえ領域

Redisいいかも。PHPからも使えるらしいです。
http://stbr.no-ip.org/daizu/2010/02/phpredis-predis.html


1年前 | | 2011年 1月 13日 | このエントリーを含むはてなブックマーク
2010年 9月 12日 はてなブックマーク -
タグ: #KVS #kumofs

結果

通常時のSet速度
  • 結果そのまま:3.8 req/sec
  • 1台で3プロセス立ち上げて、全プロセスにレプリケーションしているので、物理ホスト1台あたりの書き込み速度は 3.8×3=11.4 req/sec
  • 4台投入すると、11.4 × 3 = 45.6 req/sec
    • このうち3台にレプリケーションするので、4台構成時のSet性能は 45.6 / 3 = 15.2 req/sec

通常時のGet速度
  • 結果そのまま:6.7 req/sec

再配置時間
  • 結果そのまま:
    • データを全件スキャンして移動するべきデータを取り出すのにかかった時間:210秒
    • データの転送にかかった時間:80秒
  • スループットは 1000件 / (210秒 + 80秒)= 3.44件/sec くらい
    • MB/secに直すと 10MB × 1000件 / (210秒 + 80秒) = 34.4MB/sec くらい
      • データの転送のスループット:10MB×1000件 / 80秒 = 125MB/sec
  • 1台構成、データ量1TBで、1TB / 34.4 = 8時間 くらい
  • 4台構成、データ量1TBで、2時間 くらい

データの再配置はストリーム全体を圧縮して行っているが、今回使ったデータは全部 ‘v’ で埋められたデータなので、圧縮率がやたら効いている。

実際にはデータの転送にもっと時間がかかるハズ…だが、実際にはHDDの方がボトルネックになっているはずなので、おそらく結果には関係ない。遅延は若干増えるはずだが、ミリ秒レベル。


再配置中のGet速度
  • 結果そのまま:3.4 req/sec
  • 通常時は 6.7 req/sec だったので、半分くらいに落ちている

kumofsに10MBのvalueを入れるとどうなるか実験してみた - sdyuki-devel

HDDが遅いのでそうなりますよね。


1年前 | | 2010年 9月 12日 | このエントリーを含むはてなブックマーク
2010年 8月 25日 はてなブックマーク -
タグ: #Linux #CentOS #KVS #Flare

Flareとは?

Flareは、携帯ゲームやソーシャルネットワーキングサービスGREEで有名なグリー株式会社さんの方で開発されているオープンソースの分散KVSです。ホームページが以下URLにあり、ソースコードがダウンロードできるようになっています。

▽Flareホームページ
http://labs.gree.jp/Top/OpenSource/Flare.html

SoftwareDesign 2010年2月号に開発者であるグリーCTO藤本さんの記事が掲載されています。それによると、

  • ソーシャルネットワーキングサービスGREEのバックエンドデータベースとして稼動している
  • GREEにログインすると最初に表示される「ともだち更新情報」のデータが格納されている
  • データ容量は会員数約1500万人で、1ユーザあたりのレコード数300件

とのことで、実際に大規模なサイトでの運用実績があることが分かります。

Flareを使う(インストール編) « さくらインターネット研究所

お手軽なGree製Flareのインストール方法です。
telnetで以下のコマンドを打たないとシングル構成で動かないので要注意。
node role 192.168.13.23 12121 master 1 0

また、GC機能がないので50GBくらいまで溜まったところでファイルが破損する所も要注意ですね。


1年前 | | 2010年 8月 25日 | このエントリーを含むはてなブックマーク
2010年 8月 13日 はてなブックマーク -

[速報]mixiが障害の経緯を発表。原因はお盆のアクセス急増ではなく、memcachedの異常終了

2010年8月12日

8月10日の17時20分頃から12日未明までの長時間にわたり、サービスが利用不能もしくは利用しにくい状況になっていた「mixi」。数度の断続的な復旧ののちに、本日12日午前1時50分頃には復旧が完了し、現時点で全面的に復旧しているようです。

『mixi』のアクセス障害のお詫び及び復旧に関するお知らせ « 株式会社ミクシィ

その障害の経緯について株式会社ミクシィの広報からプレスリリース「『mixi』のアクセス障害のお詫び及び復旧に関するお知らせ」として発表されました。

原因はアクセスの急増ではなかった

プレスリリースの中で、今回の障害の原因は以下のように説明されています。

『mixi』のデータベースへの負荷軽減のために導入しているデータキャッシュシステムが複数同時に異常終了したことに伴い、データベースへの負荷が急増したため『mixi』を閲覧しづらい状態となりました。

高負荷かつ特殊な状態でのみデータキャッシュシステムの異常終了が発生していたため、根本的な原因の究明に時間がかかることとなりました。

mixiはキャッシュシステムとしてオープンソースのmemcachedを利用しており、上記の「データキャッシュシステム」もmemcachedのことを指しているようです。

同社CTOの佐藤ニール氏は、Twitterで次のように原因をツイートしています。

二日とも複数台のmemcachedが連続して落ちました。コアは吐かずにストンと落ちるので、原因追及に時間がかかりましたが、memcachedへの接続数が異常に多いと落ちる事は再現できました。 #mixiless than a minute ago via TweenNeal Sato
nealsato

mixiの障害の原因として「夏休みやお盆などでアクセスが急増したのでは?」などの推測が一部で流れていましたが、そうしたmixiへのアクセスが急増したためではなく、システム内のサーバ追加によるとのこと。

memcachedが大量の接続を受けると突然停止をするので、memcachedへの接続数を減らし安定運用中。外部からの過剰アクセスではなく、サーバ追加→クライアント数増加→停止。less than a minute ago via TweenNeal Sato
nealsato

再発防止策として、以下のような施策を実行するとプレスリリースで説明されています。

1.データキャッシュシステムへの負荷を軽減する措置を施す
2.将来的に負荷が増加した場合に備え、問題が発生した際にもデータキャッシュシステムが異常終了せず処理を継続して高い堅牢性を保つ手法を調査する
3.データキャッシュシステムの障害が『mixi』のシステム全体に影響しないよう、影響範囲の局所化を検討、実施する

memcachedはmixiだけでなく多くの大規模サイトで使われている技術です。今回の障害の原因についてさらに分析をすすめて、共有できるような教訓があればぜひ公開していただきたいと思います。

[速報]mixiが障害の経緯を発表。原因はお盆のアクセス急増ではなく、memcachedの異常終了 - Publickey

「memcached-1.4.4 + libevent-1.3b、memcachedの接続数30kの設定に対して30k以上投げ続けると、base_event_loopからなぜか抜けてしまいます」という情報がtwitterであります。
memcachedの接続数はファイルディスクリプタでの制御に過ぎないから、libeventでの不具合の追求結果を待っているところです。


1年前 | | 2010年 8月 13日 | このエントリーを含むはてなブックマーク
2010年 6月 25日 はてなブックマーク -
タグ: #KVS #memcache #memcached

memcachedの開発者らが中心となって今年の3月に立ち上げた企業NorthScaleが、memcached互換のNoSQLデータベース「Membase」のオープンソースプロジェクト「membase.org」を6月23日に発表しました。

MembaseはWebアプリケーションのバックエンドに使われることを想定したキーバリュー型データストア。高速かつ高いスケーラビリティを目指したもの。

主な機能として、将来にわたってmemcashedとプロトコルの互換性を保証しつつ、ディスクへの永続性機能(データのディスクへの書き込み)、階層型データストア管理、データレプリケーション、稼働状態での設定変更とノード間のリバランシング機能なども備えると説明されています。

memcached互換のNoSQLデータベース「Membase」がオープンソースで登場 - Publickey

またまた良いものが出てきました。


1年前 | | 2010年 6月 25日 | このエントリーを含むはてなブックマーク
2010年 6月 23日 はてなブックマーク -
タグ: #KVS #memcache #memcached
#!/bin/bash
#
# Init file for memcached
#
# Written by Dag Wieërs 
#
# chkconfig: - 80 12
# description: Distributed memory caching daemon
#
# processname: memcached_session
# config: /etc/sysconfig/memcached_session
# config: /etc/memcached_session.conf

source /etc/rc.d/init.d/functions

### Default variables
PORT="11212"
USER="nobody"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS=""
SYSCONFIG="/etc/sysconfig/memcached_session"
MEMCACHED="/usr/bin/memcached"
MEMCACHED_SESSION="/usr/bin/memcached_session"

### Read configuration
[ -r "$SYSCONFIG" ] && source "$SYSCONFIG"

RETVAL=0
prog="memcached_session"
desc="Distributed memory caching"

start() {
        echo "searching $prog"
        if [ -e $MEMCACHED_SESSION ]
        then
                echo "$prog exist"
        else
                ln -s $MEMCACHED $MEMCACHED_SESSION
        fi 
        echo -n $"Starting $desc ($prog): "
        daemon $prog -d -p $PORT -u $USER -c $MAXCONN -m $CACHESIZE $OPTIONS
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
        return $RETVAL
}

stop() {
        echo -n $"Shutting down $desc ($prog): "
        killproc $prog
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog
        return $RETVAL
}

restart() {
        stop
        start
}

reload() {
        echo -n $"Reloading $desc ($prog): "
        killproc $prog -HUP
        RETVAL=$?
        echo
        return $RETVAL
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart)
        restart
        ;;
  condrestart)
        [ -e /var/lock/subsys/$prog ] && restart
        RETVAL=$?
        ;;
  reload)
        reload
        ;;
  status)
        status $prog
        RETVAL=$?
        ;;
   *)
        echo $"Usage: $0 {start|stop|restart|condrestart|status}"
        RETVAL=1
esac

exit $RETVAL
@wieers.com>

memcachedを複数起動する起動スクリプト - netmark.jp

pid分けて起ち上げるだけですが、意外と便利そうです。


1年前 | | 2010年 6月 23日 | このエントリーを含むはてなブックマーク
2010年 6月 23日 はてなブックマーク -
タグ: #PHP #KVS #memcache

[PHP][memcached] phpセッションmemcached を使う

CentOSの場合

  • install

rpmforgeのレポジトリが入っていない人は以下の手順で追加

# wget http://dag.wieers.com/packages/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.i386.rpm
# rpm -Uhv rpmforge-release-0.3.6-1.el5.rf.i386.rpm
# yum install libevent memcached php-pecl-memcache
  • 設定

/etc/php.ini を以下のように編集

session.save_handler = memcache
session.save_path = "memcached.example.com:11211"

/etc/sysconfig/memcached を以下のように適当に編集する。

PORT="11211"
USER="nobody"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS=""
  • スタート

memcached デーモンをスタート

# chkconfig memcached on
# service memcached start

Apacheをリスタート

# service httpd restart
  • 各種設定

パケットキャプチャみると、各値の有効期限が、1440秒になっている。設定場所がわからない。

ソースを見てみると、

memcache_session.c:		if (mmc_pool_store(pool, "set", sizeof("set")-1, key_tmp, key_tmp_len, 0, INI_INT("session.gc_maxlifetime"), val, vallen TSRMLS_CC)) {

session.gc_maxlifetime を使っているのが分かる。

これで、有効期限を設定できた。

php のセッションにmemcached を使う - Sleepless geek in Seattle

スタンダードなmemcacheの場合は「session.gc_maxlifetime」を見ている。TokyoTyrant系はどうなっているのか・・・


1年前 | | 2010年 6月 23日 | このエントリーを含むはてなブックマーク
2010年 6月 4日 はてなブックマーク -
タグ: #Linux #PHP #KVS

要件は

  • 1000qps/1000コネクション以上の環境で動作可能
  • セッション数/接続数が増えてもスループットが低下しない
  • 有効期限の切れたセッションは自動で削除
  • 冗長化が可能
  • フェイルオーバーが自動
  • 任意のタイミングで停止せずにマスタの切り替えが行える
  • 書き込み直後に読み込みを行っても常に一貫した情報が取得できる
  • 構成がシンプル

が上記要件のいくつかを満たせそうだ。

repcached

  • デュアルマスタ構成可能
  • 非常に高速
  • 有効期限設定可能
  • memcachedなので揮発性
  • 使用できる容量は割り当てメモリまで

セッションストレージとして使われている話もよく聞くrepcached。memcached互換プロトコルなのでクライアントライブラリにも困らなそう。

しかし、オペレーションミスなどの”最悪な事態”を考慮すると、揮発性メモリだけにデータを置くのは怖い。キーを打つ手が震える。

Flare

  • マスタ スレーブ構成可能
  • スレーブをマスタに昇格可能
  • パーティショニング可能
  • 有効期限設定可能(らしい)
  • Tokyo Cabinetに格納
  • スケールアウト
  • 情報少なめ

FlareはファイルベースのTokyo Cabinetにデータを置く分散ストレージmemcached互換プロトコル。データの保存を行う複数のノードと、ノードを管理するインデックスサーバで構成。インデックスサーバノードを監視していて自動的にフェイルオーバーも行えるらしい。

機能は申し分無いものの、恐らく構成としてはマスタ、スレーブとインデックスサーバの3台が必要になり、またクライアント側にproxyノードを置いた方が良いみたいで、そうすると構成が複雑になってしまいうれしくない。

パーティショニングが必要になる規模になったら使ってみたい。

Tokyo Tyrant

  • デュアルマスタ構成可能
  • 有効期限は拡張スクリプトで実現
  • Tokyo Cabinetに格納
  • スケールアップ

Tokyo Tyrantは、データベースライブラリTokyo Cabinetのネットワークインターフェースmemcached互換、HTTPと独自のプロトコル。有効期限を使用するような場合は専用クライアントが必要。拡張スクリプトで機能追加を行える。マスタ スレーブ構成とデュアルマスタ構成が可能。構成は比較的シンプル

mixiではサーバ1台で10000qps/10000コネクションを処理しているらしい。

mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築

というわけで、今回はタイトルからもわかる通り、要件を満たせる度合いが高そうなTokyo Tyrantセッションデータ保存する方法を考えてみたい。

Tokyo TyrantによるHAなセッションストレージ 1 検討篇 - Webと何かとその近所

Flareを使うには3台必要になると書いてあるけれども、実際の所1台で出来ます。
ただ先ほど投稿した記事の通りGCの仕方が見あたらないので定期的にリセットする必要があり、半年ほど使った後に利用を断念することにしました。
それよりも前にrepcachedも使いましたが安定性に疑問があったので採用せず。
そして最後にTokyoTyrantに期待を寄せています。


1年前 | | 2010年 6月 4日 | このエントリーを含むはてなブックマーク
2010年 6月 3日 はてなブックマーク -
タグ: #Linux #PHP #KVS

クラッシュする直接的名原因は、 php-tokyo_tyrant のチェックが甘いからです。

ただし、実質的な問題は、 tokyo_tyrant を .tch モードで動かしたことにあります。

tokyo tyrant を .tct モードで動かしてみる。

vi /usr/local/sbin/ttservctl
--------/usr/local/sbin/ttservctl---
dbname="$basedir/casket.tch#bnum=1000000"
↓
dbname="$basedir/casket.tct#bnum=1000000"
------------------------------------

//tokyo tyrant 再起動
/etc/init.d/ttservctl restart

ブラウザでtest.phpアクセスしてみましょう、今度は大丈夫。

ページをリロードするたびに値が +1 されていくのが分かります。

php-tokyo_tyrant の公式では以下のパラメータが推奨されています。

http://www.php.net/manual/ja/tokyo-tyrant.installation.php

  • extpc expire 30.0 ‘/tmp/sessions.tct#idx=ts:dec

php-tokyo tyrant で tch だとtcrdbtblgenuid関数が失敗して Segmentation faultする件 - お前の血は何色だ!! 4

Tokyo Cabinet には3パターンのデータ形式があり、PHPからのセッション利用時にはtchである必要があるとの事です。
そうでもしないとSegmentation faultで落ちます。
・.tch … ハッシュデータベース
・.tcb … B+木データベース
・.tct … テーブルデータベース


1年前 | | 2010年 6月 3日 | このエントリーを含むはてなブックマーク
2010年 6月 3日 はてなブックマーク -
タグ: #Linux #PHP #KVS

Tokyo TyrantによるHAなセッションストレージ 2 PHPから利用する篇 - Webと何かとその近所

Tokyo Tyrantを使ったKVSなセッションストレージの実装サンプルとベンチマーク結果です。
なかなかしっかりまとまっているので素晴らしいです。

1年前 | | 2010年 6月 3日 | このエントリーを含むはてなブックマーク
2010年 3月 3日 はてなブックマーク -
タグ: #KVS #DB

Twitter が Cassandra を選んだ理由 — MyNoSQL « Agile Cat — Azure & Hadoop — Talking Book

ずっと以前から、Twitter が Cassandra の利用を計画しているというウワサ [1] があった。 しかし、このポストを除いて、他の情報を得ることは無かった。 Twitter は楽しいし、すべて人々が NoSQL プロジェクトに適していることを知っている。 それだけに、Cassandra 0.5.0 のリリースの後に、Ryan King から短いメールをもらった時の感激を想像してほしい。なぜなら、Cassandra で Twitter を推進する彼が、その内容を説明しても構わないと言ってくれたからだ。 難しい話は抜きにして、Twitter における Cassandra の用法について、私と Ryan King が交わした会話を紹介する
INSERTクエリの分散化を考えると、MySQL Cluster、そしてQ4M的なキューイング、それでだめなときにMemcache、スケールしにくいのでCassandraという流れですかね。 Memcache的なKey-Value型のストレージ(KVS)は万能ではないけれども、使い方を工夫するととてつもない力を発揮します。うまく利用していきたいです。
2年前 | | 2010年 3月 3日 | このエントリーを含むはてなブックマーク