13518219792
NoSQL，指的是非关系型的数据库。NoSQL有时也称作Not Only SQL的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称。
成都创新互联专注于企业网络营销推广、网站重做改版、商水网站定制设计、自适应品牌网站建设、H5页面制作、商城开发、集团公司官网建设、成都外贸网站建设公司、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为商水等各大城市提供网站开发制作服务。
NoSQL用于超大规模数据的存储。（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
NoSQL的优点/缺点
优点:
- 高可扩展性
- 分布式计算
- 低成本
- 架构的灵活性，半结构化数据
- 没有复杂的关系
缺点:
- 没有标准化
- 有限的查询功能（到目前为止）
- 最终一致是不直观的程序 （BY三人行慕课）
1、NoSQL：以前的翻译是“不使用SQL”：因为有一部分认为SQL查询复杂了。现在的翻译是“不仅仅是SQL”NOSQL数据库与关系性数据最大的区别在于数据存储方面。NOSQL采用文档的形式存储数据、关系型数据库采用表的结构存储数据。
2、NOSQL在大数据面前比SQL数据库更占优势。
7个因素决定大数据的复杂性 如何处理
我们谈论了很多关于复杂数据及其为你的商业智能带来的挑战和机遇，但是导致数据复杂化的是什么呢？
以及你如何区分你的公司当前的数据是否是“复杂的”，亦或不久的将来会变得复杂？本文将解决这些问题。
为什么这很重要？
当你试图将数据转化为商业价值时，它的复杂度很可能会预示你将面对的困难程度——复杂数据的准备和分析通常要比简单数据更加困难，以及通常需要一组不同的BI 工具来实现。复杂数据在可以“成熟的”分析和可视化之前需要额外的准备工作和数据模型。因此重要的是，通过了解您目前的数据的复杂程度以及它在未来的复杂性趋向，来评估您的大数据/商业智能项目是否能够胜任这一任务。
简单测试：大数据或者异构数据
在高级层面上，有两种基本的迹象表明你的数据可能被视为是复杂的：
你的数据很“大”：我们把大放在引号里是因为它貌似符合“大数据”术语的含义。然而事实是，处理海量数据在计算资源需要处理巨大的数据集方面提出了一个挑战， 就像把小麦从谷壳分开的困难，或者说在一个巨大的原始信息中辨别信号和杂音。
你的数据来自许多不同的数据源：多重数据源通常意味着脏数据，或者遵循着不同的内部逻辑结构的简单的多个数据集。为了确保数据源有统一的数据语言，数据必须被转换或整合到一个中央资源库。
可以认为这是两个最初的（可供选择的）征兆：如果你正处理大数据或异构数据，你应当开始思考数据的复杂性。但是深究一下，对你的公司的数据的复杂性，以下有7个更具体的指标。
（注意，以上两点之间有相似之处，但不互相排除——反之，例如，离散数据往往意味着各种各样的数据结构类型）
7个因素决定你的数据的复杂性
1、数据结构
不同数据源的数据，或甚至来自同一个源的不同表，通常设计同样的信息但结构却完全不同：
举例来说，想象你们人力资源部有三种不同的表格，一个是员工个人信息表，另一个是员工职位和薪资表第三个是员工职位要求表，诸如此类——而你们财务部门随同保险、福利和其他花费一起记录同样的信息到单个表中。另外，在这些表中的一些表可能提到员工的全名，而另一些则只有名字的首字母，或者二者的结合。为了从所有表中有效使用数据，同时不丢失或重复信息，需要数据建模或准备工作。
这是最简单的用例：更进一步复杂化的是处理最初没有适当地模式的非结构化数据源（例如NoSQL 数据库）。
2、数据大小
再次回到模糊的“大数据”概念，你收集的数据量会影响你需要用来分析它的软硬件的类型。这个可以通过原始大小来衡量：字节，TB或PB——数据增长越大，越有可能“窒息”广泛使用的内存数据库（IMDB），依赖于转化压缩数据到服务器内存。其他因素包括多元异构数据——包含很多数据行的表（Excel，可以说是最常用的数据分析工具，最大行数限制为1048576行），或结构化数据——包含很多数据列的表。
你将会发现在分析工具和方法上用于分析100,000行数据和那些用于分析1亿行数据的是明显不同的。
3、数据细节
你想要探索的数据的粒度水平。当创建一个仪表盘或报表，展现总结或聚合数据时常常比让终端用户钻取到每一个细节更容易实现——然而这是以牺牲数据分析的深度和数据挖掘为代价而做的权宜之计。
创建一个BI系统，使其具有颗粒向海量数据钻取处理分析的能力，（不依赖于预定义查询，聚合或汇总表）
4、查询语言
不同的数据源有不同的数据语言：虽然SQL是从常见数据源和RDBMS提取数据的主要手段，但是当使用第三方平台时你会经常需要通过它自己的API和语法去连接它，以及解析用于访问数据的数据模型和协议。
你的BI工具需要足够灵活的根据数据源允许这种本地连接的方式，或者通过内置插件或API访问，否则你会发现你自己将不得不重复一个繁琐的导出数据到表格SQL数据库数据仓库的过程，然后导入到你的商业智能软件里，从而使你的分析变得麻烦。
5、数据类型
一方面动态数据以表格形式存储，处理的大多是数值型数据，但是大规模和非结构化的机器数据完全是另外一回事儿，就像是文字数据集存储在MongoDB中，当然了，更别提像视频音频这种超大规模的非结构化数据了。
不同的数据类型具有不同的规则，为使得商业决策建立在对公司数据的全面考虑的基础上，找到一种建立单一可信来源的方法是至关重要的。
6、离散数据
数据存储在多个位置：例如，组织里的不同部门，本地或云（付费存储或通过云应用），来自客户或供应商的外部数据等。这种数据不仅收集起来很困难（简单来说是由于及时而有效的接收数据而需要的利益相关者的数量）。而且一旦收集了——在不同的数据集交叉引用和分析之前，通常需要“清理”或标准化，因为每个本地数据集是根据相关组织应用程序自身的实际和关注收集数据。
7、数据量的增长
最终，你不仅需要考虑当前数据，还有数据的增长或变化的速度。如果经常更新数据源，或经常增加新的数据源，这将会消耗你的软硬件资源（无论何时当源数据发生重大更改时,不是非常先进的系统都需要重新获取整个数据集）,以及上述提到的关于结构、类型、大小的复合性问题等。
怎样掌控复杂数据？
如果你认同上述的一个或更多以及你的数据刚刚好是复杂的，不要绝望：理解，是找到一个合适的解决方案的第一步，以及复杂数据的分析本身不需要过于复杂。我们将在未来的文章中涉及解决复杂数据的方法，但是你将想问自己的第一件事可能是——控制复杂数据你实际需要多少BI系统。
以上是小编为大家分享的关于7个因素决定大数据的复杂性 如何处理的相关内容，更多信息可以关注环球青藤分享更多干货
本质是因为：随着互联网的进一步发展与各行业信息化建设进程加快、参与者的增多，人们对软件有了更多更新的要求，需要软件不仅能实现功能，而且要求保证许多人可以共同参与使用，因而软件所需承载的数据量和吞吐量必须达到相应的需求。而目前的关系型数据库在某些方面有一些缺点，导致不能满足需要。
具体则需要对比关系型数据库与Nosql之间的区别可以得出
关系型数据库
关系型数据库把所有的数据都通过行和列的二元表现形式表示出来。
关系型数据库的优势：
1. 保持数据的一致性（事务处理）
2.由于以标准化为前提，数据更新的开销很小（相同的字段基本上都只有一处）
3. 可以进行Join等复杂查询
其中能够保持数据的一致性是关系型数据库的最大优势。
关系型数据库的不足：
不擅长的处理
1. 大量数据的写入处理（这点尤为重要）
2. 为有数据更新的表做索引或表结构（schema）变更
3. 字段不固定时应用
4. 对简单查询需要快速返回结果的处理
--大量数据的写入处理
读写集中在一个数据库上让数据库不堪重负，大部分网站已使用主从复制技术实现读写分离，以提高读写性能和读库的可扩展性。
所以在进行大量数据操作时，会使用数据库主从模式。数据的写入由主数据库负责，数据的读入由从数据库负责，可以比较简单地通过增加从数据库来实现规模化，但是数据的写入却完全没有简单的方法来解决规模化问题。
第一，要想将数据的写入规模化，可以考虑把主数据库从一台增加到两台，作为互相关联复制的二元主数据库使用，确实这样可以把每台主数据库的负荷减少一半，但是更新处理会发生冲突，可能会造成数据的不一致，为了避免这样的问题，需要把对每个表的请求分别分配给合适的主数据库来处理。
第二，可以考虑把数据库分割开来，分别放在不同的数据库服务器上，比如将不同的表放在不同的数据库服务器上，数据库分割可以减少每台数据库服务器上的数据量，以便减少硬盘IO的输入、输出处理，实现内存上的高速处理。但是由于分别存储字不同服务器上的表之间无法进行Join处理，数据库分割的时候就需要预先考虑这些问题，数据库分割之后，如果一定要进行Join处理，就必须要在程序中进行关联，这是非常困难的。
--为有数据更新的表做索引或表结构变更
在使用关系型数据库时，为了加快查询速度需要创建索引，为了增加必要的字段就一定要改变表结构，为了进行这些处理，需要对表进行共享锁定，这期间数据变更、更新、插入、删除等都是无法进行的。如果需要进行一些耗时操作，例如为数据量比较大的表创建索引或是变更其表结构，就需要特别注意，长时间内数据可能无法进行更新。
--字段不固定时的应用
如果字段不固定，利用关系型数据库也是比较困难的，有人会说，需要的时候加个字段就可以了，这样的方法也不是不可以，但在实际运用中每次都进行反复的表结构变更是非常痛苦的。你也可以预先设定大量的预备字段，但这样的话，时间一长很容易弄不清除字段和数据的对应状态，即哪个字段保存有哪些数据。
--对简单查询需要快速返回结果的处理 （这里的“简单”指的是没有复杂的查询条件）
这一点称不上是缺点，但不管怎样，关系型数据库并不擅长对简单的查询快速返回结果，因为关系型数据库是使用专门的sql语言进行数据读取的，它需要对sql与越南进行解析，同时还有对表的锁定和解锁等这样的额外开销，这里并不是说关系型数据库的速度太慢，而只是想告诉大家若希望对简单查询进行高速处理，则没有必要非使用关系型数据库不可。
NoSQL数据库
关系型数据库应用广泛，能进行事务处理和表连接等复杂查询。相对地，NoSQL数据库只应用在特定领域，基本上不进行复杂的处理，但它恰恰弥补了之前所列举的关系型数据库的不足之处。
优点：
易于数据的分散
各个数据之间存在关联是关系型数据库得名的主要原因，为了进行join处理，关系型数据库不得不把数据存储在同一个服务器内，这不利于数据的分散，这也是关系型数据库并不擅长大数据量的写入处理的原因。相反NoSQL数据库原本就不支持Join处理，各个数据都是独立设计的，很容易把数据分散在多个服务器上，故减少了每个服务器上的数据量，即使要处理大量数据的写入，也变得更加容易，数据的读入操作当然也同样容易。
典型的NoSQL数据库
临时性键值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase）
一、 键值存储
它的数据是以键值的形式存储的，虽然它的速度非常快，但基本上只能通过键的完全一致查询获取数据，根据数据的保存方式可以分为临时性、永久性和两者兼具 三种。
（1）临时性
所谓临时性就是数据有可能丢失，memcached把所有数据都保存在内存中，这样保存和读取的速度非常快，但是当memcached停止时，数据就不存在了。由于数据保存在内存中，所以无法操作超出内存容量的数据，旧数据会丢失。总结来说：
。在内存中保存数据
。可以进行非常快速的保存和读取处理
。数据有可能丢失
（2）永久性
所谓永久性就是数据不会丢失，这里的键值存储是把数据保存在硬盘上，与临时性比起来，由于必然要发生对硬盘的IO操作，所以性能上还是有差距的，但数据不会丢失是它最大的优势。总结来说：
。在硬盘上保存数据
。可以进行非常快速的保存和读取处理（但无法与memcached相比）
。数据不会丢失
（3） 两者兼备
Redis属于这种类型。Redis有些特殊，临时性和永久性兼具。Redis首先把数据保存在内存中，在满足特定条件（默认是 15分钟一次以上，5分钟内10个以上，1分钟内10000个以上的键发生变更）的时候将数据写入到硬盘中，这样既确保了内存中数据的处理速度，又可以通过写入硬盘来保证数据的永久性，这种类型的数据库特别适合处理数组类型的数据。总结来说：
。同时在内存和硬盘上保存数据
。可以进行非常快速的保存和读取处理
。保存在硬盘上的数据不会消失（可以恢复）
。适合于处理数组类型的数据
二、面向文档的数据库
MongoDB、CouchDB属于这种类型，它们属于NoSQL数据库，但与键值存储相异。
（1）不定义表结构
即使不定义表结构，也可以像定义了表结构一样使用，还省去了变更表结构的麻烦。
（2）可以使用复杂的查询条件
跟键值存储不同的是，面向文档的数据库可以通过复杂的查询条件来获取数据，虽然不具备事务处理和Join这些关系型数据库所具有的处理能力，但初次以外的其他处理基本上都能实现。
三、 面向列的数据库
Cassandra、HBae、HyperTable属于这种类型，由于近年来数据量出现爆发性增长，这种类型的NoSQL数据库尤其引入注目。
普通的关系型数据库都是以行为单位来存储数据的，擅长以行为单位的读入处理，比如特定条件数据的获取。因此，关系型数据库也被成为面向行的数据库。相反，面向列的数据库是以列为单位来存储数据的，擅长以列为单位读入数据。
面向列的数据库具有搞扩展性，即使数据增加也不会降低相应的处理速度（特别是写入速度），所以它主要应用于需要处理大量数据的情况。另外，把它作为批处理程序的存储器来对大量数据进行更新也是非常有用的。但由于面向列的数据库跟现行数据库存储的思维方式有很大不同，故应用起来十分困难。
总结：关系型数据库与NoSQL数据库并非对立而是互补的关系，即通常情况下使用关系型数据库，在适合使用NoSQL的时候使用NoSQL数据库，让NoSQL数据库对关系型数据库的不足进行弥补。
本文将从单机MySQL的场景出发，简述一下随着网站的访问量越来越大，数据库部署的演进过程，到为什么要用MySQL的必要性。
大数据时代的数据有3V的特点：海量Volume、多样Variety、实时Velocity。
互联网网站需求的3高的特点：高并发、高可扩、高性能。
一、单机MySql
当一个网站的访问量不大时，用单个数据库完全可以轻松应付。
在那个时候，更多的都是静态网页，动态交互类型的网站不多。
上述架构下，我们来看看数据存储的瓶颈是什么？
1.数据量的总大小 一个机器放不下时
2.数据的索引（B+ Tree）一个机器的内存放不下时
3.访问量(读写混合)一个实例不能承受
如果满足了上述1 or 3个，进化......
二、Memcached（缓存）+Mysql+垂直拆分
后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。
Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端
三、MySql主从复制读写分离
由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。
四、分库分表+水平拆分+Mysql集群
在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。
同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但性能也不能很好满足互联网的要求，只是在高可靠性上提供了非常大的保证。
五、Mysql的扩展性瓶颈
MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。
六、为什么用Nosql
今天我们可以通过第三方平台（如：Google,Facebook等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了, NoSQL数据库的发展也却能很好的处理这些大的数据。下面给大家看一下，web应用数据量的增长图：
七、Nosql是什么
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，
泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。
（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
八、Nosql的优势
1.易扩展
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。
数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
2.大数据量，高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。
这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
3.多样灵活的数据模型
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。
九、Nosql数据库的四大分类
键值(Key-Value)存储
列存储
文档存储
图形存储
常见的有：Redis、Memcache、MongoDB，这里就不一 一 介绍了。
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。
