Azure Cosmos DB 是多模型是什么意思？
What does it mean that Azure Cosmos DB is multi-model?
看看新的 Azure cosmos 数据库，我对它的多模型性质有点困惑。具体是指：
a) 相同的底层 database/store 可以同时以多种方式查询，这样我就可以同时使用 gremlin 图形查询和 mongodb api 来对付相同的集合。
- 或 -
b) 这是否意味着您可以在配置 Cosmos DB 时选择不同的模型（图形、键值、列、文档），这就是从那时起数据的存储方式。
小册子听起来像 a)，但是使用 Azure 仪表板创建 cosmos 实例它看起来像 b)，因为您必须在创建时选择模型类型。
此外，文献中提到了柱状数据，但我在创建时没有看到它的选项。
Cosmos DB 是一个单一的 NoSQL 数据引擎，是 Document DB 的演变。当您创建容器 ("database instance") 时，您会为您的用例选择最相关的 API，这会优化您与底层数据存储交互的方式以及数据如何持久保存到该存储中。
因此，根据选择的 API，它会将所需的模型（图形、列、键值或文档）投射到基础存储上。
您只能对一个容器使用一个 API，由于数据的存储和检索方式，不可能使用多个。 API 规定了存储模型 - 图、键值、列等，但它们都映射回引擎盖下的相同技术。
感谢@Jesse Carter 在下方的评论，您似乎可以混合搭配图表和文档SQL APIs.
多机型，多API支持
Azure Cosmos DB 原生支持多种数据模型，包括文档、键值、图形和列族。 Cosmos DB 数据库引擎的核心内容模型基于原子记录序列 (ARS)。原子由一小组基本类型组成，例如字符串、布尔值和数字。记录是由这些类型组成的结构。序列是由原子、记录或序列组成的数组。
数据库引擎可以高效地将不同的数据模型转换和投影到基于 ARS 的数据模型上。 Cosmos DB 的核心数据模型可以从动态类型的编程语言本地访问，并且可以按原样公开为 JSON.
该服务还支持流行的数据库 APIs 进行数据访问和查询。 Cosmos DB 的数据库引擎目前支持 DocumentDB SQL、MongoDB、Azure Tables（预览版）和 Gremlin（预览版）。您可以继续使用流行的 OSS API 构建应用程序，并获得久经考验且完全托管的全球分布式数据库服务的所有优势。
接受的答案遗漏了一些要点。
Cosmos DB是一个NoSQL数据库，但是它是高度分布式的，我们它的存储格式是Atom-Record-Sequence。
为什么这很重要？我们知道它接受 JSON 作为输入和输出格式，这并不意味着 Cosmos 将其数据存储为 JSON，它实际上可以是任何格式。这有助于我们推理 Cosmos 的多模型性：当你根据某个模型执行查询时，你得到的可能是你数据的投影或视图。
@JesseCarter 已经解释过我们可以互换使用 Document API 和 Graph API。上周 Table API 被公开宣布，可能这个 API 也没有太大不同。
Spectologic 的人写了一篇关于 Cosmos 的 Cross-API 用法的不错的博文，并且还指出多模型比内部结构更多的是装饰，唯一真正的例外似乎是 Mongo。 'Switching the portal experience' 章指出了有趣的部分：https://blog.spectologic.com/2017/06/30/digging-into-cosmosdb-storage/
所以也许最终可以归结为 GlobalDocumentDb 与 MongoDb
Cosmos DB 的核心是一个地理分布式数据库，具有自己的 Atom-Record-Sequence 存储引擎和索引。在该基础架构之上，我们能够实现许多不同类型的商店，从使用我们的 SQL API 的 SQL 商店到 Mongo，再到 Cassandra，再到 Gremlin，到 Azure Table 存储的实现等等。
每种不同的存储类型都有自己的数据类型（例如编码数字、日期等的方式），并以自己的方式在我们的存储和索引层中进行编码。随着时间的推移，我们希望我们的 SQL API 能够原生支持其中的大多数数据类型。但目前我们的每种数据库类型都使用自己的编码约定。在 Cosmos DB 中创建帐户时（这是一个组织单位，用户可以有多个帐户）在帐户上指定数据库的 "type"。所以一个人可以拥有一个 Table API 帐户或一个 Mongo 帐户或你有什么。
在某些情况下，可以使用 API Y 访问数据类型为 X 的帐户。例如，可以使用 SQL API 与 Table API 帐号。但在图表之外，这通常不是一个好主意。现在我们以一种特殊的格式为每个 API 编码信息，不同的数据类型不会说彼此的格式。因此，如果使用 SQL API 写入 Table API，最终结果很可能是损坏的数据。
Graph 是个例外，我们努力确保它在所有数据库类型中都能正常工作，我们将来会就此发表更多评论。
因此，如果您确实想使用多重 API 访问，我们强烈建议您只在不使用 "native" API 的 "read only" 模式下这样做对于给定的帐户。换句话说，一定要玩弄 SQL API 从 Table API 读取，只是请不要写到 Table API 帐户起诉 SQL API 客户。
我也对此很感兴趣，想从 API 使用审计的角度了解更多，并通过阅读这些答案学到了更多。
经过实验，事情似乎比原来的答案有了进一步的进展，所以要添加一个现代的旋转...
我已经能够成功地创建一个 Cosmos DB 帐户选择 SQL API，在门户中创建了一个文档然后通过 MongoDB API.
最初的答案表明 MongoDB 是单数出局，无法与其他 API 创建的数据交互。
现在，如果进行更全面的测试，这是否会由于 Yaron () 暗示的数据类型差异而导致文档损坏，以及存储差异是否会导致性能不佳，正如暗示的那样被看到。
出于我的目的，我感兴趣的是审计一个 API 是否足够，在这种情况下它不是因为在一个中创建的数据可以被另一个检索，所以我没有深入测试.
值得注意的是，ARM 模板既不使用 GlobalDocumentDB 也不使用 MongoDB 类型进行部署，但是从门户导出 ARM 模板会导致 GlobalDocumentDB，如果这恰好有所不同的话。
如果您对 CosmosDB 的实现细节感兴趣，可以阅读这篇很久以前的白皮书（假设实现没有改变）。 http://www.vldb.org/pvldb/vol8/p1668-shukla.pdf
TLDR：
- 在底部，CosmosDB 将数据存储在 ARS 中并以 JSON 格式公开它们。
- 数据库引擎默认索引所有文档中的所有字段，因此查询非常灵活。
- 数据库引擎执行类似于 JavaScript 的中间语言，桥接数据库公开的低级存储和 API。
- 由于这种桥接，可以添加更多数据库 API 以支持不同的查询机制（例如 SQL、文档、列式）。
多模型意味着您的数据可以以多种不同的方式存储。目前，CosmosDB 存储 4 种不同类型的数据，它允许您与 API 集成并围绕这些数据库存储类型构建用户体验。
这 4 种类型是 文档数据库或 Mongo 数据库、图形数据库、键值对和宽列或列族。
看看新的 Azure cosmos 数据库，我对它的多模型性质有点困惑。具体是指：
a) 相同的底层 database/store 可以同时以多种方式查询，这样我就可以同时使用 gremlin 图形查询和 mongodb api 来对付相同的集合。
- 或 -
b) 这是否意味着您可以在配置 Cosmos DB 时选择不同的模型（图形、键值、列、文档），这就是从那时起数据的存储方式。
小册子听起来像 a)，但是使用 Azure 仪表板创建 cosmos 实例它看起来像 b)，因为您必须在创建时选择模型类型。
此外，文献中提到了柱状数据，但我在创建时没有看到它的选项。
Cosmos DB 是一个单一的 NoSQL 数据引擎，是 Document DB 的演变。当您创建容器 ("database instance") 时，您会为您的用例选择最相关的 API，这会优化您与底层数据存储交互的方式以及数据如何持久保存到该存储中。
因此，根据选择的 API，它会将所需的模型（图形、列、键值或文档）投射到基础存储上。
您只能对一个容器使用一个 API，由于数据的存储和检索方式，不可能使用多个。 API 规定了存储模型 - 图、键值、列等，但它们都映射回引擎盖下的相同技术。
感谢@Jesse Carter 在下方的评论，您似乎可以混合搭配图表和文档SQL APIs.
多机型，多API支持
Azure Cosmos DB 原生支持多种数据模型，包括文档、键值、图形和列族。 Cosmos DB 数据库引擎的核心内容模型基于原子记录序列 (ARS)。原子由一小组基本类型组成，例如字符串、布尔值和数字。记录是由这些类型组成的结构。序列是由原子、记录或序列组成的数组。 数据库引擎可以高效地将不同的数据模型转换和投影到基于 ARS 的数据模型上。 Cosmos DB 的核心数据模型可以从动态类型的编程语言本地访问，并且可以按原样公开为 JSON.
该服务还支持流行的数据库 APIs 进行数据访问和查询。 Cosmos DB 的数据库引擎目前支持 DocumentDB SQL、MongoDB、Azure Tables（预览版）和 Gremlin（预览版）。您可以继续使用流行的 OSS API 构建应用程序，并获得久经考验且完全托管的全球分布式数据库服务的所有优势。
接受的答案遗漏了一些要点。
Cosmos DB是一个NoSQL数据库，但是它是高度分布式的，我们它的存储格式是Atom-Record-Sequence。
为什么这很重要？我们知道它接受 JSON 作为输入和输出格式，这并不意味着 Cosmos 将其数据存储为 JSON，它实际上可以是任何格式。这有助于我们推理 Cosmos 的多模型性：当你根据某个模型执行查询时，你得到的可能是你数据的投影或视图。
@JesseCarter 已经解释过我们可以互换使用 Document API 和 Graph API。上周 Table API 被公开宣布，可能这个 API 也没有太大不同。
Spectologic 的人写了一篇关于 Cosmos 的 Cross-API 用法的不错的博文，并且还指出多模型比内部结构更多的是装饰，唯一真正的例外似乎是 Mongo。 'Switching the portal experience' 章指出了有趣的部分：https://blog.spectologic.com/2017/06/30/digging-into-cosmosdb-storage/
所以也许最终可以归结为 GlobalDocumentDb 与 MongoDb
Cosmos DB 的核心是一个地理分布式数据库，具有自己的 Atom-Record-Sequence 存储引擎和索引。在该基础架构之上，我们能够实现许多不同类型的商店，从使用我们的 SQL API 的 SQL 商店到 Mongo，再到 Cassandra，再到 Gremlin，到 Azure Table 存储的实现等等。
每种不同的存储类型都有自己的数据类型（例如编码数字、日期等的方式），并以自己的方式在我们的存储和索引层中进行编码。随着时间的推移，我们希望我们的 SQL API 能够原生支持其中的大多数数据类型。但目前我们的每种数据库类型都使用自己的编码约定。在 Cosmos DB 中创建帐户时（这是一个组织单位，用户可以有多个帐户）在帐户上指定数据库的 "type"。所以一个人可以拥有一个 Table API 帐户或一个 Mongo 帐户或你有什么。
在某些情况下，可以使用 API Y 访问数据类型为 X 的帐户。例如，可以使用 SQL API 与 Table API 帐号。但在图表之外，这通常不是一个好主意。现在我们以一种特殊的格式为每个 API 编码信息，不同的数据类型不会说彼此的格式。因此，如果使用 SQL API 写入 Table API，最终结果很可能是损坏的数据。
Graph 是个例外，我们努力确保它在所有数据库类型中都能正常工作，我们将来会就此发表更多评论。
因此，如果您确实想使用多重 API 访问，我们强烈建议您只在不使用 "native" API 的 "read only" 模式下这样做对于给定的帐户。换句话说，一定要玩弄 SQL API 从 Table API 读取，只是请不要写到 Table API 帐户起诉 SQL API 客户。
我也对此很感兴趣，想从 API 使用审计的角度了解更多，并通过阅读这些答案学到了更多。
经过实验，事情似乎比原来的答案有了进一步的进展，所以要添加一个现代的旋转...
我已经能够成功地创建一个 Cosmos DB 帐户选择 SQL API，在门户中创建了一个文档然后通过 MongoDB API.
最初的答案表明 MongoDB 是单数出局，无法与其他 API 创建的数据交互。
现在，如果进行更全面的测试，这是否会由于 Yaron (
出于我的目的，我感兴趣的是审计一个 API 是否足够，在这种情况下它不是因为在一个中创建的数据可以被另一个检索，所以我没有深入测试.
值得注意的是，ARM 模板既不使用 GlobalDocumentDB 也不使用 MongoDB 类型进行部署，但是从门户导出 ARM 模板会导致 GlobalDocumentDB，如果这恰好有所不同的话。
如果您对 CosmosDB 的实现细节感兴趣，可以阅读这篇很久以前的白皮书（假设实现没有改变）。 http://www.vldb.org/pvldb/vol8/p1668-shukla.pdf
TLDR：
- 在底部，CosmosDB 将数据存储在 ARS 中并以 JSON 格式公开它们。
- 数据库引擎默认索引所有文档中的所有字段，因此查询非常灵活。
- 数据库引擎执行类似于 JavaScript 的中间语言，桥接数据库公开的低级存储和 API。
- 由于这种桥接，可以添加更多数据库 API 以支持不同的查询机制（例如 SQL、文档、列式）。
多模型意味着您的数据可以以多种不同的方式存储。目前，CosmosDB 存储 4 种不同类型的数据，它允许您与 API 集成并围绕这些数据库存储类型构建用户体验。 这 4 种类型是 文档数据库或 Mongo 数据库、图形数据库、键值对和宽列或列族。