Domain Unavailable!Looks like this domain has not been routed yet or is suspended. If it's your domain and you have questions, contact your service provider. Request ID: 98b227b42162d63c1ee2aba4736c2b67
MySQL をキューに使用する 5 つの微妙な方法とその落とし穴 (翻訳版) - Engine Yard Blog JP | Engine Yard Blog JP
本記事は英語版のブログに2011年9月15日に投稿された記事の翻訳版です。今回のゲスト投稿は Percona の皆さんによる記事です。同社では 2011 年 10 月 24 日と 25 日に Percona Live London というイベントを開催します。この 2 日間にわたるイベントでは、MySQL の分野における経験豊かなスピーカーにより、純粋に技術関係のセッションが行われます。 ロンドン周辺からの参加をご希望の方は、今週が無料パスを手に入れるチャンスです。応募方法は @engineyard のツイッター フィードをチェックしてください。 私は MySQL のコンサルタント会社 Percona に勤務しています。記憶の補助として、お客様から解決を依頼された興味深い問題についてメモしたテキスト ファイルを作成し、すぐに参照できるようにしています。その中で頻度の高い問題のカテゴリとして
Resque で学ぶジョブキューイング - Articles Advent Calendar 2012 Casual
こんにちは。hatak (@hisashi) です。 Perl でジョブキューというと TheSchwartz や Qudo などの名前が挙がるかと思いますが、今回はバックエンドに Redis を利用したジョブキュー "Resque" を紹介します。 Resque はバックグラウンドジョブを処理するためのライブラリで、Github を始め大規模なサイトでも利用されています。もともとは Rubyライブラリですが、Ruby 以外の様々な言語でも実装されています。今回紹介するのはその Perl 実装のモジュールです。 試してみる クライアントで入力した文字列をワーカーが表示するだけのシンプルなプログラムを作ってみます。 まずは Redis を利用できるようにしておく必要があります。今回はローカルの Redis を利用しますが、異なるホストで動作している場合は適宜ホスト名やポート番号を変更してくだ
第10回 ジョブキューで後回し大作戦―TheSchwartz、Qudo、Q4M（3） | gihyo.jp
Q4M―MySQLを利用したジョブキュー 今まではPerlで作られたミドルウェアとしてのジョブキューを紹介してきましたが、最後にMySQLのプラグインとして提供されるジョブキューQ4Mを紹介します。Q4Mは本連載第6回「UNIXプログラミングの勘所」を執筆した奥一穂氏によって作られています。MySQLには依存してしまいますが、利用するプログラミング言語には依存しません。MySQLに接続できるどのプログラミング言語からも利用できます。また、TheSchwartzやQudoのようにミドルウェア側のデータスキーマの制限を受けることがないのも魅力の一つでしょう。 Q4Mの使い方 Q4Mのインストール方法はドキュメントで確認してください。 Q4Mをインストールしたら次はジョブキューで使用するテーブルを定義します。TheSchwartzやQudoでは決められたテーブル定義を使用する必要がありましたが、
Q4Mを簡単に導入する方法 - MySQL Casual Advent Calendar 2011 - blog.nomadscafe.jp
xaicronとネタが被ったようだけど気にしない＞＜ livedoorでOperations EngineerやってるkazeburoだYo。最近livedoorからオープンソース化された3億ファイルを管理してるオブジェクトストレージ「STF」でも使ってるMessage QueueのQ4Mのインストール方法を紹介するよ！ カジュアルだからインストールだけ！ 知ってる人も多いと思うけどQ4Mはkazuhoさんによって開発されたMySQLのストレージエンジンとして実装されてるMessage Queue。livedoorではもちろん、mixiやDeNAをはじめソーシャルゲーム各社でも使われている。 Message Queueの説明や使い方はDIS_COMMENTでテーブルスペースフルの猫神様が書いてるので参考になるね！ Perl Hackers Hub 第10回 ジョブキューで後回し大作戦―Th
開発メモ: KVSとシグナル機構でジョブキューを実現する
いわゆるkey-value storeを使っている際に、レコードの挿入もしくは更新を検知して即座に何らかの処理を行いたくなることはないだろうか。俺はあんまりないけど、結構そういう質問が来るので、きっと巷にはそういう要求があるのだろう。Kyoto Cabinetでそれを実現してみた。 ジョブキュー もうちょい具体的な例を挙げると、ジョブキューである。ここで、「foo」という名前のタスクを考えてみる。読み出し側（ワーカ）は、適当な名前をつけた条件変数を常に監視していて、そこにシグナルが飛んできたら即座にレコードを取得して処理を行いたい。しかし、「一定の間隔毎にレコードの検索を繰返して発見したら処理を行う」というポーリングスタイルにはしたくない。操作にどうしてもタイムラグが出るし、ポーリングのための無駄なトラフィックが発生するからだ。 シグナル待機処理と該当レコードの取得処理を行う擬似コードは以
開発メモ: memcachedメッセージキューの詳しい使い方
memcachedプロトコルでメッセージキューが実現できるという話を前回したが、今回はその具体的な使用方法を解説してみる。 サーバを起動する まずはサーバを起動しないと始まらない。典型的には以下のコマンドで立ち上げるとよい。 $ ktserver -th 1 -ls \ -plsv /usr/local/libexec/ktplugservmemc.so \ -plex 'port=11211#tout=30#thnum=16#opts=fq#qtout=10' \ 'casket.kct#ktopts=p' 「-th 1」でメインサーバのスレッド数を1にしている。最新版からはデフォルトで16スレッドを立てるのだが、アプリ側からはメインのサーバにはアクセスしないだろうから、1個あればよい。「-ls」はログレベルをSYSTEMに設定。「-plsv ...」では、memachedプラガブルサー
Webアプリケーションにおける Job Queue システムの構成例と Worker を作る際に気をつけること - blog.nomadscafe.jp
Webアプリケーション内で処理を直列に実行せずにJob Queueに回して非同期に実行することが多くなって来て久しいと思いますが、そのおすすめ構成と気をつけることについてつらつらと。 1) 既存のデータベースをキューとして使う構成例 １つ目はMySQLなどのデータベースをキューとして用いる例。既にアプリケーションで利用しているデータベースにキュー用のテーブルを作成して利用します。データベースを利用したキュー管理の仕組みとしてJonk、Qudo、TheSchwartzなどがPerlでは有名どころです。 依存するミドルウェアが増えないので最もシンプルな構成になると思います。 上記の図ではWorkerはアプリケーション内で実行することで冗長性を確保しますが、キューを格納するデータベースはSPOFになります。しかし、、データベースに障害があった場合キューだけでなくすべてのサービスが停止すると思われ
released Jonk-0.10_01
先ほどJonkをdevリリースしました。 今までのJonkと異なり大幅にクラス構成を変更し、 またapiをガッツリ変えました。 新生Jonkでは以下のように使います Jobの登録: use DBI; use Jonk my $dbh = DBI->connect('dbi:mysql:test','user','pass'); my $jonk = Jonk->new($dbh); my $job_id = $jonk->insert('worker_key', 'job_data_here');Jonの実行 use DBI; use Jonk use Your::Worker; my $dbh = DBI->connect('dbi:mysql:test','user','pass'); my $jonk = Jonk->new($dbh, {functions => [qw/wor
非同期ジョブキューのアーキテクチャ設計、どうしてますか？ - @kyanny's blog
Gearman のメーリングリストに興味深いポストがあった。僕も色々な意見を聞いてみたいと思ったので、多くの人の目に触れることを期待して紹介する。 Google グループ ウェブサイトに画像をアップロードすると、異なるバックエンドサーバが画像を処理する。まずリサイズし、それから顔認識をする。 一つ目の要求として、処理結果が期待通りかどうかユーザーに確認させたい。顔認識が不要であればリサイズした画像を、顔認識が必要ならばその処理が施された画像を、確認画面に表示したい。つまり、アップロード操作の完了には一つまたは二つのステップを踏む必要がある。 この要求を満たすために同期処理も検討したが、バックエンドサーバがダウンするとウェブアプリケーションサーバも巻き添えを食うため採用したくない。 ウェブアプリケーションのプロセスは Gearman にリサイズ処理を非同期ジョブとして送信し、リサイズ処理のワ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
第10回 ジョブキューで後回し大作戦―TheSchwartz，Qudo，Q4M（2）：Perl Hackers Hub｜gihyo.jp … 技術評論社