MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
![SSDとTokyoTyrantやMySQLの性能検証](https://cdn-ak-scissors.b.st-hatena.com/image/square/493ca80e5412020484dcd823c550615f15b19046/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F306tokyotyrant-100422233509-phpapp01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
6. 実際にベンチしてみた 尚、 100 万件で試した場合、 memcached, TC ともにほぼ 10 倍でした。 ( MySQL は怖かったのでやってません) 100 万件入れた時のファイルのサイズは、 32MB でした。 ( Key, Value ともに、 10 文字以下程度) 内容 Memcached TC&TT MySQL 10 万件の保存と取得 15.5 秒 21.7 秒 2 分 45 秒 10 万件の取得 7.5 秒 11.7 秒 1 分 11 秒 10 万件の取得 2 回目 - - 32 秒 10 万件の挿入 8.6 秒 10.2 秒 InnoDB 1 分 34 秒 MyISAM 57 秒
PHPからセッションストレージとしてTokyo Tyrant (TT)を使用する場合、PHP用のTTクライアントライブラリが必要になるが、悲しい事に公式なライブラリはない。 幸い何種類かPHP用のライブラリが公開されているので、その中のどれかを使わせてもらおう。 Net_TokyoTyrant php-tokyo_tyrant tokyotyrant_php ざっと調べたところ上の3種類が見つかった。他にもあるらしいけど見つけられなかった。 tokyotyrant_phpは作者の方が実験レベルと言っている事から採用を見合わせ、Pure PHPのNet_TokyoTyrantとPECLのphp-tokyo_tyrantを調べてみた。どちらも現在ベータ版。 PHPのNet_TokyoTyrantの方が取り扱いは楽だしモテるらしいけど、PECLのphp-tokyo_tyrantの方がパフォーマン
yamaokaです。 通常のデータベースとしてではなく、Key-Valueストアの選択肢として Tokyo Tyrantを少しずつ使ってみています。 実際に運用するにあたって、いくつか行ったことを書いておきます。 ちなみに、現在の構成は1台のみでの運用です。 マルチマスター構成やレプリケーションなどは行っていません。 PHPのクライアント Tokyo Tyrantを利用するのはPHPのアプリケーションからです。 最初はmemcachedプロトコルを利用して PECL::memcacheを使っていましたが、 データの大量更新を連続で行うとデータの取得が正常に行えなくなる現象が発生したため、 Net_TokyoTyrantを一部改変したものをライブラリとして利用しています。 パフォーマンスではPECL::memcacheに負けますが、クリティカルな処理をしていないこともあり、 今のところ問題に
連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「
おおいしつかさ 旅行とバイクとドライブと料理と宇宙が好き。 Ubie Discoveryのプログラマ。 TokyoTyrantをActiveRecordのように気軽に使える、MiyazakiResistanceを作りました。Cabinet(内閣)、Tyrant(傀儡)という意味を見て、地方から傀儡政権に抵抗するというイメージが勝手にわいてきたのでした。 MiyazakiResistanceは、TokyoTyrantのテーブルデータベースを対象にしています。データスキーマのないTokyoTyrantに、あえてスキーマの制約を与えることで管理をしやすくしています。TokyoTyrantでは異なる種類のデータをひとつのデータベースに置くことはあまりないと想定してのことです(キー値がかぶるし)。 MiyazakiResistanceは、レプリケーションにも対応しています。マスターと複数のスレーブ構
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
なぜ最近、Tokyo Cabinet、Tokyo Tyrantと言い続けているのか?と言うと、memcacheの代替として使えないかなーと思っているからです。ここ最近、cakePHPもそうなんですが、セッションストレージとしてmemcacheを使うケースが多くなってきている気がしています。自分自身、仕事で作るアプリケーションの一部にはセッションストレージでは無いのですが、memcacheをストレージとして利用しているケースがいくつかあります。 それらの運用をしていく中で、気がついたのは「memcache 落ちたら消える さようなら」と言う事です。いくらレポリケーションしていたとしても、落ちたら消えます。きれいさっぱり。 仮にログインセッションをmemcacheにストレージしていた場合、「memcache 落ちたらログアウト さようなら(字余り)」と言う事になりかねない訳です。つまり、mem
どうぶつの森にハマって、たぬきち商店が早終いする関係で退勤時間もめっさ早くなったmikioです。今回は、Tokyo TyrantのキャッシュとLua拡張を使って超お手軽にリアルタイム検索システムを作る方法について述べます。 ユースケース 高い頻度で更新されるWeb上のテキストをリアルタイムに検索したいと思ったことはありませんか? mixi日記や各種のブログサービスやRSSリーダなどで扱う大量のコンテンツを安価かつ簡単に検索したいと思ったことはありませんか? 私は結構あります。要件を箇条書きすると以下のような感じでしょうか。 最新データの合計100万件くらいを検索できればよく、古いデータは自動的に消えてほしい。 ただし、更新はリアルタイムにして、書いた瞬間に検索結果に反映されてほしい。 サーバ1台で更新1000qpsおよび検索100qpsは処理したい。 再現率よりも精度とリアルタイム性を重視
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く