可扩展对象的键值存储答案

【问题标题】：key value stores for extendable objects可扩展对象的键值存储
【发布时间】：2011-01-07 15:30:24
【问题描述】：

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")
...

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

例如您可以在单个键下“腌制”一个对象。这具有在单个请求中获取或设置的优势
或者一个人可以是一个列表，其中第一项是字段名称索引等？

这让我开始思考 - 我想要一个分层密钥存储，例如

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")

从扩展的角度来看，get 和 set 的批处理会很重要吗？

是否有关键商店对此提供支持或有其他适用的方法？

【问题讨论】：

标签： memcached redis key-value-store

【解决方案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 是关于 hurl 如何在 Redis 中使用这种模式的interesting article

【讨论】：