orm - 相当于分布式键/值存储的 ORM？

Question

我正在评估如何使用后端的分布式键/值存储来实现某些东西。我希望在支持对象模型的键/值之上有一个层，该对象模型类似于我从对象关系映射器中获得的模型。

任何人都可以指出其他人这样做的任何例子吗？我主要是在寻找设计理念，但如果我遇到任何我足够喜欢的东西，我可能会直接使用它而不是自己编写。我可能最终会在 Riak 之上在 Perl 中实现我的，但这些决定不是最终的。

Answer 1

我们之前使用 Riak 做类似的事情，使用 Ruby 客户端 Ripple，它公开了一个 AciveModel 接口(interface)。但是，我确实必须反对它(就像其他人一样)。在键/值存储之上使用繁重的 ORM，您确实会失去它的主要优势，即速度。

我们现在正朝着跳过 Ripple 并直接与 Riak 交谈的方向发展，以解决很多速度意识的问题(我们也在转向 Erlang 并使用 PBC 而不是 HTTP 接口(interface)，但这是另一个故事:D)，我们是这样做的:

在我们的对象中，我们以 Ripple 兼容格式存储 JSON 文档。虽然我们有这个要求，因为我们仍然在某些事情上使用 Ripple，但如果我在没有 Ripple 的情况下再次这样做，我可能仍然会使用这种格式。

使用 Riak 链接将对象连接在一起，不要将外键存储在文档本身中。请注意，您可以在对象上存储的链接数量是有限的，因此不要对它们过于疯狂(例如，存储指向用户对象上每个评论的链接)。

Ripple(和 Riak)不支持索引，所以我们不得不推出自己的解决方案。作为一个例子，我们在“users”存储桶中存储一个带有随机生成 key “fen2nf4j9fecd”的用户对象。我们还在 'users_index_by_username' 存储桶中存储了一个带有键 'tom' 的对象，并带有指向 'users' 存储桶中对象的 Riak 链接。这样我们就可以很容易地找到用户名为“tom”的用户。

您可能还想研究使用 key filtering .我还没有玩过它，但是我看到了看起来相当不错的性能数据。您需要注意 Riak 不要列出存储桶的键，因为由于其实现方式，Riak 会搜索所有键，而不仅仅是该存储桶的键。

Riak 是一头野兽，但是一旦你了解它，你就会爱上它。它使复制变得毫不费力，并且“正常工作”。