Rails3アプリをnginx+unicornで動かしたら速すぎた - ぱろっと・すたじお
いやぁ・・・Rails3はいいですね(｀･ω･´) ｂ Rails2とはなんだったのか・・・というレベルの完成度で、 なんとなく納得しないままRails2を使っていた私も、 Rails3になってからはバリバリに使いまくりです*1 そんなRailsを動かすAppサーバとして、 以前から定番になっていたのがpassengerでして、 私もApacheやnginxと組み合わせて使ってました*2 ただ、最近よく耳にするのがnginxにunicornを組み合わせた構成です http://unicorn.bogomips.org/ 前々から気になっていたものの、なかなか手をつけられなかったのですが、 仕事でもプライベートでもちょうどRails3アプリをリリースするタイミングだったので、 nginx+unicornの環境を試してみました なお、非常に細かな解説がある良記事がありますので、 ぜひそちらを先
データ検索システムをTokyoCabinetだけで作ってみた - ぱろっと・すたじお
今仕事で開発しているシステムに、KVSを使えないかと、 以前からいろいろ模索していました devsumi2010の前後で検証していたときは、 「分散KVSをクラスタのキャッシュにする」という目的で、 どちらかというと書き込みの速度をチェックしていました しかし、プロジェクトの予算とか概要が見えてくる中で、 「クラスタどころか用意できてもサーバ1〜2台」という話になり、 そのくせ「複雑で柔軟な検索」がWebからできなければならない・・・と これをMySQLでやるのはパフォーマンスに難があったため、 じゃあTokyoCabinetならどうなのか・・・と、検証を進め、 検索コアをTokyoCabinetだけで構築した、というのが今回のお話 要件 100万件を超えるデータの検索 一度に検索できる範囲が100万というだけで、全データはその数十倍ある しかも複数のユーザが並列に 当然高速に しかもサー
KVS(NoSQL)のまとめと「これから」の設計手法 - ぱろっと・すたじお
仰々しいタイトルをつけてますが、 たいしたことは書いてません(´･ω･`) なぜKVSを試していたのか？ 今月に入り、KVS・・・というより、 NoSQL系の技術をいろいろ試してきたわけですが、 そもそも何を目的としているのか、というと・・・ ＜前提＞ 100万件以上あるDBテーブルが複数ある データとしては一つの集合だが、論理的にパーティショニングされている そこまで大きくはないが、他にも多くのテーブルがある これをある程度任意のクエリで検索させたい 既存システムは決まった検索から出力を行うため、それに特化した仕組みになっている 論理的なVIEWテーブルを作ったり ＜目論見＞ クエリをテーブル単位で分割し、クラスタサーバに割り振って検索を実行させる クエリをそのまま流せば確実にDBが耐えられない ある程度時間的余裕があるとはいえ、何十分もかけたくはない 一テーブルの処理に数分かかるとすれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
