5

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

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

4

2 回答 2

4

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

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

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

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

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

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

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

于 2011-04-14T10:12:34.003 回答
1

你不应该真的需要太多（如果有的话）层。

为了皮特的缘故，它是一个键/值存储，使用您的语言中存在的任何序列化机制来转换您的类型化对象和后端对象。还需要做什么？

ORM 要复杂得多，因为它们一方面处理关系模型。一个键值存储，嗯，没有。

于 2011-04-11T19:17:45.280 回答