为什么要用非关系数据库(NoSQL)？
时间：2010-09-22 来源：osdba
基本的理由：
1、High performance - 对数据库高并发读写的需求 web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的 BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。 2、Huge Storage - 对海量数据的高效率存储和访问的需求 类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个 月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。
3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求 在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展 是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？
但真实的情况，这些理由可能并不是使用NoSQL的关键，因为使用关系型数据库，也可以做数据的水平拆分，把数据分布到多台机器上。例如可能使用很多水平拆分数据的方法，在关系型数据库中还可以使用数据拆分。在应用层面对数据访问进行封装，就可以实现把数据分散到很多台的关型数据库中，如PostgreSQL中的plproxy集群，pgpool集群，还有很多公司自行开发的数据水平拆分的集群。 从目前情况看，NoSQL还不是很成熟，而各种关系型数据库都很成熟，也很稳定。
关系数据库的很多主要特性却往往无用武之地，例如：
1、数据库事务一致性需求 很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个 沉重的负担。
2、数据库的写实时性和读实时性需求 对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说我 （JavaEye的robbin）发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
3、对复杂的SQL查询，特别是多表关联查询的需求 任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产 品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
这些特性或许会变得无用武之地，但这些功能是否会大大降低关系型数据库的性能？而没有这些功能的NoSQL 性能是否会得到大大提高？
现在出现了很多的Key-Value的系统，如果我们把关系型数据库的表简单化为只有两列的表，key列，Value一列，然后在应用上做到数据的水平分割，是否一样可以NoSQL相同的功能？
1、High performance - 对数据库高并发读写的需求 web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的 BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。 2、Huge Storage - 对海量数据的高效率存储和访问的需求 类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个 月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。
3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求 在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展 是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？
但真实的情况，这些理由可能并不是使用NoSQL的关键，因为使用关系型数据库，也可以做数据的水平拆分，把数据分布到多台机器上。例如可能使用很多水平拆分数据的方法，在关系型数据库中还可以使用数据拆分。在应用层面对数据访问进行封装，就可以实现把数据分散到很多台的关型数据库中，如PostgreSQL中的plproxy集群，pgpool集群，还有很多公司自行开发的数据水平拆分的集群。 从目前情况看，NoSQL还不是很成熟，而各种关系型数据库都很成熟，也很稳定。
关系数据库的很多主要特性却往往无用武之地，例如：
1、数据库事务一致性需求 很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个 沉重的负担。
2、数据库的写实时性和读实时性需求 对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说我 （JavaEye的robbin）发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
3、对复杂的SQL查询，特别是多表关联查询的需求 任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产 品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
这些特性或许会变得无用武之地，但这些功能是否会大大降低关系型数据库的性能？而没有这些功能的NoSQL 性能是否会得到大大提高？
现在出现了很多的Key-Value的系统，如果我们把关系型数据库的表简单化为只有两列的表，key列，Value一列，然后在应用上做到数据的水平分割，是否一样可以NoSQL相同的功能？
相关阅读 更多 +
