英文:
Should I keep cached data in memory for a webapp?
问题
我有一个保存产品的数据库。
还有一个类别列表。
每个产品都属于一个类别。
当产品列表更新时，我会运行一个名为updateProductsCategories()的函数，该函数查询数据库，计算每个类别中的产品数量，并返回一个类似于以下的列表：
食品：20
饮料：74
夹克：15
我在网页的侧边栏中使用这个列表，将类别显示为带有产品数量的链接。
我的假设是，当产品发生变化时，我应该按原样运行updateProductsCategories()，但不是每次加载页面时都调用它，而是将其结果放入内存对象中，并从中获取数据以显示在页面上。
这样，我就不会在每次显示页面时进行不必要的数据库查询，而是使用缓存数据，并且当产品发生变化时，它会始终保持最新。
由于对象不是很大，我认为现在不需要像Redis这样的额外解决方案。
这是一种正确且常见的优化应用程序的方式吗？它会在实际应用中提高速度吗？
英文:
I have a database where products are kept.
There is also a list of categories.
Each product belongs to a category.
When a list of products updates, I run a function updateProductsCategories() that queries database, calculates a number of products in each category and returns a list like this:
Food: 20
Drinks: 74
Jackets: 15
I use this list in a web page sidebar to show categories as links with amount of products in it.
My assumption is that I should run updateProductsCategories() as it is when products change, though not call it each time a page loads, but put its result in an in-memory object and get data from it to show on the page.
That way I will not make unnecessary db queries every time I show the page, but will use cached data and will have it always up-to-date as it's refreshed when products change.
As the object is not large, I don't think I need any additional solutions like Redis now.
Is it a correct and common way to optimize the app? Will it add speed to the app in real world?
答案1
得分: 1
如果：
- 您经常需要统计数据（每个类别中的产品数量）
- 获取统计数据需要相对较长的时间/负载
- 产品更新相对“不频繁”（与您需要统计数据的频率相比）
那么是值得将其保存在内存中的。每次更新产品时，您可以使缓存数据失效，并在需要时再次计算（延迟计算），或者立即计算新的统计数据。
需要注意的事项：
- 访问这些统计数据时应进行同步，因为Web请求是在多个goroutine上提供的。
- 如果您有多个服务器实例，这些统计数据可能会变得不准确；在这种情况下，您确实需要像Redis这样的中央缓存。
英文:
If:
- you need the stats frequently (number of products in each category)
and / or acquiring the stats takes relatively long time / load - and product update is "infrequent" (compared to how frequently you need the stats)
then yes, it is worth keeping it in memory. Every time a product is updated, you may invalidate the cached data and let it calculated again deferred (when it is needed) or calculate the new stats right away, after the update.
Things to keep in mind:
- access to these stats should be synchronized as web requests are served on multiple goroutines
- if you have multiple server instances, these stats might become inaccurate; in this case you do need a central cache like Redis
答案2
得分: 0
这是一种正确且常见的优化应用程序的方式吗？
我认为这种方法更常用于不产生大量数据的简单查询。对于复杂查询或每个用户会话获取的任何内容，最好使用共享缓存。正如@icza所提到的，如果有多个服务器实例，你应该重新考虑你的解决方案是否最优。
这样做会在实际应用中提高速度吗？
在你的情况下，是的，会有一点点提速。
英文:
> Is it a correct and common way to optimize the app?
I believe it is more common to use this approach for simple queries which do not yield high amounts of data. Complex queries, or anything which is fetched per user session is better off in a shared cache. As @icza mentioned, having multiple server instances should make you re-think whether your solution is optimal.
> Will it add speed to the app in real world?
In your case, yes, a little bit.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论