189 8069 5689
一、概念
在瑞安等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供成都网站制作、成都做网站 网站设计制作按需开发,公司网站建设,企业网站建设,品牌网站设计,网络营销推广,外贸网站建设,瑞安网站建设费用合理。
SQL (Structured Query Language) 数据库，指关系型数据库。主要代表：SQL Server，Oracle，MySQL(开源)，PostgreSQL(开源)。
NoSQL（Not Only SQL）泛指非关系型数据库。主要代表：MongoDB，Redis，CouchDB。
二、区别
1、存储方式
SQL数据存在特定结构的表中；而NoSQL则更加灵活和可扩展，存储方式可以省是JSON文档、哈希表或者其他方式。SQL通常以数据库表形式存储数据。举个栗子，存个学生借书数据：
而NoSQL存储方式比较灵活，比如使用类JSON文件存储上表中熊大的借阅数据：
2、表/数据集合的数据的关系
在SQL中，必须定义好表和字段结构后才能添加数据，例如定义表的主键(primary key)，索引(index),触发器(trigger),存储过程(stored procedure)等。表结构可以在被定义之后更新，但是如果有比较大的结构变更的话就会变得比较复杂。在NoSQL中，数据可以在任何时候任何地方添加，不需要先定义表。例如下面这段代码会自动创建一个新的"借阅表"数据集合：
NoSQL也可以在数据集中建立索引。以MongoDB为例，会自动在数据集合创建后创建唯一值_id字段，这样的话就可以在数据集创建后增加索引。
从这点来看，NoSQL可能更加适合初始化数据还不明确或者未定的项目中。
3、外部数据存储
SQL中如何需要增加外部关联数据的话，规范化做法是在原表中增加一个外键，关联外部数据表。例如需要在借阅表中增加审核人信息，先建立一个审核人表：
再在原来的借阅人表中增加审核人外键：
这样如果我们需要更新审核人个人信息的时候只需要更新审核人表而不需要对借阅人表做更新。而在NoSQL中除了这种规范化的外部数据表做法以外，我们还能用如下的非规范化方式把外部数据直接放到原数据集中，以提高查询效率。缺点也比较明显，更新审核人数据的时候将会比较麻烦。
4、SQL中的JOIN查询
SQL中可以使用JOIN表链接方式将多个关系数据表中的数据用一条简单的查询语句查询出来。NoSQL暂未提供类似JOIN的查询方式对多个数据集中的数据做查询。所以大部分NoSQL使用非规范化的数据存储方式存储数据。
5、数据耦合性
SQL中不允许删除已经被使用的外部数据，例如审核人表中的"熊三"已经被分配给了借阅人熊大，那么在审核人表中将不允许删除熊三这条数据，以保证数据完整性。而NoSQL中则没有这种强耦合的概念，可以随时删除任何数据。
6、事务
SQL中如果多张表数据需要同批次被更新，即如果其中一张表更新失败的话其他表也不能更新成功。这种场景可以通过事务来控制，可以在所有命令完成后再统一提交事务。而NoSQL中没有事务这个概念，每一个数据集的操作都是原子级的。
7、增删改查语法
8、查询性能
在相同水平的系统设计的前提下，因为NoSQL中省略了JOIN查询的消耗，故理论上性能上是优于SQL的。
什么是NoSQL
大家有没有听说过“NoSQL”呢?近年，这个词极受关注。看到“NoSQL”这个词，大家可能会误以为是“No!SQL”的缩写，并深感愤怒：“SQL怎么会没有必要了呢?”但实际上，它是“Not Only SQL”的缩写。它的意义是：适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。
为弥补关系型数据库的不足，各种各样的NoSQL数据库应运而生。
为了更好地了解本书所介绍的NoSQL数据库，对关系型数据库的理解是必不可少的。那么，就让我们先来看一看关系型数据库的历史、分类和特征吧。
关系型数据库简史
1969年，埃德加?6?1弗兰克?6?1科德(Edgar Frank Codd)发表了划时代的论文，首次提出了关系数据模型的概念。但可惜的是，刊登论文的《IBM Research Report》只是IBM公司的内部刊物，因此论文反响平平。1970年，他再次在刊物《Communication of the ACM》上发表了题为“A Relational Model of Data for Large Shared Data banks”(大型共享数据库的关系模型)的论文，终于引起了大家的关注。
科德所提出的关系数据模型的概念成为了现今关系型数据库的基础。当时的关系型数据库由于硬件性能低劣、处理速度过慢而迟迟没有得到实际应用。但之后随着硬件性能的提升，加之使用简单、性能优越等优点，关系型数据库得到了广泛的应用。
通用性及高性能
虽然本书是讲解NoSQL数据库的，但有一个重要的大前提，请大家一定不要误解。这个大前提就是“关系型数据库的性能绝对不低，它具有非常好的通用性和非常高的性能”。毫无疑问，对于绝大多数的应用来说它都是最有效的解决方案。
突出的优势
关系型数据库作为应用广泛的通用型数据库，它的突出优势主要有以下几点:
保持数据的一致性(事务处理)
由于以标准化为前提，数据更新的开销很小(相同的字段基本上都只有一处)
可以进行JOIN等复杂查询
存在很多实际成果和专业技术信息(成熟的技术)
这其中，能够保持数据的一致性是关系型数据库的最大优势。在需要严格保证数据一致性和处理完整性的情况下，用关系型数据库是肯定没有错的。但是有些情况不需要JOIN，对上述关系型数据库的优点也没有什么特别需要，这时似乎也就没有必要拘泥于关系型数据库了。
关系型数据库的不足
不擅长的处理
就像之前提到的那样，关系型数据库的性能非常高。但是它毕竟是一个通用型的数据库，并不能完全适应所有的用途。具体来说它并不擅长以下处理：
大量数据的写入处理
为有数据更新的表做索引或表结构(schema)变更
字段不固定时应用
对简单查询需要快速返回结果的处理
。。。。。。
NoSQL数据库
为了弥补关系型数据库的不足(特别是最近几年)，NoSQL数据库出现了。关系型数据库应用广泛，能进行事务处理和JOIN等复杂处理。相对地，NoSQL数据库只应用在特定领域，基本上不进行复杂的处理，但它恰恰弥补了之前所列举的关系型数据库的不足之处。
易于数据的分散
如前所述，关系型数据库并不擅长大量数据的写入处理。原本关系型数据库就是以JOIN为前提的，就是说，各个数据之间存在关联是关系型数据库得名的主要原因。为了进行JOIN处理，关系型数据库不得不把数据存储在同一个服务器内，这不利于数据的分散。相反，NoSQL数据库原本就不支持JOIN处理，各个数据都是独立设计的，很容易把数据分散到多个服务器上。由于数据被分散到了多个服务器上，减少了每个服务器上的数据量，即使要进行大量数据的写入操作，处理起来也更加容易。同理，数据的读入操作当然也同样容易。
提升性能和增大规模
下面说一点题外话，如果想要使服务器能够轻松地处理更大量的数据，那么只有两个选择：一是提升性能，二是增大规模。下面我们来整理一下这两者的不同。
首先，提升性能指的就是通过提升现行服务器自身的性能来提高处理能力。这是非常简单的方法，程序方面也不需要进行变更，但需要一些费用。若要购买性能翻倍的服务器，需要花费的资金往往不只是原来的2倍，可能需要多达5到10倍。这种方法虽然简单，但是成本较高。
另一方面，增大规模指的是使用多台廉价的服务器来提高处理能力。它需要对程序进行变更，但由于使用廉价的服务器，可以控制成本。另外，以后只要依葫芦画瓢增加廉价服务器的数量就可以了。
不对大量数据进行处理的话就没有使用的必要吗？
NoSQL数据库基本上来说为了“使大量数据的写入处理更加容易(让增加服务器数量更容易)”而设计的。但如果不是对大量数据进行操作的话，NoSQL数据库的应用就没有意义吗?
答案是否定的。的确，它在处理大量数据方面很有优势。但实际上NoSQL数据库还有各种各样的特点，如果能够恰当地利用这些特点将会是非常有帮助。具体的例子将会在第2章和第3章进行介绍，这些用途将会让你感受到利用NoSQL的好处。
希望顺畅地对数据进行缓存(Cache)处理
希望对数组类型的数据进行高速处理
希望进行全部保存
多样的NoSQL数据库
NoSQL数据库存在着“key-value存储”、“文档型数据库”、“列存储数据库”等各种各样的种类，每种数据库又包含各自的特点。下一节让我们一起来了解一下NoSQL数据库的种类和特点。
NoSQL数据库是什么
NoSQL说起来简单，但实际上到底有多少种呢?我在提笔的时候，到NoSQL的官方网站上确认了一下，竟然已经有122种了。另外官方网站上也介绍了本书没有涉及到的图形数据库和对象数据库等各个类别。不知不觉间，原来已经出现了这么多的NoSQL数据库啊。
本节将为大家介绍具有代表性的NoSQL数据库。
key-value存储
这是最常见的NoSQL数据库，它的数据是以key-value的形式存储的。虽然它的处理速度非常快，但是基本上只能通过key的完全一致查询获取数据。根据数据的保存方式可以分为临时性、永久性和两者兼具三种。
临时性
memcached属于这种类型。所谓临时性就是 “数据有可能丢失”的意思。memcached把所有数据都保存在内存中，这样保存和读取的速度非常快，但是当memcached停止的时候，数据就不存在了。由于数据保存在内存中，所以无法操作超出内存容量的数据(旧数据会丢失)。
在内存中保存数据
可以进行非常快速的保存和读取处理
数据有可能丢失
永久性
Tokyo Tyrant、Flare、ROMA等属于这种类型。和临时性相反，所谓永久性就是“数据不会丢失”的意思。这里的key-value存储不像memcached那样在内存中保存数据，而是把数据保存在硬盘上。与memcached在内存中处理数据比起来，由于必然要发生对硬盘的IO操作，所以性能上还是有差距的。但数据不会丢失是它最大的优势。
在硬盘上保存数据
可以进行非常快速的保存和读取处理(但无法与memcached相比)
数据不会丢失
两者兼具
Redis属于这种类型。Redis有些特殊，临时性和永久性兼具，且集合了临时性key-value存储和永久性key-value存储的优点。Redis首先把数据保存到内存中，在满足特定条件(默认是15分钟一次以上，5分钟内10个以上，1分钟内10000个以上的key发生变更)的时候将数据写入到硬盘中。这样既确保了内存中数据的处理速度，又可以通过写入硬盘来保证数据的永久性。这种类型的数据库特别适合于处理数组类型的数据。
同时在内存和硬盘上保存数据
可以进行非常快速的保存和读取处理
保存在硬盘上的数据不会消失(可以恢复)
适合于处理数组类型的数据
面向文档的数据库
MongoDB、CouchDB属于这种类型。它们属于NoSQL数据库，但与key-value存储相异。
不定义表结构
面向文档的数据库具有以下特征：即使不定义表结构，也可以像定义了表结构一样使用。关系型数据库在变更表结构时比较费事，而且为了保持一致性还需修改程序。然而NoSQL数据库则可省去这些麻烦(通常程序都是正确的)，确实是方便快捷。
可以使用复杂的查询条件
跟key-value存储不同的是，面向文档的数据库可以通过复杂的查询条件来获取数据。虽然不具备事务处理和JOIN这些关系型数据库所具有的处理能力，但除此以外的其他处理基本上都能实现。这是非常容易使用的NoSQL数据库。
不需要定义表结构
可以利用复杂的查询条件
面向列的数据库
Cassandra、Hbase、HyperTable属于这种类型。由于近年来数据量出现爆发性增长，这种类型的NoSQL数据库尤其引人注目。
面向行的数据库和面向列的数据库
普通的关系型数据库都是以行为单位来存储数据的，擅长进行以行为单位的读入处理，比如特定条件数据的获取。因此，关系型数据库也被称为面向行的数据库。相反，面向列的数据库是以列为单位来存储数据的，擅长以列为单位读入数据。
高扩展性
面向列的数据库具有高扩展性，即使数据增加也不会降低相应的处理速度(特别是写入速度)，所以它主要应用于需要处理大量数据的情况。另外，利用面向列的数据库的优势，把它作为批处理程序的存储器来对大量数据进行更新也是非常有用的。但由于面向列的数据库跟现行数据库存储的思维方式有很大不同，应用起来十分困难。
高扩展性(特别是写入处理)
应用十分困难
最近，像Twitter和Facebook这样需要对大量数据进行更新和查询的网络服务不断增加，面向列的数据库的优势对其中一些服务是非常有用的，但是由于这与本书所要介绍的内容关系不大，就不进行详细介绍了。
总结：
NoSQL并不是No-SQL，而是指Not Only SQL。
NoSQL的出现是为了弥补SQL数据库因为事务等机制带来的对海量数据、高并发请求的处理的性能上的欠缺。
NoSQL不是为了替代SQL而出现的，它是一种替补方案，而不是解决方案的首选。
绝大多数的NoSQL产品都是基于大内存和高性能随机读写的（比如具有更高性能的固态硬盘阵列），一般的小型企业在选择NoSQL时一定要慎重！不要为了NoSQL而NoSQL，可能会导致花了冤枉钱又耽搁了项目进程。
NoSQL不是万能的，但在大型项目中，你往往需要它！
nosql是not only sql的意思。是近今年新发展起来的存储系统。当前使用最多的是key-value模型，用于处理超大规模的数据。
以下是摘自百度百科中的一部分
NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。
当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系，如Facebook 的Cassandra， Apache 的HBase，也得到了广泛认同。从这些NoSQL项目的名字上看不出什么相同之处：Hadoop、Voldemort、Dynomite，还有其它很多。
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，也得到了广泛认同。
大数据分析师应该要学的知识有，统计概率理论基础，软件操作结合分析模型进行实际运用，数据挖掘或者数据分析方向性选择，数据分析业务应用。
1、统计概率理论基础
这是重中之重，千里之台，起于垒土，最重要的就是最下面的那几层。统计思维，统计方法，这里首先是市场调研数据的获取与整理，然后是最简单的描述性分析，其次是常用的推断性分析，方差分析，到高级的相关，回归等多元统计分析，掌握了这些原理，才能进行下一步。
2、软件操作结合分析模型进行实际运用
关于数据分析主流软件有（从上手度从易到难）：Excel，SPSS，Stata，R，SAS等。首先是学会怎样操作这些软件，然后是利用软件从数据的清洗开始一步步进行处理，分析，最后输出结果，检验及解读数据。
3、数据挖掘或者数据分析方向性选择
其实数据分析也包含数据挖掘，但在工作中做到后面会细分到分析方向和挖掘方向，两者已有区别，关于数据挖掘也涉及到许多模型算法，如：关联法则、神经网络、决策树、遗传算法、可视技术等。
4、数据分析业务应用
这一步也是最难学习的一步，行业有别，业务不同，业务的不同所运用的分析方法亦有区分，实际工作是解决业务问题，因此对业务的洞察能力非常重要。扩展资料
分析工作内容
1、搜索引擎分析师(Search Engine Optimization Strategy Analyst，简称SEO分析师)是一项新兴信息技术职业，主要关注搜索引擎动态，修建网站，拓展网络营销渠道，网站内部优化，流量数据分析，策划外链执行方案，负责竞价推广。
2、SEO分析师需要精通商业搜索引擎相关知识与市场运作。通过编程，HTML，CSS，JavaScript，MicrosoftASP.NET，Perl，PHP，Python等建立网站进行各种以用户体验为主同时带给公司盈利但可能失败的项目尝试。
2. 什么是NoSQL？
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，
泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。
（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 关系型数据库与NoSQL的区别？
3.1 RDBMS
高度组织化结构化数据
结构化查询语言（SQL）
数据和关系都存储在单独的表中。
数据操纵语言，数据定义语言
严格的一致性
基础事务
ACID
关系型数据库遵循ACID规则
事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：
A (Atomicity) 原子性
原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。
C (Consistency) 一致性
一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。
I (Isolation) 独立性
所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。
3.2 NoSQL
代表着不仅仅是SQL
没有声明性查询语言
没有预定义的模式
键 - 值对存储，列存储，文档存储，图形数据库
最终一致性，而非ACID属性
非结构化和不可预知的数据
CAP定理
高性能，高可用性和可伸缩性
分布式数据库中的CAP原理(了解)
CAP定理：
Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
P: 系统中任意信息的丢失或失败不会影响系统的继续运作。
定理：任何分布式系统只可同时满足二点，没法三者兼顾。
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。
而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。
所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。
说明：C：强一致性 A：高可用性 P：分布式容忍性
举例：
CA：传统Oracle数据库
AP：大多数网站架构的选择
CP：Redis、Mongodb
注意：分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。
因此牺牲C换取P，这是目前分布式数据库产品的方向。
4. 当下NoSQL的经典应用
当下的应用是 SQL 与 NoSQL 一起使用的。
代表项目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型机，很贵的，好像好几万一台；O 是指 Oracle 数据库，也很贵的，好几万呢；M 是指 EMC 的存储设备，也很贵的。
难点：
数据类型多样性。
数据源多样性和变化重构。
数据源改造而服务平台不需要大面积重构。