カテゴリー: テクノロジー

前回の記事に書いたように、compositeIdによるドキュメントルーティングを採用した場合、compositeIdのハッシュ値のどの範囲をどのシャードが担当するのかはSolrの管理画面で確認することができます。ただし、実際のハッシュ値を知ることは実はできません。

簡単なテストプログラムを書いて、compositeIdのハッシュ値がどのように計算されるのかを確認してみました。

まずは単独のIDでハッシュを計算してみます。

$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '1234'
id = 1234
hash = 721c5dc3
$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '中央区'
id = 中央区
hash = a812f493
$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '公園'
id = 公園
hash = eb2b06c4

IDを組み合わせてみます。

$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '中央区!1234'
id = 中央区!1234
hash = a8125dc3
$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '中央区!公園!1234'
id = 中央区!公園!1234
hash = a82b5dc3

8ビットで16進数2桁、16ビットで16進数4桁です。
「中央区!1234」の場合は16ビット:16ビットになるので
「中央区(a812f493)」の上位4桁
「1234(721c5dc3)」の下位4桁
でa8125dc3になっていることが分かります。
「中央区!公園!1234」の場合は8ビット:8ビット:16ビットなので
「中央区(a812f493)」の上位2桁
「公園(eb2b06c4)」の3桁目と4桁目
「1234(721c5dc3)」の下位4桁
でa82b5dc3となります。

さらにビット数を指定してみます。

$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '中央区/4!公園/4!1234'
id = 中央区/4!公園/4!1234
hash = ab1c5dc3
$ java -cp .:solr-solrj-8.1.0.jar CompositeIdTest '中央区/4!公園!1234'
id = 中央区/4!公園!1234
hash = ab2c5dc3

「中央区/4!公園/4!1234」の場合は4ビット:4ビット:24ビットなので
「中央区(a812f493)」の上位1桁
「公園(eb2b06c4)」の2桁目
「1234(721c5dc3)」の3桁目以降
でab1c5dc3となります。
「中央区/4!公園!1234」の場合に無指定の「公園」の扱いがどうなるか興味があったのですが、2階層の場合はデフォルト8ビットなので「中央区/4!公園/8!1234」と同じになるようです。
「中央区(a812f493)」の上位1桁
「公園(eb2b06c4)」の2,3桁目
「1234(721c5dc3)」の4桁目以降
でab2c5dc3となります。

簡単なプログラムではありますが、特定のレコードがどのシャードに配置されているのかを確認したい場合に便利に使えそうです。

Tweet

はじめに

SolrのcompositeIdを使ったドキュメントルーティングではシャードキーを複数指定することができます。シャードキーを複数指定した場合の動作をちゃんと考えたことが無かったので調べてみました。

compositeIdを使ったドキュメントルーティング

compositeIdを使ったドキュメントルーティングではドキュメントIDとシャードキーから計算されたハッシュ値に基づいて、インデッ クス先のシャードが決まります。シャードキーが指定されなければドキュメントIDのハッシュだけが使われます。

1レベルのシャードキー

シャードキーを指定する場合、ドキュメントIDのフィールドを以下のように記述します。
“シャードキー!ドキュメントID”
以前サンプルに利用した大阪市の施設情報のデータの場合、区名に基づいてシャードを分けるには
“中央区!1234”
のようにドキュメントIDのフィールドを指定します。
こうすることで、同じ区の施設データは必ず同じシャードに配置されるようにインデックスされます。

2レベルのシャードキー

2段階目のシャード分けの条件として施設タイプを使うとすると、ドキュメントIDの指定の仕方は以下のようになります。
“中央区!官公庁!1234”
こう書けるところまではドキュメントを読めば書いてあります。ではこう書いた場合に具体的にはどのような配置になるのでしょうか。

ドキュメントIDのハッシュとシャードの対応付け

ハッシュは32ビットです。00000000からffffffffまでの値をシャード数に応じて均等に区分けします。たとえばシャード数が8の場合、以下のように分けられます。

8等分なので上位3ビットで分類するわけです。

シャードキーが指定されたときにハッシュがどう計算されるのか

こちらの記事によると、
シャードキーが1つの場合
ハッシュの上位16ビット:シャードキーのハッシュから
ハッシュの下位16ビット:ドキュメントIDのハッシュから

シャードキーが2つの場合
ハッシュの上位8ビット:シャードキー1のハッシュから
ハッシュの次の8ビット:シャードキー2のハッシュから
ハッシュの下位16ビット:ドキュメントIDのハッシュから
となるようです。

シャードキーを2つ指定したとしても、最上位の8ビットをシャードキー1が占めているため、シャード数が256より小さい限りはシャードキー2は影響を与えることができません。

実際に8シャードのコレクションに2パターンのデータを投入して、シャード毎のレコード数をカウントしてみました。シャードキーが1つの場合も2つの場合も同じになっていることが分かります。

$ head -3 data1.json
[
{"id":"住之江区!158","type":"官公庁","area":"住之江区","name":"軽自動車検査協会大阪主管事務所","address":"住之江区南港東3-4-62"}
{"id":"住之江区!157","type":"官公庁","area":"住之江区","name":"大阪陸運支局なにわ自動車検査登録事務所","address":"住之江区南港東3-1-14"},
$ curl 'http://localhost:8983/solr/compositeid/update?commit=true&indent=true' --data-binary @data1.json -H 'Content-Type: application/json'
$ for i in {1..8}; do curl -s "http://localhost:8983/solr/compositeid/select?q=*:*&rows=0&shards=shard${i}"|jq '.response.numFound'; done
580
509
1471
1203
2092
761
545
2077

$ head -3 data2.json
[
{"id":"住之江区!官公庁!158","type":"官公庁","area":"住之江区","name":"軽自動車検査協会大阪主管事務所","address":"住之江区南港東3-4-62"},
{"id":"住之江区!官公庁!157","type":"官公庁","area":"住之江区","name":"大阪陸運支局なにわ自動車検査登録事務所","address":"住之江区南港東3-1-14"},
$ curl 'http://localhost:8983/solr/compositeid/update?commit=true&indent=true' --data-binary @data1.json -H 'Content-Type: application/json'
$ for i in {1..8}; do curl -s "http://localhost:8983/solr/compositeid/select?q=*:*&rows=0&shards=shard${i}"|jq '.response.numFound'; done
580
509
1471
1203
2092
761
545
2077

ビット数の制限付きでシャードキーを指定する

シャードキーと共にビット数を指定することもできます。たとえば
“中央区/2!官公庁/14!1234”
とすると、
ハッシュの上位2ビット:区名のハッシュから
ハッシュの次の14ビット:施設タイプのハッシュから
ハッシュの下位16ビット:ドキュメントIDのハッシュから
となります。
2ビットということは、区名により4つに分類されるということです。
たとえば8シャード用意されている場合、特定の区は特定の2シャードのどちらかに配置されることになり、そのどちらになるのかは施設タイプにより決定される、という訳です。

このパターンで先程同様にデータを投入すると、シャードごとのレコード数が大きく変化したことが分かります。

$ head -3 data3.json
[
{"id":"住之江区/2!官公庁/4!158","type":"官公庁","area":"住之江区","name":"軽自動車検査協会大阪主管事務所","address":"住之江区南港東3-4-62"},
{"id":"住之江区/2!官公庁/4!157","type":"官公庁","area":"住之江区","name":"大阪陸運支局なにわ自動車検査登録事務所","address":"住之江区南港東3-1-14"},
$ curl 'http://localhost:8983/solr/compositeid/update?commit=true&indent=true' --data-binary @data4.json -H 'Content-Type: application/json'
$ for i in {1..8}; do curl -s "http://localhost:8983/solr/compositeid/select?q=*:*&rows=0&shards=shard${i}"|jq '.response.numFound'; done
578
511
1414
1260
1572
1281
1390
1232

それほど大規模なシステムではない場合、このように少ないビット数で制限を掛けるやり方が、現実的なシャードキーの利用方法になるでしょう。

Tweet

今回は小ネタです。

先日、1GB近くある巨大なJSONファイルをSolrに投入する機会がありました。とあるシステムからダンプしたデータで、以下のような形になっています。

[{"id":"10001","name":"名前1","description":"説明文1","timestamp":"2018-01-01 12:00:00"},{"id":"10002","name":"名前2","description":"説明文2","timestamp":"2018-01-02 12:00:00"},{"id":"10003","name":"名前3","description":"説明文3","timestamp":"2018-01-03 12:00:00"},{"id":"10004","name":"名前4","description":"説明文4","timestamp":"2018-01-04 12:00:00"},{"id":"10005","name":"名前5","description":"説明文5","timestamp":"2018-01-05 12:00:00"},...]

要するに、改行のない巨大な1行のテキストファイルです。
SolrにJSONファイルをPOSTしてインデックスを作成させることはできますが、1GBはちょっと大きすぎるので、分割することを考えました。

1行1レコードになっていれば話は簡単で、適当な行数で分割してからJSONの配列になるように加工すればいいだけのことですが、全部が1行になっているのでそういう訳にはいきません。

スクリプト言語でJSONを読み込んで分割することも考えましたが、JSON全体を一括で読み込んで処理するタイプのJSONパーサーでは1GBを扱うのは辛いものがあります。SAXタイプのJSONパーサーを探さないといけないかなあと考えているうちに、jq コマンドを使うのがいいんじゃないかと思い当たりました。

$ jq '.[]' sample.json
{
  "id": "10001",
  "name": "名前1",
  "description": "説明文1",
  "timestamp": "2018-01-01 12:00:00"
}
{
  "id": "10002",
  "name": "名前2",
  "description": "説明文2",
  "timestamp": "2018-01-02 12:00:00"
}
{
  "id": "10003",
  "name": "名前3",
  "description": "説明文3",
  "timestamp": "2018-01-03 12:00:00"
}
{
  "id": "10004",
  "name": "名前4",
  "description": "説明文4",
  "timestamp": "2018-01-04 12:00:00"
}
{
  "id": "10005",
  "name": "名前5",
  "description": "説明文5",
  "timestamp": "2018-01-05 12:00:00"
}

一番外の配列を外して各レコードを取り出すことはできました。1レコード1行になっていると加工しやすいので-cオプションを指定します。

$ jq -c '.[]' sample.json
{"id":"10001","name":"名前1","description":"説明文1","timestamp":"2018-01-01 12:00:00"}
{"id":"10002","name":"名前2","description":"説明文2","timestamp":"2018-01-02 12:00:00"}
{"id":"10003","name":"名前3","description":"説明文3","timestamp":"2018-01-03 12:00:00"}
{"id":"10004","name":"名前4","description":"説明文4","timestamp":"2018-01-04 12:00:00"}
{"id":"10005","name":"名前5","description":"説明文5","timestamp":"2018-01-05 12:00:00"}

ここまでくれば後は簡単で、1000行程度ずつ読み込んでまとめてPOSTするスクリプトを作成して無事に投入することができました。

Tweet