【发布时间】：2021-10-13 12:33:11
【问题描述】：
我目前正在设计一个应用程序，它将使用像 MongoDB 这样的非 SQL 数据库作为数据库。数据库设计将相当简单 (CRUD)。
按照设计，读取会很多，有人建议我应该给数据库加一个缓存层。我想知道MVP是否真的需要这样做？会付出多大的努力？
我认为解决这个问题的最好方法是做一些测试，我会这样做，但与此同时，有什么意见吗？
【问题讨论】：
标签： database-design redis architecture
【发布时间】：2021-10-13 12:33:11
【问题描述】：
我在 Redis 缓存方面没有任何具体的个人经验 - 但是你的想法是先测试，看看它是否真的是一个问题，真的很好。
考虑进行“容量和容量规划”练习，您可以：
- 获取预期的用户数。
- 猜猜他们将进行的活动类型。
- 将其转化为对系统实际负载的预测（例如读取次数，以及使用哪些 API/方法/组件/表），例如请求的频率以及通常需要移动多少数据。
确保您考虑到活动高峰 - 例如“月销售额”、“星期一早上首次登录”或其他任何内容。
然后尝试根据您的预测进行一些实际的性能测试。您应该很快就会看到实际性能如何与预测相匹配。这应该足以通知您是否/何时需要缓存。
根据您进行性能测试的方式，您甚至可能会发现性能瓶颈（如果存在）与数据访问无关（缓存无济于事）；这不一定是可能的，但奇怪的事情发生了。
在努力方面，我不能说。启动概念验证可能是一个好主意，这样您就可以在它成为问题之前取得一些进展。
我不知道您使用的是什么技术，或者您的架构是什么，但使用 dependency inversion 将帮助您切换数据提供者，而对它们上面的代码层影响最小/没有影响。
如果转向使用缓存，请熟悉 caching design patterns，例如 write-behind 和 write-through。
【讨论】：