微软将Azure搜索推广为"云搜索"，但并不一定说它是"数据库";或者"数据存储"。它没有说这是大数据。
可以/应该使用Azure Search作为某些数据的主数据库吗?还是应该总是有一些"主要的"?被"复制"的数据存储在Azure搜索中进行搜索?
如果是，在什么情况下/什么情况下使用Azure搜索作为主数据库是有意义的?
虽然我们通常不建议这样做，但您可以考虑使用Azure Search作为主要存储:
-
你的应用程序可以容忍一些数据不一致。 Azure搜索最终一致。
- 索引数据时，不能立即查询。
- 目前没有机制来控制索引中同一文档的并发更新。
- 当使用搜索查询读取数据时，分页不是基于任何类型的快照，因此您可能会丢失或重复文档。
-
您不需要读取索引的全部内容。Azure Search中的分页依赖于
$skip参数，该参数目前的上限为100000。对于大于100000个文档的索引，读取所有数据可能非常棘手。您需要选择一些字段进行分区，并且您的读取没有一致性保证。 - 在意外删除的情况下，您可以丢失您的数据。在撰写本文时， Azure搜索不支持备份/还原。如果你不小心删除了你的数据，你需要从原始来源重新索引它。
-
你不需要改变你的索引定义。从索引中修改或删除字段当前需要重新索引所有数据(您可以添加新字段而无需重新索引)。如果Azure搜索是你的主存储，你唯一的选择可能是尝试将旧索引中的所有数据读取到新索引中，这受到所有上述关于一致性，
$skip等的限制。 - 您的应用程序的查询需要匹配Azure搜索提供的功能。 Azure Search支持全文搜索、facet和OData过滤器语言的一个子集，但它不支持索引之间的连接或任意聚合之类的东西。如果你的应用需要不同于Azure Search提供的查询功能，你应该考虑另一个NoSQL解决方案，比如Azure Cosmos DB。
- 您的应用程序可以容忍高写延迟。因为它是一个搜索引擎，而不是一个通用的数据库，所以Azure search对查询性能进行了大量优化(特别是全文搜索查询)。这是以较慢的写入性能为代价的，因为每次写入都需要大量的工作来索引数据。特别是，通过将索引操作批处理在一起(批处理最多可包含1000个索引操作)，您将获得最佳写吞吐量。每次将一个文档写入索引将导致更低的吞吐量。
请注意，这些都是我们希望在未来改进Azure搜索的地方，以提高可管理性和易用性，但我们的目标从来不是让Azure搜索成为一个通用的NoSQL数据库。