SQLとElasticsearchの概念のマッピング

SQLとElasticsearchはデータの整理方法に異なる用語（および異なる意味）を持っていますが、基本的にはその目的は同じです。

では、基本から始めましょう。これらは大まかに次のようになります：

SQL Elasticsearch 説明
column field 両者とも、最も低いレベルでは、データはさまざまなデータ型の名前付きエントリに格納され、1つの値を含みます。SQLではこのエントリをカラムと呼び、Elasticsearchではフィールドと呼びます。

注意すべきは、Elasticsearchではフィールドが同じ型の複数の値（本質的にはリスト）を含むことができるのに対し、SQLではカラムがその型の値を正確に_1つだけ含むことができる点です。
Elasticsearch SQLはSQLの意味をできるだけ保持し、クエリに応じて、複数の値を返すフィールドを拒否します。 |
| row | document | Columnとfieldは単独では存在しません；それらはrowまたはdocumentの一部です。2つはわずかに異なる意味を持ちます：rowは厳密である傾向があり（より多くの強制がある）、documentは少し柔軟または緩い傾向があります（それでも構造を持っています）。 |
| table | index | SQLまたはElasticsearchでクエリが実行される対象です。 |
| schema | 暗黙的 | RDBMSでは、schemaは主にテーブルの名前空間であり、通常はセキュリティ境界として使用されます。Elasticsearchにはそれに相当する概念はありません。しかし、セキュリティが有効になっている場合、Elasticsearchは自動的にセキュリティの強制を適用し、役割が許可されたデータのみを表示します（SQL用語で言うと、そのスキーマ）。 |
| catalogまたはdatabase | clusterインスタンス | SQLでは、catalogまたはdatabaseは互換的に使用され、スキーマのセット、すなわち複数のテーブルを表します。
Elasticsearchでは、利用可能なインデックスのセットはclusterにグループ化されます。意味も少し異なります；databaseは本質的に別の名前空間であり（データの保存方法にいくつかの影響を与える可能性があります）、Elasticsearchのclusterはランタイムインスタンス、または少なくとも1つのElasticsearchインスタンスのセット（通常は分散して実行されます）です。
実際には、SQLではインスタンス内に複数のカタログを持つことが可能ですが、Elasticsearchでは_1つに制限されています。 |
| cluster | cluster（連邦型） | 伝統的にSQLでは、クラスターは複数のcatalogまたはdatabase（上記参照）を含む単一のRDBMSインスタンスを指します。同じ言葉はElasticsearch内でも再利用できますが、その意味は少し明確になっています。
RDBMSは通常、単一のマシン上で実行される単一のインスタンスしか持たないのに対し（分散されていない）、Elasticsearchは逆の方向に進み、デフォルトで分散型でマルチインスタンスです。
さらに、Elasticsearchのclusterは連邦型で他のclusterに接続できるため、clusterは次のようになります：
単一のクラスター::
通常、同じ名前空間内で実行される複数のElasticsearchインスタンスがマシンに分散しています。
複数のクラスター::
それぞれ独自の名前空間を持つ複数のクラスターが、連邦型のセットアップで互いに接続されています（クロスクラスター検索を参照）。 |

概念間のマッピングは正確に1対1ではなく、意味もやや異なりますが、違いよりも共通点が多いことがわかります。実際、SQLの宣言的な性質のおかげで、多くの概念がElasticsearchを通じて透過的に移動でき、2つの用語は今後の資料全体で互換的に使用される可能性があります。