相当于分布式键/值存储的 ORM？
我正在评估如何使用后端的分布式键/值存储来实现某些内容。我希望在键/值之上有一个层来支持对象模型，该模型类似于我从对象关系映射器获得的模型。
谁能给我指出其他人这样做的例子吗？我主要是在寻找设计想法，但如果我遇到任何我足够喜欢的东西，我可能会直接使用它而不是自己编写。我可能最终会在 Riak 之上用 Perl 实现我的，但这些决定不是最终的。
I'm in the process of evaluating how to implement something using a distributed key/value store for the back end. I'd like to have a layer on top of the key/value supporting an object model that is similar to what I'd get from an object-relational mapper.
Can anyone point me at any examples of other people doing this? I'm mostly looking for design ideas, though if I run across anything that I like enough I may just use it instead of writing my own. I'm probably going to wind up implementing mine in Perl on top of Riak, but those decisions are not final.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们之前使用 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 是个野兽，但是一旦你了解了它，你就会爱上它。它使复制变得毫不费力，并且确实“正常工作”。
We have previously used Riak to do something similar, using the Ruby client Ripple which exposes an AciveModel interface. However, I do have to really advise against it (as others have). Using a heavy ORM on top of a key/value store you really do lose it's main advantage, which is speed.
We are now moving towards skipping Ripple and talking directly to Riak for a lot of speed conscious things (we are also moving to Erlang and using the PBC rather than HTTP interface, but that's another story :D), here is how we do it:
In our objects we store a JSON document, in a Ripple compatible format. Although we have a requirement of this as we still use Ripple for some things, if I were to do this again without Ripple I would still probably use this format.
Use Riak links to join objects together, don't store foreign keys in the document itself. Be advised there is a limit to the number of links you can store on an object, so don't go too crazy with them (e.g. storing a link to each comment on the user object).
Ripple (and Riak) doesn't support indexes, so we had to roll our own solution. As an example we store a user object with a randomly generated key, 'fen2nf4j9fecd' in the 'users' bucket. We also store an object with the key 'tom' in the 'users_index_by_username' bucket with a Riak link to the object in the 'users' bucket. That way we can easily find which user has the username 'tom'.
You may also want to look into using key filtering. I haven't played with it yet, however I have seen performance figures that look quite good. You need to be careful with Riak not to list the keys of a bucket as due to the way it is implemented, Riak searches all keys, not just that bucket's keys.
Riak is quite a beast, however once you get your head around it you will love it. It make's replication effortless, and it does 'just work'.
为此，您实际上不需要太多（如果有的话）层。
为了皮特的缘故，它是一个键/值存储，使用您的语言中存在的任何序列化机制来将您的类型对象转换为后端对象。还有什么可做的吗？
ORM 要复杂得多，因为它们一方面处理关系模型。键值存储则不然。
You shouldn't really need much, if any, layer for this.
It's a key/value store for pete's sake, use whatever serialization mechanism exists in your language to convert to and from your typed object to the back-end's object. What else is there to do?
ORM's are far more complicated because they are dealing with a relational model on one side. A key value store, well, doesn't.