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

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

我知道一个在内存中，一个在外，所以表存储会慢一些，但随着我们的扩展，我相信只有一个CPU从Redis缓存中提供数据，而使用表存储，我们不会有这个问题，因为这将取决于我们运行的web服务器的数量

有没有人有过以这种方式使用表存储的经验，或者有没有人比较过这两种方法

---

我应该补充一点，我们以一种非常简单的方式使用Redis获取/设置，除此之外，我们会逐出我们自己的数据，如果没有这一点，则在空间不足时将逐出留给Redis。

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

• 表存储是一种持久的键/值存储。因此，内容不会过期。您将负责清除数据
• 表存储可扩展到500TB
• Redis可以跨多个节点水平扩展（或者，可以通过Redis服务进行扩展）。相比之下，表存储在一个分区上最多可提供2000个事务/秒，在整个存储帐户上可提供20000个事务/秒，要扩展到更大的范围，您需要使用多个存储帐户
• 与VM或Redis服务相比，表存储的成本占用要低得多
• Redis提供了Azure存储表以外的功能（如发布/订阅、内容逐出等）
• 表存储和Redis缓存都可以通过端点访问，API中有许多特定于语言的SDK包装

---

我找到了一些关于azure redis和table的度量标准，希望能对您有所帮助。关于azure redis的视频中还有一个演示，在视频的第50分钟左右可以比较table storage和redis。 或许可以作为参考。但具体性能取决于应用程序、数据记录等。

---

表存储的定价取决于表存储的容量，请参阅。它比我的便宜多了

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

因为redis是内存中的数据存储，所以它非常昂贵。这是为了降低延迟。查看Azure的规划常见问题解答，从吞吐量的角度全面了解redis的性能。

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

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

Redis拥有更大的功能集。它可以提供关键价值，但也有一系列其他数据结构，如集合和列表，许多应用程序可以找到方法从增加的灵活性中获益

请参阅“Redis简介”

---

COSMODB可能是另一个可供选择的选择，如果你主要倾向于Azure技术。它非常昂贵，但速度很快，功能丰富。同时主要是作为一个持久性存储。

您好，感谢您的回复和信息。对我来说，关键是降低成本，但如果性能达到1000%，那么它的吸引力就会降低。不是真的在寻求意见，而是希望从任何可能尝试过这一方法或同时使用这两种方法的人那里获得信息，并大致了解他们在性能方面是如何进行比较的。我的开发可用性是相当有限的，所以我想看看它是否至少可行，然后我将开始一个概念验证练习，但如果它是一个明确的非初学者，我不想浪费宝贵的时间。特别是如果在使用表作为web缓存时我忽略了一些关键的事情，Ta。我真的认为这取决于您的基准测试，看看哪一个最适合您。性能将根据您的应用程序、VM/应用程序服务大小等而有所不同。您好，这很有趣，因为在这个示例中，他使用Redis获取分区和行键，然后转到表存储，它仍然非常快，因为它是一个Redis+表调用，而且我们将按分区和行查询表存储，并且永远不需要更复杂的查询，这会降低速度。干杯。我知道已经有一段时间了-你在这里干什么？我也在考虑同样的举措。Redis（连接和存储）的成本使表存储成为一个非常合理的选择（存储帐户、表和分区允许轻松解决任何限制）。我们使用存储表进行缓存，响应时间通常为个位数毫秒，因此速度足以满足我们的需要。唯一需要注意的是对存储进行过多的调用，因为它在自动过期、订阅更改等方面没有缓存的正常基础。您需要自己在代码中实现很多。您需要仔细考虑如何对数据进行分组、过期和过时，否则可能会导致过多的存储请求。但最终，即使过期，也是对服务的调用。我的代码仍然为缓存对象调用Redis，然后Redis说“不，过期了”