我正在评估如何使用分布式键/值存储为后端实现某些功能。我希望在键/值的顶部有一个层，支持一个对象模型，类似于我从对象关系映射器获得的对象模型。
有人能指出其他人这样做的例子吗？我主要是在寻找设计思路，但是如果我遇到任何我喜欢的东西，我可能只是使用它而不是自己编写。我可能最终会在Riak的顶层实施Perl，但这些决定并非最终决定。
答案 0 :(得分：4)
我们以前使用Riak做类似的事情，使用暴露AciveModel接口的Ruby客户端Ripple。但是，我必须真的反对它（正如其他人所做的那样）。在密钥/值存储的顶部使用繁重的ORM，你确实失去了它的主要优势，即速度。
我们现在正在跳过Ripple并直接与Riak谈论很多速度意识的事情（我们也转向Erlang并使用PBC而不是HTTP接口，但这是另一个故事：D），这是我们如何做到这一点：
在我们的对象中，我们以Ripple兼容格式存储JSON文档。虽然我们有一个要求，因为我们仍然使用Ripple进行某些操作，如果我在没有Ripple的情况下再次使用Ripple，我仍然可能会使用这种格式。
使用Riak链接将对象连接在一起，不要将外键存储在文档本身中。请注意，您可以在对象上存储的链接数量有限制，因此不要过于疯狂（例如，存储指向用户对象上每条注释的链接）。
Ripple（和Riak）不支持索引，所以我们不得不推出自己的解决方案。作为示例，我们在“用户”存储桶中存储具有随机生成的密钥“fen2nf4j9fecd”的用户对象。我们还在'users_index_by_username'存储桶中存储一个带有密钥'tom'的对象，其中包含指向'users'存储桶中对象的Riak链接。这样我们就可以轻松找到哪个用户拥有用户名'tom'。
您可能还想查看使用key filtering。我还没玩过它，但是我看到的表现数据看起来相当不错。您需要小心Riak不要列出存储桶的密钥，因为它的实现方式，Riak搜索所有密钥，而不仅仅是该存储桶的密钥。
Riak是一头野兽，但是一旦你了解它，你就会喜欢它。它使复制毫不费力，而且“只是工作”。
答案 1 :(得分：1)
你真的不需要太多（如果有的话）。
它是皮特的键/值存储，使用您的语言中存在的任何序列化机制来转换为您的类型对象和从您的类型对象转换到后端的对象。还需要做什么？
ORM更加复杂，因为它们一方面处理关系模型。一个关键的价值商店，嗯，没有。