タグ: Solr

【Solr】Date Mathの仕様をソースコードで確認する

Solr のリファレンスガイドでは Date Math においてどの時間単位がどういう表記で許されているかの仕様はあまり詳しくは説明されておらず、いくつかの具体例が挙げられているのみです。 例に挙がっていない時間の単位が使えるのかはどうかは試してみないと分かりません。

そこで Solr 8.4.1 のソースコードで仕様を確認してみました。

Date Math を扱うクラスを探して org.apache.solr.util.DateMathParser というクラスに行き当たりました。そのソースコードでは、扱える単位は以下のように定義されていました。

    Map units = new HashMap<>(13);
    units.put("YEAR",        ChronoUnit.YEARS);
    units.put("YEARS",       ChronoUnit.YEARS);
    units.put("MONTH",       ChronoUnit.MONTHS);
    units.put("MONTHS",      ChronoUnit.MONTHS);
    units.put("DAY",         ChronoUnit.DAYS);
    units.put("DAYS",        ChronoUnit.DAYS);
    units.put("DATE",        ChronoUnit.DAYS);
    units.put("HOUR",        ChronoUnit.HOURS);
    units.put("HOURS",       ChronoUnit.HOURS);
    units.put("MINUTE",      ChronoUnit.MINUTES);
    units.put("MINUTES",     ChronoUnit.MINUTES);
    units.put("SECOND",      ChronoUnit.SECONDS);
    units.put("SECONDS",     ChronoUnit.SECONDS);
    units.put("MILLI",       ChronoUnit.MILLIS);
    units.put("MILLIS",      ChronoUnit.MILLIS);
    units.put("MILLISECOND", ChronoUnit.MILLIS);
    units.put("MILLISECONDS",ChronoUnit.MILLIS);

まとめると以下のようになります。ミリ秒の異表記が妙に充実していますね。

  • 年 : YEAR,YEARS
  • 月 : MONTH,MONTHS
  • 日 : DAY,DAYS,DATE
  • 時 : HOUR,HOURS
  • 分 : MINUTE,MINUTES
  • 秒 : SECOND,SECONDS
  • ミリ秒 : MILLI,MILLIS,MILLISECOND,MILLISECONDS

週(WEEK)が見当たりませんが、近くに書かれているコメントによると、週については
/WEEK と書いたときの丸め処理(たとえば NOW/DAY と書くとその日の0時0分0秒になる)がややこしいので今のところ採用していないとのことです。

【Solr】Date Mathによる日付表現

はじめに

Solr では、pdate 等の時刻を扱うフィールドに対するクエリで使用できる Date Math という表現が用意されています。「今日からN日前」のような表現を使いたいときに便利です。 この記事ではDate Mathについてまとめました。

通常の日付表現

Solr では日付のフィールドは以下の形式で表現します。

2020-03-22T14:55:29Z

ミリ秒までの精度があるので、小数点表記も有効です。

2020-03-22T14:55:29.123Z

時刻は秒まできちんと表記しなければエラーになります。

ミリ秒よりも小さい桁が書いてあっても受付けますが、無視されます。

エラーになる例

2020-03-22
2020-03-22T14:55Z

Date Math

Date Mathは、特定の時点からの相対的な時刻を指定しやすくするための表記法です。
起点として良く使用される「今現在」を指定するために NOW という Date Math が用意されています。

Date Mathではまず起点となる日付を書き、それプラスN日という形で表記します。
「2ヶ月後」

NOW+2MONTH

「10日前」

NOW-10DAY

「1年後」

NOW-1YEAR

プラス/マイナスの部分は連続して書くことができます。

NOW+1YEAR+3MONTH+5DAY

起点として通常の日付を指定することもできます。

2020-03-22T10:15:18Z+7DAY

丸め表記

スラッシュ(‘/’)を併用することで、「〜の最初」を表現できます。
たとえば現在時刻が2020年3月22日11時22分33秒だとします。

NOW/HOUR

→2020年3月22日11時00分00秒

NOW/DAY

→2020年3月22日00時00分00秒

Date Math と組み合わせて使えるリクエストパラメータ

NOW

NOW パラメータにより、Date Math で記述した “NOW” を特定の日付に設定することができます。 NOW パラメータには、いわゆる UNIX TIME の Long 値を指定します。
NOW パラメータを指定することで、複数のノードにまたがる分散検索での NOW の値を揃えることができます。テストのときにも役に立ちそうです。

TZ

TZ パラメータを指定することで、デフォルト UTC である Date Math の日付計算を別のタイムゾーンとして扱うことができます。

SolrのDateRangeFieldで日時の範囲を扱う

はじめに

Solrで日時を扱うためのフィールドタイプとして、通常使う DatePointField の他にもう一つ DateRangeField があります。その名の通り幅の有る時間を取り扱えます。

DateRangeFieldとDatePointField

店舗の営業時間を扱うことを考えてみます。

<fieldType name="pdate" class="solr.DatePointField" docValues="true"/>
<field name="start" type="pdate" indexed="true"/>
<field name="end" type="pdate" indexed="true"/>

与えられた時刻(たとえば2020年3月1日19時)に営業している店舗を調べるには、営業開始時刻(start)と営業終了時刻(end)のフィールドを定義して、「startが2020年3月1日19時よりも前」かつ「endが2020年3月1日19時よりも後」である店舗を検索します。 (話を簡単にするためこの記事ではタイムゾーンのことは考えないことにします)

start:[* TO 2020-03-01T19:00:00Z] AND end:[2020-03-01T19:00:00Z * TO]

対して DateRangeFieldを使えば、営業時間のフィールドが1つで済みます

<fieldType name="rdate" class="solr.DateRangeField" docValues="true"/>
<field name="start_end" type="rdate" indexed="true" multiValued="true"/>

投入するデータは以下のような形式です。

[
    {
     "id":"1",
     "start_end":[
	 "[2020-03-01T18:00Z TO 2020-03-01T23:00Z]"
     ]
    }
]

以下のクエリで2020年3月1日19時に営業している店舗を検索できます。

start_end:"2020-03-01T19:00:00Z"

DateRangeFieldを使うパターンだと営業時間を複数登録するのも簡単です。

[
    {
     "id":"2",
     "start_end":[
	 "[2020-03-01T11:00Z TO 2020-03-01T14:00Z]",
	 "[2020-03-01T18:00Z TO 2020-03-01T23:00Z]",
	 "[2020-03-02T18:00Z TO 2020-03-02T23:00Z]",
	 "[2020-03-04T11:00Z TO 2020-03-04T14:00Z]",
	 "[2020-03-04T18:00Z TO 2020-03-04T23:00Z]"
     ]
    }
]

クエリは先程と同じもので大丈夫です。

start_end:"2020-03-01T19:00:00Z"

DatePointFieldでstartとendの2つのフィールドを使うパターンだと、どうでしょう?
start と end を multiValued にしても解決しません。

[
    {
     "id":"10",
     "start":["2020-03-01T11:00Z","2020-03-01T18:00Z"],
     "end":["2020-03-01T14:00Z","2020-03-01T23:00Z"]
    }
]

と登録したとして、startのどちらがendのどちらに対応しているのかが検索時に区別できないからです。したがって、別のレコードに分けなければなりません。

[
    {
     "id":"10",
     "start":"2020-03-01T11:00Z",
     "end":"2020-03-01T14:00Z"
    },
    {
     "id":"11",
     "start":"2020-03-01T18:00Z",
     "end":"2020-03-01T23:00Z"
    }
]

営業時間だけを扱っている分にはこれでも良さそうに見えますが、他の店舗情報(店舗名、住所、電話番号等)もインデックスに含めるとすると、以下のどちらかを考えなければならなくなります。

  • すべてのレコードに店舗情報を含める(すごく冗長)
  • 店舗情報と営業時間情報を分けてJOINする(処理が複雑になる)

どちらにしても、DateRangeField を使った場合のシンプルさには比べるべくもありません。

検索時のオプション

インデックス側とクエリ側のどちらも時間範囲である場合、以下の5通りの組み合わせが考えられます。

  1. 全く重ならない(例: インデックス「1時から2時」クエリ「4時から5時」)
  2. 完全に一致する(例: インデックス「1時から2時」クエリ「4時から5時」)
  3. 一部分が重なる(例: インデックス「1時から2時」クエリ「1時半から3時」)
  4. インデックス側がクエリ側に含まれる(例: インデックス「1時から2時」クエリ「0時から3時」)
  5. クエリ側がインデックス側に含まれる(例: インデックス「1時から2時」クエリ「1時20分から1時40分」)

検索クエリとしてヒットしたかどうかの判定時に、1はヒットしない、2はヒットしたでいいのですが、3,4,5は要件によって判定を変えたいことがあります。そこで、以下のオプションが用意されています。

  • Intersects(デフォルト): 2,3,4,5がヒット
  • Within: 2,4がヒット
  • Contains: 2,5がヒット

と思ったら、8.4.0の実際の挙動は以下の通りでした。

  • Intersects(デフォルト): 2,3,4,5がヒット
  • Within: 4がヒット
  • Contains: 2,5がヒット

具体的には

[2020-03-01T01:00Z TO 2020-03-01T02:00Z]

というデータに対して

{!field f=dateRange op=Within}[2020-03-01T01:00:00Z TO 2020-03-01T02:00:00Z]

というクエリがヒットしませんでした。opがContainsやIntersectsならヒットしました。Withinの場合は両端のどちらかが一致しているとヒットにはならず、インデックス側が完全に内側に無いといけないようです。

おわりに

DateRangeFieldを使うと、幅の有る時間のデータをシンプルに取り扱うことができます。「日付データ→pdate」と短絡せず、要件に合わせて使い分けるようにしたいところです。

Solr 8.4.0 で追加された”Untrusted Configsets”の制限について

Solr 8.4.0 の Changes には以下の項目があります。

SOLR-14071: Untrusted configsets (ones that are uploaded via unsecured configset API) cannot use <lib> directive. Consider enabling authentication/authorization so that the uploaded configsets are trusted. Note: If you already have a collection using untrusted configset that uses directive, it will not load after upgrading to 8.4. You can re-upload your configset using “bin/solr zk -upconfig ..” or place your libraries in the classpath and restart Solr.

「Untrusted configsets は lib ディレクティブを使えません」とあります。
configsets が trusted として扱われるためには、認証有りでアップロードしなければならないとのことです。Solr 8.4.0 では _default の solrconfig.xml から lib を使う設定が無くなったのもこの変更に合わせてのようです。

Untrusted configsets では lib ディレクティブが使えないというのが具体的にどういう意味なのかを確認してみました。

まず Solr 8.4.0 が起動した状態で sample_techproducts_configs (このサンプル設定には 8.4.0 でも lib ディレクティブが含まれます)を configsets_test という名前でアップロードします。

$ (cd solr-8.4.0/server/solr/configsets/sample_techproducts_configs/conf && zip -r - *) > configsets_test.zip
$ curl -X POST --header "Content-Type:application/octet-stream" --data-binary @configsets_test.zip "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=configsets_test"

アップロードした configsets_test を使ってコレクションを作成します。

curl -s "http://localhost:8983/solr/admin/collections?action=CREATE&name=configsets_test&numShards=1&replicationFactor=1&collection.configName=configsets_test&omitHeader=true"
{
  "failure":{
    "127.0.1.1:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 'configsets_test_shard1_replica_n1': Unable to create core [configsets_test_shard1_replica_n1] Caused by: The configset for this collection was uploaded without any authentication in place, and use of  is not available for collections with untrusted configsets. To use this component, re-upload the configset after enabling authentication and authorization."},
  "Operation create caused exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Underlying core creation failed while creating collection: configsets_test",
  "exception":{
    "msg":"Underlying core creation failed while creating collection: configsets_test",
    "rspCode":400},
  "error":{
    "metadata":[
      "error-class","org.apache.solr.common.SolrException",
      "root-error-class","org.apache.solr.common.SolrException"],
    "msg":"Underlying core creation failed while creating collection: configsets_test",
    "code":400}}

アップロードはできましたが、その configsets を使ってコレクションを作成することろでエラーになりました。

次に BASIC 認証を設定してからコレクション作成してみます。

$ ./solr-8.4.0/server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983 -cmd put /security.json '{
"authentication":{
   "blockUnknown": true,
   "class":"solr.BasicAuthPlugin",
   "credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
 }
}'

ここで Solr を再起動して BASIC 認証が有効になった状態で再度コレクション作成。

$ curl --user solr:SolrRocks -s "http://localhost:8983/solr/admin/collections?action=CREATE&name=configsets_test&numShards=1&replicationFactor=1&collection.configName=configsets_test&omitHeader=true"
{
  "failure":{
    "127.0.1.1:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error from server at http://127.0.1.1:8983/solr: Error CREATEing SolrCore 'configsets_test_shard1_replica_n1': Unable to create core [configsets_test_shard1_replica_n1] Caused by: The configset for this collection was uploaded without any authentication in place, and use of  is not available for collections with untrusted configsets. To use this component, re-upload the configset after enabling authentication and authorization."},
  "Operation create caused exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Underlying core creation failed while creating collection: configsets_test",
  "exception":{
    "msg":"Underlying core creation failed while creating collection: configsets_test",
    "rspCode":400},
  "error":{
    "metadata":[
      "error-class","org.apache.solr.common.SolrException",
      "root-error-class","org.apache.solr.common.SolrException"],
    "msg":"Underlying core creation failed while creating collection: configsets_test",
    "code":400}}

やはりエラーになります。

confitsets を trusted として扱ってもらうために、認証有りの状態で再度アップロードします。UPLOAD コマンドでは上書きできないので、DELETE してから UPLOAD します。

$ curl --user solr:SolrRocks -X POST --header "Content-Type:application/octet-stream" --data-binary @configsets_test.zip "http://localhost:8983/solr/admin/configs?action=DELETE&name=configsets_test"
{
  "responseHeader":{
    "status":0,
    "QTime":220}}
$ curl --user solr:SolrRocks -X POST --header "Content-Type:application/octet-stream" --data-binary @configsets_test.zip "http://localhost:8983/solr/admin/configs?action=UPLOAD&name=configsets_test"
{
  "responseHeader":{
    "status":0,
    "QTime":292}}

認証有りでアップロードした configsets を使ってコレクションを作成してみます。

$ curl --user solr:SolrRocks -s "http://localhost:8983/solr/admin/collections?action=CREATE&name=configsets_test&numShards=1&replicationFactor=1&collection.configName=configsets_test&omitHeader=true"
{
  "success":{
    "127.0.1.1:8983_solr":{
      "responseHeader":{
        "status":0,
        "QTime":2126},
      "core":"configsets_test_shard1_replica_n1"}}}

今度はうまくいきました。

結論としては、「Untrusted configsets では lib ディレクティブが使えない」とは、libディレクティブを含む Untrusted configsets ではコレクションを生成できないという意味でした。

ところで、configsets アップロードする方法としては、Solr の Configsets API を使う方法とは別に zookeeper に直接アップロードする方法もあります。

$ ./solr-8.4.0/server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983 -cmd upconfig -confdir solr-8.4.0/server/solr/configsets/sample_techproducts_configs/conf -confname configsets_test2
INFO  - 2020-02-23 22:52:50.804; org.apache.solr.common.cloud.ConnectionManager; Waiting for client to connect to ZooKeeper
INFO  - 2020-02-23 22:52:50.821; org.apache.solr.common.cloud.ConnectionManager; zkClient has connected
INFO  - 2020-02-23 22:52:50.821; org.apache.solr.common.cloud.ConnectionManager; Client is connected to ZooKeeper
$ curl --user solr:SolrRocks -s "http://localhost:8983/solr/admin/collections?action=CREATE&name=configsets_test2&numShards=1&replicationFactor=1&collection.configName=configsets_test2&omitHeader=true"
{
  "success":{
    "127.0.1.1:8983_solr":{
      "responseHeader":{
        "status":0,
        "QTime":1361},
      "core":"configsets_test2_shard1_replica_n1"}}}

なんとコレクション生成できてしまいました。

現時点では Untrusted Configsets の制限はまだ不十分なようで、今後の進展に注意する必要がありそうです。

SolrにBasic認証を設定する

Solrの管理画面やAPIへのアクセスに認証を掛けることができます。この記事ではBASIC認証を設定してみます。

SolrCloudの環境では Zookeeper の /security.json に設定ファイルを置きます。 Solrリファレンス にはユーザ:solr パスワード:SolrRocks で設定する例が載っています。

$ ./zkcli.sh -zkhost localhost:9983 -cmd put /security.json '{
"authentication":{
   "blockUnknown": true,
   "class":"solr.BasicAuthPlugin",
   "credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
 }
}'

この後Solrの再起動でBASIC認証が有効になり、管理画面にブラウザでアクセスすると、ユーザ名とパスワードの入力を促されます。ここで solr と SolrRocks で確かにログインできます。

このままリファレンスに載っているユーザとパスワードを使い続ける訳にはいかないので、別のユーザを追加することを考えます。初めは security.json に追加の設定を記載するのかと思いましたが、パスワードをSolrが期待する形式でハッシュ化する方法が分かりませんでした。結局のところ、リファレンスに書いてある通り、APIで設定変更するしかなさそうです。

ここで、APIへのHTTPアクセスにも認証が必要となります。

新しいユーザの追加

curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 'Content-type:application/json' -d '{"set-user": {"solradmin":"solrpass"}}'

最初に設定した solr ユーザの削除

curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 'Content-type:application/json' -d  '{"delete-user": ["solr"]}'

追加と削除の後の security.json の内容を確認

$ server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983 -cmd get /security.json
{"authentication":{
    "blockUnknown":true,
    "class":"solr.BasicAuthPlugin",
    "credentials":{"solradmin":"AkZTG0uVSAgfzB/OC+kI1tqw9aeR8pP05tpNdcnnfN8= wRKTRwEcTX5eiCgEmCfIRXdRf9zIq2/Aef/LP6ZzdIQ="},
    "":{"v":13}}}

確かに変わっています。パスワードもハッシュ化されています。

管理画面だけではなく、コマンドラインツールも認証が必要になります。

bin/post -c mycollection data.json
POSTing file data4.json (application/json) to [base]/json/docs
SimplePostTool: WARNING: Solr returned an error #401 (require authentication) for url: http://localhost:8983/solr/mycollection/update/json/docs
SimplePostTool: FATAL: Looks like Solr is secured and would not let us in. Try with another user in '-u' parameter

オプションで指定するだけなので簡単。

bin/post -u solradmin:solrpass -c mycollection data.json

昔は認証が必要な場合は Jetty 側でなんとかしていたようですが、今は Solr 側で設定できるようになっています。Solr 8.4 からは認証が設定されていない場合にはAPI経由での設定ファイルのアップロード(というかアップロードする設定の内容)に制限が付くこともあるので、この辺の設定もきちんと押さえておきたいところです。