Question

我们有兴趣将DocumentDb用作许多数据源的数据存储，因此我们正在运行快速POC以确定它是否符合我们正在寻找的标准。

我们渴望提供的一个领域是预见某些领域的搜索功能。传统上使用SQL LIKE语法提供这些语法，目前似乎不支持这种语法。

在线搜索我看到有人在谈论集成Azure搜索，但对于这样一个简单的用例来说，这似乎是一种非常昂贵的机制。

我也看到人们提到使用UDF，但这似乎需要整个收集扫描，从性能角度来看这是不切实际的。

有没有人有其他建议？我考虑过的一件事是，每次插入文档\更新\删除时，只使用SQL表并启动更新？

Answer 1

DocumentDB支持STARTSWITH和范围索引以支持前缀/前瞻搜索。

您可以根据用户在文本框中输入的内容逐步进行以下查询：

SELECT TOP 10 * FROM hotel H WHERE STARTSWITH(H.name, "H")
SELECT TOP 10 * FROM hotel H WHERE STARTSWITH(H.name, "Hi") 
SELECT TOP 10 * FROM hotel H WHERE STARTSWITH(H.name, "Hil")
SELECT TOP 10 * FROM hotel H WHERE STARTSWITH(H.name, "Hilton")

请注意，您必须使用range index为这些查询配置集合或路径/属性。您可以扩展此方法以处理其他情况：

要以不区分大小写的方式进行查询，您必须存储搜索属性的小写形式，并使用该形式进行查询。

Answer 2

我遇到了类似的情况，需要快速查找，作为用户输入的搜索词。

我的情况是，可能有数千个并发用户正在执行此类查找;在负载下进行测试时，为了避免饱和和限制，我们发现在我们的特定情况下，我们必须将DocumentDB请求单元（RU）吞吐量增加到对我们来说不具有财务可行性。

我们认为DocumentDB最适合用作持久存储，并且“完全”用于存储。数据检索 - 这个角色执行得非常好 - 而小型ElasticSearch集群执行的角色它是为text search，faceted search，weighted search，{而设计的{1}}，与您的问题最相关，stemming和autocomplete analyzers。

类型提前查询，索引创建，自动完成分析器和查询时间的主题在您键入时搜索＆＃39;在ElasticSearch中可以找到here，here和here

您计划拥有多个数据源的事实也可能使ElasticSearch集群方法更具吸引力，以聚合搜索数据。

我使用Azure市场中可用的Bitnami模板来创建相对较小的实例，最重要的是，这使我可以将群集放在与其他组件相同的虚拟网络上，从而大大提高了性能。

成本低于Azure搜索（在引擎盖下使用ElasticSearch）。

请继续搜索azure DocumentDb中的文档字段

2 个答案: