Azure：用于 Web 缓存的 Redis 与表存储答案

【问题标题】：Azure: Redis vs Table Storage for web cacheAzure：用于 Web 缓存的 Redis 与表存储
【发布时间】：2017-02-27 10:48:58
【问题描述】：

我们目前使用 Redis 作为我们 Web 应用程序的持久缓存，但由于内存和成本有限，我开始考虑表存储是否是一个可行的选择。

我们存储的数据是相当基本的 json 数据，具有明确的 2 部分键，我们将用于表存储中的分区和行键，所以我希望这意味着快速查询。

我很欣赏一个在内存中，一个在内存中，所以表存储会慢一些，但随着我们的扩展，我相信只有一个 CPU 提供来自 Redis 缓存的数据，而使用表存储我们不会遇到这个问题，因为这将取决于我们运行的 Web 服务器的数量。

有没有人有任何以这种方式使用表存储的经验或两者之间的比较。

我应该补充一点，我们以一种非常简单的方式使用 Redis 获取/设置，仅此而已，我们驱逐自己的数据，如果空间不足，则将驱逐留给 Redis。

【问题讨论】：

我知道已经有一段时间了 - 你在这里做了什么？我正在考虑同样的举动。 Redis 的成本（连接和存储）使表存储成为一个非常合理的选择（存储帐户、表和分区允许轻松解决任何限制）
我们使用存储表进行缓存，响应时间通常为个位数毫秒，因此足以满足我们的需求。唯一需要注意的是对存储进行了太多调用，因为它在自动到期、订阅更改等方面没有缓存的正常基础。你需要自己在代码中实现很多。您需要仔细考虑如何对数据进行分组、过期和陈旧，否则会导致过多的存储请求。
但最终，即使过期，它也是对服务的调用。我的代码仍然为缓存对象调用 Redis，然后 Redis 说“不，已过期”，此时我调用底层服务，然后重新填充 Redis。所以我看不出这是如何最小化的。真正的缺点是自动过期，因此您可能使用了无效的存储空间，需要进行一些维护。还有发布/订阅场景——我没有 ATM。（以及非常繁忙的站点的请求限制）。同样，这是 Redis 的一个问题，需要 $$$ 才能升级到更大的服务，所以我在那里看到了类似的问题。
是的，对不起，我的意思是 Redis 原生的任何东西，比如自动过期和 pub/sub 等。关于分组我只是提到它，这样你就可以避免我们在缓存项目方面犯的最初错误粒度导致缓存请求比我们需要的多。我们当时是缓存新手，所以事后看来，对于那些在职业生涯中至少做过一次网站缓存的人来说，它们是明显的设计考虑 :-)

标签： azure caching azure-table-storage azure-redis-cache

【解决方案1】：

这是一个相当广泛/征求意见的问题。但从客观的角度来看，这些是您在决定使用哪个属性时需要考虑的属性：

表存储是一种持久的键/值存储。因此，内容不会过期。您将负责清除数据。
表存储可扩展到 500TB。
Redis 可跨多个节点水平扩展（或通过 Redis 服务扩展）。相比之下，表存储将在一个分区上提供高达 2,000 个事务/秒，跨存储帐户提供 20,000 个事务/秒，并且要扩展，您需要使用多个存储帐户。
与 VM 或 Redis 服务相比，表存储的成本占用显着降低。
Redis 提供 Azure 存储表之外的功能（例如发布/订阅、内容驱逐等）。
表存储和 Redis 缓存均可通过端点访问，API 周围有许多特定于语言的 SDK 包装器。

【讨论】：

您好，感谢您的回复和信息。对我来说，关键是降低成本，但如果这会导致 1000% 的性能下降，那么它就不那么吸引人了。不是真的在寻找意见，而是希望从任何可能尝试过这个或使用过这两种方法的人那里获得信息，并对他们如何比较性能有一个粗略的了解。我的开发可用性相当有限，所以想看看它是否至少可行，然后我将开始进行概念验证练习，但如果它显然不是初学者，我不想浪费宝贵的时间。特别是如果我在使用表格作为网络缓存时忽略了一些关键的事情，Ta。
我真的认为这取决于您进行基准测试，看看哪一个最适合您。性能会因您的应用、VM/应用服务大小等而异。

【解决方案2】：

我找到了一些关于 azure redis 和 table 的材料，希望它可以帮助你。有一个关于 Azure Redis 的video，其中还包括一个演示，用于在视频中从第 50 分钟开始比较 table storage 和 redis。或许可以作为参考。但细节表现取决于你的应用、数据记录等。表存储的定价取决于表存储的容量，请参考details。它比redis便宜得多。

【讨论】：

嗨，这很有趣，因为在示例中他使用 Redis 获取分区和行键，然后进入表存储，考虑到它的 Redis+Table 调用，它仍然非常快，我们将按分区和行查询表存储，并且永远不需要更复杂的查询，这确实使速度不再是一个问题。干杯。

【解决方案3】：

您可能会关心许多差异，包括价格、性能和功能集。并且，数据的持久性和数据一致性。

因为 redis 是一种内存数据存储，所以它非常昂贵。这样您就可以获得低延迟。在此处查看 Azure 的规划常见问题解答，以大致了解吞吐量方面的 redis 性能。 Azure Redis planning FAQ

Redis 确实有一个可选的持久性功能，如果您希望在服务器很少停机时保留和恢复数据，您可以打开该功能。但它没有强大的一致性保证。

Azure 表存储不是缓存解决方案。这是一种持久存储解决方案，并将数据永久保存在某种磁盘上。从历史上看（免责声明，我没有寻找最新和最好的性能数据）它具有更高的读写延迟。它也是严格的键值存储模型（具有两部分键）。值可以具有属性，但有许多严格的限制，例如您可以存储的对象的大小、属性的长度等等。如果您的应用遇到这些限制，这些限制就会变得僵硬和痛苦。

Redis 具有更大的功能集。它可以做键值，但也有许多其他数据结构，如集合和列表，许多应用程序都可以找到从增加的灵活性中受益的方法。

请参阅“Redis 简介”(redis docs) 。

如果您主要倾向于 Azure 技术，则 CosmosDB 可能是另一个可供考虑的替代方案。它非常昂贵，但速度非常快且功能丰富。同时也主要是为了成为一个持久存储。

【讨论】：