【问题标题】:Redis - Which datatype would be most efficient way to store dataRedis - 哪种数据类型是存储数据的最有效方式
【发布时间】:2019-05-27 14:45:34
【问题描述】:

我不确定哪种数据类型/方法最适合以下场景。

我将存储完整的 json 对象,每个对象都有多个属性,其中一个是 ID(int 字段)。

public class Event
{
   public int EventId {get; set}
   public DateTime EventDate {get; set;}
   public string Title {get; set;}
   public int TypeId {get; set;}
}
  1. 我需要能够通过这个 id 来查找单个对象,我假设这将被存储为一个键/值对,键是“something”+id,值是一个序列化的 json对象。

  2. 我希望能够以分页方式获取上述对象的列表,例如第一页,页面大小为 20。(哈希集或排序集)

  3. 上面的第2个也可以通过分页来完成,但是先通过其中一个字段过滤然后返回结果

我希望每个 json 对象只有一个副本来满足上述场景,从我目前阅读的所有内容来看,我似乎将创建每个对象的多个副本来满足上述所有场景。

所以简而言之,我喜欢我的存储对象列表,以便由

  1. 通过 ID 检索单个项目(json 对象的属性

  2. 没有过滤器的分页列表

  3. 带有分页和过滤 json 对象的分页列表

  4. 用户可以随时更改任何事件对象,因此需要更新缓存(使缓存无效/更新缓存)

我正在用 .NET 编写代码,所以如果这有什么不同的话。

【问题讨论】:

  • 您确定 Redis 是完成这项工作的最佳工具吗? Redis 主要是一个键/值存储。无论如何,过滤值并不是它的强项。为什么要在某种旨在进行过滤和分页的数据库上使用 Redis?我个人不会为此使用 Redis,这可能就是您无法弄清楚如何做的原因。
  • @nate 我已经在使用 RDBM,我正在介绍可能使用 Redis 从数据库服务器上卸载工作,并使查询更快,因为它在内存中检索而不是必须去数据库。我也在质疑过滤部分是否应该是 Redis 的一部分,但我想至少让分页和单项检索在可能的情况下与 reds 一起工作
  • 如果我是你,我会看看你是否可以对你的数据库进行任何性能调整。也许您可能缺少一些关键索引或其他东西。即使使用 RDBM,这种东西也应该快如闪电。如果不是,您可能有一个应该修复而不是忽略的数据库问题。我知道这并不能回答您的问题,但我认为这是最好的方法。
  • 另外,我会检查您正在运行的查询。有时人们运行的查询不是很好,然后当它们运行缓慢时会感到惊讶。
  • @Nate 感谢您的回复,查询非常轻量级,将通过索引等进行调整。如果数据库上的调优和索引不够好并且可以打开和关闭 Redis,则引入 Redis 的想法纯粹是另一种选择。我过去的经验表明,在大多数情况下,内存中(不是 Redis)缓存可以比最优化的数据库更快地减轻,但从未对内存中的对象进行实际的分页/过滤。这对我来说是一个新领域,因此我为什么要尝试更多选择。

标签: c# .net caching redis


【解决方案1】:

似乎除了进行简单的键值查询之外,您还需要一些额外的逻辑来在服务器(Redis)端运行。您可以在 Redis 中使用 Lua 脚本来执行此类任务。

如果我正确理解您的要求,我会采取以下方法:

  1. 将对象存储在排序集中(如果您按特定顺序返回对象)

  2. 您现在可以通过本机 Redis 命令查询单个和未过滤的对象: Redis - Sorted set, find item by property value

  3. 对于过滤的对象,您可以查看 Lua 脚本

  4. Redis 不提供任何现成的功能来使列表中存储的缓存失效/更新。而且您必须编写额外的代码来处理缓存更新。在此处阅读更多信息:https://quickleft.com/blog/how-to-create-and-expire-list-items-in-redis

您也可以查看 ignite,它内置了一些您可能感兴趣的功能:

  1. 二进制编组器: “它使您能够从对象的序列化形式中读取任意字段,而无需完整的对象反序列化。” https://apacheignite.readme.io/docs/binary-marshaller

  2. 缓存更新的读/写能力:https://ignite.apache.org/use-cases/caching/database-caching.html

【讨论】:

    猜你喜欢
    • 2012-01-09
    • 1970-01-01
    • 2019-07-23
    • 1970-01-01
    • 1970-01-01
    • 2014-06-26
    • 2016-11-19
    • 2013-04-30
    • 2012-02-16
    相关资源
    最近更新 更多