Question

http://www.infoq.com/presentations/newport-evolving-key-value-programming-model是关于KV商店的视频，整个前提是redis提升了基于列的样式，用于将对象的属性存储在单独的键下，而不是序列化对象并存储它在一把钥匙下。

（这个问题不是特定于redis，但更多是KV商店的一般风格和最佳做法。）

redis鼓励使用基于列的样式，而不是使用“人”这样的blob，其中对象中的属性存储为单独的键，例如。

R.set("U:123:firstname","Billy")
R.set("U:123:surname","Newport")
...

我很好奇这是否是最佳做法，如果人们采取不同的方法。

E.g。你可以在一把钥匙下'腌制'一个物体。这具有在单个请求中提取或设置的优势
或者某个人可能是列表，第一项是字段名称索引等？

这让我想到了 - 我想要一个分层的密钥库，例如

R.set(["U:123","firstname"],"Billy")
R.set(["U:123","surname"],"Newport")
R.get(["U:123"]) returns [("firstname","Billy"),("surname","Newport")]

然后添加交易：

with(R.get(["U:132"]) as user):
  user.set("firstname","Paul")
  user.set("lastname","Simon")

从缩放的角度来看，获取和设置的批处理是重要的吗？

是否有关键商店确实有此支持或有其他适用的方法？

Answer 1

您可以通过使用额外的Set来跟踪对象的各个成员，从而在Redis中获得类似的行为。

SET U:123:firstname Billy
SADD U:123:members firstname
SET U:123:surname Cobin
SADD U:123:members surname

GET U:123:firstname => Billy
GET U:123:firstname => Cobin
SORT U:123:members GET U:123:* -> [Billy, Cobin]
or
SMEMBERS U:123:members -> [firstname, surname]
MGET U:123:firstname U:123:firstname

不是完美匹配，但在很多情况下都足够好。关于interesting article如何在Redis

中使用此模式，有一个hurl

可扩展对象的键值存储

1 个答案: