InstantSearch缓存策略

Question

我想实现一个快速，顺利的搜索。搜索的项目不多：~100最多。每个项目都保存着facebook事件所包含的数据量。它们都会出现在初始负载(可能是一个输入卷轴)。数据不会经常变化。不超过100个并发用户。

在上述条件下，搜索结果的最佳缓存策略是什么？

最可伸缩的策略是什么？

Stack

• 正面：努克斯特 (VueJS) + InstantSearch (没有Algolia!)
• 后端:弹簧引导
• 文件化

可能的解决方案

1. 后端上的额外缓存服务(例如reddis、memcached) +使UI在每个搜索操作上切换到服务器。这基本上是在每次击键时都会发送后端垃圾信息。
2. 将所有项目加载到本地存储中(例如维克斯)，并直接在那里搜索。这将增加应用程序的内存占用，并可能导致混乱的加班。
3. 两者的结合？

Answer 1

缓存层绝对不会受伤。用户数量不应该是一个问题。即使是aws上最小的EC2实例也可以轻松地处理这个问题。

您可以尝试在文本框中添加一点延迟，这样并不是每次击键都会触发搜索，但可能会给出大约50 of的回旋余地？在搜索栏输入时要试着看看是什么感觉。

对于100个项目，Vuex也可以非常快，只要您不直接将静态资产(如图像)加载到Vuex。~ JSON数据中的100个条目并不多--但如果应用程序突然有10000条条目，它也不会扩展。

我认为最好的情况是：

• Redis缓存，因为很多请求都是非常相似的，甚至相同的。你只需要在缓存有效的时间上找个合适的地方
• 负载平衡您的后端和前端，即根据需要创建更多的停靠映像实例，以便在CPU使用率超过某个阈值时处理请求中的潜在峰值。
• 如果后端不仅仅是搜索，那么将搜索外包给一个专用实例，这样它就不会干扰“常规请求”
• 非常重要的是:为了更快的搜索结果，在数据库中创建索引，尽可能避免完全扫描！
• 如果你的应用程序没有24/7的流量，也许可以考虑变得没有服务器。

编辑：-让api、缓存和数据库彼此靠近，这样实例之间的通信就不必走得太远。