nosql并发排行,nosql 排名
什么是NoSQL数据库?
答案:A
成都创新互联公司是一家专业提供颍东企业网站建设,专注与成都网站设计、成都做网站、外贸网站建设、HTML5、小程序制作等业务。10年已为颍东众多企业、政府机构等服务。创新互联专业网络公司优惠进行中。
1.文档型数据库
作为最受欢迎的NoSQL产品,文档型数据库MongoDB当仁不让地占据了第一的位置,同时它也是所有NoSQL数据库中排名最靠前的产品(总排行榜第七名)。Apache基金会的CouchDB排在第二,基于.Net的数据库RavenDB排在第三,Couchbase排在第四。
2.键值(Key-value)数据库
键值(Key-value)数据库是NoSQL领域中应用范围最广的,也是涉及产品最多的一种模型。从最简单的BerkeleyDB到功能丰富的分布式数据库Riak再到Amazon托管的DynamoDB不一而足。
在键值数据库流行度排行中,Redis不出意外地排名第一,它是一款由Vmware支持的内存数据库,总体排名第十一。排在第二位的是Memcached,它在缓存系统中应用十分广泛。排在之后的是Riak、BerkeleyDB、SimpleDB、DynamoDB以及甲骨文的Oracle NoSQL数据库。值得注意的是,Oracle NoSQL数据库上榜不久,得分已经翻番,上升势头非常迅猛。
3. 列式存储
列式存储被视为NoSQL数据库中非常重要的一种模式,其中Cassandra流行度最高,它已经由Facebook转交给到Apache进行管理,同时Cassandra在全体数据库排名中排在第十位,紧随MongoDB成为第二受欢迎的NoSQL数据库。基于Hadoop的Hbase排在第二位,Hypertable排在第三。而Google的BigTable并未列入排名,原因是它并未正式公开。
一直在说的高并发,多少QPS才算高并发?
首先是无状态前端机器不足以承载请求流量,需要进行水平扩展,一般QPS是千级。 然后是关系型数据库无法承载读取或写入峰值,需要数据库横向扩展或引入nosql,一般是千到万级。 之后是单机nosql无法承载,需要nosql横向扩展,一般是十万到百万QPS。
最后是难以单纯横向扩展nosql,比如微博就引入多级缓存架构,这种架构一般可以应对百万到千万对nosql的访问QPS。 当然面向用户的接口请求一般到不了这个量级,QPS递增大多是由于读放大造成的压力,单也属于高并发架构考虑的范畴。
QPS(TPS):每秒钟 request/事务 数量,在互联网领域,指每秒响应请求数吞吐量:单位时间内处理的请求数量(通常由QPS与并发数决定);响应时间:系统对一个请求做出响应的平均时间。例如系统处理一个HTTP请求需要200ms,这个200ms就是系统的响应时间(我认为这里应该仅包含处理时间,网络传输时间忽略),这里一定要注意,QPS ≠ 并发数。
高并发通常是指我们提供的系统服务能够同时并行处理很多请求。并发是指,某个时刻有多少个访问同时到来。QPS是指秒钟响应的请求数量。那么这里就肯容易推算出一个公式:QPS = 并发数 / 平均响应时间
如果你发现自己高并发,一定要及时就医,寻求正规医生的帮助。
几种Nosql数据库对比
NoSQL不像传统关系型库那样有统一的标准,也不具有普适性。所以要根据应用和数据的存取特征来选择适合的NoSQL。
如果以前没有接触过NoSQL,MongoDB是一个比较好的选择,他支持的所以和查询能力是所有NoSQL中最强大的,缺点是索引的成本和文档大小限制。
如果是使用Hadoop大数据分析,数据基本上不存在修改,只是插入和查询,并且需要配合Hadoop的MR任务,HBase会是很好的选择。
如果要求有很强的扩展能力,高并发读写和维护方便,Casaandra则是不错的选择。
当然除了上面三个流行的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并发排行,nosql 排名
本文链接:http://scyanting.com/article/hdcdgi.html