必要なのは、データベース読み取り用のスクリプト、SolrへのPOST用スクリプト、そしてその間に配置する変換用のフィルターだけです。
これらを書くだけなら、クラウド環境でDIHを動かす方法をあれこれ模索するより、はるかに少ない時間と労力で済むこともあります。

― Dima

そう、それこそ昔ながらのETLですね。
私の解決策は、データを1ドキュメントあたり1つのJSONオブジェクトとしてダンプし、必要に応じて変換ステップを挟み、それからスキーマ非依存のマルチスレッドPythonローダーでSolrに読み込むというものでした。
このマルチスレッドローダーは、DIHよりもはるかに高速に動作しました。

この方法は、再インデックスや失敗時の再実行にも簡単に対応できます。

Solr 1.3の時代、DIHが登場する前には、データベースから取得してSolrに投入するJavaプログラムを自作していました。
そのときも多少の変換処理をしていて、主にビューと整合性の取れた形でキューに追加できるようにしていました（当時はNetflixでの話です）。

wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)

DIH（Data Import Handler）はやめた方がいいと私は思います。
私たちは実際にやめて、とても良かったと感じています。
処理が速くなり、柔軟性が増し、メンテナンスもしやすくなりました。

以下は、私たちが行った内容です。

私たちはDIHを使ってOracleデータベースにSQLクエリを実行し、その結果をメインの検索用コア（4,000万件の書籍タイトル）にインポートしていました。
自作のスケジューラを使ってDIHを一日に何度も実行し、Oracleからの更新を取り込んでいましたが、同時に複数のDIHを動かすのは非常に危険だったため、セマフォを使って同時実行を防いでいました。

しかし、そういった仕組みはすべて捨てて、「index-titles」というツール（名前の通りの単純なもの）に切り替えました。
このツールは、Oracleに対して基本的に同じクエリを実行し、結果を1回につき5,000件ずつ適切なJSON形式に整形して /core/update にPOSTします。そしてすべてのインポートが完了したら、/core/update?commit=true に最終POSTを送ってコミットを実行します。
だいたい、1回の実行で10万件ほどのタイトルを更新します。これを1日に何度か行います。

この方法には多くの利点があります：

1. インデックス作成プログラムがSolrにデータを「プッシュ」する方式の方が、はるかに柔軟です。
   　Oracleクエリを実行できて、SolrにPOSTできるマシンであれば、どこでもインデクサーを実行できます。

2. Solrが直接Oracleと通信しなくてよくなります。
   　これが移行を決めた一番の理由でもあります。私たちはローカルハードウェアからAzureへ移行しており、Solrをコンテナ化したかったのです。
   　SolrにOracleクライアントをインストールせずに済ませたかったのですが、今はインデクサーがOracleに接続するため、Solr自身はデータの出所をまったく気にしなくてよくなりました。

2a) SolrをOracleに対応させたカスタムビルドを作らなくてよくなったので、プレーンなDockerコンテナをそのまま使えるようになりました。

1. index-titlesを複数インスタンス動かせば、フル再インデックスのスピードが大幅に向上します。
   　たとえば10個のindex-titleインスタンス（必要なら別のマシン上でも可）を起動し、それぞれに全体の1/10ずつを担当させれば、4,000万件の再インデックスも1時間ちょっとで終わります（以前は8時間以上かかっていました）。

2. こうした高速性と柔軟性のおかげで、開発者ごとに自分専用のSolrコアを持たせることも容易になりました。
   　今では、空のコアを含んだDockerコンテナを立ち上げて、1時間でコアのコピーを再インデックスできます。
   　以前はコアのスキーマを変更するのは悪夢のようでしたが、今では他の開発者に影響を与えずに作業できます。

DIHはやめた方がいいです。
確かに最初は少し手間がかかりますが、後になって「やってよかった」と心から思えるはずです。

— Andy

こんにちは、Sarah。

正直に言ってDIHを使い続けることを勧めるのは難しいですが、参考までに言うと、昔のように /lib ディレクトリにJARファイルを配置して設定すれば、まだ使えるのではないでしょうか？
この方法なら、ランタイムでのプラグインデプロイが不要なカスタムイメージには適していて、今でも普通に動くと思います。

それと最近、SolrCloudのコーディネータノード上で動作できるようにする機能を追加しました：
https://github.com/SearchScale/dataimporthandler/pull/62

代替案としてApache Hopを調査したこともありますが、適切な SolrOutputPlugin がないと、正しいペイロードを作成するのが難しく感じました。私自身まだそのプラグインを実装できていません。

--
よろしくお願いします、
Mikhail Khludnev

DIHを動かし続けるためにJARをSolr 9に組み込んで対応できたという人たちの話を聞いて、私も再度取り組んでみることにし、必要なJARを組み込んだカスタムSolrイメージを最終的に作成しました。
Solr 8をベースにしたイメージでそれはうまく動作しました。Solr 9ではまだ試していません。
今にして思えば、最初からJARをイメージに組み込む方法を試すべきだったと思います。
長期的には別の解決策が必要だとは思いますが、ひとまず何かが動いてくれてほっとしています。

コーディネータノードについても見てみます。アドバイスありがとうございます。

— Sarah

私たちの間では少し齟齬があって、DIHに対して最小限のサポートを提供している人たちが、実際にそれを導入・利用しているわけではないという点があります。
DIHを実際に使っているユーザーの方々が、バグ修正やプラグインの保守にもっと貢献してくれたら素晴らしいことです。

DIHは、Solr本体から分離されたことで、それを積極的に使っている人たち自身が開発や改良を推進できる、健全なコミュニティを作るための基盤になったのです！

私はDIHは非常に強力な機能だと思っていますが、それを支えるメンテナーが必要なのです！

Eric Pugh | ファウンダー | OpenSource Connections, LLC

約1年前、私たちも同じような状況にありました。Solr v7を使用し、組み込みのDIHを使っていました。

そこからSolr v9.4にアップグレードし、SearchScaleのGitHubリポジトリにあるContribパッケージを使ってDIHも更新しました。このアップグレードは非常にうまくいきました。

（当時Solr v9.5はすでにリリースされていましたが、2024年初頭の時点では、SearchScaleのDIHの最新版はv9.4向けでした。）

DIH定義の更新は必要でした。具体的には、それまで使っていたJavaScriptトランスフォーマーを削除し、それらの処理をSQLやSolrの組み込みトランスフォーマーに書き直しました。というのも、SearchScaleのContribパッケージはJavaScriptトランスフォーマーに対応していなかった（あるいは現在も対応していない）からです。

あなたが言及されていたカスタムコードの問題については詳しくありませんが、Solr v9でもDIHは問題なく使えるということは確かです。実際、SearchScaleでは現在v9.6およびv9.7向けのリリースも出ています。v9.4でのアップグレード経験を踏まえれば、v9.6やv9.7でもDIHは問題なく動くはずです。

ただし、最近になって、Solrインデックスをほぼリアルタイムで更新する必要があるユースケースが発生しました。
私たちのDIHの使い方（基本的に毎晩すべてのSolrコアを再インデックスする方式 — 最悪でも数分で終わるため、これまでは問題ありませんでした）は、リアルタイムな更新には向いていません。
そこで、DIHの使い方を作り直すよりも、ETLに基づいたインポーターに切り替える方がずっとシンプルで、かつDIHアドオンへの依存もなくなるという利点がありました（他の方も同様のことをこのスレッドで言及されています）。

※強調しておきたいのは、SearchScaleのDIHアドオン自体に何の問題もなかったということです。移行の動機は、
(a) DIHが常に最新のSolrバージョンに対応しているわけではないこと、
(b) システムの構成要素（moving parts）を減らしたいという一般的な理由です。

結局のところ、SearchScale DIHは非常にうまく動いていましたが、もし1年前に未来が見えていたなら、私たちはDIH更新をスキップして、最初からETL／インポーターに切り替えていたと思います。
したがって、私たちの経験に基づくと、他の方々と同様に、DIHをやめて独自のインポーターを実装することをお勧めします。全体としてその方が手間は少なくて済むと確信しています。

— Andrew Witt

シニアソフトウェアエンジニア II

もしかすると JesterJ を試してみるのも良いかもしれません。
データベースコネクターも備わっており、ぜひ一度試してみてほしいです。

https://github.com/nsoft/jesterj

質問やフィードバックがある場合は、ディスカッションフォーラムやIssue投稿、Discordチャンネルも用意されています。

※念のためお伝えしておくと、JesterJの大部分は私が書きました。ただし、JDBCコネクターは他の方の貢献です :)

http://www.needhamsoftware.com (work)