nosql怎样组建集群的简单介绍

一、NoSQL数据库简介

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

在丹东等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供网站设计制作、网站设计 网站设计制作按需定制网站,公司网站建设,企业网站建设,品牌网站建设,营销型网站,成都外贸网站制作,丹东网站建设费用合理。

随着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最普遍的解释是“非关系型的”，强调Key-Value Stores和文档数据库的优点，而不是单纯的反对RDBMS。

非关系型数据库特点

1.可以处理超大量的数据。

2.运行在便宜的PC服务器集群上。PC集群扩充起来非常方便并且成本很低，避免了“sharding”操作的复杂性和成本。

3.击碎了性能瓶颈。NoSQL的支持者称，通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间，执行速度变得更快。

4.没有过多的操作。

5.支持者来源于社区。因为NoSQL项目都是开源的，因此它们缺乏供应商提供的正式支持。这一点它们与大多数开源项目一样，不得不从社区中寻求支持。

NoSQL-HDFS-基本概念

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的功能。

优点：

缺点：

【软件架构篇】互联网架构模板

架构图如下图所示。这张图基本涵盖了互联网技术公司的大部分技术点，不同公司只是在具体的技术实现上稍有差异，但不会跳出这个框架的范畴。

SQL： 常用的有mysql，用于存储业务数据。互联网发展初期，各个业务一般都会独立运营mysql集群，但随着业务越来越多，mysql集群规模越来越大，那就有必要做成SQL平台。

NoSQL: 翻译为Not Only SQL，作为mysql的一种补充。Nosql一般本身就提供集群，且使用起来很方便，公司业务发展初期没有必要。一般Nosql集群的数量越来越多，那就有必要做成Nosql平台。

小文件： 互联网中有很多小文件，比如商品图片，Facebook的图片。这类小文件具有数据小、数量巨大、访问大的特点。如果每个业务都去考虑小文件存储的话，就会出现重复造轮子现象，那就有必要做成小文件平台了。

大文件： 互联网的大文件主要分为两类：一类是业务上的大数据，例如Youtube的视频、电影网站的电影；另一类是海量的日志数据，例如各种访问日志。实力雄厚的一些大公司会基于开源方案做成大数据平台。

开发框架： 比如常见的Spring框架。

Web服务器： 常见的有tomcat、jetty等。

容器： Docker可以极大降低运维成本，以及在实现动态扩容上非常方便。

配置中心： 故名思义，配置中心就是集中管理各个系统的配置。

服务中心： 解决跨系统依赖的配置和调度问题。比如有10个系统依赖A系统的x接口，此时A系统实现了一个y接口可以更好地支持x接口，那么如果直接更新10个系统依赖的配置将会很麻烦。

消息队列： 支持系统解耦。

负载均衡： 充当任务分配器的职责。

CDN： 可以对一些常用文件进行就近缓存，来提高访问速度。

多机房： 多机房的主要目的是备灾，当机房故障时可以快速地将业务切换到另外一个机房，这种切换操作允许一定时间的中断，比如10分钟，1个小时。

多中心： 多中心的要求就更高了，要求同时对外提供服务，且业务能够自动在多中心之间切换，故障后不需人工干预或者很少的人工干预就能自动恢复。

用户管理： 对各个系统的用户进行统一管理。

消息推送： 根据不同途径分为短信、邮件、站内信、App推送。

存储云： 实现是CDN+小文件存储。

图片云： 实现也是CDN+小文件存储。为何不与存储云统一一套系统呢？这是因为图片业务的复杂性导致的。图片涉及的业务会更多，包括裁剪、压缩、美化、审核、水印等。

业务千差万别，各个互联网业务面对的主要问题是复杂度越来越高。此时就要用到拆和合的技术。拆即将一个大系统拆分为多个子系统，降低复杂度。当子系统越来越多，有可能就需要采用合的技术。

测试平台的核心目的是提升测试效率。

运维平台的核心职责分为四大块：配置、部署、监控、应急。

数据平台的核心职责主要包含三部分：数据管理、数据分析和数据应用。

管理平台的核心职责就是权限管理。