入れ子構造の文書

入れ子になった文書をそのままインデックスできると便利なことがあります。たとえば

• 親文書:ブログ本文、子文書:コメント
• 親文書:製品の基本情報、子文書:サイズ違い、色違いなどのバリエーション
• 親文書:音楽プレイリスト、子文書:曲

などです。

Solrで入れ子構造を扱う

Solrは入れ子になった文書を扱うことができますが、そのためにはいくつかの条件と制限があります。

• 親-子の2階層まで
• indexされるがstoreされない root フィールドを持つ。同一の文書に含まれるすべての親要素、子要素は自動的に root フィールドに同じ値を与えられる
• 親階層の文書であることを示すフィールドを持つ。検索時の条件として使う。
• いわゆるスキーマレスの設定が必要。構造の異なる(場合が多い)親と子を同じコア(コレクション)内で扱う必要があるため

例: プレイリスト

以下のようなプレイリスト情報を Solr に与えます。
(_default の configset で core を作っていればスキーマレスでインデックス作成できます)

{
    "id":"list_1",
    "contentType":"playlist",
    "title":"list1",
    "songs":[
	{
	    "id":"song_1",
	    "contentType":"song",
	    "title":"title1",
	    "artist":"artist1",
	    "trackNum":1
	},
	{
	    "id":"song_2",
	    "contentType":"song",
	    "title":"title2",
	    "artist":"artist2",
	    "trackNum":2
	}
    ]
},
{
    "id":"list_2",
    "contentType":"playlist",
    "title":"list2",
    "songs":[
	{
	    "id":"song_3",
	    "contentType":"song",
	    "title":"title3",
	    "artist":"artist3",
	    "trackNum":1
	},
	{
	    "id":"song_1",
	    "contentType":"song",
	    "title":"title1",
	    "artist":"artist1",
	    "trackNum":2
	}
    ]
}

こういう入れ子構造を検索するのに使える Block Join Query Parser が用意されています。

親文書すべて

q={!parent which="contentType:playlist"}

"response":{"numFound":2,"start":0,"docs":[
      {
        "id":"list_1",
        "contentType":["playlist"],
        "title":["list1"],
        "_version_":1630800916686831616},
      {
        "id":"list_2",
        "contentType":["playlist"],
        "title":["list2"],
        "_version_":1630800916689977344}]
  }

子文書の情報もまとめて取得

ChildDocTransformerを利用します。

q={!parent which="contentType:playlist"}
fl=id, title, [child parentFilter="contentType:playlist" childFilter="contentType:song" fl=id,trackNum,title,artist]

"response":{"numFound":2,"start":0,"docs":[
      {
        "id":"list_1",
        "title":["list1"],
        "_childDocuments_":[
        {
          "id":"song_1",
          "title":["title1"],
          "artist":["artist1"],
          "trackNum":[1]},
        {
          "id":"song_2",
          "title":["title2"],
          "artist":["artist2"],
          "trackNum":[2]}]},
      {
        "id":"list_2",
        "title":["list2"],
        "_childDocuments_":[
        {
          "id":"song_3",
          "title":["title3"],
          "artist":["artist3"],
          "trackNum":[1]},
        {
          "id":"song_1",
          "title":["title1"],
          "artist":["artist1"],
          "trackNum":[2]}]}]
  }

「”title2″を含むプレイリスト」

q={!parent which="contentType:playlist"} title:title2
fl=id, title, [child parentFilter="contentType:playlist" childFilter="contentType:song" fl=id,trackNum,title,artist]

"response":{"numFound":1,"start":0,"docs":[
      {
        "id":"list_1",
        "title":["list1"],
        "_childDocuments_":[
        {
          "id":"song_1",
          "title":["title1"],
          "artist":["artist1"],
          "trackNum":[1]},
        {
          "id":"song_2",
          "title":["title2"],
          "artist":["artist2"],
          "trackNum":[2]}
}

部分的に更新するとどうなるか

更新するときは親子関係にある文書をすべてひとまとめにすること、という制限を破るとどうなるか試してみました。

{
        "id":"list_1",
        "title":["list1"],
        "_childDocuments_":[
        {
          "id":"song_1",
          "title":["title1"],
          "artist":["artist1"],
          "trackNum":[1]},
        {
          "id":"song_2",
          "title":["title2"],
          "artist":["artist2"],
          "trackNum":[2]}]
}

というプレイリストの一部分だけを更新してみます。

{
    "id":"song_2",
    "contentType":"song",
    "title":"title22",
    "artist":"artist2",
    "trackNum":2
}

上のようなデータを与えてupdateしても特にエラーにはなりません。

q=title:title2

{
        "id":"song_2",
        "contentType":["song"],
        "title":["title2"],
        "artist":["artist22"],
        "trackNum":[2],
        "_version_":1630801429121728512}]
}

title:title2 という条件で検索してみると id:song_2 単体として見れば更新されていることが分かりますが、実は親子関係は破壊されてしまってます。

q={!parent which="contentType:playlist"}
fl=id, title, [child parentFilter="contentType:playlist" childFilter="contentType:song" fl=id,trackNum,title,artist]

"response":{"numFound":2,"start":0,"docs":[
      {
        "id":"list_1",
        "title":["list1"],
        "_childDocuments_":[
        {
          "id":"song_1",
          "title":["title1"],
          "artist":["artist1"],
          "trackNum":[1]}]},
      {
        "id":"list_2",
        "title":["list2"],
        "_childDocuments_":[
        {
          "id":"song_3",
          "title":["title3"],
          "artist":["artist3"],
          "trackNum":[1]},
        {
          "id":"song_1",
          "title":["title1"],
          "artist":["artist1"],
          "trackNum":[2]}]}]
}

検索実行時にJOINする方法との比較

この記事でご紹介したのは入れ子構造のままインデックスする方法です。それとは別に、親文書と子文書を別々のコア(コレクション)に分けて検索時にJOINする方法もあり、パフォーマンスと扱いやすさとのトレードオフが存在します。

• 入れ子のまま扱う: 親子関係の情報自体をインデックスするのでパフォーマンス面で有利だがその分制限強め
• 検索時JOIN: パフォーマンス面では不利だが柔軟

Tweet