本地nosql性能,nosql主要解决了大数据环境下的

一、NoSQL数据库简介

Web1.0的时代,数据访问量很有限,用一夫当关的高性能的单点服务器可以解决大部分问题。

成都创新互联公司-专业网站定制、快速模板网站建设、高性价比八宿网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式八宿网站制作公司更省心,省钱,快速模板网站建设找我们,业务覆盖八宿地区。费用合理售后完善,10余年实体公司更值得信赖。

随着Web2.0的时代的到来,用户访问量大幅度提升,同时产生了大量的用户数据。加上后来的智能移动设备的普及,所有的互联网平台都面临了巨大的性能挑战。

NoSQL(NoSQL = Not Only SQL ),意即“不仅仅是SQL”,泛指非关系型的数据库。

NoSQL 不依赖业务逻辑方式存储,而以简单的key-value模式存储。因此大大的增加了数据库的扩展能力。

Memcache Memcache Redis Redis MongoDB MongoDB 列式数据库 列式数据库 Hbase Hbase

HBase是Hadoop项目中的数据库。它用于需要对大量的数据进行随机、实时的读写操作的场景中。

HBase的目标就是处理数据量非常庞大的表,可以用普通的计算机处理超过10亿行数据,还可处理有数百万列元素的数据表。

Cassandra Cassandra

Apache Cassandra是一款免费的开源NoSQL数据库,其设计目的在于管理由大量商用服务器构建起来的庞大集群上的海量数据集(数据量通常达到PB级别)。在众多显著特性当中,Cassandra最为卓越的长处是对写入及读取操作进行规模调整,而且其不强调主集群的设计思路能够以相对直观的方式简化各集群的创建与扩展流程。

主要应用:社会关系,公共交通网络,地图及网络拓谱(n*(n-1)/2)

为什么要使用NoSQL?NOSQL的优势

这次的NoSQL专栏系列将先整体介绍NoSQL,然后介绍如何把NoSQL运用到自己的项目中合适的场景中,还会适当地分析一些成功案例,希望有成功使用NoSQL经验的朋友给我提供一些线索和信息。

NoSQL概念随着web2.0的快速发展,非关系型、分布式数据存储得到了快速的发展,它们不保证关系数据的ACID特性。NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”,“Not Only SQL”也被很多人接受。(“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字。)

NoSQL被我们用得最多的当数key-value存储,当然还有其他的文档型的、列存储、图型数据库、xml数据库等。在NoSQL概念提出之前,这些数据库就被用于各种系统当中,但是却很少用于web互联网应用。比如cdb、qdbm、bdb数据库。

传统关系数据库的瓶颈

传统的关系数据库具有不错的性能,高稳定型,久经历史考验,而且使用简单,功能强大,同时也积累了大量的成功案例。在互联网领域,MySQL成为了绝对靠前的王者,毫不夸张的说,MySQL为互联网的发展做出了卓越的贡献。

在90年代,一个网站的访问量一般都不大,用单个数据库完全可以轻松应付。在那个时候,更多的都是静态网页,动态交互类型的网站不多。

到了最近10年,网站开始快速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。在初期,论坛的流量其实也不大,如果你接触网络比较早,你可能还记得那个时候还有文本型存储的论坛程序,可以想象一般的论坛的流量有多大。

Memcached+MySQL

后来,随着访问量的上升,几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题,web程序不再仅仅专注在功能上,同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力,优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力,但是当访问量继续增大的时候,多台web机器通过文件缓存不能共享,大量的小文件缓存也带了了比较高的IO压力。在这个时候,Memcached就自然的成为一个非常时尚的技术产品。

Memcached作为一个独立的分布式的缓存服务器,为多个web服务器提供了一个共享的高性能缓存服务,在Memcached服务器上,又发展了根据hash算法来进行多台Memcached缓存服务的扩展,然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。当时,如果你去面试,你说你有Memcached经验,肯定会加分的。

Mysql主从读写分离

由于数据库的写入压力增加,Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负,大部分网站开始使用主从复制技术来达到读写分离,以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。

分表分库随着web2.0的继续高速发展,在Memcached的高速缓存,MySQL的主从复制,读写分离的基础之上,这时MySQL主库的写压力开始出现瓶颈,而数据量的持续猛增,由于MyISAM使用表锁,在高并发下会出现严重的锁问题,大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。同时,开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候,分表分库成了一个热门技术,是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候,MySQL推出了还不太稳定的表分区,这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群,但是由于在互联网几乎没有成功案例,性能也不能满足互联网的要求,只是在高可靠性上提供了非常大的保证。

MySQL的扩展性瓶颈

在互联网,大部分的MySQL都应该是IO密集型的,事实上,如果你的MySQL是个CPU密集型的话,那么很可能你的MySQL设计得有性能问题,需要优化了。大数据量高并发环境下的MySQL应用开发越来越复杂,也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性,但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更,可能又需要一种新的分库方式。

MySQL数据库也经常存储一些大文本字段,导致数据库表非常的大,在做数据库恢复的时候就导致非常的慢,不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小,如果能把这些数据从MySQL省去,MySQL将变得非常的小。

关系数据库很强大,但是它并不能很好的应付所有的应用场景。MySQL的扩展性差(需要复杂的技术来实现),大数据下IO压力大,表结构更改困难,正是当前使用MySQL的开发人员面临的问题。

NOSQL的优势易扩展NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了可扩展的能力。

大数据量,高性能

NoSQL数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关系性,数据库的结构简单。一般MySQL使用Query Cache,每次表的更新Cache就失效,是一种大粒度的Cache,在针对web2.0的交互频繁的应用,Cache性能不高。而NoSQL的Cache是记录级的,是一种细粒度的Cache,所以NoSQL在这个层面上来说就要性能高很多了。

灵活的数据模型

NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。

高可用NoSQL在不太影响性能的情况,就可以方便的实现高可用的架构。比如Cassandra,HBase模型,通过复制模型也能实现高可用。

总结NoSQL数据库的出现,弥补了关系数据(比如MySQL)在某些方面的不足,在某些方面能极大的节省开发成本和维护成本。

MySQL和NoSQL都有各自的特点和使用的应用场景,两者的紧密结合将会给web2.0的数据库发展带来新的思路。

nosql是什么

NoSQL,泛指非关系型的数据库。随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战,尤其是大数据应用难题。

虽然NoSQL流行语火起来才短短一年的时间,但是不可否认,现在已经开始了第二代运动。尽管早期的堆栈代码只能算是一种实验,然而现在的系统已经更加的成熟、稳定。不过现在也面临着一个严酷的事实:技术越来越成熟——以至于原来很好的NoSQL数据存储不得不进行重写,也有少数人认为这就是所谓的2.0版本。这里列出一些比较知名的工具,可以为大数据建立快速、可扩展的存储库。

NoSQL(NoSQL = Not Only SQL ),意即“不仅仅是SQL”,是一项全新的数据库革命性运动,早期就有人提出,发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储,相对于铺天盖地的关系型数据库运用,这一概念无疑是一种全新的思维的注入。

对于NoSQL并没有一个明确的范围和定义,但是他们都普遍存在下面一些共同特征:

不需要预定义模式:不需要事先定义数据模式,预定义表结构。数据中的每条记录都可能有不同的属性和格式。当插入数据时,并不需要预先定义它们的模式。

无共享架构:相对于将所有数据存储的存储区域网络中的全共享架构。NoSQL往往将数据划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能,从而提高了系统的性能。

弹性可扩展:可以在系统运行的时候,动态增加或者删除结点。不需要停机维护,数据可以自动迁移。

分区:相对于将数据存放于同一个节点,NoSQL数据库需要将数据进行分区,将记录分散在多个节点上面。并且通常分区的同时还要做复制。这样既提高了并行性能,又能保证没有单点失效的问题。

异步复制:和RAID存储系统不同的是,NoSQL中的复制,往往是基于日志的异步复制。这样,数据就可以尽快地写入一个节点,而不会被网络传输引起迟延。缺点是并不总是能保证一致性,这样的方式在出现故障的时候,可能会丢失少量的数据。

BASE:相对于事务严格的ACID特性,NoSQL数据库保证的是BASE特性。BASE是最终一致性和软事务。

NoSQL数据库并没有一个统一的架构,两种NoSQL数据库之间的不同,甚至远远超过两种关系型数据库的不同。可以说,NoSQL各有所长,成功的NoSQL必然特别适用于某些场合或者某些应用,在这些场合中会远远胜过关系型数据库和其他的NoSQL。

如何根据性能选择内存NoSQL数据库

本文主要内容是测试了不同NoSQL数据库在测试工具YCSB中的表现。我们选取了3款流行的内存(in-memory)数据库管理系统:Redis,Tarantool 以及 CouchBase,还有缓存系统Memchached。Memchached虽然不属于数据库管理系统但常作为快速存储系统使用。

测试环境由4台在Microsoft Azure Cloud中的虚拟机组成的计算机组组成。这些虚拟机同属于一个数据中心。nosql-1和nosql-2用作测试Tarantool和CouchBase,nosql-3和nosql-4用作测试Redis,Azure Redis Cache 以及 Memcached。这些机器都安装和配置了相应数据库和测试项目。虚拟机的配置为4核A3 CPU,7GB RAM,120GB硬盘。

数据库及设置

内存数据库管理系统会存储所有在主内存中的数据并在磁碟上进行持续更新操作;透过日志记录每个数据的修改以确保连贯性。由于是以append-only方式进行日志写入,因此它很少遇到瓶颈问题;读取/写入都不会造成频繁的磁碟头移动。

Redis在2009推出,目前的最新版本是3.0.5。我们这里使用的版本是3.0.4,以append-only(只附加)方式进行数据管理,与其配合使用的是Microsoft Azure Redis Cache工具。

Tarantool是一款开源NoSQL数据库管理系统。我们使用的是Tarantool 1.6.7-126-gb35aff9,日志采用write-ahead(先写)模式。Memcached是一款分布式内存缓存系统,这里使用是Memcached 1.4.14-0ubuntu9。

Couchbase Server是开源分布式NoSQL面向文档数据库,这里使用的版本是Couchbase 4.0.0-4047-1。

YCSB测试工具

Yahoo! Cloud Serving Benchmark(YCSB)是功能强大的NoSQL数据库性能测试工具,它提供了6种主要的负载工作类型,以字母A到F来区分。

负载A负责更新操作,极值是50/50的读写操作,如用于进行新近操作记录。负载B负责读取操作,极值是95/5的读写操作,如用于进行图片标签管理,多进行标签读取操作。负载C负载100%的读取操作,如用于进行用户属性获取。负载D以先进先出方式进行插入操作,如用户进行最新数据读取。负载E负责小范围记录读取而不是单个记录读取,如线程会话。负载F负责记录的读取,修改和写入,如用户信息管理。

我们对配置文件作了两处参数修改:数据条目recordcount设为200000,操作条目operationcount设为5000000。YCSB是多线程工具,我们将以8, 16, 32, 64, 128 及256 线程来进行测试。详细的测试脚本请点击这里进行下载。

下列测试结果图以颜色进行测试对象区分,

Tarantool (HASH) (蓝)

Tarantool (TREE)(浅蓝)

Redis (红)

Azure Redis Cache (橙)

Memcached (绿)

CouchBase(黑)

更多图片请点击[这里]查看。

结论

Tarantool在所有负载类型测试中皆取得了最优成绩。它创建了一个无锁内存引擎,以协同多任务方式进行操作而不是互斥或并行处理方式。根据以下性能图表现,我们的结论是Tarantool的高吞吐量处理是其最大优势之一。因此在多数场合下,Tarantool是用户的最佳选择。

NoSQL和MySQL的区别大吗?

即非关系型数据库和关系型数据库。

MySQL的优点:事务处理—保持数据的一致性;由于以标准化为前提,数据更新的开销很小(相同的字段基本上只有一处);可以进行Join等复杂查询

NoSQL的优点:首先它是基于内存的,也就是数据放在内存中,而不是像数据库那样把数据放在磁盘上,而内存的读取速度是磁盘读取速度的几十倍到上百倍,所以NoSQL工具的速度远比数据库读取速度要快得多,满足了高响应的要求。即使NoSQL将数据放在磁盘中,它也是一种半结构化的数据 格式,读取到解析的复杂度远比MySQL要简单,这是因为MySQL存储的是经过结构化、多范式等有复杂规则的数据,还原为内存结构的速度较慢。NoSQL在很大程度上满足了高并发、快速读/和响应的要求,所以它也是Java互联网系统的利器。

简单的扩展:典型例子是Cassandra,由于其架构是类似于经典的P2P,所以能通过轻松地添加新的节点来扩展这个集群;

低廉的成本:这是大多数分布式数据库共有的特点,因为主要都是开源软件,没有昂贵的License成本;

NoSQL的缺点:大多数NoSQL数据库都不支持事务,也不像 SQL Server和Oracle那样能提供各种附加功能,比如BI和报表等; 不提供对SQL的支持

那么该如何选择?

如果规模和性能比24小时的数据一致性更重要,那NoSQL是一个理想的选择 (NoSQL依赖于BASE模型——基本可用、软状态、最终一致性)。

但如果要保证到“始终一致”,尤其是对于机密信息和财务信息,那么MySQL很可能是最优的选择(MySQL依赖于ACID模型——原子性、一致性、独立性和耐久性)。

如果关系数据库在你的应用场景中,完全能够很好的工作,而你又是非常善于使用和维护关系数据库的,那么我觉得你完全没有必要迁移到NoSQL上面,除非你是个喜欢折腾的人。如果你是在金融,电信等以数据为王的关键领域,目前使用的是Oracle数据库来提供高可靠性的,除非遇到特别大的瓶颈,不然也别贸然尝试NoSQL。

然而,在WEB2.0的网站中,关系数据库大部分都出现了瓶颈。在磁盘IO、数据库可扩展上都花费了开发人员相当多的精力来优化,比如做分表分库(database sharding)、主从复制、异构复制等等,然而,这些工作需要的技术能力越来越高,也越来越具有挑战性。如果你正在经历这些场合,那么我觉得你应该尝试一下NoSQL了。

具体问题具体分析

MySQL体积小、速度快、成本低、结构稳定、便于查询,可以保证数据的一致性,但缺乏灵活性。

NoSQL高性能、高扩展、高可用,不用局限于固定的结构,减少了时间和空间上的开销,却又很难保证数据一致性。

————————————————

版权声明:本文为CSDN博主「蒟蒻熊」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:

简述什么是nosql数据库,并列举两种常见的nosql数据库名称及其特点

NoSQL太火,冒出太多产品了,保守估计也成百上千了。

互联网公司常用的基本集中在以下几种,每种只举一个比较常见或者应用比较成功的例子吧。

1. In-Memory KV Store : Redis

in memory key-value store,同时提供了更加丰富的数据结构和运算的能力,成功用法是替代memcached,通过checkpoint和commit log提供了快速的宕机恢复,同时支持replication提供读可扩展和高可用。

2. Disk-Based KV Store: Leveldb

真正基于磁盘的key-value storage, 模型单一简单,数据量不受限于内存大小,数据落盘高可靠,Google的几位大神出品的精品,LSM模型天然写优化,顺序写盘的方式对于新硬件ssd再适合不过了,不足是仅提供了一个库,需要自己封装server端。

3. Document Store: Mongodb

分布式nosql,具备了区别mysql的最大亮点:可扩展性。mongodb 最新引人的莫过于提供了sql接口,是目前nosql里最像mysql的,只是没有ACID的特性,发展很快,支持了索引等特性,上手容易,对于数据量远超内存限制的场景来说,还需要慎重。

4. Column Table Store: HBase

这个富二代似乎不用赘述了,最大的优势是开源,对于普通的scan和基于行的get等基本查询,性能完全不是问题,只是只提供裸的api,易用性上是短板,可扩展性方面是最强的,其次坐上了Hadoop的快车,社区发展很快,各种基于其上的开源产品不少,来解决诸如join、聚集运算等复杂查询。


分享题目:本地nosql性能,nosql主要解决了大数据环境下的
网站URL:http://myzitong.com/article/hdegip.html