RDBMS作为缓存，需要设计建议

Question

我有一个“黑匣子”应用程序，它将值映射作为参数，执行繁重和长时间（最多5秒）的计算，并生成可以保存在数据库中的单个Result。 我对该应用程序的所有了解都是：

• 结果对于提供的地图af值
是唯一的
• Argument是一个String-＆gt; String映射，两者的已知最大长度 关键和价值
• 参数图具有可变长度（从2-3到1000个条目或 所以）
• 可能的键值列表大小约为1000

示例参数是：

Map: {'k1'->'a', 'k2'->'b'} 
Map: {'k1'->'a', 'k2'->'b', ... 'k100'->'zzz'}
Map: {'k1'->'x', 'k8'->'y'}
Map: {'k6'->'z'}

以上每个都会产生唯一的Result对象。

现在想象一下另一个服务，它构建在那个慢速库之上，需要每秒上线并处理几十个计算请求。 如果没有缓存已计算的结果，这是不可能的。 我对可能的高速缓存大小总数的估计约为100-500百万条记录，这导致我将RDBMS用作高速缓存存储。

由于结果由提供的映射唯一标识，我可以按键对参数映射进行排序，并将其连接到字符串'k1：a：k2：b ....'。这将定义为缓存键，但是：

• 缓存密钥将是巨大的，超过许多RDBMS和的密钥大小限制 需要索引CLOB的
• 我将不会使用关键值受限的事实 可能的价值。

你的建议是什么？表演是我的主要关注点。

Answer 1

实际上，这听起来更像是key-value store或document database最好解决的问题，而不是RDBMS。

值得研究的另一种可能性是像memcached这样的缓存服务器。

Answer 2

我的建议是计算500M * 5秒的时间，以天为单位。这是计算将存储在缓存中的所有结果所需的时间，也就是之前开始看到构建缓存的实际好处所花费的时间。< / p>

（是的，我知道，你可以“逐渐”建立你的缓存。但如果有那么多可能的条目，那么命中的概率与缓存大小本身成正比，即：几乎没有启动阶段。在你达到合理的命中概率之前，需要花费一倍的时间.imho。）