タグ: Solr

SolrのUAX29URLEmailTokenizerを使う

Solrにはさまざまなトークナイザーが用意されており、その中に UAX29URLEmailTokenizer があります。
このトークナイザーは基本的には StandardTokenizer と同じ挙動なのですが、以下の要素をトークンとして切り出してくれるという特徴があります。

  • ドメイン名
  • URL(http(s)://, file://, ftp://)
  • Eメールアドレス
  • IPアドレス(IPv4とIPv6)

UAX29URLEmailTokenizer を使うフィールドタイプとフィールドを定義して動作を確認してみます。

<fieldType name="text_url" class="solr.TextField" positionIncrementGap="100">
  <analyzer>
    <tokenizer class="solr.UAX29URLEmailTokenizerFactory"/>
  </analyzer>
</fieldType>                                                                                                            
<field name="url_test" type="text_url" stored="true"/>

この設定で「http://www.example.com/example/です。」をトークナイズした結果は以下の通りです。

日本語の文書を扱う場合、通常の文章の部分が StandardTokenizer 相当でトークナイズされるといろいろ使い勝手が悪いので、たとえば形態素解析のトークナイザーと組み合わせることを考えます。

<fieldType name="url" class="solr.TextField" positionIncrementGap="100">
  <analyzer type="index">
    <tokenizer class="solr.UAX29URLEmailTokenizerFactory"/>
    <filter class="solr.TypeTokenFilterFactory" types="url_whitelist.txt" useWhitelist="true"/>
  </analyzer>
  <analyzer type="query">
    <tokenizer class="solr.KeywordTokenizerFactory"/>
  </analyzer>
</fieldType>

<field name="body" type="text_ja" stored="true"/>
<field name="url" type="url" stored="true"/>
<copyField source="body" dest="url"/>

UAX29URLEmailTokenizer の後ろに TypeTokenFilter を追加することで、必要なトークンタイプだけを残すことができます。TypeTokenFilter のホワイトリストとして url_whitelist.txt に以下の1行だけを記述して、URLだけを残すようにします。

<URL>

クエリ用のアナライザを別に定義したのは、URLのフィールドの検索では余計なトークナイズをさせずに文字列マッチ相当の動作にしたいからです。
urlフィールドをurlフィールドタイプとして定義し、text_jaフィールドタイプであるbodyフィールドのコピーフィールドにしています。

以下の文書を投入します。

[
    {"id":"1",
     "body":"昨日 http://blog.splout.co.jp/ をみた。"
    },
    {"id":"2",
     "body":"明後日は http://splout.co.jp/ をみる。"
    }
]

各フィールドにどういうトークンが納められたのかを確認します。

$ curl -s 'http://localhost:8983/solr/urlTokenizer/terms?terms.fl=url&terms.limit=-1&omitHeader=true&wt=json'
{
  "terms":{
    "url":[
      "http://blog.splout.co.jp/",1,
      "http://splout.co.jp/",1]}}

urlフィールドにはURLだけが納められています。

$ curl -s 'http://localhost:8983/solr/urlTokenizer/terms?terms.fl=body&terms.limit=-1&omitHeader=true&wt=json'
{
  "terms":{
    "body":[
      "co",2,
      "http",2,
      "jp",2,
      "splout",2,
      "みる",2,
      "blog",1,
      "明後日",1,
      "昨日",1]}}

bodyフィールドには通常の形態素解析結果が納められています。

この状態で検索してみます。まずは body フィールドを “http://splout.co.jp/” で。

$ curl -s 'http://localhost:8983/solr/urlTokenizer/select?q=body%3Ahttp%5C%3A%5C%2F%5C%2Fsplout.co.jp%5C%2F'
{
  "responseHeader":{
    "zkConnected":true,
    "status":0,
    "QTime":0,
    "params":{
      "q":"body:http\\:\\/\\/splout.co.jp\\/"}},
  "response":{"numFound":2,"start":0,"docs":[
      {
        "id":"2",
        "body":"明後日は http://splout.co.jp/ をみる。",
        "url":"明後日は http://splout.co.jp/ をみる。",
        "_version_":1656715432355168256},
      {
        "id":"1",
        "body":"昨日 http://blog.splout.co.jp/ をみた。",
        "url":"昨日 http://blog.splout.co.jp/ をみた。",
        "_version_":1656715432353071104}]
  }}

“http”, “splout”, “co”, “jp” がバラバラにトークンとして扱われるので、”http://blog.splout.co.jp/” も “http://splout.co.jp/” も両方がヒットしています。
次に url フィールドを同じく “http://splout.co.jp/” で。

$ curl -s 'http://localhost:8983/solr/urlTokenizer/select?q=url%3Ahttp%5C%3A%5C%2F%5C%2Fsplout.co.jp%5C%2F'
{
  "responseHeader":{
    "zkConnected":true,
    "status":0,
    "QTime":0,
    "params":{
      "q":"url:http\\:\\/\\/splout.co.jp\\/"}},
  "response":{"numFound":1,"start":0,"docs":[
      {
        "id":"2",
        "body":"明後日は http://splout.co.jp/ をみる。",
        "url":"明後日は http://splout.co.jp/ をみる。",
        "_version_":1656715432355168256}]
  }}

“http://splout.co.jp/” の方だけがヒットします。

urlフィールドの検索ではワイルドカードを使うこともできます。”http://*.splout.co.jp/” を指定して splout.co.jp のサブドメインだけを検索してみます。

$ curl -s 'http://localhost:8983/solr/urlTokenizer/select?q=url%3Ahttp%5C%3A%5C%2F%5C%2F*.splout.co.jp%5C%2F'
{
  "responseHeader":{
    "zkConnected":true,
    "status":0,
    "QTime":1,
    "params":{
      "q":"url:http\\:\\/\\/*.splout.co.jp\\/"}},
  "response":{"numFound":1,"start":0,"docs":[
      {
        "id":"1",
        "body":"昨日 http://blog.splout.co.jp/ をみた。",
        "url":"昨日 http://blog.splout.co.jp/ をみた。",
        "_version_":1656715432353071104}]
  }}

文章に含まれるURLやメールアドレスの扱いは案外面倒なものです。
UAX29URLEmailTokenizer をうまく使えば、自前でURLやメールアドレスを抽出してstringフィールドに格納するよりもバグも少なく取り扱うことができるでしょう。

SolrCloudのエイリアス機能(その2)

はじめに

SolrCloudのエイリアス機能には大きく分けて Standard Aliases と Routed Aliases があります。基本的な機能はどちらも共通で、Routed Aliases には特定のフィールドの値に応じて特定のコレクションを対象として指定できるという特徴があります。

この記事では、Routed Aliases の中の Time Routed Aliases を採り上げます。

Time Routed Aliases の作成

Time Routed Aliases を作るときの基本的なリクエストは以下のようなものです。

$ curl -s 'http://localhost:8983/solr/admin/collections?action=CREATEALIAS&name=timedata&router.start=NOW/DAY&router.field=date&router.name=time&router.interval=%2B1DAY&router.maxFutureMs=3600000&router.autoDeleteAge=/DAY-90DAYS&create-collection.collection.configName=aliasConfigSet&create-collection.numShards=1'

指定されているパラメータの説明

  • action=CREATEALIAS
  • router.name=time
    • Time Routed Aliases の場合は “time” を指定
  • name=timedata
    • エイリアス名
    • コレクション名は、この文字列をプレフィックスとして”timedata_2019-12-25″のようになる
  • router.field=date
    • 振り分けの基準にするフィールド名
  • router.start=NOW/DAY
    • 起点の時刻
    • この時刻を含むコレクションが最初のコレクションとして生成される。それより古いデータはエラーになる。
  • router.interval=+1DAY
    • 1つのコレクションが受け持つ時間の範囲
  • router.maxFutureMs=3600000
    • 現在時刻よりもどのくらい先の時刻までのデータを受け入れるか(ミリ秒)
    • 3600000が指定された場合、1時間先のデータまでは受け入れる
  • router.autoDeleteAge=/DAY-90DAYS
    • ここで指定された期間を過ぎたコレクションは自動的に削除される
  • create-collection.collection.configName=aliasConfigSet
    • Time Routed Aliases に属するコレクションが共通して持つコンフィグセットの指定
  • create-collection.numShards=1
    • Routed Aliases では CREATEALIAS の際にコレクションを作成するので、CREATE アクションでコレクションを作成する際に指定できるパラメータをcreate-collection.* という形で指定できる。

たとえば2019年12月25日に上に示したリクエストを実行したとすると、以下のような運用になります。

  • エイリアス名 timedata
  • コレクション名 timedata_2019-12-25
  • 現在時刻から1時間先のデータまで受け付る
  • 2019年12月26日のデータを受け付けると timedata_2019-12-26 が作られる
  • 90日よりも古くなったコレクションは削除

コレクションの自動追加

上述の通り、最新のコレクションが timedata_2019-12-25 であるときに12月26日のデータを追加しようとすると、新しく timedata_2019-12-26 が作られます。 新しいコレクションの作成には数秒を要し、その間 timedata_2019-12-26 への更新処理はブロックされます。

秒あたりのデータ数が多く、このブロック発生が許容できない場合には、CREATEALIAS アクションのオプションとして router.preemptiveCreateMath を指定できます。ここで例えば60分を指定しておくと、12月25日の23:00のデータを処理した時点で先に timedata_2019-12-26 を非同期に作成しておくことができます。

おわりに

Time Routed Aliases は以下の特徴を持つ Routed Aliases です。

  • エイリアス配下のコレクションそれぞれが一定の時間範囲のデータを担当する
    • (例)12月10日用のコレクション、11日用のコレクション、12日用のコレクション…
  • 時刻のフィールドによる振り分け
  • 更新を許容する時間範囲の設定
  • 現在時刻に応じて自動的に新しいコレクションを追加
  • 現在時刻に応じて古いコレクションを自動的に削除

時間的に連続するログデータやセンサの計測データなどを扱うのに向いています。

SolrCloudのエイリアス機能(その1)

はじめに

SolrCloudにはコレクションにエイリアスを設定する機能があります。
このエイリアスが役に立つ場面として、リファレンスでは以下の3つが挙げられています。
・新しく作った、再生成したインデックスをダウンタイム無しで既存のものと差し替える
・コレクション名の変更がクライアントプラグラムに影響を与えないようにする
・同じスキーマの複数のコレクションに1回だけクエリを発行する

1つめと2つめについては経験がありますが、3つめの複数のコレクションを対象にエイリアスを設定するパターンは使ったことは無かったので、その挙動等を調べてみました。

複数コレクションにエイリアスを設定する

まずalias_test1とalias_test2の2つのコレクションを作成してエイリアスalias_testを設定。

$ curl -s 'http://localhost:8983/solr/admin/collections?action=CREATE&name=alias_test1&numShards=1&replicationFactor=1&wt=json'
$ curl -s 'http://localhost:8983/solr/admin/collections?action=CREATE&name=alias_test2&numShards=1&replicationFactor=1&wt=json'
$ curl -s 'http://localhost:8983/solr/admin/collections?action=CREATEALIAS&name=alias_test&collections=alias_test1,alias_test2'

エイリアスを確認。

curl -s 'http://localhost:8983/solr/admin/collections?action=CLUSTERSTATUS' | jq .cluster.aliases
{
  "alias_test1": "alias_test1",
  "alias_test2": "alias_test2",
  "alias_test": "alias_test1,alias_test2"
}

エイリアスに対するスキーマ変更

コレクションではなくエイリアスを指定してフィールドを追加してみます。

$ cat add_field.json
{
  "add-field":{
     "name":"date",
     "type":"pdate",
      "stored":true },
  "add-field":{
     "name":"body",
     "type":"string",
      "stored":true }
}
$ curl -s -X POST -H 'Content-type:application/json' -d @add_field.json 'http://localhost:8983/solr/alias_test/schema'

各コレクションのスキーマを確認。

$ curl -s 'http://localhost:8983/solr/alias_test1/schema/fields?omitHeader=true'
{
  "fields":[
    {
      "name":"_root_",
      "type":"string",
      "docValues":false,
      "indexed":true,
      "stored":false},
    {
      "name":"_text_",
      "type":"text_general",
      "multiValued":true,
      "indexed":true,
      "stored":false},
    {
      "name":"_version_",
      "type":"plong",
      "indexed":false,
      "stored":false},
    {
      "name":"body",
      "type":"string",
      "stored":true},
    {
      "name":"date",
      "type":"pdate",
      "stored":true},
    {
      "name":"id",
      "type":"string",
      "multiValued":false,
      "indexed":true,
      "required":true,
      "stored":true}]
$ curl -s 'http://localhost:8983/solr/alias_test2/schema/fields?omitHeader=true'
{
  "fields":[{
      "name":"_root_",
      "type":"string",
      "docValues":false,
      "indexed":true,
      "stored":false},
    {
      "name":"_text_",
      "type":"text_general",
      "multiValued":true,
      "indexed":true,
      "stored":false},
    {
      "name":"_version_",
      "type":"plong",
      "indexed":false,
      "stored":false},
    {
      "name":"id",
      "type":"string",
      "multiValued":false,
      "indexed":true,
      "required":true,
      "stored":true}]

dataフィールドとbodyフィールドが追加されたのはalias_test1の方だけでした。alias_test2にはコレクション名を指定してフィールドを追加しておきます。

$ curl -s -X POST -H 'Content-type:application/json' -d @add_field.json 'http://localhost:8983/solr/alias_test2/schema'
$ curl -s 'http://localhost:8983/solr/alias_test2/schema/fields?omitHeader=true'
{
  "fields":[{
      "name":"_root_",
      "type":"string",
      "docValues":false,
      "indexed":true,
      "stored":false},
    {
      "name":"_text_",
      "type":"text_general",
      "multiValued":true,
      "indexed":true,
      "stored":false},
    {
      "name":"_version_",
      "type":"plong",
      "indexed":false,
      "stored":false},
    {
      "name":"id",
      "type":"string",
      "multiValued":false,
      "indexed":true,
      "required":true,
      "stored":true},
    {
      "name":"body",
      "type":"string",
      "stored":true},
    {
      "name":"date",
      "type":"pdate",
      "stored":true}]

エイリアスに対する更新

エイリアス alias_test を指定してデータを投入してみます。

$ cat data.json
[
    {"id":"1",
     "date":"2019-01-01T00:00:00Z",
     "body":"body1"
    }
]
$ curl -s -X POST -H 'Content-type:application/json' -d @data.json 'http://localhost:8983/solr/alias_test/update/json/docs?commit=true'

それぞれのコレクションの内容を確認。

$ curl -s 'http://localhost:8983/solr/alias_test1/select?q=*%3A*&omitHeader=true'
{
  "response":{"numFound":1,"start":0,"docs":[
      {
        "id":"1",
        "date":"2019-01-01T00:00:00Z",
        "body":"body1",
        "_version_":1653627228838166528}]
  }}
$ curl -s 'http://localhost:8983/solr/alias_test2/select?q=*%3A*&omitHeader=true'
{
  "response":{"numFound":0,"start":0,"docs":[]
  }}

やはりalias_test1の方だけ更新されている。

エイリアスに対する検索

コレクションalias_test2を指定して別のデータを投入しておきます。

$ cat data2.json
[
    {"id":"2",
     "date":"2019-01-02T00:00:00Z",
     "body":"body2"
    }
]
$ curl -s -X POST -H 'Content-type:application/json' -d @data2.json 'http://localhost:8983/solr/alias_test2/update/json/docs?commit=true'
$ curl -s 'http://localhost:8983/solr/alias_test2/select?q=*%3A*&omitHeader=true'
{
  "response":{"numFound":1,"start":0,"docs":[
      {
        "id":"2",
        "date":"2019-01-02T00:00:00Z",
        "body":"body2",
        "_version_":1653898674683510784}]
  }}

エイリアスを指定して検索。

$ curl -s 'http://localhost:8983/solr/alias_test/select?q=*%3A*&omitHeader=true'
{
  "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
      {
        "id":"1",
        "date":"2019-01-01T00:00:00Z",
        "body":"body1",
        "_version_":1653627228838166528},
      {
        "id":"2",
        "date":"2019-01-02T00:00:00Z",
        "body":"body2",
        "_version_":1653898674683510784}]
  }}

コレクション alias_test1 と alias_test2 の結果が統合されていることが分かります。

おわりに

複数のコレクションを対象にしたエイリアスの挙動を探ってみました。
検索では1回のリクエストで統一的に結果を得ることができます。
更新の場合は最初に指定されたコレクションがUPDATEリクエストを処理するようになっており、更新先を指定したい場合にはコレクション名を使う必要があります。

同じスキーマのコレクションを複数に分けたい使い方というのは、ログ等の時系列のデータが典型例です。実はSolrではこのような使い方に便利なRouted Aliasという機能が用意されています。Routed Aliasの詳細については別の機会に採り上げたいと思います。

Solrのコレクション名に日本語を使えるか

先日、テーブル名やカラム名に日本語が使われているデータベースからデータをSolrにインポートする機会がありました。Solr側のコレクション名やフィールド名で日本語を使えるならインポートの手間が小さくて済むので、実際そういうことができるのか調べてみました。

コレクションAPIで日本語名のコレクションを作ってみます。

$ curl -s 'http://localhost:8983/solr/admin/configs?action=CREATE&omitHeader=true&name=test1&baseConfigSet=_default'
$ curl -s 'http://localhost:8983/solr/admin/collections?action=CREATE&name=テスト&numShards=1&replicationFactor=1&wt=json'
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<title>Error 500 Server Error</title>
</head>
<body><h2>HTTP ERROR 500</h2>
<p>Problem accessing /solr/admin/collections. Reason:
<pre>    Server Error</pre></p><h3>Caused by:</h3><pre>org.apache.solr.common.SolrException: URLDecoder: The query string contains a not-%-escaped byte > 127 at position 19
(略)

サーバエラーになってしまったのでURLエンコードしてパラメータ指定します。

$ curl -s 'http://localhost:8983/solr/admin/collections?action=CREATE&name=%E3%83%86%E3%82%B9%E3%83%88&numShards=1&replicationFactor=1'
{
  "responseHeader":{
      "status":400,
      "QTime":0},
      "error":{
      "metadata":[
        "error-class","org.apache.solr.common.SolrException",
        "root-error-class","org.apache.solr.common.SolrException"],
        "msg":"Invalid collection: [テスト]. collection names must consist entirely of periods, underscores, hyphens, and alphanumerics as well not start with a hyphen",
        "code":400}}
エラーメッセージによると、コレクション名に利用できるのは以下の文字種に限るようです。
  • 英数文字
  • ピリオド
  • アンダースコア
  • ハイフン(ハイフンは先頭文字としては使えない)

ソースコードを調べると、コレクション名のチェックをしているのは以下のクラスでした。

solr/solrj/src/java/org/apache/solr/client/solrj/util/SolrIdentifierValidator.java

チェックに使う正規表現は以下の通りです。

final static Pattern identifierPattern = Pattern.compile("^(?!\\-)[\\._A-Za-z0-9\\-]+$");

SolrIdentifierValidatorではシャード、コレクション、コア、エイリアスの名前をチェックしています。チェックに使う正規表現は共通なので、シャード、コレクション、コア、エイリアスについては同じ仕様であることが分かりました。

Solrのフィールド名に日本語を使えるか

前回の記事に引き続き、今回はフィールド名に日本語を使えるかどうかを調査しました。

フィールド名の仕様については、Solrリファレンスガイドの”Field Type Definitions and Properties”に記載があります。

The name of the fieldType. This value gets used in field definitions, in the “type” attribute. It is strongly recommended that names consist of alphanumeric or underscore characters only and not start with a digit. This is not currently strictly enforced.

  • 英数字(先頭文字として数字は使えない)
  • アンダースコア

「今は厳密には強制していません」というのが微妙なところです。“Defining Fields”にもう少し詳しい説明がありました。

Field names should consist of alphanumeric or underscore characters only and not start with a digit. This is not currently strictly enforced, but other field names will not have first class support from all components and back compatibility is not guaranteed.

英数字とアンダースコア以外の文字も使えないことはないけど、全部のコンポーネントがサポートしているとは限らないよ、ということのようです。

フィールド名に日本語を使うとどういうことが起こるか試してみました。

まずtestという名のコレクションを作成します。

$ curl -s 'http://localhost:8983/solr/admin/collections?action=CREATE&name=test&numShards=1&replicationFactor=1'

「日付」というフィールドを追加します。

$ cat add_field_j.json 
{
  "add-field":{
     "name":"日付",
     "type":"pdate",
     "stored":true }
}
$ curl -s -X POST -H 'Content-type:application/json' -d @add_field_j.json http://localhost:8983/solr/test/schema

APIで「日付」フィールドが存在することを確認できます。

$ curl -s 'http://localhost:8983/solr/test/schema/fields/%E6%97%A5%E4%BB%98'
{
  "responseHeader":{
    "status":0,
    "QTime":0},
  "field":{
    "name":"日付",
    "type":"pdate",
    "stored":true}}

「日付」フィールドに値を持つデータを投入してみます。

$ cat j.json
{"日付":"2019-01-01"}
$ ./post -c test j.json

比較のため、”date”フィールドを追加してデータを投入します。

$ cat add_field_e.json
{
  "add-field":{
     "name":"date",
     "type":"pdate",
     "stored":true }
}
$ curl -s -X POST -H 'Content-type:application/json' -d @add_field_e.json http://localhost:8983/solr/test/schema
$ cat e.json
{"date":"1999-01-01"}
$ ./post -c test e.json

データがどう保持されているか比較します。

$ curl -s 'http://localhost:8983/solr/test/select?q=*%3A*&omitHeader=true'
{
  "response":{"numFound":2,"start":0,"docs":[
      {
        "id":"578b7513-831e-4ef3-bdb9-770268f27a7e",
        "__":["2019-01-01T00:00:00Z"],
        "_version_":1651454167605051392},
      {
        "date":"1999-01-01T00:00:00Z",
        "id":"892eb3b5-a648-45a5-80c1-5b975e8ebc47",
        "_version_":1651454169922404352}]
  }}

“date”の方は特に問題ありません。「日付」フィールドは無く”__”というフィールドに値が格納されています。値が配列になっていることから、「日付」フィールドの定義とは異なるフィールドとして扱われていることが分かります。何か別のダイナミックフィールドのルールにヒットしたようです。

当然検索もできません。

$ curl -s 'http://localhost:8983/solr/test/select?q=%E6%97%A5%E4%BB%98%3A%5B*%20TO%20*%5D&omitHeader=true'
{
  "response":{"numFound":0,"start":0,"docs":[]
  }}
$ curl -s 'http://localhost:8983/solr/test/select?q=date%3A%5B*%20TO%20*%5D&omitHeader=true'
{
  "response":{"numFound":1,"start":0,"docs":[
      {
        "date":"1999-01-01T00:00:00Z",
        "id":"892eb3b5-a648-45a5-80c1-5b975e8ebc47",
        "_version_":1651454169922404352}]
  }}

というわけで、割と基本的なところで躓いてしまいました。結論としては、フィールド名に日本語を使うのも実用としては無理ということになりそうです。