关于Key/value store的一些困惑

09-10-16 air82
         

最近公司有个新项目,对于负载和并发的要求很高,因此考虑使用key/value store去解决数据持久化的问题,但是在思考过程中碰到一些问题,在这里提出来希望能有高人指点一下

1.建模如何做.通常一个实体在应用中有多个地方需要引用,比如,以论坛为例,一个帖子如果存储在用户对象中,那么,各版块引用这些帖子做列表的时候如何做,只存索引?那效率貌似低了一些,虽然有各种缓存,但是这样还是觉得别扭。做一个冗余的记录?似乎也不是办法。如果存储在版块中,那么查询用户的帖子又是个问题。这个倒是可以配合全文搜索来解决,只是想向高人讨教一下有没有别的方式解决这个问题。

2.排序如何做。绝大多数key value store都只支持单一排序,如果我需要多种排序,是不是必须借助全文搜索或者做多个副本。

归根到底,key/value store兴起的时间不长,资料相对少。有谁有这方面最佳实践之类的文章可否共享一下。

谢谢大家了!

         

3
banq
2009-10-16 17:38

参考这篇

Qi4j和NoSql运动

Key/value store要结合Evans DDD才显威力,Qi4j作者认为Key/value store就不应该支持Joins 和 queries,这些都是业务层来实现,比如使用Qi4j的RDF store,通过和key-value存储结合,可以获得惊人的加载和存储性能。

我认为key value store实际就是缓存概念的延伸,是将缓存中对象以key value形式持久化保存到硬盘上,这种方式有别于关系数据库以关系形势存储。如下图:

最著名的文章:

Anti-RDBMS: A list of distributed key-value stores

1.你患了云计算疯狂。

2.你需要一个机会实现'get your Erlang on'

3.你所听到的CouchDB很酷。

4.你恨MySQL和PostgreSQL,尽管他们已经表现不错,但它仍然没有像样的复制。有没有机会你买甲骨文许可证。

5.您的数据存储和主要由主键无需进行复杂的检索,联接。 (类似缓存中对象操作,做大这点,必须以对象关系替代以前的数据关系,DDD就起了关键作用)

6.你有一个不平凡的数据量,以及管理RDBMS的碎片和大量复制失败的情况,这些都带给你的恐惧。

[该贴被admin于2009-10-16 17:56修改过]