こんにちは、

その質問をしていただきありがとうございます。

計算とストレージの分離は、「data」役割を持つノード、すなわちインデックスをホストするノードに関連しています。

SIP-20は、これらのインデックスを共有ストレージ（S3やGCSなど）に配置し、個々のノードに長期間保存しない方法を提供します。これにより、ノード自体がステートレスとなり（再起動時にディスクの内容をすべて失っても問題なく動作します）、ノードがローカルなストレージを持たなくてもよくなります。役割であるコーディネーターやオーバーシーアはローカルステート（ノードのローカルディスクに保存されたローカルストレージ）を必要としないため、SIP-20はノードをステートレスにします。ノード役割を使用しない場合と同様に、ステートはZooKeeperと共有ストレージバックエンドにのみ維持されます。

特定のノード役割の割り当てが特定のクラスターやユースケースで機能している場合、そのクラスターでSIP-20を採用すると、インデックスのストレージや各アップデートの処理方法（SIP-20なしでは複数のレプリカに分散され、SIP-20では単一のレプリカによって処理され、共有ストレージされる）に変化が生じますが、役割はおそらく変わりません。オーバーシーアやクエリのコーディネートを担当するために推奨されるノードがあり、同じノードのサブセットがインデックスを処理します（ただし、異なる方法で）。

お役に立てれば幸いです。
Ilan

HDFS（およびHDFS-S3コネクタを通じて間接的にS3）を使用した共有ストレージバックエンドの実装はすでにありますよね？

SIP-20の提案では、シャードの1つのコピーが共有ストレージ上に存在し、そのシャードの既存のレプリカまたは将来のレプリカ（リーダーかどうかに関わらず）が同じストレージ領域にアクセスします。

HdfsDirectoryの場合、各レプリカごとに共有ストレージ上にコピーがあります。書き込み時には、通常のSolrCloudのレプリケーション戦略（耐障害性のために複数のレプリカに書き込む）が使用され、ノードがダウンすると、そのレプリカに関連付けられたトランザクションログやリモートで保存されたセグメントから最新の状態を取得するためにノードを再起動する必要があります（または代替ノードを再起動する）。

SolrCloudの耐障害性のために複数のレプリカを維持する哲学と、S3の耐障害性保証が重複（冗長）している点に注意してください。複数のレプリカがS3に個別に保存される場合です。SIP-20は耐障害性を共有ストアに委任します。

基本的に、HdfsDirectoryはリモートローカルノードストレージであり（AWS EBSなどのローカルリモートストレージと冗長ですか？）、SIP-20は計算とストレージの間により強い分離を提案します。

もう1つの大きな違いは、SIP-20では、データがリモートストレージからノードにダウンロードされると、ローカル（エフェメラル）ディスクに存在（キャッシュ）します。これにより、HdfsDirectory実装よりも高速なアクセスが可能になります。HdfsDirectoryはメモリキャッシング（おそらくOSバッファキャッシュ）を使用しますが、ローカルディスクキャッシングはありません。

SIP-20は、SolrCloudの弾力性の実装（スケーリングアップやダウン、ノード間の負荷のバランス調整）やノードのスケーラビリティ（未使用のレプリカのローカルディスク内容を削除し、必要に応じて再ロードする）において、より柔軟性を提供します。

Ilan