cy dn 20070912 my sql users conf japan 2007
TRANSCRIPT
サイボウズのMySQL に対する取り組みサイボウズのMySQL に対する取り組み
サイボウズ株式会社 開発本部プロダクト開発部
ガルーン開発グループ
丹羽 純平
米川 健一
サイボウズ株式会社 開発本部プロダクト開発部
ガルーン開発グループ
丹羽 純平
米川 健一
2
目次
ガルーン 2 とは?
MySQLを使い倒したグループウェア
特徴と問題点
解決策 → 次期ガルーン
全文検索を求めて
Senna の取り込み
スケーラビリティを求めて
ガルーン 2 のスケールアウトについて
DB/テーブル分割、クエリチューニング、キャッシュ
3
ガルーン2とは?
サイボウズのWebグループウェア
http://garoon.cybozu.co.jp/
300人以上の中規模でもOK
つなガル、ひろガル、おてガル
管理者もユーザもみんなが使いやすいグループウェア
弊社のグループウェアは 7回連続顧客満足度1位
MySQLを使い倒したグループウェア
5
ポータル画面
各アプリケーションをアイコンで分かりやすく説明。ワンクリックで目的の情報の場所に移動できます。
当日、今週のスケジュールや天気がひと目でわかります。
自分に関係があるすべての情報の新着や更新がトップページに集ります。好みにあわせて、情報の表示位置を変え、仕事のしやすい環境を作れます。
全社・所属部署・個人と目的や組織別に自由にポータルを作成できます。
グラフポートレットを使って簡単にグラフ化。数字を視覚的に表示できます。
≪個人ポータル画面≫
≪企業ポータル画面≫
6
スケジュール機能
見たい予定の期間を選択できます。
所属部署のメンバや他部署の社員の予定、会議室や備品の予約まで一覧で把握できます。
予定はクリック操作だけで時間、メンバー、会議室まですべて登録できます。
予約登録時にメンバーや会議室の空き時間を確認して、予定を調整できます。
8
現行ガルーン2が抱える障壁
スケーラビリティの壁
現行バージョンでは分間アクセス 1,500を上限
更なるスケールアップ
遅い・・・
検索機能の壁
現バージョンでは検索は LIKE のみ
アクセス権の評価をするため、複雑なSQL処理が必要
SELECT * FROM bulletin WHERE article LIKE ’%hoge%’ AND (アクセス権);
9
次期ガルーン
スケーラビリティを求めて 検索機能を求めて
・Sennaの取り込み
・MySQL+Senna → Tritonnを利用
・DB分割
・ユーザ単位でテーブル分割
・キャッシュを活用(memcached)
11
全文検索エンジン
FAST
インターネット
Google Search Appliance
イントラネット
Lucene, HyperEstraier, Senna
アプリケーション
オープンソース多数
Hit!
12
Senna
組み込み用の高速全文検索エンジン
MySQLやPostgreSQL、Ruby等に対応
アプリ側から見たら、普通にMySQLを使用
(有)未来検索ブラジルにおいて開発
http://qwik.jp/senna/
LGPL
13
Tritonn (MySQL + Senna)
MySQLのソースにパッチ
MySQLの上位層がSennaを隠蔽
FULLTEXTのINDEXの処理時にSennaが使用される
My SQL
MEMORY Inno DB MyISAM
SQL文解析 → 最適化 → データ検索/格納
patch
Senna
RAM .sen.iibdata1 .MYD .MYI
(HEAP)
引用元 : http://qwik.jp/tritonn/about.html
14
ガルーンの全文検索
検索機能
「横串検索」
ガルーン内の複数のアプリケーションを横断して検索
「全文検索」
ガルーン内に保存されたファイルの中身も検索
(例:WordやExcelやPowerpointやpdfファイル)
テキスト抽出フィルター
TFライブラリ(データ変換研究所)を使用
http://www.dehenken.co.jp/products/products-01/products-tf01.html
高速なアクセス権評価が必須
データとACL(アクセス制御リスト)のクローリング
15
全文検索の構成
データ収集エンジン
・クローラ →データとACL
・インデクサ→テキスト抽出フィルタ
→クロールしたデータの追加
データの変更/削除
検索エンジン
・認証
・SQL実行
×
設定画面
16
Crawler
Queue
Indexer
MySQL+
Senna
filter
filter
filter
filter…
クロール間隔やスレッド数は設定ファイルで変更可能
…
acl_id,uid list
Crawler
Data
ACL
Use bulk transfer
APIACL
Data
データ収集エンジンの概観
acl_id,uid list
GRN
18
検索 SQL 実行
掲示板
title data …検索
社内メール
title data …
……
スコア/日付でマージ
select * from tab_grn_bulletinwhere (MATCH (title, data) AGAINST (‘hoge’) )
select * from tab_grn_messagewhere (MATCH (title, data) AGAINST (‘hoge’) )
検索
+
+
…acl_id
acl_id
acl_id uid
acl_id uid
JOIN
JOIN
データテーブル ACL評価テーブル
19
•UIDの比較
•データテーブルをユーザ毎に用意
ACL評価
・ACL評価テーブルにUIDが含まれているか?
・object単位でACLの評価を行うと高コスト
→カテゴリ単位、フォルダ単位
・クロールされるデータには、ACL評価テーブルのIDが含まれる
・GRANTモデルでもREVOKEモデルでもOK
共有系
PIM系
31
機能単位のDB分散
負荷の高い機能のテーブルを別のDBに分散する
ユーザー情報などの共通テーブルはマスタDBに配置してレプリケーションする
共通テーブルの更新は常にマスタへ
分散するアプリはインストール時に設定する→ 運用中の変更は考慮しない
32
マスタDB
レプリケーション
ユーザーテーブル組織テーブル
…
共通テーブルへの更新
各アプリケーションへの更新
ユーザーテーブル組織テーブル
…
スケジュールテーブル
ユーザーテーブル組織テーブル
…社内メールテーブル
スケジュールDB 社内メールDB
33
クエリチューニング
スロークエリログに出現した遅いクエリを排除して
レスポンスを上げる
純粋なパフォーマンスチューニング- インデックスを追加 / 張り直す- 正しいインデックスを使うようにする- 非正規化
34
Memcachedの導入
更新の少ないデータをキャッシュしてクエリの数を減らす
複数のMemcachedサーバーを登録して負荷を分散できる
ダウンしているMemcachedへのアクセスは自動でフェイルオーバーさせることができる
36
_id col_user ….
1 100 ….2 200 ….
_id ….
1 ….
tab_grn_notification_notfy___100 tab_grn_notification_notfy___200
tab_grn_notification_notify
_id ….
1 ….
37
大量テーブルと参照性制約による弊害
col_userはユーザーテーブルに参照性制約を
設定している
テーブルに対してクエリを実行すると子テーブルと子テーブルに参照性制約を設定しているテーブルを全て開こうとする
MySQL起動後のそのテーブルに対する最初のクエリのみこの現象が起きる
39
host1
_id col_user ….1 100 ….2 2003 1500 ….
tab_grn_notification_notify
tab_grn_notification_notfy___100
tab_grn_notification_notfy___200tab_grn_notification_notfy___1500
例) ユーザーID1~1000のユーザーをhost1にユーザーID1001~2000のユーザーをhost2に
host2
41
まとめ
アプリケーション単位でDBを分散して負荷を減らす
クエリチューニングで重いクエリを排除する
Memcachedを導入してクエリの数を減らす
ユーザーごとのデータを分割して共通テーブルの負荷も分散する
42
今後の課題 / 展望
複数ユーザーの個人データに対する更新処理のパフォーマンス
分割により大量に作られるテーブルへの対策
ユーザーごとの分割ではなく、1サーバーに1テーブルでよいかもしれない
MySQL5.1のパーティショニング
行ベースレプリケーション
InnoDB 以外のストレージエンジンの検討