最新情報
Droonga Engine用のRuby用クライアントライブラリとコマンドラインツールを提供するdroonga-client-rubyの、バージョン0.2.2をリリースしました！
このバージョンでは、Droongaクラスタをコマンドライン操作でGroonga感覚で利用できるツールのdroonga-groongaコマンドにおいて、標準入力を使った複数コマンドの流し込みに対応しました。
これにより、以下の要領でGroonga用のスキーマ定義ファイルなどの内容を簡単にDroongaクラスタに反映することができます。
$ cat /path/to/schema.grn | droonga-groonga --host node0 --port 10031
元々、似たようなことはgrn2drnとdroonga-requestコマンドの組み合わせでできていましたが、2つのコマンドの使い方を覚えなくてはならないため若干面倒でした。
groongaコマンドとほとんど同じ感覚で使える、という点が特徴のdroonga-groongaコマンド単体で標準入力からの流し込みを行えるようになったことで、Groongaからの移行がより容易になったと言えるでしょう。
Groongaを使い慣れているという方は、ぜひ試してみて下さい。
また、droonga-add, droonga-system-status, droonga-groongaの各コマンドについて、--dry-runオプションを指定することで、実際に送信される予定のメッセージの確認のみを行えるようにしました。
コマンドの実行前に影響を予想したい場合にお使い下さい。
Droongaプロジェクトはユーザや開発者としての皆さんのご協力をお待ちしています！
詳しくはコミュニティのページをご覧下さい。
コマンドラインツール群のリファレンスマニュアルが利用可能になりました！
Droongaおよび関連プロジェクトが提供する代表的なコマンドラインツールについて解説していますので、チュートリアルを読み進めたり実際にDroongaを試してみたりする際に是非とも役立てて下さい。
大変長らくお待たせしました。ようやく、待望の機能と共にDroonga 1.1.0をリリースしました！
Droongaとは？
DroongaはGroongaと互換性を持つ分散型の全文検索エンジンです。
Droongaクラスタは、レプリケーション機能を持つGroonga互換のHTTPサーバとして動作します。
どのように動作しどのように利用するのかについては、チュートリアルをご覧下さい。
また、設計について興味がある場合は概要もご覧下さい。
replicaノードの真の意味でのHot-Addが可能になりました！
今回のDroonga 1.1.0のリリースにおける最大の改善点は、replicaノードの完全なHot-Addへの対応です。
この機能はDroongaに必要な基本機能の1つとして長らく認識されていましたが、ようやく実現の運びとなりました。
今や、Droongaクラスタはダウンタイム無しでreplicaノードを追加できるようになりました。
クローリングや新規データの追加を停止する必要はもうありません！
なお、replicaノードのHot-Addを行うためには、追加する新しいreplicaノードを除いて、クラスタ内に2つ以上のreplicaノードが存在している必要があります。
詳細はreplicaノードの追加のチュートリアルを参照して下さい。
改善点の詳細な一覧
- Droonga-engine 1.1.0
- 全般:
- 継続的に流入してくるメッセージがある状況でのgracefulな終了・再起動が正しく動作するようにしました。
- Single stepの定義において、新しいパラメータ
single_operationを導入しました。
これをtrueに設定した場合、そのハンドラ用のメッセージは全てのreplicaおよびsliceの中から1つのボリュームにだけ配送されます。
これは、system.statusのようにクラスタ内で1回だけ実行されればそれでよいコマンドを実装するのに役立ちます。
- Single stepの定義において、新しいパラメータ
use_all_replicasを導入しました。
これをtrueに設定した場合、そのハンドラ用のメッセージは全てのreplicaに必ず配送されます。
これは、system.statistics.object.count.per-volumeのように全てのreplicaで実行される必要があるコマンドを実装するのに役立ちます。
addコマンドが、型の一致しないkeyの自動変換に対応しました。
例えば、keyの型がUInt32と定義されたテーブルであっても、keyを文字列で"1"と書いたリクエストのままでレコードを追加できます。dumpコマンド：他のテーブルのレコードを参照しているカラムの値を、オブジェクトの形（addコマンドのパラメータとしては使えない）ではなく、レコードのkey文字列として正しく出力するようにしました。
この結果、参照カラムを含むテーブルをクラスタ間で正しくコピーできるようになりました。dumpコマンド：_keyカラムのみを含むテーブルのレコードも正しく出力するようにしました。dumpコマンド：転送されるメッセージに、それ自身のdateフィールドを付与するようにしました。Collectors::RecursiveSumを導入しました。キーの値が数値であるハッシュや数値の配列などについて、値を再帰的に足し算できます。system.statusコマンド：レスポンスの一部として、情報を報告してきたノードの識別子を出力するようにしました。system.statistics.object.countコマンドを追加しました。これはコマンドラインユーティリティによって内部的に使用されます。system.statistics.object.count.per-volumeコマンドを追加しました。これはreplicaの同値性を確認するのに利用できます。system.absorb-dataコマンドを追加しました。これはコマンドラインユーティリティによって内部的に使用されます。
- メッセージ形式:
targetRoleフィールドを追加しました。
メッセージを処理することのできるEngineノードのロールを明示的にして揺ることができます。
もしメッセージを受信したノードのロールと一致しなかった場合には、可能であれば、適切なノードへ自動的にメッセージが転送されます。timeoutフィールドを追加しました。
リクエストに対するレスポンスをいつまで待つかを秒数で指定できます。
- コマンドラインユーティリティ:
droonga-engine-joinおよびdroonga-engine-absorb-dataコマンドがより確実に動作するようになりました。- いくつかのコマンドについて、内部的に行っているSerfの通信内容を監視するための
--verboseオプションを追加しました。
- 主にデバッグ用として、
droonga-engine-set-roleコマンドを追加しました。
- Groongaとの互換性:
- Groongaの
deleteコマンドとの互換性の向上:
- 数値型のキーを持つテーブルに対しても正しく動作するようにしました。
funa1gさんによる報告がきっかけでの改善です。ありがとうございます！
- 型の一致しないkeyの自動変換に対応しました。
例えば、keyの型が
UInt32と定義されたテーブルであっても、keyを文字列で"1"と書いたリクエストのままでレコードを削除できます。
- Droonga-http-server 1.1.2
express-droongaの要求バージョンを繰り上げました。
- Express-droonga 1.0.9
- Droonga Engine 1.1.0の仕様変更に追従しました。
- uber-cache 2.0.0に対応しました。
- Droonga Engineノードとの接続状況を調査できるように、以下のエンドポイントを追加しました。
/engines：現在接続されているDroonga Engineノードの一覧を返します。/connections：Droonga Engineノードとの接続の詳細な内部状態を返します。
- Droongaクラスタの構成に何か変更があった場合に、必ずDroonga Engineノードとの接続を更新するようにしました。
/droonga/*以下のエンドポイントに対するリクエストのクエリパラメータを、Droonga Engineノードに送るメッセージのbodyとして使うようにしました。
- Drndump 1.0.1
- 実装がモジュール化されました。
他の製品から内部的なライブラリを利用できるようになりました。
- Drntest 1.2.0
- 改善点
- メッセージの補完や妥当性検証を制御するためのディレクティブを追加しました。
#@enable_completionおよび#@disable_completionで、リクエストメッセージの必須フィールドの補完を制御できます（既定の状態では、必須のフィールドは自動的に補完されます）。#@enable_validationおよび#@disable_validationで、リクエストメッセージの妥当性検証を制御できます（既定の状態では妥当性が検証されます）。
dumpのようなサブスクリプション型のコマンド向けに、#@subscribe-untilディレクティブを追加しました。
当該ディレクティブに続くリクエストによるサブスクリプションについて、指定したタイムアウトで自動的にサブスクリプションを解除できます。例：
#@subscribe-until 10s- エンジンのプロセスが異常停止している場合に、結果のステータスとして
NO RESPONSEがすぐに返されるようになりました。
- Groongaコマンドのレスポンスとして不正な内容が返されても、エラーにならないようにしました。
- Droonga-client-ruby 0.2.1
- 入力メッセージの必須フィールドについて、既定の状態で自動的に補完するようにしました。
- 入力メッセージについて、既定の状態で自動的に妥当性を検証するようにしました。
- サブスクリプション型のメッセージについて、タイムアウトを指定できるようにしました。
client.subscribe(request, :subscription_timeout => 10)
のように指定すると、指定された秒数が経過した後に自動的にサブスクリプションが解除されます。
- 便利のためにいくつかのユーティリティコマンドを追加しました。
droonga-system-status：クラスタに対してsystem.statusのリクエストを簡単に送れます。droonga-add：クラスタに対してaddリクエストでのデータ追加を簡単に行えます。droonga-groonga：groongaコマンドと似た要領で動作します。
- droonga-send, droonga-request:
--[no-]completionオプションを追加しました。
意図的に不完全なメッセージを送りたい場合は、--no-completionを指定するようにして下さい。--[no-]validationオプションを追加しました。
意図的に不正なメッセージを送りたい場合は、--no-validationを指定するようにして下さい。--default-datasetオプションを追加しました。
このオプションの値は、datasetフィールドがないメッセージを送ろうとした場合に使われます。--default-target-roleオプションを追加しました。
このオプションの値は、targetRoleフィールドがないメッセージを送ろうとした場合に使われます。dateフィールドを、Droonga Engine内部での物と同じく、マイクロ秒まで含んだ形式（2015-04-08T06:16:20.571303Zのような）で補完するようにしました。
まとめ
- Droonga 1.1.0をリリースしました！
- ダウンタイム無しでのreplicaノードの追加が、ついに可能になりました。
- Droongaプロジェクトは今後も新バージョンを継続的にリリースしていきます。乞う御期待！
Droongaプロジェクトはユーザや開発者としての皆さんのご協力をお待ちしています！
詳しくはコミュニティのページをご覧下さい。
2014年のいい肉の日に開催された「検索エンジンGroongaを囲む夕べ5」にご参加いただき、ありがとうございます！
Droonga 1.0.9は、定例でない臨時のリリースです。
イベントでのDroongaについての発表において遭遇してしまったいくつかの不具合は、このリリースで修正されました！
Droonga 1.0.9の改善点
まず、クラスタ管理コマンドの droonga-engine-join, droonga-engine-unjoin, droonga-engine-absorb-data がどのノード上でも動作するようになりました。
これまでのバージョンでは、これらのコマンドには分かりにくい前提条件がいくつかあり、使いにくい物となってしまっていました。
次に、クラスタから切り離されたノードがdroonga-http-serverから正しく無視されるようになりました。
1つ前のバージョンでは、droonga-http-serverはノードから既に切り離されたdroonga-engineのノードへの接続を保持したままになってしまっていました。
本バージョンから、droonga-engineのノード群は、それぞれのDroongaクラスタに固有のIDによって、お互いの関係を管理するようになりました。
droonga-http-serverはこの情報に基づいて、どのEngineノードがクラスタから切り離されたのかを正しく検出できるようになりました。
これらの修正によって、Droongaをより試していただきやすくなっています！
改善点の詳細な一覧
- Droonga-engine 1.0.9
droonga-engine-join, droonga-engine-unjoin, droonga-engine-absorb-data の各コマンドがあらゆるホスト上で動作するようになりました。
その代わりとしてこれらのコマンドは、コマンドを実行している作業マシン自身のホスト名またはIPアドレスを--receiver-hostオプションで必ず指定しなくてはなりません。- クラスタはそれぞれに固有のIDで管理されます。
前のバージョンでは、Droongaクラスタから切り離されたノードは、依然としてSerfクラスタの一員であるにも関わらず、Droongaクラスタを識別するための情報がなかったために、Protocol AdapterのノードはどのEngineノードが実際のDroongaクラスタの一員かを識別することができませんでした。
- Droonga-http-server 1.1.0 および Express-droonga 1.0.8
- クラスタ構成が変更された時に、そのノードに関連付けられたEngineノードが属しているクラスタにだけ正しく接続するようになりました。
1つ前のバージョンでは、クラスタから切り離されたEngineノードへの接続が意図せず維持されてしまっていました。
まとめ
- Droonga 1.0.9をリリースしました！
- クラスタ管理コマンドのいくつかの不便な制限が解消されました。
droonga-http-serverがクラスタ管理操作の後も期待通りの動作を示すようになりました。- Droongaプロジェクトは今後も新バージョンを毎月リリースしていきます。乞う御期待！
Droongaプロジェクトはユーザや開発者としての皆さんのご協力をお待ちしています！
詳しくはコミュニティのページをご覧下さい。
Droongaとは？
DroongaはGroongaと互換性を持つ分散型の全文検索エンジンです。
Droongaクラスタは、レプリケーション機能を持つGroonga互換のHTTPサーバとして動作します。
どのように動作しどのように利用するのかについては、チュートリアルをご覧下さい。
また、設計について興味がある場合は概要もご覧下さい。
Droonga 1.0.8 での改善点
今回のDroonga 1.0.8のリリースは、多くの改善を含んでいます。
その中でも特に大きな話題は以下の3つです。
フロントエンドのHTTPサーバがクラスタの一部として管理されるようになりました
droonga-http-serverによるフロントエンドのHTTPサーバのノードが、Droongaクラスタの本当の一員として動作するようになりました。
これまでのバージョンでは、1つのdroonga-http-serverノードは対応する1つのdroonga-engineノードに強く結びつけられていました。
そのため、あるdroonga-engineノードが停止してしまうと、それに紐付いていたdroonga-http-serverノードまでが停止してしまっていました。
しかし、その制限はこのバージョンで解消されました。
もしdroonga-engineノードの1つが停止してしまっても、droonga-http-serverノードは自動的に、他の生存しているdroonga-engineと共に動作し続けます。
また、クライアントからのリクエストを1つのdroonga-http-serverノードが受け付けた場合でも、それらは複数のdroonga-engineノードに振り分けられるようになりました。
言い換えると、簡易的なロードバランサーのように振る舞うようになりました。
検索処理（特にgroupBy、Groongaのselectにおけるドリルダウン指定を伴う場合）のパフォーマンスの改善
シャーディングが行われていないレプリカでの検索処理における、groupBy使用時のパフォーマンスが改善されました。
また、offsetの指定を伴う検索処理についても改善があります。
以上を踏まえた、現在のDroongaとGroongaの比較のベンチマーク結果は以下の通りです：
ベンチマークの条件は以下の通りです:
- Wikipedia日本語版に由来する1500000件のレコード。
- すべてのリクエストは、実際のページタイトルを使用した全文検索のクエリで、且つドリルダウンを伴う。
例：
/d/select?command_version=2&table=Pages&limit=10&match_columns=title,text&output_columns=snippet_html(title),snippet_html(text),categories,_key&query_flags=NONE&sortby=title&drilldown=categories&drilldown_limit=10&drilldown_output_columns=_id,_key,_nsubrecs&drilldown_sortby=_nsubrecs&query=Wikipedia%3AText+of+GNU+Free+Documentation+License
- キャッシュヒット率は50%を想定。
- 開発用の物理的なPC上で計測を実施。
- node0: Ubuntu 14.04LTS, Intel Core i5 M460 2.53GHz, 8GB RAM
- node1: Ubuntu 14.04LTS, Intel Core i5 650 3.20GHz, 6GB RAM
- node2: Ubuntu 14.04LTS, Intel Core i5 650 3.20GHz, 8GB RAM
- クライアント: Ubuntu 14.04LTS, Intel Core i5-4300U vPro 1.90GHz, 4GB RAM
詳細な結果はプレゼン資料のリポジトリに含まれています。
上記のグラフを見て分かる通り、現在、単一のDroongaノードのスループット性能はGroongaのそれに匹敵しています。
それだけでなく、Droongaノードをクラスタに追加することでスループットの上限が拡大されていることも分かります。
他方、Droongaにおいては全般的にレイテンシがGroongaよりも大きいです。
しかしながら、大量のアクセスがある場合には、GroongaとDroongaの性能は逆転します。
大量のリクエストに対しては、DroongaはGroongaよりも迅速にレスポンスを返せています。
Groongaとの互換性の向上
いくつかの細かい非互換が解消され、Groongaとの互換性が向上しました。
selectコマンド:
output_columnsオプションが空白文字区切りのリストを受け付けるようになりました。
（これはGroongaのcommand_version=1の時の形式と互換性があります。）TABLE_NO_KEYのテーブルに対して、output_columns=*の指定が正しく動作するようになりました。
column_listコマンド:
TABLE_HASH_KEY, TABLE_PAT_KEY, およびTABLE_DAT_KEYのテーブルにおいて、主キーにあたる_keyという名前の仮想カラムが結果に正しく表れるようになりました。- インデックスカラムの
sourceの値がGroongaの結果と同じになりました。
table_createコマンド:
TABLE_HASH_KEY, TABLE_PAT_KEY, およびTABLE_DAT_KEYのテーブルにおいて、key_typeパラメータが必須になりました。
パラメータを指定しなかった場合はエラーが返ります。
（現在の所Groongaはkey_typeパラメータ無しのtable_createコマンドへのリクエストを受け付けますが、これは既知の不具合です。）
改善点の詳細な一覧
- Droonga-engine 1.0.8
- Groongaの
select, column_list, および table_create の各コマンドの互換性が向上しました。
（詳細は上記）
- 静的な設定ファイルに書かれた
daemonオプションは無視されるようになりました。
このバージョンから、droonga-engineをデーモンとして起動するためには、droonga-engineコマンドへの--daemonオプションの指定が必須となりました。
droonga-engine-configureコマンドが、常にすべてのオプションについての入力を求めるようになりました。droonga-engine-absorb-dataとdroonga-engine-joinの各コマンドについて、初期状態でデータのコピー速度が1秒あたり最大100件ずつまでに制限されるようになりました。droonga-engine-absorb-dataとdroonga-engine-joinの各コマンドについて、可能な場合は進行状況が表示されるようになりました。
- Droonga-http-server 1.0.9
- 接続要求を受け付けるIPアドレスを制限するための新しいオプション
--hostが利用可能になりました。
既定値は0.0.0.0（「すべてのIPアドレスで接続を受け付ける」の意味）です。
- キャッシュの有効期限を指定するための新しいオプション
--cache-ttl-in-seconds が利用可能になりました。
単位は秒数で、既定値は60（1分）です。
--enable-trust-proxyの設定が静的な設定ファイルで有効化されている時に明示的に機能を無効化するためのオプションとして--disable-trust-proxyが利用可能になりました。- ドキュメントルートを指定するための新しいオプション
--document-root が利用可能になりました。
初期値は組み込みのGroonga管理ページのパスです。
- 静的な設定ファイルに書かれた
daemonオプションは無視されるようになりました。
このバージョンから、droonga-engineをデーモンとして起動するためには、droonga-http-serverコマンドへの--daemonオプションの指定が必須となりました。
droonga-http-server-configureコマンドが、常にすべてのオプションについての入力を求めるようになりました。- ほとんどのコマンドに対するリクエストが無駄にキャッシュされなくなりました。
現在のところは、
searchおよびGroongaのselectコマンド、および管理ページのレスポンスのみがキャッシュされます。
- すべてのレスポンスキャッシュを消去するためのエンドポイントとして、
/cacheが利用可能になりました。
キャッシュされたコンテンツを消去するには、このパスに対してHTTPのDELETEメソッドのリクエストを送信してください。
express-droongaの改善が反映されました。詳細は以下の項目を参照してください。
- Express-droonga 1.0.7
- バックエンドとして複数のDroonga Engineノードに接続できるようになりました。
これにより、
express-droongaは簡易的なロードバランサーとして振る舞います。
- 接続するDroonga Engineノードのリストを、クラスタ内で実際に利用可能なノードのリストに基づいて更新できるようになりました。
この機能は
application.droonga()メソッドに渡すsyncHostNamesオプションにより有効化できます。
- Drnbench 1.0.4
drnbench-request-response
- 最もレスポンスが遅かったリクエストだけでなく、最もレスポンスが速かったリクエストも出力するようになりました。
これは、おかしなクエリなどによって発生する「異常に良い」結果の検出に役立つでしょう。
報告されるリクエストの件数は、
--n-fast-requestsオプションで制御できます。
- 仮想クライアントがマルチプロセスで動作するようになりました。
ベンチマークを動作させるクライアントに複数のプロセッサが搭載されている場合、drnbenchはそれらをより効果的に使えるようになりました。
- Drntest 1.1.7 (2014-11-18にリリース)
- Groongaの
column_listコマンドのレスポンスに現れる、_keyのような仮想的なカラムを正しく受け付けるようになりました。
まとめ
- Droonga 1.0.8をリリースしました！
- フロントエンドのHTTPサーバのノードが、クラスタの構成ノードとして管理されるようになりました。
これにより、Droongaクラスタはより堅牢に動作するようになりました。
- 検索処理のパフォーマンスが改善されました。
Droongaは現在、Groongaと同等かそれ以上のスループット性能を発揮できます。
- Groongaとの互換性が向上しました。
- Droongaプロジェクトは今後も新バージョンを毎月リリースしていきます。乞う御期待！
Droongaプロジェクトはユーザや開発者としての皆さんのご協力をお待ちしています！
詳しくはコミュニティのページをご覧下さい。
Droongaとは？
DroongaはGroongaと互換性を持つ分散型の全文検索エンジンです。
Droongaクラスタは、レプリケーション機能を持つGroonga互換のHTTPサーバとして動作します。
どのように動作しどのように利用するのかについては、チュートリアルをご覧下さい。
また、設計について興味がある場合は概要もご覧下さい。
サービス起動スクリプトの致命的な問題を修正しました！
Droonga 1.0.7は緊急のリリースです。
Droonga 1.0.6で導入されたサービス起動スクリプトには致命的な問題があり、一度インストールしたはずのdroonga-engineとdroonga-http-serverの両サービスが、コンピュータの再起動後には起動できない状態となっていました。
この問題はDroonga 1.0.7で修正されています。
サービス起動スクリプトの更新を含むため、更新時には、インストールスクリプトを使って両サービスを再インストールする必要があります:
# curl https://raw.githubusercontent.com/droonga/droonga-engine/master/install.sh | \
bash
# curl https://raw.githubusercontent.com/droonga/droonga-http-server/master/install.sh | \
bash
その他の大きな話題は以下の通りです:
- Groongaとの互換性が少し向上しました。
droonga-engine 1.0.7では、Groongaのselectコマンドにおいてquery_flagsオプションの指定に対応しました（ただしALLOW_UPDATE以外）。
あなたのアプリケーションがquery_flagsを初期値から変更している場合も、Droongaはあなたのアプリケーションからの検索リクエストを処理できるようになりました。
droonga-http-serverのシステムログのログレベルを指定できるようになりました。
ログレベルを指定するためには、droonga-http-server-configureコマンドをroot権限で再実行してサービスを再設定して下さい。- DroongaとGroongaのベンチマーク測定のチュートリアルを公開しました。
このチュートリアルでは、GroongaとDroongaの性能を測定して比較する手順を紹介しています。
改善点の詳細な一覧
- Droonga-engine 1.0.7
- Groongaとの互換性の向上：
selectコマンドがquery_flagsオプションに対応しました。
ただし、対応する機能がDroonga側に未実装のため、ALLOW_UPDATEは指定しても無視されます。
saerchコマンドが何点か改良されました。
- クエリ構文形式での検索条件において、
allowPragmaとallowColumnをfalseに設定すると指定が反映されるようになりました。
これ以前のバージョンでは、これらのオプションは常にtrueと扱われる不具合がありました。
- クエリ構文形式での検索条件において、
allowLeadingNotオプションに対応しました。
初期値はfalseです。
- コンピュータの再起動後もサービスとして正しく動作するようになりました。
droonga-engine-configureがログレベルの指定を尋ねるようになりました。
- Droonga-http-server 1.0.8
- コンピュータの再起動後もサービスとして正しく動作するようになりました。
- システムのログのログレベルが変更可能になりました。
droonga-http-server.yamlにsystem_log_level: debugのような形で指定を追加すると、ログレベルが反映されます。
また、droonga-http-server-configureもログレベルの指定を尋ねるようになりました。
- Express-droonga 1.0.6
- デバッグログをロガー経由で出力するようになりました。
- Drnbench 1.0.3
drnbench-request-response
--default-hostsオプションでカンマ区切りで複数のホストを指定できるようになりました。
複数接続先への負荷分散を簡単にシミュレートすることができます。- URLのパス部分のリストのプレーンテキストファイルを、パターンファイルとして指定できるようになりました。
drnbench-extract-searchterms
--escapeオプションを指定することで、出力する単語をあらかじめURLエンコードしておけるようになりました。
まとめ
- Droonga 1.0.7をリリースしました！
- このバージョンではサービス起動スクリプトの致命的な欠陥を修正しました。
- ベンチマーク測定のチュートリアルを公開しました。
- Droongaプロジェクトは今後も新バージョンを毎月リリースしていきます。乞う御期待！
Droongaプロジェクトはユーザや開発者としての皆さんのご協力をお待ちしています！
詳しくはコミュニティのページをご覧下さい。
長らくお待たせして申し訳ありません。
先月のリリースは残念ながら見送られましたが、その甲斐あって、大きな改善を含むDroonga 1.0.6をリリースしました！
Droongaとは？
DroongaはGroongaと互換性を持つ分散型の全文検索エンジンです。
Droongaクラスタは、レプリケーション機能を持つGroonga互換のHTTPサーバとして動作します。
Droongaのインストールが簡単になりました！
今回のDroonga 1.0.6のリリースにおける最大の改善点は、インストールが非常に簡単になったことです。
Droongaの主要なコンポーネントであるdroonga-engineとdroonga-http-serverが、インストールスクリプト経由で導入できるようになりました。
導入にあたっては、root権限で以下のようにしてスクリプトを実行するだけでOKです:
# curl https://raw.githubusercontent.com/droonga/droonga-engine/master/install.sh | \
bash
# curl https://raw.githubusercontent.com/droonga/droonga-http-server/master/install.sh | \
bash
これだけで、droonga-engineとdroonga-http-serverが、serviceコマンドで管理されるシステムのサービスとして登録されます。
サービスの起動と終了も、以下のように単純なコマンドで行えます:
# service droonga-engine start
# service droonga-http-server start
また、クラスタのノード構成を管理するためのユーティリティコマンド（droonga-engine-joinやdroonga-engine-unjoinなど）も使いやすくなりました。
詳細は、新しくなった「使ってみる」のチュートリアルおよびそれに続く一連のチュートリアルを参照して下さい。
他方で、残念なお知らせもあります。
Droongaのインストールスクリプトは現在の所、Debian、Ubuntu、CentOS 7でのみ動作します。
他の環境（例えばCentOS 6.5、OS X、BSDなど）は、現時点では未対応です。
もし、導入に必要なコマンド群（gem、npm、そしてgit) のインストール方法や独自のサービスをシステムに登録する方法について、それらの環境でのノウハウをお持ちであれば、インストールスクリプトの改善に是非ご協力下さい！
開発者向けの情報
インストールスクリプトは最新のリリース版に対してだけでなく、masterブランチの最新リビジョンに対しても利用できます。
以下のように、追加の環境変数 VERSION を指定するだけでOKです:
# curl https://raw.githubusercontent.com/droonga/droonga-engine/master/install.sh | \
VERSION=master bash
# curl https://raw.githubusercontent.com/droonga/droonga-http-server/master/install.sh | \
VERSION=master bash
これにより、インストールスクリプトはmasterからサービスをインストールするようになります。
これは、次のリリースを待たずに最新の修正内容を試してみるのに便利でしょう。
また、手持ちのPC上に複数台の仮想マシンを用意するための手順の解説も新たに用意しました。
これにより、気軽にDroongaをお試しいただけます。
改善点の詳細な一覧
- droonga-engine 1.0.6
- インストールスクリプトが利用可能になりました。
これにより、必要なソフトウェアの導入と、
droonga-engineをシステムのサービスとして設定する作業が自動化されました。
現在の所、このスクリプトはDebian、Ubuntu、CentOS 7でのみ利用できます。
- サービスとしての利用において、専用のユーザである
droonga-engineの権限で動作することが前提となりました。
今後は、設定ディレクトリはこのユーザのホーム以下に置かれます。
hostなどの既定の設定を定義する静的な設定ファイルが導入されました。
これはcatalog.jsonと同じ位置に置かれる必要があります。
これにより、droonga-engineコマンドを大量のオプションを伴って起動しなくても良くなりました。droonga-engine-joinが、catalog.jsonを複製元となるノードから自動的に取得するようになりました。
これにより、droonga-engine-joinコマンドの実行前に他のノードからcatalog.jsonを手動でコピーしてこなくても良くなりました。- 既存のクラスタから
catalog.jsonを取得するために、既定のプラグインの1つとしてcatalogが追加されました。
このプラグインはcatalog.jsonのプラグインリストに必ず含まれていなくてはなりません。
- 新しいコマンドラインユーティリティ
droonga-engine-configureが追加されました。
これは、静的な設定ファイルとcatalog.jsonをサービス向けに生成する物です。
また、ノードを空にするために既存のデータを消去するのにも使えます。
- ユーティリティコマンドのいくつかの必須オプションが省略可能になりました。
それらの情報は自動的に認識されます。
- サーバがより安全に再起動するようになりました。
- droonga-http-server 1.0.7
- インストールスクリプトが利用可能になりました。
これにより、必要なソフトウェアの導入と、
droonga-http-serverをシステムのサービスとして設定する作業が自動化されました。
現在の所、このスクリプトはDebian、Ubuntu、CentOS 7でのみ利用できます。
- サービスとしての利用において、専用のユーザである
droonga-http-serverの権限で動作することが前提となりました。
今後は、設定ディレクトリはこのユーザのホーム以下に置かれます。
portなどの既定の設定を定義する静的な設定ファイルが導入されました。
これは環境変数DROONGA_BASE_DIRで示される設定ディレクトリに置かれる必要があります。
これにより、droonga-http-serverコマンドを大量のオプションを伴って起動しなくても良くなりました。- 新しいコマンドラインユーティリティ
droonga-http-server-configureが追加されました。
これは、静的な設定ファイルをサービス向けに生成する物です。
- レスポンスキャッシュが正常に動作するようになりました。
- express-droonga 1.0.5
- レスポンスキャッシュが正常に動作するようになりました。
- drntest 1.1.6
- テスト結果の安定化のために、dumpの結果をソートするようにしました。
- droonga-engineが利用可能になるまで待つために、
--ready-notify-fdオプションを使うようにしました。
- grn2drn 1.0.4
- 出力先のディレクトリを自動的に作成するようにしました。
まとめ
- Droonga 1.0.6をリリースしました！
- Droongaのインストール手順が簡単になり、より使い始めやすくなりました。
- Droongaプロジェクトは今後も新バージョンを毎月リリースしていきます。乞う御期待！
Droongaプロジェクトはユーザや開発者としての皆さんのご協力をお待ちしています！
詳しくはコミュニティのページをご覧下さい。
最新情報について、今後は日本語でも情報を提供していきます。
乞う御期待！