Engine用のRuby用クライアントライブラリとコマンドラインツールを提供するdroonga-client-rubyの、バージョン0.2.2をリリースしました!このバージョンでは、Droongaクラスタをコマンドライン操作でGroonga感覚で利用できるツールのdroonga-groongaコマンドにおいて、標準入力を使った複数コマンドの流し込みに対応しました。これにより、以下の要領でGroonga用のスキーマ定義ファイルなどの内容を簡単にDroongaクラスタに反映することができます。10031元々、似たようなことはgrn2drnとdroonga-requestコマンドの組み合わせでできていましたが、2つのコマンドの使い方を覚えなくてはならないため若干面倒でした。groongaコマンドとほとんど同じ感覚で使える、という点が特徴のdroonga-groongaコマンド単体で標準入力からの流し込みを行えるようになったことで、Groongaからの移行がより容易になったと言えるでしょう。Groongaを使い慣れているという方は、ぜひ試してみて下さい。droonga-groongaの各コマンドについて、--dry-runオプションを指定することで、実際に送信される予定のメッセージの確認のみを行えるようにしました。コマンドの実行前に影響を予想したい場合にお使い下さい。詳しくはコミュニティのページをご覧下さい。Tweetコマンドラインツールのリファレンスマニュアルを公開しました!2015-05-08コマンドラインツール群のリファレンスマニュアルが利用可能になりました!Droongaおよび関連プロジェクトが提供する代表的なコマンドラインツールについて解説していますので、チュートリアルを読み進めたり実際にDroongaを試してみたりする際に是非とも役立てて下さい。1.1.0をリリースしました!2015-04-29大変長らくお待たせしました。1.1.0をリリースしました!Droongaとは?DroongaはGroongaと互換性を持つ分散型の全文検索エンジンです。Droongaクラスタは、レプリケーション機能を持つGroonga互換のHTTPサーバとして動作します。どのように動作しどのように利用するのかについては、チュートリアルをご覧下さい。設計について興味がある場合は概要もご覧下さい。1.1.0のリリースにおける最大の改善点は、replicaノードの完全なHot-Addへの対応です。この機能はDroongaに必要な基本機能の1つとして長らく認識されていましたが、ようやく実現の運びとなりました。今や、Droongaクラスタはダウンタイム無しでreplicaノードを追加できるようになりました。クローリングや新規データの追加を停止する必要はもうありません!なお、replicaノードのHot-Addを行うためには、追加する新しいreplicaノードを除いて、クラスタ内に2つ以上のreplicaノードが存在している必要があります。詳細はreplicaノードの追加のチュートリアルを参照して下さい。1.1.0全般:継続的に流入してくるメッセージがある状況でのgracefulな終了・再起動が正しく動作するようにしました。stepの定義において、新しいパラメータsingle_operationを導入しました。これをtrueに設定した場合、そのハンドラ用のメッセージは全てのreplicaおよびsliceの中から1つのボリュームにだけ配送されます。これは、system.statusのようにクラスタ内で1回だけ実行されればそれでよいコマンドを実装するのに役立ちます。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"と書いたリクエストのままでレコードを削除できます。1.1.2express-droongaの要求バージョンを繰り上げました。1.1.0の仕様変更に追従しました。2.0.0に対応しました。Engineノードとの接続状況を調査できるように、以下のエンドポイントを追加しました。Engineノードの一覧を返します。Engineノードとの接続の詳細な内部状態を返します。Engineノードとの接続を更新するようにしました。Engineノードに送るメッセージのbodyとして使うようにしました。1.0.1実装がモジュール化されました。他の製品から内部的なライブラリを利用できるようになりました。1.2.0改善点メッセージの補完や妥当性検証を制御するためのディレクティブを追加しました。#@enable_completionおよび#@disable_completionで、リクエストメッセージの必須フィールドの補完を制御できます(既定の状態では、必須のフィールドは自動的に補完されます)。#@enable_validationおよび#@disable_validationで、リクエストメッセージの妥当性検証を制御できます(既定の状態では妥当性が検証されます)。dumpのようなサブスクリプション型のコマンド向けに、#@subscribe-untilディレクティブを追加しました。当該ディレクティブに続くリクエストによるサブスクリプションについて、指定したタイムアウトで自動的にサブスクリプションを解除できます。RESPONSEがすぐに返されるようになりました。Groongaコマンドのレスポンスとして不正な内容が返されても、エラーにならないようにしました。0.2.1入力メッセージの必須フィールドについて、既定の状態で自動的に補完するようにしました。入力メッセージについて、既定の状態で自動的に妥当性を検証するようにしました。サブスクリプション型のメッセージについて、タイムアウトを指定できるようにしました。ように指定すると、指定された秒数が経過した後に自動的にサブスクリプションが解除されます。便利のためにいくつかのユーティリティコマンドを追加しました。droonga-system-status:クラスタに対してsystem.statusのリクエストを簡単に送れます。droonga-add:クラスタに対してaddリクエストでのデータ追加を簡単に行えます。droonga-groonga:groongaコマンドと似た要領で動作します。droonga-request:--[no-]completionオプションを追加しました。意図的に不完全なメッセージを送りたい場合は、--no-completionを指定するようにして下さい。--[no-]validationオプションを追加しました。意図的に不正なメッセージを送りたい場合は、--no-validationを指定するようにして下さい。--default-datasetオプションを追加しました。このオプションの値は、datasetフィールドがないメッセージを送ろうとした場合に使われます。--default-target-roleオプションを追加しました。このオプションの値は、targetRoleフィールドがないメッセージを送ろうとした場合に使われます。Engine内部での物と同じく、マイクロ秒まで含んだ形式(2015-04-08T06:16:20.571303Zのような)で補完するようにしました。1.1.0をリリースしました!ダウンタイム無しでのreplicaノードの追加が、ついに可能になりました。Droongaプロジェクトは今後も新バージョンを継続的にリリースしていきます。詳しくはコミュニティのページをご覧下さい。1.0.9は、定例でない臨時のリリースです。どのノード上でも動作するようになりました。これまでのバージョンでは、これらのコマンドには分かりにくい前提条件がいくつかあり、使いにくい物となってしまっていました。次に、クラスタから切り離されたノードがdroonga-http-serverから正しく無視されるようになりました。1つ前のバージョンでは、droonga-http-serverはノードから既に切り離されたdroonga-engineのノードへの接続を保持したままになってしまっていました。本バージョンから、droonga-engineのノード群は、それぞれのDroongaクラスタに固有のIDによって、お互いの関係を管理するようになりました。droonga-http-serverはこの情報に基づいて、どのEngineノードがクラスタから切り離されたのかを正しく検出できるようになりました。各コマンドがあらゆるホスト上で動作するようになりました。その代わりとしてこれらのコマンドは、コマンドを実行している作業マシン自身のホスト名またはIPアドレスを--receiver-hostオプションで必ず指定しなくてはなりません。クラスタはそれぞれに固有のIDで管理されます。AdapterのノードはどのEngineノードが実際のDroongaクラスタの一員かを識別することができませんでした。1.0.8クラスタ構成が変更された時に、そのノードに関連付けられたEngineノードが属しているクラスタにだけ正しく接続するようになりました。1つ前のバージョンでは、クラスタから切り離されたEngineノードへの接続が意図せず維持されてしまっていました。1.0.9をリリースしました!クラスタ管理コマンドのいくつかの不便な制限が解消されました。droonga-http-serverがクラスタ管理操作の後も期待通りの動作を示すようになりました。Droongaプロジェクトは今後も新バージョンを毎月リリースしていきます。詳しくはコミュニティのページをご覧下さい。1.0.8をリリースしました!2014-11-29Droongaとは?DroongaはGroongaと互換性を持つ分散型の全文検索エンジンです。Droongaクラスタは、レプリケーション機能を持つGroonga互換のHTTPサーバとして動作します。どのように動作しどのように利用するのかについては、チュートリアルをご覧下さい。設計について興味がある場合は概要もご覧下さい。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上で計測を実施。RAM詳細な結果はプレゼン資料のリポジトリに含まれています。上記のグラフを見て分かる通り、現在、単一のDroongaノードのスループット性能はGroongaのそれに匹敵しています。それだけでなく、Droongaノードをクラスタに追加することでスループットの上限が拡大されていることも分かります。他方、Droongaにおいては全般的にレイテンシがGroongaよりも大きいです。大量のアクセスがある場合には、GroongaとDroongaの性能は逆転します。大量のリクエストに対しては、DroongaはGroongaよりも迅速にレスポンスを返せています。Groongaとの互換性の向上いくつかの細かい非互換が解消され、Groongaとの互換性が向上しました。selectコマンド:output_columnsオプションが空白文字区切りのリストを受け付けるようになりました。(これはGroongaのcommand_version=1の時の形式と互換性があります。)TABLE_NO_KEYのテーブルに対して、output_columns=*の指定が正しく動作するようになりました。TABLE_DAT_KEYのテーブルにおいて、主キーにあたる_keyという名前の仮想カラムが結果に正しく表れるようになりました。インデックスカラムのsourceの値がGroongaの結果と同じになりました。TABLE_DAT_KEYのテーブルにおいて、key_typeパラメータが必須になりました。パラメータを指定しなかった場合はエラーが返ります。(現在の所Groongaはkey_typeパラメータ無しの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の各コマンドについて、可能な場合は進行状況が表示されるようになりました。1.0.9接続要求を受け付けるIPアドレスを制限するための新しいオプション--hostが利用可能になりました。既定値は0.0.0.0(「すべてのIPアドレスで接続を受け付ける」の意味)です。利用可能になりました。単位は秒数で、既定値は60(1分)です。--enable-trust-proxyの設定が静的な設定ファイルで有効化されている時に明示的に機能を無効化するためのオプションとして--disable-trust-proxyが利用可能になりました。利用可能になりました。初期値は組み込みのGroonga管理ページのパスです。静的な設定ファイルに書かれたdaemonオプションは無視されるようになりました。このバージョンから、droonga-engineをデーモンとして起動するためには、droonga-http-serverコマンドへの--daemonオプションの指定が必須となりました。droonga-http-server-configureコマンドが、常にすべてのオプションについての入力を求めるようになりました。ほとんどのコマンドに対するリクエストが無駄にキャッシュされなくなりました。現在のところは、searchおよびGroongaのselectコマンド、および管理ページのレスポンスのみがキャッシュされます。すべてのレスポンスキャッシュを消去するためのエンドポイントとして、/cacheが利用可能になりました。キャッシュされたコンテンツを消去するには、このパスに対してHTTPのDELETEメソッドのリクエストを送信してください。express-droongaの改善が反映されました。詳細は以下の項目を参照してください。Engineノードに接続できるようになりました。これにより、express-droongaは簡易的なロードバランサーとして振る舞います。Engineノードのリストを、クラスタ内で実際に利用可能なノードのリストに基づいて更新できるようになりました。この機能はapplication.droonga()メソッドに渡すsyncHostNamesオプションにより有効化できます。1.0.4drnbench-request-response最もレスポンスが遅かったリクエストだけでなく、最もレスポンスが速かったリクエストも出力するようになりました。これは、おかしなクエリなどによって発生する「異常に良い」結果の検出に役立つでしょう。報告されるリクエストの件数は、--n-fast-requestsオプションで制御できます。仮想クライアントがマルチプロセスで動作するようになりました。ベンチマークを動作させるクライアントに複数のプロセッサが搭載されている場合、drnbenchはそれらをより効果的に使えるようになりました。(2014-11-18にリリース)Groongaのcolumn_listコマンドのレスポンスに現れる、_keyのような仮想的なカラムを正しく受け付けるようになりました。1.0.8をリリースしました!フロントエンドのHTTPサーバのノードが、クラスタの構成ノードとして管理されるようになりました。これにより、Droongaクラスタはより堅牢に動作するようになりました。検索処理のパフォーマンスが改善されました。Droongaは現在、Groongaと同等かそれ以上のスループット性能を発揮できます。Groongaとの互換性が向上しました。Droongaプロジェクトは今後も新バージョンを毎月リリースしていきます。詳しくはコミュニティのページをご覧下さい。1.0.7をリリースしました!2014-10-07Droongaとは?DroongaはGroongaと互換性を持つ分散型の全文検索エンジンです。Droongaクラスタは、レプリケーション機能を持つGroonga互換のHTTPサーバとして動作します。どのように動作しどのように利用するのかについては、チュートリアルをご覧下さい。設計について興味がある場合は概要もご覧下さい。1.0.7は緊急のリリースです。1.0.6で導入されたサービス起動スクリプトには致命的な問題があり、一度インストールしたはずのdroonga-engineとdroonga-http-serverの両サービスが、コンピュータの再起動後には起動できない状態となっていました。1.0.7で修正されています。bashその他の大きな話題は以下の通りです:Groongaとの互換性が少し向上しました。1.0.7では、Groongaのselectコマンドにおいてquery_flagsオプションの指定に対応しました(ただしALLOW_UPDATE以外)。あなたのアプリケーションがquery_flagsを初期値から変更している場合も、Droongaはあなたのアプリケーションからの検索リクエストを処理できるようになりました。droonga-http-serverのシステムログのログレベルを指定できるようになりました。ログレベルを指定するためには、droonga-http-server-configureコマンドをroot権限で再実行してサービスを再設定して下さい。DroongaとGroongaのベンチマーク測定のチュートリアルを公開しました。このチュートリアルでは、GroongaとDroongaの性能を測定して比較する手順を紹介しています。1.0.7Groongaとの互換性の向上:selectコマンドがquery_flagsオプションに対応しました。対応する機能がDroonga側に未実装のため、ALLOW_UPDATEは指定しても無視されます。saerchコマンドが何点か改良されました。クエリ構文形式での検索条件において、allowPragmaとallowColumnをfalseに設定すると指定が反映されるようになりました。これ以前のバージョンでは、これらのオプションは常にtrueと扱われる不具合がありました。クエリ構文形式での検索条件において、allowLeadingNotオプションに対応しました。初期値はfalseです。コンピュータの再起動後もサービスとして正しく動作するようになりました。droonga-engine-configureがログレベルの指定を尋ねるようになりました。1.0.8コンピュータの再起動後もサービスとして正しく動作するようになりました。システムのログのログレベルが変更可能になりました。debugのような形で指定を追加すると、ログレベルが反映されます。droonga-http-server-configureもログレベルの指定を尋ねるようになりました。1.0.6デバッグログをロガー経由で出力するようになりました。1.0.3drnbench-request-response--default-hostsオプションでカンマ区切りで複数のホストを指定できるようになりました。複数接続先への負荷分散を簡単にシミュレートすることができます。URLのパス部分のリストのプレーンテキストファイルを、パターンファイルとして指定できるようになりました。drnbench-extract-searchterms--escapeオプションを指定することで、出力する単語をあらかじめURLエンコードしておけるようになりました。1.0.7をリリースしました!このバージョンではサービス起動スクリプトの致命的な欠陥を修正しました。ベンチマーク測定のチュートリアルを公開しました。Droongaプロジェクトは今後も新バージョンを毎月リリースしていきます。詳しくはコミュニティのページをご覧下さい。1.0.6をリリースしました!2014-09-29長らくお待たせして申し訳ありません。1.0.6をリリースしました!Droongaとは?DroongaはGroongaと互換性を持つ分散型の全文検索エンジンです。Droongaクラスタは、レプリケーション機能を持つGroonga互換のHTTPサーバとして動作します。1.0.6のリリースにおける最大の改善点は、インストールが非常に簡単になったことです。Droongaの主要なコンポーネントであるdroonga-engineとdroonga-http-serverが、インストールスクリプト経由で導入できるようになりました。bashこれだけで、droonga-engineとdroonga-http-serverが、serviceコマンドで管理されるシステムのサービスとして登録されます。startまた、クラスタのノード構成を管理するためのユーティリティコマンド(droonga-engine-joinやdroonga-engine-unjoinなど)も使いやすくなりました。詳細は、新しくなった「使ってみる」のチュートリアルおよびそれに続く一連のチュートリアルを参照して下さい。他方で、残念なお知らせもあります。X、BSDなど)は、現時点では未対応です。インストール方法や独自のサービスをシステムに登録する方法について、それらの環境でのノウハウをお持ちであれば、インストールスクリプトの改善に是非ご協力下さい!開発者向けの情報インストールスクリプトは最新のリリース版に対してだけでなく、masterブランチの最新リビジョンに対しても利用できます。bashこれにより、インストールスクリプトはmasterからサービスをインストールするようになります。これは、次のリリースを待たずに最新の修正内容を試してみるのに便利でしょう。手持ちのPC上に複数台の仮想マシンを用意するための手順の解説も新たに用意しました。これにより、気軽にDroongaをお試しいただけます。1.0.6インストールスクリプトが利用可能になりました。これにより、必要なソフトウェアの導入と、droonga-engineをシステムのサービスとして設定する作業が自動化されました。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をサービス向けに生成する物です。ノードを空にするために既存のデータを消去するのにも使えます。ユーティリティコマンドのいくつかの必須オプションが省略可能になりました。それらの情報は自動的に認識されます。サーバがより安全に再起動するようになりました。1.0.7インストールスクリプトが利用可能になりました。これにより、必要なソフトウェアの導入と、droonga-http-serverをシステムのサービスとして設定する作業が自動化されました。7でのみ利用できます。サービスとしての利用において、専用のユーザであるdroonga-http-serverの権限で動作することが前提となりました。今後は、設定ディレクトリはこのユーザのホーム以下に置かれます。portなどの既定の設定を定義する静的な設定ファイルが導入されました。これは環境変数DROONGA_BASE_DIRで示される設定ディレクトリに置かれる必要があります。これにより、droonga-http-serverコマンドを大量のオプションを伴って起動しなくても良くなりました。新しいコマンドラインユーティリティdroonga-http-server-configureが追加されました。これは、静的な設定ファイルをサービス向けに生成する物です。レスポンスキャッシュが正常に動作するようになりました。1.0.5レスポンスキャッシュが正常に動作するようになりました。1.1.6テスト結果の安定化のために、dumpの結果をソートするようにしました。droonga-engineが利用可能になるまで待つために、--ready-notify-fdオプションを使うようにしました。1.0.4出力先のディレクトリを自動的に作成するようにしました。1.0.6をリリースしました!Droongaのインストール手順が簡単になり、より使い始めやすくなりました。Droongaプロジェクトは今後も新バージョンを毎月リリースしていきます。詳しくはコミュニティのページをご覧下さい。Tweet最新情報の日本語での提供を開始しました2014-09-26最新情報について、今後は日本語でも情報を提供していきます。