Azure 认知搜索能否用作某些数据的主数据库？

Question

Microsoft 将 Azure Search 推广为“云搜索”，但不一定说它是“数据库”或“数据存储”。它没有说它是大数据。

可以/应该将 Azure 搜索用作某些数据的主数据库吗？或者是否应该在 Azure 搜索中始终存在一些“主”数据存储以用于搜索目的？

如果是这样，在什么情况下/什么场景下使用 Azure 搜索作为主数据库有意义？

Answer 1

虽然我们通常不推荐它，但在以下情况下，您可以考虑使用 Azure 搜索作为主存储：

1. 您的应用可以容忍一些数据不一致。 Azure 搜索最终是一致的。
   • 索引数据时，不能立即查询。
   • 目前没有控制对索​​引中同一文档的并发更新的机制。
   • 使用搜索查询读取数据时，分页不基于任何类型的快照，因此您可能会丢失或重复文档。
2. 您无需读出索引的全部内容。 Azure 搜索中的分页依赖于 $skip 参数，该参数当前上限为 100000。对于大于 100000 个文档的索引，读取所有数据可能非常棘手。您需要选择一些字段进行分区，并且您的读取没有一致性保证。
3. 如果意外删除，您可以放心丢失数据。截至撰写本文时，Azure 搜索不支持备份/恢复。如果您不小心删除了数据，则需要从其原始来源重新编制索引。
4. 您不需要对索引定义进行太多更改。目前，从索引中修改或删除字段需要重新索引所有数据（您可以添加新字段而无需重新索引）。如果 Azure 搜索是您的主要存储，您唯一的选择可能是尝试将旧索引中的所有数据读取到新索引中，这会受到上述所有关于一致性的限制，$skip 等。
5. 应用程序的查询需要与 Azure 搜索提供的功能相匹配。 Azure 搜索支持全文搜索、分面和 OData 过滤器语言的子集，但不支持索引之间的连接或任意聚合。如果您的应用需要不同于 Azure 搜索提供的查询功能，则应考虑使用另一种 NoSQL 解决方案，例如 Azure Cosmos DB。
6. 您的应用程序可以容忍高写入延迟。 由于它是搜索引擎而不是通用数据库，因此 Azure 搜索针对查询性能（尤其是全文搜索查询）进行了大量优化。这是以降低写入性能为代价的，因为每次写入都需要大量工作来索引数据。特别是，通过将索引操作批处理在一起（批处理最多可以包含 1000 个索引操作），您将获得最佳的写入吞吐量。一次将一个文档写入索引会导致吞吐量大大降低。

请注意，为了可管理性和易用性，我们希望在未来改进 Azure Search 的许多领域，但将 Azure Search 打造成通用 NoSQL 数据库从来都不是我们的目标。