NoSQL数据库探讨之一 － 为什么要用非关系数据库？

性能,关系数据一大要求就是不能因为性能而改变逻辑结构。比如说一个tuple{id,year,name,salary},按照SQL的做法搞一个表吧,按照id为key.然后存啊存啊存，发现数据越大查询性能越慢，恩然后程序员说我们分表吧，一年一个表.这种情况在关系数据里是不允许的。

比如一个SNS系统，有1亿注册用户，我们可以按用户ID平均分成100组DB。
客户端通过用户ID和一个映射规则去获取它所属的DB组，然后再使用。

因为每组DB只有100w，所以能满足高性能并发读写的需求，慢的话再细分；

对于写缓存，读缓存等是应用的事，可以写应用来实现缓存。
同理，对海量数据高效率存储也可以通过优化mysql或者更细的划分DB组来达到；
每组DB都做热备以达到高可用性；

当用户又增长了100万时，增加一组DB，修改下映射规则就可以满足扩展性。
什么时候该用 nosql db呀

我在工作中也遇到很多问题，关系数据库确实有些力不从心了，但是不使用关系数据库，面对复杂的查询，没有好的解决方案。
从这篇文章的介绍看，我对MongoDB最感兴趣，期待后续。

我的需求和这里列出的Web2.0的网站需求还不太一样。我的场景是：

• 数据量非常巨大，写操作特别多。数据量可以说是无限的，就看系统能处理多少，如果能处理更多就要接入更多的数据（一般来说我们只接入了部分数据）。
• 读操作非常少，可以用每天多少次来衡量（就那么几个使用人员，他用的时候才有查询操作），但是一旦有查询操作，往往都是重量级的。
• 查询操作可以稍微慢点，能在5秒内出来就不错了，如果进行复杂的查询，30秒出来也算不错了。10分钟甚至1个小时才查出结果，是非常不好的，但是能出来总比不能要好。
• 写操作允许丢失少量数据，但是整个数据库的完整性要有保证
• 数据最好能够压缩存储

在某个项目里面，数据量大的时候大约每天40、50G，使用postgresql，居然也支撑了下来，但是查询非常慢。接下来的一些项目数据量会更大，可能会有这个量的100倍以上，目前没有好的办法，只能从数据源头先做过滤。

我在1年前，开始尝试进行一些探索，根据产品需求特点，使用自定义的数据格式存储。目前能够解决的问题有：

• 对数据进行简单的解析和压缩存储
• 能够对压缩的数据进行简单的查询（指定数据源、时间范围、关键字），查询较慢，但是比SQL有一个好处，就是能看见当前查询到哪个时间点了，而不是像SQL一样，等运行完了才能给用户看到
• 高性能的写入。目前在我的笔记本上进行简单的测试，每秒2万条的UDP包，丢包率是0.5%，在复杂的环境下性能是会下降的，但服务器的性能会更好

不幸的是，我只有很少的时间能投入到这上面，有时候几个星期都没空去弄，所以到现在还有很多要完善的地方，没有在项目里面实用。有时候我都怀疑这条路是不是走错了。

目前没有解决的问题是高性能的、对数据的复杂查询。数据可以分为2部分，原始数据和格式化后的数据，目前我这里只解决了原始数据的问题，对于格式化数据的复杂查询，还是需要类似关系数据库的功能才行。这也是我对MongoDB比较感兴趣的原因。