5.2.1. 比較#
groonga と groonga-httpd にはたくさんの違いがあります。以下はそれらの違いを示す比較表です。
groonga |
groonga-httpd |
|
---|---|---|
性能 |
○ |
○ |
複数CPUコア対応 |
○(マルチスレッドで対応) |
○(マルチプロセスで対応) |
設定ファイル |
なくてもよい |
必須 |
プレフィックスパスの変更 |
× |
○ |
コマンドバージョンの変更 |
○ |
○ |
複数データベース |
× |
○ |
認証 |
× |
○ |
gzip圧縮 |
× |
○ |
POST |
○ |
○ |
HTTPS |
× |
○ |
アクセスログ |
× |
○ |
ダウンタイムなしでのアップグレード |
× |
○ |
5.2.1.1. 性能#
groonga と groonga-httpd はどちらも非常に高速です。どちらも同じスループットで動きます。
5.2.1.2. 複数CPUコア対応#
Groongaは複数のCPUコアを使って性能を向上できます。 groonga はマルチスレッドを使って性能を向上させます。 groonga-httpd はマルチプロセスを使って性能を向上させます。
groonga はデフォルトでCPUコアと同じ数のスレッドを使います。もし、CPUコアが8個あった場合は、デフォルトで8個のスレッドを使います。
groonga-httpd はデフォルトで1つのプロセスを使います。複数のCPUコアを使う場合は worker_processes ディレクティブを設定する必要があります。CPUコアが8個ある場合は、以下のように設定ファイルに worker_processes 8
と指定します。:
worker_processes 8;
http {
# ...
}
5.2.1.3. 設定ファイル#
groonga は設定ファイルがなくても動きます。ポート番号や最大スレッド数などといった設定項目はすべてコマンドラインから指定できます。設定ファイルを使っても設定項目を指定することができます。
groonga はいくつかのオプションを指定するだけで実行できるので、非常に簡単にgroonga用のHTTPサーバーを起動することができます。以下は groonga でHTTPサーバーを起動する一番簡単なコマンドラインです。:
% groonga --protocol http -d /PATH/TO/DATABASE
groonga-httpd を実行するには設定ファイルが必須です。以下は groonga-httpd でHTTPサーバーを実行する一番簡単な設定ファイルです。:
events {
}
http {
server {
listen 10041;
location /d/ {
groonga on;
groonga_database /PATH/TO/DATABASE;
}
}
}
5.2.1.4. プレフィックスパスの変更#
groonga は /d/
から始まるパスをコマンドURLとして受け付けます。例えば、 http://localhost:10041/d/status
となります。この /d/
というプレフィックスパスを変更することはできません。
groonga-httpd はプレフィックスパスを変更することができます。例えば、 http://localhost:10041/api/status
というコマンドURLを使うことができます。以下は /api/
をプレフィックスパスとして使う設定例です。:
events {
}
http {
server {
listen 10041;
location /api/ { # <- change this
groonga on;
groonga_database /PATH/TO/DATABASE;
}
}
}
5.2.1.5. コマンドバージョンの変更#
Groongaには コマンドバージョン という仕組みがあります。これは後方互換性を維持したままgroongaコマンドをアップグレードするための仕組みです。
groonga は --default-command-version
オプションでデフォルトのコマンドバージョンを変更できます。以下はデフォルトのコマンドバージョンとしてコマンドバージョン2を使うコマンドライン例です。:
% groonga --protocol http --default-command-version 2 -d /PATH/TO/DATABASE
groonga-httpd はまだデフォルトのコマンドバージョンを変更できません。しかし、すぐにサポートする予定です。サポートされたら、同じ groonga-httpd プロセス内で異なったコマンドバージョンのgroongaコマンドを提供できます。以下はコマンドバージョン1のコマンドを /api/1/
以下で、コマンドバージョン2のコマンドを /api/2/
以下で提供するための設定例です。:
events {
}
http {
server {
listen 10041;
groonga_database /PATH/TO/DATABASE;
location /api/1/ {
groonga on;
groonga_default_command_version 1;
}
location /api/2/ {
groonga on;
groonga_default_command_version 2;
}
}
}
5.2.1.6. 複数データベース#
groonga は1つのプロセスで1つのデータベースしか使うことができません。
groonga-httpd は同一プロセス内で複数のデータベースを使うことができます。以下は /tmp/db1
にあるデータベースを /db1/
以下で、 /tmp/db2
にあるデータベースを /db2/
以下で提供する設定例です。:
events {
}
http {
server {
listen 10041;
location /db1/ {
groonga on;
groonga_database /tmp/db1;
}
location /db2/ {
groonga on;
groonga_database /tmp/db2;
}
}
}
5.2.1.7. 認証#
HTTPではベーシック認証やダイジェスト認証などの認証方法をサポートしています。認証することにより shutdown などのように危険なコマンドの実行を制限することができます。
groonga では認証できません。危険なコマンドの使用を制限するためには、iptablesやリバースプロキシなど他のツールを使う必要があります。
groonga-httpd はベーシック認証をサポートしています。以下は shutdown コマンドの使用を制限する設定例です。:
events {
}
http {
server {
listen 10041;
groonga_database /PATH/TO/DATABASE;
location /d/shutdown {
groonga on;
auth_basic "manager is required!";
auth_basic_user_file "/etc/managers.htpasswd";
}
location /d/ {
groonga on;
}
}
}
5.2.1.8. gzip圧縮#
HTTPは Content-Encoding: gzip
レスポンスヘッダーを付けてgzipでレスポンスを圧縮する機能をサポートしています。これはネットワーク流量を小さくすることができます。大きな検索結果を返すときに有用です。
groonga は圧縮をサポートしていません。圧縮をサポートするためには、リバースプロキシを使う必要があります。
groonga-httpd はgzip圧縮をサポートしています。以下はレスポンスをgzipで圧縮する設定例です。:
events {
}
http {
server {
listen 10041;
groonga_database /PATH/TO/DATABASE;
location /d/ {
groonga on;
gzip on;
gzip_types *;
}
}
}
gzip_types * を指定していることに注意してください。この設定はとても重要な設定です。 gzip_types はgzip対象のデータフォーマットをMIMEタイプで指定します。 groonga-httpd は JSON、XML、MessagePackのどれかのフォーマットでデータを返します。しかし、これらのフォーマットは gzip_types のデフォルト値に含まれていません。 gzip_types のデフォルト値は text/html です。
groonga-httpd のレスポンスデータをgzip圧縮するには、明示的に gzip_types * または gzip_types application/json text/xml application/x-msgpack と指定する必要があります。 gzip_types * の方がおすすめです。理由は2つあります。1つは、groongaが、将来、他のフォーマットもサポートする可能性もあるからという理由です。2つめは、この location のすべてのリクエストはgroongaが処理するので、他のモジュールのことについて考えなくてもよいからという理由です。
5.2.1.9. POST#
JSONデータをPOSTすることでデータをロードすることができます。POSTでロードする場合は以下のルールに従ってください。
Content-Type ヘッダーの値を application/json にする。
JSONデータはbodyとして送る。
テーブル名は
table=名前
というようにクエリーパラメーターで指定する。
以下はcurlを使って alice と bob という2人のユーザーを Users テーブルにロードするコマンドラインの例です:
% curl --data-binary '[{"_key": "alice"}, {"_key": "bob"}]' -H "Content-Type: application/json" "http://localhost:10041/d/load?table=Users"
5.2.1.10. HTTPS#
TODO
5.2.1.11. アクセスログ#
TODO
5.2.1.12. ダウンタイムなしでのアップグレード#
TODO