nosql不适用场景,nosql的使用场景
NoSQL应用
而传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,例如:
让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:空间域名、网络空间、营销软件、网站建设、华州网站维护、网站推广。
1、High performance - 对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载非常高,往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求,硬盘IO就已经无法承受了。其实对于普通的BBS网站,往往也存在对高并发写请求的需求。
2、Huge Storage - 对海量数据的高效率存储和访问的需求
对于大型的SNS网站,每天用户产生海量的用户动态,以国外的Friendfeed为例,一个月就达到了2.5亿条用户动态,对于关系数据库来说,在一张2.5亿条记录的表里面进行SQL查询,效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统,例如腾讯,盛大,动辄数以亿计的帐号,关系数据库也很难应付。
3、High Scalability High Availability- 对数据库的高可扩展性和高可用性的需求
在基于web的架构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移,为什么数据库不能通过不断的添加服务器节点来实现扩展呢?
在上面提到的“三高”需求面前,关系数据库遇到了难以克服的障碍,而对于web2.0网站来说,关系数据库的很多主要特性却往往无用武之地,例如:
1、数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。
2、数据库的写实时性和读实时性需求
对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性。
3、对复杂的SQL查询,特别是多表关联查询的需求
任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询,特别是SNS类型的网站,从需求以及产品设计角度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。
因此,关系数据库在这些越来越多的应用场景下显得不那么合适了,为了解决这类问题的非关系数据库应运而生。
NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构,通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。
当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系,如Facebook 的Cassandra, Apache 的HBase,也得到了广泛认同。
高性能 NoSQL
关系数据库经过几十年的发展,已经非常成熟,但同时也存在不足:
表结构是强约束的,业务变更时扩充很麻烦。
如果对大数据量的表进行统计运算,I/O会很高,因为即使只针对某列进行运算,也需要将整行数据读入内存。
全文搜索只能使用 Like 进行整表扫描,性能非常低。
针对这些不足,产生了不同的 NoSQL 解决方案,在某些场景下比关系数据库更有优势,但同时也牺牲了某些特性,所以不能片面的迷信某种方案,应将其作为 SQL 的有利补充。
NoSQL != No SQL,而是:
NoSQL = Not Only SQL
典型的 NoSQL 方案分为4类:
Redis 是典型,其 value 是具体的数据结构,包括 string, hash, list, set, sorted set, bitmap, hyperloglog,常被称为数据结构服务器。
以 list 为例:
LPOP key 是移除并返回队列左边的第一个元素。
如果用关系数据库就比较麻烦了,需要操作:
Redis 的缺点主要体现在不支持完成的ACID事务,只能保证隔离性和一致性,无法保证原子性和持久性。
最大的特点是 no-schema,无需在使用前定义字段,读取一个不存在的字段也不会导致语法错误。
特点:
以电商为例,不同商品的属性差异很大,如冰箱和电脑,这种差异性在关系数据库中会有很大的麻烦,而使用文档数据库则非常方便。
文档数据库的主要缺点:
关系数据库是按行来存储的,列式数据库是按照列来存储数据。
按行存储的优势:
在某些场景下,这些优势就成为劣势了,例如,计算超重人员的数据,只需要读取体重这一列进行统计即可,但行式存储会将整行数据读取到内存中,很浪费。
而列式存储中,只需要读取体重这列的数据即可,I/O 将大大减少。
除了节省I/O,列式存储还有更高的压缩比,可以节省存储空间。普通行式数据库的压缩比在 3:1 到 5:1 左右,列式数据库在 8:1 到 30:1,因为单个列的数据相似度更高。
列式存储的随机写效率远低于行式存储,因为行式存储时同一行多个列都存储在连续空间中,而列式存储将不同列存储在不连续的空间。
一般将列式存储应用在离线大数据分析统计场景,因为这时主要针对部分列进行操作,而且数据写入后无须更新。
关系数据库通过索引进行快速查询,但在全文搜索的情景下,索引就不够了,因为:
假设有一个交友网站,信息表如下:
需要匹配性别、地点、语言列。
需要匹配性别、地点、爱好列。
实际搜索中,各种排列组合非常多,关系数据库很难支持。
全文搜索引擎是使用 倒排索引 技术,建立单词到文档的索引,例如上面的表信息建立倒排索引:
所以特别适合根据关键词来查询文档内容。
上面介绍了几种典型的NoSQL方案,及各自的适用场景和特点,您可以根据实际需求进行选择。
HBase 的使用有哪些限制,不适用的场景有哪些?
目前来说,我认为hbase版本还不稳定,使用起来还是会出现很多潜在的bug,你看看淘宝的使用经验就知道了,所以使用hbase的限制: 1. 要有比较强大的IT团队,且有一定的nosq 库表的设计经验,否则你无法发挥hbase的性能优势 2. hbase的 有效性还存在一定的问题(nosql CAP理论中的A),因为只要集群中的一个节点宕机了,这个节点上的数据暂时就不能访问了,需要等待一定的时间,进行同步处理,查询数据时,你会发现有部分缺失。当然,也有处理方法,淘宝就是找人专门盯着这些集群,以最快的速度恢复这些宕机的机器 4. 查询简单,只能根据key,扫描一条记录,或全表扫描,或根据key范围性扫描,不支持复杂的sql处理,也不会具有关系型数据库的ACID特性. 5. hbase基本上是采用hdfs作为存储,你使用hdfs,就得考虑它的 单几点问题,也就是HA问题,当然,目前版本好像提供了HA机制,但好不好用,还待验证总之,hbase目前还是存在很多问题的,想要用好它,你得自己考虑这些问题,且做增强,它还不算一个非常成熟的数据库,我猜想,后期版本会有大改
新闻名称:nosql不适用场景,nosql的使用场景
本文网址:http://myzitong.com/article/dsgcgop.html