分布式键/值存储的ORM替代方案是什么？

Question

我正在评估如何使用分布式键/值存储实现某些内容的过程中。我希望在键/值之上有一个支持对象模型的层，类似于从对象关系映射器（ORM）中得到的模型。

有没有人能给我指点一下其他人实现这个功能的示例？我主要是在寻找设计思路，如果我遇到任何我喜欢的东西，我可能会直接使用它而不是编写自己的代码。我最终可能要在Riak上使用Perl来实现我的代码，但这些决策并不是最终的。

- btilly

Answer 1

我们之前使用了Ripple，通过其暴露的ActiveModel接口，使用Riak来完成类似的事情。然而，我必须强烈反对这种做法（正如其他人所建议的）。在键/值存储之上使用重量级ORM会使你失去它的主要优势，即速度。

我们现在正在朝着跳过Ripple直接与Riak通信的方向发展，以获得更快的速度（我们还在转向Erlang并使用PBC而不是HTTP接口，但这是另一个故事：D），以下是我们的做法：

• 我们在对象中存储一个JSON文档，格式兼容Ripple。虽然我们对此有要求，因为我们仍然在某些方面使用Ripple，但如果我没有Ripple，我还是会使用这种格式。

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

• Ripple（和Riak）不支持索引，因此我们不得不自己解决问题。例如，我们使用随机生成的密钥“fen2nf4j9fecd”在“users”存储桶中存储用户对象。我们还在“users_index_by_username”存储桶中存储了一个密钥为“tom”的对象，并使用Riak链接将其链接到“users”存储桶中的对象。这样，我们就可以轻松找到具有用户名“tom”的用户。

你可能还想了解如何使用key filtering。我还没有尝试过，但是我看到的性能数据看起来非常好。需要注意的是，由于Riak的实现方式，不要列出一个存储桶的所有密钥，因为Riak会搜索所有密钥，而不仅仅是该存储桶的密钥。

Riak相当强大，但一旦你理解了它，你就会喜欢上它。它使复制变得轻松，并且它确实“只是工作”。

- Luca Spiller

---

在我的研究中，我意识到许多相同的事情。我知道Riak Search，但它对我来说还有点太beta了。我不知道链接数量有限制，这是很好的信息。我已经意识到我们自己编制索引的重要性。我仍在努力找出如何避免潜在的竞争条件。 - btilly

我认为链接数量的限制仅在使用HTTP接口时才会发生，因为头部的总大小有限制。不过我不是100%确定。另外我提到了错误的产品，我指的是键过滤，而不是Riak搜索（已编辑）。 - Luca Spiller

Answer 2

对于这个问题，你实际上不需要太多的层。

这是一个键/值存储，使用您语言中存在的任何序列化机制将类型化对象转换为后端对象并从后端对象转换即可。还有什么需要做的呢？

ORM更加复杂，因为它们处理一侧的关系模型。键值存储则不然。

- quentin-starin

---

如果您愿意将一个对象及其所有可能的子对象存储在一个键/值对中，那么这样做就没问题了，然后您必须为每个请求序列化和反序列化整个“怪物”。我不赞成这种方法。如果一个对象引用多个子对象，我希望各个对象及其关系存储在多个键/值对中，并且应该保持同步。避免重复逻辑需要在键/值存储之上构建一个抽象层。 - btilly

什么？“我希望各种对象及其关系被存储在多个键/值对中，这些应该保持同步。” -- 这就是所谓的关系型数据库。不要在 KV 无 SQL 存储之上构建 RDBMS，只需使用正确类型的存储引擎即可。 - quentin-starin

我非常熟悉关系型数据库是什么。如果有一个水平可扩展且没有指定主数据库的关系型数据库，我会选择使用它。但实际上并没有这样的数据库，因此我需要在KV NoSQL存储之上创建所需的对象模型。 - btilly