短暂搜索的案例

比如说，你正在一个电子商务网站上为家居装修产品工作，比如钉子、螺丝钉、木头、瓷砖、油灰刀……诸如此类的东西。这些类型的商店（实体店或网上商店）通常销售种类繁多的产品。值得注意的是，当一个人从这样的商店买东西时，以后需要更多同样的东西是很常见的，因为谁知道一个项目需要多少钉子呢？

提供快速且易于使用的购买历史记录对于提供良好的用户体验非常重要，但关键在于细节。一种简单的方法是按逆时间顺序列出物品，但在购买几件物品后，这可能会令人沮丧。客户真正需要的是一种有效搜索单个美国客户的购买历史记录的方法呃。

一种方法可能是保存您曾经储存过的所有产品的列表，并为每个项目关联一个表行，然后在关系数据库系统上进行简单的全文搜索。不幸的是，与真正的全文搜索引擎相比，关系数据库的全文搜索功能往往缺乏。

另一种选择是使用一个真正的搜索引擎，它使用一个包含用户名称、产品名称、描述和购买时间的搜索索引——每个索引都是一个文档。如果您将结果限制为特定用户，那么这将为您提供真正的全文搜索功能。不幸的是，这种方法可能很难实现，因为搜索的索引大小会随着每次购买增加越来越多的单个索引而快速增长，而且每次搜索都需要查询任何用户的每一次购买。让我们来计算一下这个索引有多大:

#顾客群	每位客户平均购买的商品数量	#文档集
500，000	150	75000000年

即使用户数量相对较少，这种类型的索引也会很快失控。当你有500万用户时会发生什么？1500万用户？

这个特性的使用模式非常有趣——在所有用户中，在任何给定的时间，使用情况可能都是相当正常的分布。如果不考虑醒着的时间，你可以假设它不会激增。从侧面考虑，单个用户可能很少接触这个功能。事实上，在大多数情况下，每个用户每周在您的电子商务平台上花费的时间不会超过几分钟。在任何给定的时间，只有一小部分搜索索引被使用。虽然一般的网站搜索应该在任何时候都对所有用户可用，但是购买历史搜索本质上是一个只有登录才能使用的功能。

那么，如果我们可以为每个用户创建一个动态搜索索引会怎么样呢?当用户登录到站点时，购买搜索历史记录将从另一个数据存储填充，然后标记为在特定时间内过期，就像他们的会话一样?如果用户手动注销，您可以安全地删除搜索索引。

这个模式需要一个搜索引擎支持:

• 轻量级索引创建和删除
• 索引到期日
• 快速文件索引

如果你拥有所有这些东西，你会得到什么?让我们重新审视我们的简单数学，但让我们添加一个额外的假设:2%的用户基础在任何给定的时间登录。

500000的2%	每位客户平均购买的商品数量	#文档集
10000活跃用户	150	1,500,000

这一数量的文档比原始策略更易于管理。此外，它根据您网站的实际使用情况而不是累计购买历史进行缩放。因此，如果您的站点变得更加繁忙（通常是好事情)，然后你可以随着业务的增加而扩大购买历史搜索。

由于购买历史很少更改，因此图中的其他数据存储不需要非常复杂也不需要很高的性能——只在用户登录或购买商品时访问它。它可以像平面文件一样简单。

再研究中的短暂性

由于您是在Redis网站上阅读此内容，您可能会想象您可以将此模式用于RedSearch。事实上，RedSearch有几个属性和特性可以很好地与这个用例相匹配。首先，由于RedSearch是一个Redis模块，它继承了Redis本身的大部分性能。与Redis一样，RediSearch首先在内存中，这意味着写入和读取更加平等，而基于磁盘的系统更改或删除数据需要更长的时间。快速将购买历史记录填充到RedSearch中不是性能问题。此外，RedSearch经过优化，可以快速创建索引以及删除或终止索引。

再深入一点，让我们看看如何在每个用户的基础上创建索引:

> FT.CREATE history:user:1234 TEMPORARY 3600 SCHEMA title TEXT description TEXT purchase

创建这个索引唯一不寻常的地方是短暂的论点。这告诉RediSearch将搜索索引设置为临时的，并在指定的3600秒(或任何与会话超时一致的时间)之后删除它。任何时候使用搜索索引，添加/删除文档或查询，重置空闲计时器。一旦时间过期，索引将被删除。另外，请注意索引的名称包含一个用户标识符。

在登录时，索引将被填充英尺加来自其他数据源。这里不需要什么特别的东西，重新搜索将把文档和键作为临时的，没有其他语法。对于大多数文档，添加文档将在低单位毫秒范围内快速完成。这不需要同步完成，因此当用户最初浏览站点时，可以在后台加载购买历史记录。

关于重新搜索，有一点需要重申，特别是在这个多索引上下文中：所有文档名称在所有索引中都应该是唯一的，以防止散列级别的密钥争用诺瑟夫选项英尺加．这将不会存储文档，而只是索引它，仅为您提供文档ID on搜索，尽管这使检索结果的过程变得复杂。

实现搜索功能本身很简单。将用户输入作为搜索．与任何RedSearch实现的唯一区别在于，索引名将以某种方式从用户标识符派生。

当用户显式注销服务时FT.DROP命令删除索引和文档。严格来说，这不是一个必要的操作，因为短暂的索引将自动过期，但使用显式FT.DROP将更快地释放资源。

电子商务之外的短暂搜索

这种特定模式并不局限于电子商务应用程序。当您有一组个性化的文档来搜索特定用户时，这是一个可行的模式。想象一下一个财务门户的发票或账单搜索。每个用户只有少数特定于他们的文档，但搜索体验对于查找特定信息至关重要。与此同时，在一个消息应用程序中，你可能想要搜索你的聊天记录，这也是只有在你与应用程序交互时才需要的，而且这个搜索是特定于单个用户的聊天记录的。

这种模式为用户提供了一种优化体验的方法，而无需创建一个庞大、繁琐的全局索引，该索引的维护和扩展都很困难。此功能取决于创建许多已过期的轻量级索引的能力，以及动态快速索引文档的能力。

要开始使用此模式，请下载在redisearch.io RediSearch或者继续学习reresearch101复述,大学．