13518219792
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 ： db.getProfilingStatus()
返回：
{
"was": NumberInt("0"),
"slowms": NumberInt("100")
}
注：was：0表示未开启。1表示记录慢命令（默认：执行时常超过100ms）2表示记录所有命令。
二、修改was：
nosql： db.setProfilingLevel(2)
三、查看操作日志
nosql：db.system.profile.find()
而传统的关系数据库在应付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，也得到了广泛认同。
Hadoop
文件系统：文件系统是用来存储和管理文件，并且提供文件的查询、增加、删除等操作。
直观上的体验：在shell窗口输入 ls 命令，就可以看到当前目录下的文件夹、文件。
文件存储在哪里？硬盘
一台只有250G硬盘的电脑，如果需要存储500G的文件可以怎么办？先将电脑硬盘扩容至少250G，再将文件分割成多块，放到多块硬盘上储存。
通过 hdfs dfs -ls 命令可以查看分布式文件系统中的文件，就像本地的ls命令一样。
HDFS在客户端上提供了查询、新增和删除的指令，可以实现将分布在多台机器上的文件系统进行统一的管理。
在分布式文件系统中，一个大文件会被切分成块，分别存储到几台机器上。结合上文中提到的那个存储500G大文件的那个例子，这500G的文件会按照一定的大小被切分成若干块，然后分别存储在若干台机器上，然后提供统一的操作接口。
看到这里，不少人可能会觉得，分布式文件系统不过如此，很简单嘛。事实真的是这样的么？
潜在问题
假如我有一个1000台机器组成的分布式系统，一台机器每天出现故障的概率是0.1%，那么整个系统每天出现故障的概率是多大呢？答案是(1-0.1%)^1000=63%，因此需要提供一个容错机制来保证发生差错时文件依然可以读出，这里暂时先不展开介绍。
如果要存储PB级或者EB级的数据，成千上万台机器组成的集群是很常见的，所以说分布式系统比单机系统要复杂得多呀。
这是一张HDFS的架构简图：
client通过nameNode了解数据在哪些DataNode上，从而发起查询。此外，不仅是查询文件，写入文件的时候也是先去请教NameNode，看看应该往哪个DateNode中去写。
为了某一份数据只写入到一个Datanode中，而这个Datanode因为某些原因出错无法读取的问题，需要通过冗余备份的方式来进行容错处理。因此，HDFS在写入一个数据块的时候，不会仅仅写入一个DataNode，而是会写入到多个DataNode中，这样，如果其中一个DataNode坏了，还可以从其余的DataNode中拿到数据，保证了数据不丢失。
实际上，每个数据块在HDFS上都会保存多份，保存在不同的DataNode上。这种是牺牲一定存储空间换取可靠性的做法。
接下来我们来看一下完整的文件写入的流程：
大文件要写入HDFS，client端根据配置将大文件分成固定大小的块，然后再上传到HDFS。
读取文件的流程：
1、client询问NameNode，我要读取某个路径下的文件，麻烦告诉我这个文件都在哪些DataNode上？
2、NameNode回复client，这个路径下的文件被切成了3块，分别在DataNode1、DataNode3和DataNode4上
3、client去找DataNode1、DataNode3和DataNode4，拿到3个文件块，通过stream读取并且整合起来
文件写入的流程：
1、client先将文件分块，然后询问NameNode，我要写入一个文件到某个路径下，文件有3块，应该怎么写？
2、NameNode回复client，可以分别写到DataNode1、DataNode2、DataNode3、DataNode4上，记住，每个块重复写3份，总共是9份
3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把数据写到他们上面
出于容错的考虑，每个数据块有3个备份，但是3个备份快都直接由client端直接写入势必会带来client端过重的写入压力，这个点是否有更好的解决方案呢？回忆一下mysql主备之间是通过binlog文件进行同步的，HDFS当然也可以借鉴这个思想，数据其实只需要写入到一个datanode上，然后由datanode之间相互进行备份同步，减少了client端的写入压力，那么至于是一个datanode写入成功即成功，还是需要所有的参与备份的datanode返回写入成功才算成功，是可靠性配置的策略，当然这个设置会影响到数据写入的吞吐率，我们可以看到可靠性和效率永远是“鱼和熊掌不可兼得”的。
潜在问题
NameNode确实会回放editlog，但是不是每次都从头回放，它会先加载一个fsimage，这个文件是之前某一个时刻整个NameNode的文件元数据的内存快照，然后再在这个基础上回放editlog，完成后，会清空editlog，再把当前文件元数据的内存状态写入fsimage，方便下一次加载。
这样，全量回放就变成了增量回放，但是如果NameNode长时间未重启过，editlog依然会比较大，恢复的时间依然比较长，这个问题怎么解呢？
SecondNameNode是一个NameNode内的定时任务线程，它会定期地将editlog写入fsimage，然后情况原来的editlog，从而保证editlog的文件大小维持在一定大小。
NameNode挂了， SecondNameNode并不能替代NameNode，所以如果集群中只有一个NameNode，它挂了，整个系统就挂了。hadoop2.x之前，整个集群只能有一个NameNode，是有可能发生单点故障的，所以hadoop1.x有本身的不稳定性。但是hadoop2.x之后，我们可以在集群中配置多个NameNode，就不会有这个问题了，但是配置多个NameNode，需要注意的地方就更多了，系统就更加复杂了。
俗话说“一山不容二虎”，两个NameNode只能有一个是活跃状态active，另一个是备份状态standby，我们看一下两个NameNode的架构图。
两个NameNode通过JournalNode实现同步editlog，保持状态一致可以相互替换。
因为active的NameNode挂了之后，standby的NameNode要马上接替它，所以它们的数据要时刻保持一致，在写入数据的时候，两个NameNode内存中都要记录数据的元信息，并保持一致。这个JournalNode就是用来在两个NameNode中同步数据的，并且standby NameNode实现了SecondNameNode的功能。
进行数据同步操作的过程如下：
active NameNode有操作之后，它的editlog会被记录到JournalNode中，standby NameNode会从JournalNode中读取到变化并进行同步，同时standby NameNode会监听记录的变化。这样做的话就是实时同步了，并且standby NameNode就实现了SecondNameNode的功能。
优点：
缺点：
数据库日志记录是高可用的数据库解决方案设计的重要部分，它可以从故障中恢复过来，同步主数据库和辅助数据库都需要用到数据库日志。
所有数据库都有相关的日志，这些日志保存了有关数据库更改的记录。
如果需要将数据库复原到上一完整、脱机备份之前的一个点，那么需要日志才能将数据前滚至故障点。
先存在nosql 中，然后存在数据库中，
然后过一段时间 （验证网站无异常），清理掉访问日志。
但是这些规则指定好之后，不要外传，属于公司内部机密。
请采纳！
