架构设计：什么时候我们需要使用内存存储（如redis）作为数据库的缓存层
Architecture design: when do we need to use in-memory store (like redis) as a cache layer of the database
我目前正在设计一个应用程序，它将使用像 MongoDB 这样的非 SQL 数据库作为数据库。数据库设计将相当简单（CRUD）。
按照设计，读会比较多，有人建议我给数据库加个缓存层。我想知道 MVP 是否真的需要这样做？需要多大的努力？
我认为解决这个问题的最佳方法是进行一些测试，我会这样做，但与此同时，您有什么意见吗？
我在 Redis 缓存方面没有任何具体的个人经验 - 但你的想法是先测试，看看它是否真的是一个问题，这真的很好。
考虑进行“容量和容量规划”练习，您：
- 取预期的用户数。
- 猜猜他们 activity 会做什么。
- 将其转化为对系统实际负载的预测（例如，有多少读取，以及 API 的/方法/组件/表），例如请求的频率以及通常需要移动的数据量。
确保考虑 activity 中的峰值 - 例如“每月销售额”、“周一早上首次登录”或其他任何内容。
然后尝试根据您的预测进行一些实际的性能测试。您应该很快就会看到实际性能如何与预测相比较。这应该足以通知您是否/何时需要缓存。
根据您进行性能测试的方式，您甚至可能会发现性能瓶颈（如果存在）与数据访问无关（缓存不会有帮助）；这不一定有可能，但奇怪的事情已经发生了。
努力的话，不好说。开始进行概念验证可能是个好主意，这样您就可以在它成为问题之前取得一些进展。
我不知道您使用的是什么技术，或者您的架构是什么，但是使用 dependency inversion 将帮助您切换数据提供者，而对它们之上的代码层的影响最小/没有影响。
如果转向使用缓存，请熟悉 caching design patterns，例如后写和直写。
我目前正在设计一个应用程序，它将使用像 MongoDB 这样的非 SQL 数据库作为数据库。数据库设计将相当简单（CRUD）。
按照设计，读会比较多，有人建议我给数据库加个缓存层。我想知道 MVP 是否真的需要这样做？需要多大的努力？
我认为解决这个问题的最佳方法是进行一些测试，我会这样做，但与此同时，您有什么意见吗？
我在 Redis 缓存方面没有任何具体的个人经验 - 但你的想法是先测试，看看它是否真的是一个问题，这真的很好。
考虑进行“容量和容量规划”练习，您：
- 取预期的用户数。
- 猜猜他们 activity 会做什么。
- 将其转化为对系统实际负载的预测（例如，有多少读取，以及 API 的/方法/组件/表），例如请求的频率以及通常需要移动的数据量。
确保考虑 activity 中的峰值 - 例如“每月销售额”、“周一早上首次登录”或其他任何内容。
然后尝试根据您的预测进行一些实际的性能测试。您应该很快就会看到实际性能如何与预测相比较。这应该足以通知您是否/何时需要缓存。
根据您进行性能测试的方式，您甚至可能会发现性能瓶颈（如果存在）与数据访问无关（缓存不会有帮助）；这不一定有可能，但奇怪的事情已经发生了。
努力的话，不好说。开始进行概念验证可能是个好主意，这样您就可以在它成为问题之前取得一些进展。
我不知道您使用的是什么技术，或者您的架构是什么，但是使用 dependency inversion 将帮助您切换数据提供者，而对它们之上的代码层的影响最小/没有影响。
如果转向使用缓存，请熟悉 caching design patterns，例如后写和直写。