Content-Length: 251028 | pFad | http://b.hatena.ne.jp/hirose31/Tokyo%20Tyrant/
SSDとTokyoTyrantやMySQLの性能検証
2. 2 経緯 • 今後、ソーシャルアプリ開発でSSDや TokyoTyrantなどを使いたい • メーカーさんのおかげで、SSD搭載サーバの 評価機を2週間借りられることになった • 是非検証したい！ 3. 3 目的 • SSD搭載サーバは30万円くらいプラスになる ので、費用対効果を知りたい • SSDとHDDの性能や特徴について調査する • 特に、TokyoTyrantなどのミドルウェアとの相 性について調査する 4. 4 サーバスペック・検証環境 • サーバスペック – CPU: 「Xeon E5502 @ 1.87GHz」 ×２(Dual)×２ – DISK • SSD RAID1 46GB （OS、ログ等用） • SSD RAID1 46GB （データ用） • HDD(10000RPM) RAID1 67GB（データ用） – OS: CentOS 5 (設定はほとんどいじってい
Tokyo TyrantとテーブルDBでリアルタイム検索 - mixi engineer blog
ドラクエは卒業して、もっと英語漬けをやっているmikioです。さて今回は、データベースサーバTokyo Tyrantとテーブルデータベースを使ってリアルタイム検索システムを構築する方法について語ります。 テーブルDBを分散させたい Tokyo TyrantでもテーブルDBがサポートされているわけですが、これはリアルタイム検索システムへの布石です。テーブルDBは任意のコラムにインデックスを張ることができ、時系列のコラムにインデックスを張ればその値によって古いコラムを効率的に消すことができます。チュートリアルの「Persistent but Expirable Cache」でもその方法を示しています。また、任意のコラムに分かち書きトークン方式もしくは文字N-gram方式で転置インデックスを張ることができます。これらを総合すると、最新のデータのみを保持してサイズと性能を一定に保ったインデックスを
MySQL-Memcached or NOSQL Tokyo Tyrant - part 3
This is part 3 of our series. In part 1 we talked about boosting performance with memcached on top of MySQL, in Part 2 we talked about running 100% outside the data with memcached, and now in Part 3 we are going to look at a possible solution to free you from the database. The solution I am going to discuss here is Tokyo Cabinet and Tyrant. I am not going to give you a primer or Tutorial on
プラグインで独自ストレージを作ろう - mixi engineer blog
OpenSocialとかC++0xとか世の中の流れが早すぎて、いろいろと勉強しなきゃなと焦りつつも、ついついピクミン2にはまってしまうmikioです。今回はTokyo Tyrant（TT）を使ってユーザ独自のストレージシステムを簡単に構築する方法について説明します。 プラグインとは オブジェクト指向プログラミングに慣れた人にとっては、インターフェイスと実装を分離することによってプログラムの拡張性や保守性を向上させる技法（データ抽象）は常識ですよね。その考えをさらに進めると、インターフェイスのみをプログラムに記述しておいて、具体的な実装は実行時に割り当てるという、いわゆるプラグイン（plug-in）という技法に至ります。プラグインでカスタマイズできる能力をプラガブル（pluggable）などと言ったりもします。 例えばTokyo Cabinet（TC）では、レコードの挿入、削除、参照といった
mixi Engineers’ Blog >> Tokyo (Cabinet|Tyrant)の新機能
アロハシャツとショートパンツとビーサンで出勤してスネ毛が美しくないと評判のmikioです。さて今回は、Tokyo Cabinet（TC）とTokyo Tyrant（TT）のそれぞれ最新版でサポートされた新機能についてご紹介します。 固定長データベース 最終ログイン時刻データベースをTTで管理する仕組みについての記事を以前書きましたが、それに対して「各レコードを固定長にすればlseek一発で参照できるよ」という趣旨のご指摘をいただきました。全くその通りで、最終ログイン時刻の値に必要な領域は各ユーザ毎に10バイトもあれば十分ですし、検索キーはユーザID（mixiにおいては1からの連番）なので、それを添字に使えば二次元配列としてデータベースを表現することができます。 ただし、yamazさんも指摘しているように、ログイン時刻データベースのスループット限界はwriteがブロックすることにより訪れるの
mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/hirose31/Tokyo%20Tyrant/
Alternative Proxies:
Twitter / Mikio February11: @hirose31 あ！ TCのソース（tcadb. ...
http://1978th.net/tech-en/promenade.cgi?id=6
moved