「インデックス」という用語の混同に注意（RDB vs OpenSearch）

RDB と OpenSearch では「インデックス」という同じ言葉が別物を指す。混乱しがちなので整理したメモ。
関連: OpenSearchとActiveRecordの利用用途の違い（検索フロー全体）、
searchkickのレイヤー構造とOpenSearchからActiveRecordへの境界（Rails での実装の内側）

---

1. 結論

RDB の「テーブルに付けるインデックス」とは別物。
OpenSearch の「インデックス」は RDB でいう「テーブル」に近い概念で、
ドキュメント（JSON）が丸ごと入った独立したデータの入れ物。
MySQL のインデックス（B-tree など）を操作しているわけではない。

---

2. 「インデックス」という言葉が2つある

	RDB のインデックス	OpenSearch のインデックス
何者か	テーブルに付ける検索補助データ（B-tree など）	テーブルそのものに相当するデータの入れ物
例えると	本の巻末の索引	本そのもの（索引が最初から織り込まれた本）
単体で存在できる？	できない（元テーブルの付属品）	できる（独立したデータストア）

MySQL:       users テーブル ＋ そこに付けた index
OpenSearch:  users インデックス ＝ ユーザーJSONの集合体そのもの
             （テーブル相当。MySQLとは別サーバーの別データ）

MySQL で ADD INDEX するあの「インデックス」を想像すると混乱するので注意。

RDB ⇄ OpenSearch のおおまかな用語対応

「インデックス」以外もまとめて対応づけると混同しにくい。

RDB	OpenSearch
テーブル (Table)	インデックス (Index)
レコード / 行 (Row)	ドキュメント (Document / JSON)
カラム / 列 (Column)	フィールド (Field)
（テーブルに付ける）インデックス	転置インデックスなどの内部構造（下記4章）

---

3. 実際にやっていること

• 同期時: RDB のレコードを JSON に変換して、
  OpenSearch 側の「ドキュメント置き場」に丸ごとコピーを書き込む
• 検索時: そのコピーの山に対して Query DSL で検索する

つまり「RDB のインデックスを操作している」のではなく、
「RDB とは別の場所にある、検索専用のデータ置き場を読み書きしている」が正確。

---

4. なぜ入れ物を「インデックス」と呼ぶのか

OpenSearch は内部で全フィールドを転置インデックス
（「この単語を含むのはドキュメント3と7」という逆引き表）などの
検索最適構造で保持しているため。

「全カラムに最初から索引が張られた状態でしか存在しないテーブル」
—— だから入れ物自体を「インデックス」と呼ぶ

と捉えると腑に落ちる。

---

5. まとめ

• ❌ RDB のテーブルのインデックスをいじっている
• ⭕ RDB とは別サーバーにある「検索用のテーブル相当の入れ物（＝インデックス）」に、レコードのコピーを出し入れしている

対象は RDB の付属品ではなく、独立した検索用データストアそのもの。