subtitle : Droongaの簡単な紹介と、 Groongaからの移行手順
author : 結城洋志
institution : 株式会社クリアコード
theme : groonga
「自作のアプリケーションを GroongaからDroongaへ 今すぐ移行できるのか?」 にお答えします
- 気になる事があったら:
- メモして後から質問
- その場で質問してもOK
- どこが気になったかを 教えてください!
- Droongaとは?
- Droongaの何が嬉しい?
- Droongaの何が嬉しくない?
- デモ
- 分散が流行ってる
- Groongaは分散処理に 対応していない
Distributed Groonga =分散Groonga
- 今までと同じ感覚で使える
- Groongaベースの 既存のアプリケーションを 最小の工数で分散対応できる
- レプリケーション
- 現在の開発はここに注力
- パーティショニング
- 現在は部分的に対応(これから改善)
{:relative_width="35" align="left" relative_margin_left="-20"}
{:relative_width="45" align="right"}
{:relative_width="40" align="left" relative_margin_left="-20"}
{:relative_width="50" align="right"}
今現在得られるメリット
- レプリケーションできる ようになる
- ノードを簡単に追加・削除できる
付属のコマンドラインユーティリティを使用
- droonga-engine-join
- droonga-engine-unjoin
% droonga-engine-join --host=cccc --replica-source-host=bbbb
% droonga-engine-unjoin --host=cccc
今現在あるデメリット
- レイテンシーが低下する
- 処理のオーバーヘッドがある
- Groonga非互換の部分が まだある
- 検索対象: Wikipedia日本語版の全ページ
- 検索クエリ: よく見られているページのタイトル上位1000件
- キャッシュヒット率: 50%
(ここにグラフ)
- Groonga
- サーバ1台の処理能力では有利
- 負荷が増えた時に スループットが頭打ちになる
- Droonga
- サーバ1台の処理能力では不利
- 負荷が増えてもノードを増やして スループットの上限を増やせる
- オーバーヘッドがある(レイテンシーが落ちる)
- Groongaで単一サーバでさばききれる程度のリクエストに対しては、性能面でのメリットはない。
- 耐障害性の高さ、アクセスの増加への対応のしやすさとのトレードオフ。
- スキーマ変更系
load
,delete
select
それ以外は未対応(今後の課題)
table操作系
table_create
table_remove
table_list
column操作系
column_create
column_remove
column_rename
column_list
データ更新系
load
- ただし、以下は未対応
--ifexists
--input_type
- ただし、以下は未対応
delete
検索系
select
- ただし、以下は未対応
--scorer
--cache
--match_escalation_threshold
--query_expansion
--query_flags
--query_expander
--adjuster
- ただし、以下は未対応
- GQTPは喋れない
- ダッシュボードがまだ無い(Groongaの管理画面はちょっと動く)
- サジェストもまだ対応していない
- 監視機能もまだできていない
- Groongaベースの アプリケーションを作成
- バックエンドをDroongaに移行
- Droongaクラスタを構築
- データを移行
- アプリケーションの接続先変更
様々な条件でのベンチマーク結果
- できればGroongaでの ベンチマーク結果も添えて
- 開発チームで認識できていない ボトルネックを明らかにしたい
- ベンチマーク取得手順公開中
実際のWebアプリケーションからの 使い勝手レポート
- 互換性向上の作業の 優先順位付けの参考にしたい
フィードバックは droonga-engineのissue tracker もしくは groonga-dev ML までお寄せ下さい
- MySQL/MariaDB + Mroonga + Spider
- 自前で頑張る (Yappoさんによる事例)