[Solr]バックアップの置き場をS3にする

Solr には予め設定しておいたレポジトリにバックアップする機能があります。
レポジトリには以下の種類があります。

  • ローカルファイルシステム
  • HDFS
  • GCS(Google Cloud Storage)
  • Amazon S3

ここではローカルファイルシステムとS3の設定例を見てみます。

LocalFileSystemRepository

バックアップレポジトリの設定は solr.xml に書きます。

<backup>
  <repository name="local_repo" class="org.apache.solr.core.backup.repository.LocalFileSytemRepository">
    <str name="location">solr/backup_data</str>
  </repository>
</backup>

LocalFileSystemRepository の場合、設定項目は location だけです。

以下のようにAPIを利用してバックアップを実行した場合、Solr のインストールディレクトリを $SOLR_DIR とすると $SOLR_DIR/server/solr/backup_data/backup1 にコレクション backup_test のバックアップが作られます。

$ curl 'http://localhost:8983/solr/admin/collections?action=BACKUP&name=backup1&collection=backup_test&repository=local\
_repo'

S3BackupRepository

S3BackupRepository を使うためにはプラグインの設定が必要です。
$SOLR_DIR/server/solr/lib を作成し、dist/solr-s3-repository-8.10.0.jar と contrib/s3-repository/lib/*.jar をコピーして
solrconfig.xml に以下を追加します。

<lib dir="./lib" />                                                                                                     

レポジトリの設定はsolr.xmlに追加します。

<backup>
  <repository name="s3_repo" class="org.apache.solr.s3.S3BackupRepository" default="false">
    <str name="s3.bucket.name">XXXX.splout.co.jp</str>
    <str name="s3.region">us-west-2</str>
  </repository>
</backup>

s3.bucket.name でバケット名を、s3.region でリージョン名を指定します。
その他に S3 のエンドポイントを指定する s3.endpoint、プロキシを設定するための s3.proxy.url, s3.proxy.useSystemSettings \
があります。

上記の設定例の場合、以下のようにAPIを利用してバックアップを実行した場合、s3://XXX.splout.co.jp/backup2 にコレクション backup_test のバックアップが作られます。

$ curl 'http://localhost:8983/solr/admin/collections?action=BACKUP&name=backup2&collection=backup_test&repository=s3_re\
po'

10インチの電子ペーパータブレット BOOX Note Air2

数学の勉強をしていると手書きの機会が多くなります。紙と鉛筆で書きながら考えるというスタイルです。本物の紙を使う場合、あらかじめ用意しておくとか計算が終わった後に捨てるとかが面倒になってくるので、タブレット端末を使うようにしていました。

ただ、タブレット端末にはいろいろな使い途があって家の中のあちこちに持ち歩くため、ぱっと手書きしたいときに手元に無かったりします。そこで、読み書きに特化した電子ペーパータブレットを買って使うことにしました。

購入したのは BOOX Note Air 2 という10.3インチの E-Ink タブレットです。
製品の立ち位置としては、電子書籍リーダー&手書きノートといったところです。
価格はおよそ6万円。

Kindle と大きく異なる特徴は以下の通りです。

  • 画面が大きい
  • Android 11 なのでアプリをインストールして複数の書籍リーダーを使い分けられる
  • ペンデバイスを使って手書きできる

普通のAndroidタブレット(+ペンデバイス)との違いは以下の通り。

  • モノクロ
  • 端末自体はそれなりの処理能力をもっているものの、E-Ink なので画面の書き換えはもっさり。ゲームとか動画閲覧とかは実用できない
  • 軽い
  • バッテリーの保ちが良い
  • 目に優しい

普通の液晶画面が見づらいとか見てて疲れるとか感じたことがない人間としては、どうしても E-Ink でなきゃダメという点は正直ほとんど無く、かなりロマン側に倒した選択ではあります。要は使ってみたかったということで。

画面の表示は綺麗で電子書籍リーダーとしての品質は高いと思います。10インチあるのでPDFの書籍や論文も読みやすい大きさで表示されます。

手書きはスムーズで、書いたときのペン先の感触もとても良い感じです。

計算したり図を描いたりするときにいつも手元にあってすぐに書き始められないと紙の代わりにはなりませんが、Note Air 2 はその条件を満たしてくれます。2ヶ月ほど使った段階では思い切って買ってみて良かったなと思っています。


[Solr]分散検索でどのレプリカに検索リクエストを送るのかを制御する

SolrCloud でシャードに複数のレプリカを作った場合、検索リクエストを処理する際にどのレプリカを優先するのかを shards.preference パラメータで指定できます。

以下の形式で優先順を指定します。
shards.preference=属性1:値1,属性2:値2,…
左側にあるものほど優先度が高くなります。

指定できる属性は以下の通りです。

replica.type

レプリカの種類(PULL, TLOG, NRT)を指定します

replica.location

http://hostname:port から始まる文字列でレプリカの場所を指定します。前方一致でレプリカを選びます。

特殊なケースとして “local” を指定した場合、リクエストを処理するサーバと同じサーバにある Solr インスタンスのレプリカが選ばれます。フィールド数が多い、巨大なフィールドがある、などの理由で検索結果のデータサイズが大きい場合に有効です。特定のレプリカに障害が発生した場合の影響範囲を小さくする効果もあります。

replica.base

優先順位が同じレプリカが存在するときに、それらの間でどれを優先するかを決めるためのルールを指定します。

  • random ランダムに1つ選びます
  • stable:dividend:パラメータ名 指定したパラメータに対応する整数値をレプリカ数で割った余りで決定します
  • stable[:hash[:パラメータ名]] 指定したパラメータに対応する文字列のハッシュ値をレプリカ数で割った余りで決定します。パラメータ名が指定されない場合はメインのクエリである q の値が使われます。

node.sysprop

指定したシステムプロパティの値が同じレプリカが選ばれます。
たとえば同じラックに属する Solr インスタンスが同じ rack プロパティの値を持つように -Drack=rack1 のように設定しておき、検索時に shards.preference=node.sysprop:sysprop.rack を指定すると、リクエストを処理している Solr インスタンスと同じ rack プロパティの値を持つ(=同じラックに属する)レプリカが選ばれます。

replica.leader

リーダーレプリカを優先するかどうかを true または false で指定します。たとえばレプリカが6台ある状態で replica.leader:false が指定されるとリーダー以外の5台が分散検索の対象となります。


VS CODE for the Webを使ってみた

Stack Overflow 2019 Developer Surveyで最も人気のある開発者環境ツールとしてランクインし(wikipedia参照)、2021年現在テキストエディタ戦国時代を制した感のあるVS CODE。個人的にも以前からMicorosoftのアプリケーションでは久々の当たりだなぁと思っていたのですが、2021年10月20日にwebブラウザ版がリリースされました。

ということで少し触ってみたいと思います。

必要なことはURLを叩くだけ

ブラウザを起動して「https://vscode.dev/」にアクセスするだけでエディタが起動。たったこれだけなので割りとガチめにびっくりしますw立ち上がりも一瞬。

そしてサイドメニューの「Open Folder」をクリックするとローカルファイルにアクセスするのがすごい。

Dockerで仮想開発環境を利用してたとしてもローカルにマウントしたファイルを編集するので特に問題なくVS CODE for the Webは活用できるんじゃないでしょうか。

気になる環境設定や拡張機能について

とはいえテキストエディタといえば自分が作業しやすい設定や拡張機能を追加してなんぼというところなので、いくらWeb版があるからといってそこんところどうなの?

・環境設定はローカルストレージなどに保存している模様。一度設定した環境は維持されます
・拡張機能については一部のものだけ利用可能のようです。残念。(日本語化プラグインも未対応)
 PHP系はLINT系(構文チェック)ツールやスニペットなどはほぼほぼ対応中のようです。
 逆にHTML5やJavaScript系は割とある様子。Pythonなんかもちらほらという塩梅。
・「GitHubの機能も統合しているため、リポジトリ、コードスペース、プルリクエストの拡張機能が利用できる。 「github.dev」はWeb用VSCode向けにカスタマイズされたインスタンスで、ログインが自動で行なわれ、.comを.devに変更すればリポジトリを編集できる。とのこと(出典『「Visual Studio Code」がインストール不要に。Webブラウザで動作|PC Watch』)

vimは使えましたw

Setting Syncで同期可能

GithubもしくはMicrosoftアカウントでサインインすればローカルアプリのVS CODEの設定を引き継ぐことができるようです。

詳細はリファレンスで確認することができます。

まとめ

かなり良い線までいってるのですが拡張機能が未対応のものが多いので、Web版をメインに据えるのはまだまだ厳しそうですね。今後の動向に期待したいところ。
VS CODEでは最近、悪意のあるプラグインによるセキュリティが問題になっていたりするので、クラウド上ならセキュリティ対策が最速で対応されそうですし、その辺は価値があるかもしれません。
今のところはサーバーなどを介さずフロントのみで実行できるようなスクリプトを作成するなんかには合っているのでプログラミングのお勉強などで利用するのにはちょうど良さそうです。


SolrCloudにおけるレプリカの種類

ドキュメント数の非常に多いコレクションを扱う場合、複数のシャードを作ってデータを分けることができます。ドキュメントはそれぞれ複数のシャードのどれか1箇所にだけ属します。
シャードは1個以上のレプリカから構成されます。同じシャードに属するレプリカの内容はすべて同じです。シャードのうちどれか一つがリーダーとして選ばれます。

インデックス対象のドキュメントがSolrに送られてきたとき、まずそのドキュメントがどのシャードに属するべきかが決定され、そのシャードのリーダーにドキュメントが送られます。そして同じシャードに属する他のレプリカすべてにリーダーからドキュメントが転送されます。

レプリカにはいくつか種類があります。

NRT(= NearRealTime)

  • デフォルトの設定。トランザクションログを保持しつつ自身のローカルのインデックスの更新も行う。
  • リーダー選出の候補となる。

TLOG

  • トランザクションログの維持はするが、自身ではローカルのインデックス更新は行わない。
  • このタイプのレプリカはコミットを実行する必要が無いのでインデックスの速度向上が見込める。
  • このタイプのレプリカでインデックスを更新するには、リーダーからインデックスをレプリケートする。
  • リーダー選出の候補となる。
  • もしもリーダーに選出された場合には、NRTレプリカと同様に動作する。

PULL

  • トランザクションログの維持もローカルのインデックス更新もせず、リーダーのインデックスのレプリケーションのみを行う。
  • リーダー選出の候補にはならない。

レプリカのうちどれかはリーダーにならなければならないので、シャードのレプリカをすべてPULLだけで構成することはできません。
Solrリファレンスでお薦めされているレプリカタイプの組み合わせは以下の通りです。

すべてNRT

更新のリアルタイム性が必要でありインデックス更新のスループットがそれほど大きくない場合、この組み合わせにする。
特にSoft Commitが必要な場合はNRTしか選択肢が無い。

すべてTLOG

インデックス更新のリアルタイム性が必要でなくシャード内のレプリカが非常に多い場合、すべてのレプリカで更新リクエストを扱えるようにしておきたいと考えるならば、この組み合わせにする。

TLOGとPULLの組み合わせ

インデックス更新のリアルタイム性が必要でなくシャード内のレプリカが非常に多い場合、多少古い検索結果を許容しつつ検索クエリへの応答能力拡大をするにはこの組み合わせにする。