我正在评估如何使用分布式键/值存储为后端实现某些功能.我希望在键/值的顶部有一个支持对象模型的层,它与我从对象关系映射器获得的类似.
任何人都可以指出其他人这样做的例子吗？我主要是在寻找设计思路,但是如果我遇到任何我喜欢的东西,我可能只是使用它而不是自己编写.我可能最终会在Riak的顶层实施Perl,但这些决定并非最终决定.
我们之前使用 Riak 做过类似的事情，使用 Ruby 客户端 Ripple 公开了一个 AciveModel 接口。然而，我确实必须反对它（就像其他人一样）。在键/值存储之上使用重型 ORM，您确实会失去它的主要优势，即速度。
我们现在正朝着跳过 Ripple 并直接与 Riak 对话的方向进行许多注重速度的事情（我们也正在转向 Erlang 并使用 PBC 而不是 HTTP 接口，但那是另一个故事了 :D），以下是我们的做法：
在我们的对象中，我们以 Ripple 兼容格式存储 JSON 文档。尽管我们有这样的要求，因为我们仍然使用 Ripple 来做某些事情，但如果我在没有 Ripple 的情况下再次这样做，我仍然可能会使用这种格式。
使用 Riak 链接将对象连接在一起，不要在文档本身中存储外键。请注意，您可以在对象上存储的链接数量是有限的，因此不要对它们过于疯狂（例如，存储指向用户对象上每个评论的链接）。
Ripple（和 Riak）不支持索引，因此我们必须推出自己的解决方案。作为示例，我们将具有随机生成的密钥“fen2nf4j9fecd”的用户对象存储在“users”存储桶中。我们还将一个带有键“tom”的对象存储在“users_index_by_username”存储桶中，并通过 Riak 链接指向“users”存储桶中的该对象。这样我们就可以轻松找到哪个用户的用户名是“tom”。
您可能还想研究使用键过滤。我还没有玩过它，但我看到性能数据看起来相当不错。您需要注意 Riak 不要列出存储桶的键，因为它的实现方式使 Riak 搜索所有键，而不仅仅是该存储桶的键。
Riak 是个野兽，但是一旦你了解了它，你就会爱上它。它使复制变得毫不费力，并且确实“正常工作”。