189 8069 5689
1.大数据是什么?
成都创新互联是一家专注于成都做网站、成都网站建设与策划设计,灵武网站建设哪家好?成都创新互联做网站,专注于网站建设10年,网设计领域的专业建站公司;建站业务涵盖:灵武等地区。灵武做网站价格咨询:18982081108
大数据是最近IT界最常用的术语之一。然而对大数据的定义也不尽相同，所有已知的论点例如结构化的和非结构化、大规模的数据等等都不够完整。大数据系统通常被认为具有数据的五个主要特征，通常称为数据的5 Vs。分别是大规模，多样性，高效性、准确性和价值性。
据Gartner称，大规模可以被定义为“在本(地)机数据采集和处理技术能力不足以为用户带来商业价值。当现有的技术能够针对性的进行改造后来处理这种规模的数据就可以说是一个成功的大数据解决方案。
这种大规模的数据没将不仅仅是来自于现有的数据源，同时也会来自于一些新兴的数据源，例如常规(手持、工业)设备，日志，汽车等，当然包括结构化的和非结构化的数据。
据Gartner称，多样性可以定义如下：“高度变异的信息资产，在生产和消费时不进行严格定义的包括多种形式、类型和结构的组合。同时还包括以前的历史数据，由于技术的变革历史数据同样也成为多样性数据之一 “。
高效性可以被定义为来自不同源的数据到达的速度。从各种设备，传感器和其他有组织和无组织的数据流都在不断进入IT系统。由此，实时分析和对于该数据的解释(展示)的能力也应该随之增加。
根据Gartner，高效性可以被定义如下：“高速的数据流I/O(生产和消费)，但主要聚焦在一个数据集内或多个数据集之间的数据生产的速率可变上”。
准确性，或真实性或叫做精度是数据的另一个重要组成方面。要做出正确的商业决策，当务之急是在数据上进行的所有分析必须是正确和准确(精确)的。
大数据系统可以提供巨大的商业价值。像电信，金融，电子商务，社交媒体等，已经认识到他们的数据是一个潜在的巨大的商机。他们可以预测用户行为，并推荐相关产品，提供危险交易预警服务，等等。
与其他IT系统一样，性能是大数据系统获得成功的关键。本文的中心主旨是要说明如何让大数据系统保证其性能。
2.大数据系统应包含的功能模块
大数据系统应该包含的功能模块，首先是能够从多种数据源获取数据的功能，数据的预处理(例如，清洗，验证等)，存储数据，数据处理、数据分析等(例如做预测分析，生成在线使用建议等等)，最后呈现和可视化的总结、汇总结果。
下图描述了大数据系统的这些高层次的组件：
2.1各种各样的数据源
当今的IT生态系统，需要对各种不同种类来源的数据进行分析。这些来源可能是从在线Web应用程序，批量上传或feed，流媒体直播数据，来自工业、手持、家居传感的任何东西等等。
显然从不同数据源获取的数据具有不同的格式、使用不同的协议。例如，在线的Web应用程序可能会使用SOAP / XML格式通过HTTP发送数据，feed可能会来自于CSV文件，其他设备则可能使用MQTT通信协议。
由于这些单独的系统的性能是不在大数据系统的控制范围之内，并且通常这些系统都是外部应用程序，由第三方供应商或团队提供并维护，所以本文将不会在深入到这些系统的性能分析中去。
2.2数据采集
第一步，获取数据。这个过程包括分析，验证，清洗，转换，去重，然后存到适合你们公司的一个持久化设备中(硬盘、存储、云等)。
在下面的章节中，本文将重点介绍一些关于如何获取数据方面的非常重要的技巧。请注意，本文将不讨论各种数据采集技术的优缺点。
2.3存储数据
第二步，一旦数据进入大数据系统，清洗，并转化为所需格式时，这些过程都将在数据存储到一个合适的持久化层中进行。
在下面的章节中，本文将介绍一些存储方面的最佳实践(包括逻辑上和物理上)。在本文结尾也会讨论一部分涉及数据安全方面的问题。
2.4数据处理和分析
第三步，在这一阶段中的一部分干净数据是去规范化的，包括对一些相关的数据集的数据进行一些排序，在规定的时间间隔内进行数据结果归集，执行机器学习算法，预测分析等。
在下面的章节中，本文将针对大数据系统性能优化介绍一些进行数据处理和分析的最佳实践。
2.5数据的可视化和数据展示
最后一个步骤，展示经过各个不同分析算法处理过的数据结果。该步骤包括从预先计算汇总的结果(或其他类似数据集)中的读取和用一种友好界面或者表格(图表等等)的形式展示出来。这样便于对于数据分析结果的理解。
3.数据采集中的性能技巧
数据采集是各种来自不同数据源的数据进入大数据系统的第一步。这个步骤的性能将会直接决定在一个给定的时间段内大数据系统能够处理的数据量的能力。
数据采集过程基于对该系统的个性化需求，但一些常用执行的步骤是 – 解析传入数据，做必要的验证，数据清晰，例如数据去重，转换格式，并将其存储到某种持久层。
涉及数据采集过程的逻辑步骤示如下图所示：
下面是一些性能方面的技巧：
●来自不同数据源的传输应该是异步的。可以使用文件来传输、或者使用面向消息的(MoM)中间件来实现。由于数据异步传输，所以数据采集过程的吞吐量可以大大高于大数据系统的处理能力。 异步数据传输同样可以在大数据系统和不同的数据源之间进行解耦。大数据基础架构设计使得其很容易进行动态伸缩，数据采集的峰值流量对于大数据系统来说算是安全的。
●如果数据是直接从一些外部数据库中抽取的，确保拉取数据是使用批量的方式。
●如果数据是从feed file解析，请务必使用合适的解析器。例如，如果从一个XML文件中读取也有不同的解析器像JDOM，SAX，DOM等。类似地，对于CSV，JSON和其它这样的格式，多个解析器和API是可供选择。选择能够符合需求的性能最好的。
●优先使用内置的验证解决方案。大多数解析/验证工作流程的通常运行在服务器环境(ESB /应用服务器)中。大部分的场景基本上都有现成的标准校验工具。在大多数的情况下，这些标准的现成的工具一般来说要比你自己开发的工具性能要好很多。
●类似地，如果数据XML格式的，优先使用XML(XSD)用于验证。
●即使解析器或者校等流程使用自定义的脚本来完成，例如使用java优先还是应该使用内置的函数库或者开发框架。在大多数的情况下通常会比你开发任何自定义代码快得多。
●尽量提前滤掉无效数据，以便后续的处理流程都不用在无效数据上浪费过多的计算能力。
●大多数系统处理无效数据的做法通常是存放在一个专门的表中，请在系统建设之初考虑这部分的数据库存储和其他额外的存储开销。
●如果来自数据源的数据需要清洗，例如去掉一些不需要的信息，尽量保持所有数据源的抽取程序版本一致，确保一次处理的是一个大批量的数据，而不是一条记录一条记录的来处理。一般来说数据清洗需要进行表关联。数据清洗中需要用到的静态数据关联一次，并且一次处理一个很大的批量就能够大幅提高数据处理效率。
●数据去重非常重要这个过程决定了主键的是由哪些字段构成。通常主键都是时间戳或者id等可以追加的类型。一般情况下，每条记录都可能根据主键进行索引来更新，所以最好能够让主键简单一些，以保证在更新的时候检索的性能。
●来自多个源接收的数据可以是不同的格式。有时，需要进行数据移植，使接收到的数据从多种格式转化成一种或一组标准格式。
●和解析过程一样，我们建议使用内置的工具，相比于你自己从零开发的工具性能会提高很多。
●数据移植的过程一般是数据处理过程中最复杂、最紧急、消耗资源最多的一步。因此，确保在这一过程中尽可能多的使用并行计算。
●一旦所有的数据采集的上述活动完成后，转换后的数据通常存储在某些持久层，以便以后分析处理，综述，聚合等使用。
●多种技术解决方案的存在是为了处理这种持久(RDBMS，NoSQL的分布式文件系统，如Hadoop和等)。
●谨慎选择一个能够最大限度的满足需求的解决方案。
4.数据存储中的性能技巧
一旦所有的数据采集步骤完成后，数据将进入持久层。
在本节中将讨论一些与数据数据存储性能相关的技巧包括物理存储优化和逻辑存储结构(数据模型)。这些技巧适用于所有的数据处理过程，无论是一些解析函数生的或最终输出的数据还是预计算的汇总数据等。
●首先选择数据范式。您对数据的建模方式对性能有直接的影响，例如像数据冗余，磁盘存储容量等方面。对于一些简单的文件导入数据库中的场景，你也许需要保持数据原始的格式，对于另外一些场景，如执行一些分析计算聚集等，你可能不需要将数据范式化。
●大多数的大数据系统使用NoSQL数据库替代RDBMS处理数据。
●不同的NoSQL数据库适用不同的场景，一部分在select时性能更好，有些是在插入或者更新性能更好。
●数据库分为行存储和列存储。
●具体的数据库选型依赖于你的具体需求(例如，你的应用程序的数据库读写比)。
●同样每个数据库都会根据不同的配置从而控制这些数据库用于数据库复制备份或者严格保持数据一致性。
●这些设置会直接影响数据库性能。在数据库技术选型前一定要注意。
●压缩率、缓冲池、超时的大小，和缓存的对于不同的NoSQL数据库来说配置都是不同的，同时对数据库性能的影响也是不一样的。
●数据Sharding和分区是这些数据库的另一个非常重要的功能。数据Sharding的方式能够对系统的性能产生巨大的影响，所以在数据Sharding和分区时请谨慎选择。
●并非所有的NoSQL数据库都内置了支持连接，排序，汇总，过滤器，索引等。
●如果有需要还是建议使用内置的类似功能，因为自己开发的还是不灵。
●NoSQLs内置了压缩、编解码器和数据移植工具。如果这些可以满足您的部分需求，那么优先选择使用这些内置的功能。这些工具可以执行各种各样的任务，如格式转换、压缩数据等，使用内置的工具不仅能够带来更好的性能还可以降低网络的使用率。
●许多NoSQL数据库支持多种类型的文件系统。其中包括本地文件系统，分布式文件系统，甚至基于云的存储解决方案。
●如果在交互式需求上有严格的要求，否则还是尽量尝试使用NoSQL本地(内置)文件系统(例如HBase 使用HDFS)。
●这是因为，如果使用一些外部文件系统/格式，则需要对数据进行相应的编解码/数据移植。它将在整个读/写过程中增加原本不必要的冗余处理。
●大数据系统的数据模型一般来说需要根据需求用例来综合设计。与此形成鲜明对比的是RDMBS数据建模技术基本都是设计成为一个通用的模型，用外键和表之间的关系用来描述数据实体与现实世界之间的交互。
●在硬件一级，本地RAID模式也许不太适用。请考虑使用SAN存储。
5.数据处理分析中的性能技巧
数据处理和分析是一个大数据系统的核心。像聚合，预测，聚集，和其它这样的逻辑操作都需要在这一步完成。
本节讨论一些数据处理性能方面的技巧。需要注意的是大数据系统架构有两个组成部分，实时数据流处理和批量数据处理。本节涵盖数据处理的各个方面。
●在细节评估和数据格式和模型后选择适当的数据处理框架。
●其中一些框架适用于批量数据处理，而另外一些适用于实时数据处理。
●同样一些框架使用内存模式，另外一些是基于磁盘io处理模式。
●有些框架擅长高度并行计算，这样能够大大提高数据效率。
●基于内存的框架性能明显优于基于磁盘io的框架，但是同时成本也可想而知。
●概括地说，当务之急是选择一个能够满足需求的框架。否则就有可能既无法满足功能需求也无法满足非功能需求，当然也包括性能需求。
●一些这些框架将数据划分成较小的块。这些小数据块由各个作业独立处理。协调器管理所有这些独立的子作业
●在数据分块是需要当心。
●该数据快越小，就会产生越多的作业，这样就会增加系统初始化作业和清理作业的负担。
●如果数据快太大，数据传输可能需要很长时间才能完成。这也可能导致资源利用不均衡，长时间在一台服务器上运行一个大作业，而其他服务器就会等待。
●不要忘了查看一个任务的作业总数。在必要时调整这个参数。
●最好实时监控数据块的传输。在本机机型io的效率会更高，这么做也会带来一个副作用就是需要将数据块的冗余参数提高(一般hadoop默认是3份)这样又会反作用使得系统性能下降。
●此外，实时数据流需要与批量数据处理的结果进行合并。设计系统时尽量减少对其他作业的影响。
●大多数情况下同一数据集需要经过多次计算。这种情况可能是由于数据抓取等初始步骤就有报错，或者某些业务流程发生变化，值得一提的是旧数据也是如此。设计系统时需要注意这个地方的容错。
●这意味着你可能需要存储原始数据的时间较长，因此需要更多的存储。
●数据结果输出后应该保存成用户期望看到的格式。例如，如果最终的结果是用户要求按照每周的时间序列汇总输出，那么你就要将结果以周为单位进行汇总保存。
●为了达到这个目标，大数据系统的数据库建模就要在满足用例的前提下进行。例如，大数据系统经常会输出一些结构化的数据表，这样在展示输出上就有很大的优势。
●更常见的是，这可能会这将会让用户感觉到性能问题。例如用户只需要上周的数据汇总结果，如果在数据规模较大的时候按照每周来汇总数据，这样就会大大降低数据处理能力。
●一些框架提供了大数据查询懒评价功能。在数据没有在其他地方被使用时效果不错。
●实时监控系统的性能，这样能够帮助你预估作业的完成时间。
6.数据可视化和展示中的性能技巧
精心设计的高性能大数据系统通过对数据的深入分析，能够提供有价值战略指导。这就是可视化的用武之地。良好的可视化帮助用户获取数据的多维度透视视图。
需要注意的是传统的BI和报告工具，或用于构建自定义报表系统无法大规模扩展满足大数据系统的可视化需求。同时，许多COTS可视化工具现已上市。
本文将不会对这些个别工具如何进行调节，而是聚焦在一些通用的技术，帮助您能打造可视化层。
●确保可视化层显示的数据都是从最后的汇总输出表中取得的数据。这些总结表可以根据时间短进行汇总，建议使用分类或者用例进行汇总。这么做可以避免直接从可视化层读取整个原始数据。
●这不仅最大限度地减少数据传输，而且当用户在线查看在报告时还有助于避免性能卡顿问题。
●重分利用大化可视化工具的缓存。缓存可以对可视化层的整体性能产生非常不错的影响。
●物化视图是可以提高性能的另一个重要的技术。
●大部分可视化工具允许通过增加线程数来提高请求响应的速度。如果资源足够、访问量较大那么这是提高系统性能的好办法。
●尽量提前将数据进行预处理，如果一些数据必须在运行时计算请将运行时计算简化到最小。
●可视化工具可以按照各种各样的展示方法对应不同的读取策略。其中一些是离线模式、提取模式或者在线连接模式。每种服务模式都是针对不同场景设计的。
●同样，一些工具可以进行增量数据同步。这最大限度地减少了数据传输，并将整个可视化过程固化下来。
●保持像图形，图表等使用最小的尺寸。
●大多数可视化框架和工具的使用可缩放矢量图形(SVG)。使用SVG复杂的布局可能会产生严重的性能影响。
7.数据安全以及对于性能的影响
像任何IT系统一样安全性要求也对大数据系统的性能有很大的影响。在本节中，我们讨论一下安全对大数据平台性能的影响。
– 首先确保所有的数据源都是经过认证的。即使所有的数据源都是安全的，并且没有针对安全方面的需求，那么你可以灵活设计一个安全模块来配置实现。
– 数据进过一次认证，那么就不要进行二次认证。如果实在需要进行二次认证，那么使用一些类似于token的技术保存下来以便后续继续使用。这将节省数据一遍遍认证的开销。
– 您可能需要支持其他的认证方式，例如基于PKI解决方案或Kerberos。每一个都有不同的性能指标，在最终方案确定前需要将其考虑进去。
– 通常情况下数据压缩后进入大数据处理系统。这么做好处非常明显不细说。
– 针对不同算法的效率、对cpu的使用量你需要进行比较来选出一个传输量、cpu使用量等方面均衡的压缩算法。
– 同样，评估加密逻辑和算法，然后再选择。
– 明智的做法是敏感信息始终进行限制。
– 在审计跟踪表或登录时您可能需要维护记录或类似的访问，更新等不同的活动记录。这可能需要根据不同的监管策略和用户需求个性化的进行设计和修改。
– 注意，这种需求不仅增加了数据处理的复杂度，但会增加存储成本。
– 尽量使用下层提供的安全技术，例如操作系统、数据库等。这些安全解决方案会比你自己设计开发性能要好很多。
8.总结
本文介绍了各种性能方面的技巧，这些技术性的知道可以作为打造大数据分析平台的一般准则。大数据分析平台非常复杂，为了满足这种类型系统的性能需求，需要我们从开始建设的时候进行考量。
本文介绍的技术准则可以用在大数据平台建设的各个不同阶段，包括安全如何影响大数据分析平台的性能。
Nosql全称是Not Only SQL，是一种不同于关系型数据库的数据库管理系统设计方式。对NoSQL最普遍的解释是“非关系型的”，强调Key-Value Stores和文档数据库的优点，而不是单纯的反对RDBMS
mogodb是非关系型（NoSQL）数据库，它文档型数据库。
我用过mongodb做了个小项目练习，我简单说说（因为我也了解不深）它与传统数据库的区别吧：
最基本的区别就是数据模型的区别：
传统数据库 从大到小为数据库，表，行。而mongodb是：数据库，集合，文档，BSON（类似json的二进制数据）。
传统数据库需要预定义表结构（一经定义，不能改变），而mongodb不需要，而且文档结构可变化（比如说用来相关的文档是放在同一个集合的，但同一个集合的文档不一定结构都是相同的）
应该还有，想不起来了。
数据模型不同，对应的查询方式也不同。传统的数据库查询方式都是sql，而mongodb的查询方式和sql完全不一样。
还有其他的，如提高可靠性的方案，原子操作的级别等等也不一样。
传统数据库的一些概念在mongodb是不存在的。
设计数据库的时候也不一样，传统数据库在设计时会进行范式化规范化，而mongodb数据库进行设计时候往往会反范式。
下面是从百度百科拿来的：
对于NoSQL并没有一个明确的范围和定义，但是他们都普遍存在下面一些共同特征：
不需要预定义模式：不需要事先定义数据模式，预定义表结构。数据中的每条记录都可能有不同的属性和格式。当插入数据时，并不需要预先定义它们的模式。
无共享架构：相对于将所有数据存储的存储区域网络中的全共享架构。NoSQL往往将数据划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能，从而提高了系统的性能。
弹性可扩展：可以在系统运行的时候，动态增加或者删除结点。不需要停机维护，数据可以自动迁移。
分区：相对于将数据存放于同一个节点，NoSQL数据库需要将数据进行分区，将记录分散在多个节点上面。并且通常分区的同时还要做复制。这样既提高了并行性能，又能保证没有单点失效的问题。
异步复制：和RAID存储系统不同的是，NoSQL中的复制，往往是基于日志的异步复制。这样，数据就可以尽快地写入一个节点，而不会被网络传输引起迟延。缺点是并不总是能保证一致性，这样的方式在出现故障的时候，可能会丢失少量的数据。
BASE：相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。BASE是最终一致性和软事务。
NoSQL数据库并没有一个统一的架构，两种NoSQL数据库之间的不同，甚至远远超过两种关系型数据库的不同。可以说，NoSQL各有所长，成功的NoSQL必然特别适用于某些场合或者某些应用，在这些场合中会远远胜过关系型数据库和其他的NoSQL。
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
大家有没有听说过“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不是万能的，但在大型项目中，你往往需要它！
1、在本地和服务器都安装同样的数据库客户端，如oracle常用SQLPlus、MySQL常用HeiDi sql或者navicat、mssql2005则常用SQL Server Management Studio；
2、在本地通过数据库客户端导出数据库为sql文件；
3、将sql文件远程传递到服务器上；
4、在服务器上用相同的数据库客户端将sql文件执行一遍即可将本地数据库导入到服务器上。