q4mその2

q4mのメリット/デメリット

  • メリット
    • SQLを使ったアクセス・データ管理ができる

  → 専用モジュールを書かなくても良い
  → 言語のバインティングがなくても使える

  • デメリット
    • MySQLがないと使えない

q4mのゴール

  • 堅牢性
    • キューとして使う以上は、OSクラッシュ、停電時などでもデータを損なわない
  • 高速性
  • 柔軟性
    • 管理ツールじゃなくて、SQLで管理できる
    • JOINで他のストレージとデータ共有できる

q4mの3つのモデル

  • 通常のMQ
  • Relay
  • Message Brokers

MQとRelay

  • リレーのうれしいところ
    • それぞれバージョンアップできる。落ちてもOK
    • リレーが切れてもメッセージは消えない
    • 送信プロセスと受信プロセスを別の場所(データセンター間)に置いて接続とかできる
    • データの中身によって、宛先を(リレーする受信側キュー)を変えたりできる
    • 途中でログ取ったり、マルチキャストしたり…

Message Brokers

  • リレー中のメッセージを書き変えられる(フォーマットを変えるとか)
  • ロジックと送受信の分離
    • プロセスにキューに送る、キューから取るということだけを意識させる

q4m-forward

  • メッセージ転送用スクリプト
  • SQLAPIで実装されている

q4mのパフォーマンス

  • 複数スレッドからのリクエスト(SQLクエリ)を単一のI/Oにまとめる
  • クライアント(スレッド)が多いほうが、パフォーマンスがあがる
  • ベンチマーク(256 byte/message, マシン一台)
    • HDD 7,655 message/sec
    • MEM 23,637 message/sec
  • 分散しなくてもテキストメッセージ程度なら、1台で十分な処理ができる

Function

  • queue_wait('table name'); table_nameのテーブルからデータ取得
  • queue_end(); テーブルからデータを削除して、NON-OWNER modeにする
  • queue_abort(); テーブルを非所有状態にして、NON-OWNER modeにする

Mode

  • NON-OWNER mode : 通常と同じようにselect文で全部のレコードがとれる
  • OWNER mode:queue_waitで起動する排他的モード。処理中の1レコードしかとれない。queue_endで戻る。

特徴

  • indexがない
  • Updateは、もちろんない(キューの文をUpdateする必要などない)
  • selectと、delete文はある。これらの文で、キューを管理することはできる。