OpenSourceConference2007 Tokyo/Spring (3月16日 その2)

MySQL+Sennaによる全文検索
1. MySQL+Sennaの背景
 1.1. RDBMSによる全文検索
  ・特定のキーワードを含む文書を検索
  ・Btree/Hashインデックス検索とは異なる
  ・全文検索≠部分一致検索(テーブルスキャンが発生するため処理が遅い)
 1.2. MySQL全文検索
  ・日本語の場合、入力データを事前に分かち書きしないと、検索結果が「0」件になる。
 1.3. Senna
  ・組込み用全文検索エンジン
  ・手軽、高精度、高速
  ・対応文字コードが豊富(sjisEUC-JP、UTF-8 etc)

2. MySQL+Sennaの特徴
 2.1. 特徴
  ・MySQLがアプリケーションからSennaを隠蔽するため、扱いが容易
  ・さまざまな検索方法が利用可能
  ・高速
  ・アーキテクチャ:FULLTEXTインデックス作成時にMyISAMからSennaインデックスを使用するようにする
  ・機能:自然言語検索 / boolean modeによる検索
  ・完全転置員デーックスの採用
  ・2ind機能(インデックスマージ補完)
 2.2. Sennaのインデックスキーの切り出し方法
  ・mecab(形態素解析エンジンMeCab)
  ・ngram(N-gram方式)
  ・delimited(半角スペース区切り)

3. MySQLバインディング
 3.1. http://qwik.jp/tritonn/(Sennaのサブプロジェクト)
  3.1.1. 対応内容
   ・文字コード対応強化
   ・ログ機能強化
   ・新しい管理用SQLコマンドの実装("show senna status")
   ・2indパッチの統合(--senna-2ind=[ON/OFF])
   ・バグ修正
  3.1.2. 現状の制限、課題
   ・mecabビルト時の文字コードに限定
   ・IPA辞書のライセンスが不透明のため、商用利用に問題あり
   ・2ind機能がβ版
   ・対応エンジンが「MyISAM」のみ
   ・MySQL5.0系のみ対応


■ミラクル・リナックスAsianuxプロジェクト(カーネルの秘密)
 「カーネルの秘密」とあったので、もっとマニアックな話題になるかと思っていたので、ちょっと残念でした。
 まぁ、マニアックな話題は「か〜ねる読書会」でということでしょうか・・・。


1. Asianuxプロジェクト参加企業
 ・MIRACLE Linux (日)
 ・Red Flag (中)
 ・HANSOFT (韓)

2. Asianux2.0の特徴
 2.1. コンセプト
  ・RASの強化
    カーネル2.6.9
    CGL対応
    障害解析機能強化
    Stratus FTServer対応
  ・言語環境強化(日本語、中国語、韓国語)
  ・操作性強化
 2.2. 解析ツール
  2.2.1. カーネルレベルのパフォーマンス解析
   ・OProfile
   ・LKST logtools
  2.2.2. Dump/Trace
   ・diskdump
   ・netdump
   ・LKST v2.3
  2.2.3. 解析ツール
   ・LKST logtools
   ・DAV(フラグメンテーション解析)

3. Asianux2.0の品質安定プロセス
 3.1. Asianux2.0 SP2基本品質安定化
  ・RHEL U4以降のバグフィックス取り込み(パッチ数:約70個)
  ・LTP stress/iozone etc 負荷試験実施、評価
  ・全てのパッチについて、レビューを実施
 3.2. カーネルパッチ作成のきっかけ
  ・内部調査(セキュリティパッチ調査)
  ・内部評価(内部テスト etc)
  ・パートナーからの依頼、指摘
 3.3. OSSプロジェクトへの貢献
  ・Linuxメッセージマニュアルデータベース
  ・Linuxリグレッションテスト

4. 差分解析情報サービス
 ソースコード、Bugzilla、lkmlから修正点をレベル分けし、パッチの内部メカニズムを調査・解析しレポートを提供するサービス。
 現状のアップデートでは、リリースノートで修正点は分かるが、どのパッチがどの問題に対応しているのか分からない。
 システムの安定稼働には、提供されるアップデートを目をつぶって、パッチを適用するわけにはいかない。(他アプリケーションへの影響など)


■出張!か〜ねる読書会
1. か〜ねる読書会の紹介
  次回は、是非参加します。

2. か〜ねる読書会ネタ(2007.3.12のネタ)
  (お題)大規模SMP環境でのMySQLのスケーラビリティがでない問題について
     8コア環境で、MySQLのパフォーマンスが限界点から落ちてしまう問題(スケールしない)
  (結論?)
   ・カーネルの問題か?
     can_migrate_task()
     rebalance_tick()
     load_balance()
   ・glibcの問題か?
   ・MySQLの問題か?

  (参考)スケーラビリティの問題
     以下の点が問題となることが多い
      1) Lock(I/O、CPUとも空いている場合)
        a. Lock対象を小さくする
        b. Lockの時間を短くする
      2) I/O(対応:Disk増設 etc)
      3) CPU(対応:CPU増加、アップグレード)