“大数据架构”用哪种框架更为合适

个完整的大数据平台应该提供离线计算、即席查询、实时计算、实时查询这几个方面的功能。

hadoop、spark、storm无论哪一个，单独不可能完成上面的所有功能。

hadoop+spark+hive是一个很不错的选择hadoop的HDFS毋庸置疑是分布式文件系统的解决方案，解决存储问题；hadoopmapreduce、hive、sparkapplication、sparkSQL解决的是离线计算和即席查询的问题；sparkstreaming解决的是实时计算问题；另外，还需要HBase或者Redis等NOSQL技术来解决实时查询的问题。

除了这些，大数据平台中必不可少的需要任务调度系统和数据交换工具；

任务调度系统解决所有大数据平台中的任务调度与监控；数据交换工具解决其他数据源与HDFS之间的数据传输，比如：数据库到HDFS、HDFS到数据库等等。关于大数据平台的架构技术文章，可搜索"lxw的大数据田地"，里面有很多。

大数据是什么意思：

麦肯锡全球研究所给出的定义是：一种规模大到在获取、存储、管理、分析方面大大超出了传统数据库软件工具能力范围的数据集合，具有海量的数据规模、快速的数据流转、多样的数据类型和价值密度低四大特征。

大数据技术的战略意义不在于掌握庞大的数据信息，而在于对这些含有意义的数据进行专业化处理。换而言之，如果把大数据比作一种产业，那么这种产业实现盈利的关键，在于提高对数据的“加工能力”，通过“加工”实现数据的“增值”。从技术上看，大数据与云计算的关系就像一枚硬币的正反面一样密不可分。大数据必然无法用单台的计算机进行处理，必须采用分布式架构。它的特色在于对海量数据进行分布式数据挖掘。但它必须依托云计算的分布式处理、分布式数据库和云存储、虚拟化技术。

随着云时代的来临，大数据（Bigdata）也吸引了越来越多的关注。大数据（Bigdata）通常用来形容一个公司创造的大量非结构化数据和半结构化数据，这些数据在下载到关系型数据库用于分析时会花费过多时间和金钱。大数据分析常和云计算联系到一起，因为实时的大型数据集分析需要像MapReduce一样的框架来向数十、数百或甚至数千的电脑分配工作。

大数据需要特殊的技术，以有效地处理大量的容忍经过时间内的数据。适用于大数据的技术，包括大规模并行处理（MPP）数据库、数据挖掘、分布式文件系统、分布式数据库、云计算平台、互联网和可扩展的存储系统。

问题一：大数据技术有哪些 非常多的，问答不能发link，不然我给你link了。有譬如Hadoop等开源大数据项目的，编程语言的，以下就大数据底层技术说下。

简单以永洪科技的技术说下，有四方面，其实也代表了部分通用大数据底层技术：

Z-Suite具有高性能的大数据分析能力，她完全摒弃了向上升级(Scale-Up)，全面支持横向扩展(Scale-Out)。Z-Suite主要通过以下核心技术来支撑PB级的大数据：

跨粒度计算(In-Databaseputing)

Z-Suite支持各种常见的汇总，还支持几乎全部的专业统计函数。得益于跨粒度计算技术，Z-Suite数据分析引擎将找寻出最优化的计算方案，继而把所有开销较大的、昂贵的计算都移动到数据存储的地方直接计算，我们称之为库内计算(In-Database)。这一技术大大减少了数据移动，降低了通讯负担，保证了高性能数据分析。

并行计算(MPP puting)

Z-Suite是基于MPP架构的商业智能平台，她能够把计算分布到多个计算节点，再在指定节点将计算结果汇总输出。Z-Suite能够充分利用各种计算和存储资源，不管是服务器还是普通的PC，她对网络条件也没有严苛的要求。作为横向扩展的大数据平台，Z-Suite能够充分发挥各个节点的计算能力，轻松实现针对TB/PB级数据分析的秒级响应。

列存储 (Column-Based)

Z-Suite是列存储的。基于列存储的数据集市，不读取无关数据，能降低读写开销，同时提高I/O 的效率，从而大大提高查询性能。另外，列存储能够更好地压缩数据，一般压缩比在5 -10倍之间，这样一来，数据占有空间降低到传统存储的1/5到1/10 。良好的数据压缩技术，节省了存储设备和内存的开销，却大大了提升计算性能。

内存计算

得益于列存储技术和并行计算技术，Z-Suite能够大大压缩数据，并同时利用多个节点的计算能力和内存容量。一般地，内存访问速度比磁盘访问速度要快几百倍甚至上千倍。通过内存计算，CPU直接从内存而非磁盘上读取数据并对数据进行计算。内存计算是对传统数据处理方式的一种加速，是实现大数据分析的关键应用技术。

问题二：大数据使用的数据库是什么数据库 ORACLE、DB2、SQL SERVER都可以，关键不是选什么数据库，而是数据库如何优化！ 需要看你日常如何 *** 作，以查询为主或是以存储为主或2者，还要看你的数据结构，都要因地制宜的去优化！所以不是一句话说的清的！

问题三：什么是大数据和大数据平台 大数据技术是指从各种各样类型的数据中，快速获得有价值信息的能力。适用于大数据的技术，包括大规模并行处理（MPP）数据库，数据挖掘电网，分布式文件系统，分布式数据库，云计算平台，互联网，和可扩展的存储系统。

大数据平台是为了计算，现今社会所产生的越来越大的数据量。以存储、运算、展现作为目的的平台。

问题四：常用大型数据库有哪些 FOXBASE

MYSQL

这俩可算不上大型数据库管理系统

PB 是数据库应用程序开发用的ide，根本就不是数据库管理系统

Foxbase是dos时代的产品了，进入windows时代改叫foxpro，属于桌面单机级别的小型数据库系统，mysql是个中轻量级的，但是开源，大量使用于小型网站，真正重量级的是Oracle和DB2，银行之类的关键行业用的多是这两个，微软的MS SQLServer相对DB2和Oracle规模小一些，多见于中小型企业单位使用，Sybase可以说是日薄西山，不行了

问题五：几大数据库的区别 最商业的是ORACLE,做的最专业,然后是微软的SQL server,做的也很好,当然还有DB2等做得也不错,这些都是大型的数据库,,,如果掌握的全面的话,可以保证数据的安全 然后就是些小的数据库access,mysql等,适合于中小企业的数据库100万数据一下的数据如有帮助请采纳,谢!

问题六：全球最大的数据库是什么 应该是Oracle，第一，Oracle为商业界所广泛采用。因为它规范、严谨而且服务到位，且安全性非常高。第二，如果你学习使用Oracle不是商用，也可以免费使用。这就为它的广泛传播奠定了在技术人员中的基础。第三，Linux/Unix系统常常作为服务器，服务器对Oracle的使用简直可以说极其多啊。建议楼梗多学习下这个强大的数据库

问题七：什么是大数据？ 大数据(big data)，或称巨量资料，指的是所涉及的资料量规模巨大到无法通过目前主流软件工具，在合理时间内达到撷取、管理、处理、并整理成为帮助企业经营决策更积极目的的资讯。(在维克托・迈尔-舍恩伯格及肯尼斯・库克耶编写的《大数据时代》中大数据指不用随机分析法（抽样调查）这样的捷径，而采用所有数据的方法[2]）大数据的4V特点：Volume（大量）、Velocity（高速）、Variety（多样）、Value（价值）。

说起大数据，就要说到商业智能：

商业智能（Business Intelligence，简称：BI），又称商业智慧或商务智能，指用现代数据仓库技术、线上分析处理技术、数据挖掘和数据展现技术进行数据分析以实现商业价值。

商业智能作为一个工具，是用来处理企业中现有数据，并将其转换成知识、分析和结论，辅助业务或者决策者做出正确且明智的决定。是帮助企业更好地利用数据提高决策质量的技术，包含了从数据仓库到分析型系统等。

商务智能的产生发展

商业智能的概念经由Howard Dresner(1989年)的通俗化而被人们广泛了解。当时将商业智能定义为一类由数据仓库（或数据集市）、查询报表、数据分析、数据挖掘、数据备份和恢复等部分组成的、以帮助企业决策为目的技术及其应用。

商务智能是20世纪90年代末首先在国外企业界出现的一个术语，其代表为提高企业运营性能而采用的一系列方法、技术和软件。它把先进的信息技术应用到整个企业，不仅为企业提供信息获取能力，而且通过对信息的开发，将其转变为企业的竞争优势，也有人称之为混沌世界中的智能。因此，越来越多的企业提出他们对BI的需求，把BI作为一种帮助企业达到经营目标的一种有效手段。

目前，商业智能通常被理解为将企业中现有的数据转化为知识，帮助企业做出明智的业务经营决策的工具。这里所谈的数据包括来自企业业务系统的订单、库存、交易账目、客户和供应商资料及来自企业所处行业和竞争对手的数据，以及来自企业所处的其他外部环境中的各种数据。而商业智能能够辅助的业务经营决策既可以是作业层的，也可以是管理层和策略层的决策。

为了将数据转化为知识，需要利用数据仓库、线上分析处理（OLAP）工具和数据挖掘等技术。因此，从技术层面上讲，商业智能不是什么新技术，它只是ETL、数据仓库、OLAP、数据挖掘、数据展现等技术的综合运用。

把商业智能看成是一种解决方案应该比较恰当。商业智能的关键是从许多来自不同的企业运作系统的数据中提取出有用的数据并进行清理，以保证数据的正确性，然后经过抽取（Extraction）、转换（Transformation）和装载（Load），即ETL过程，合并到一个企业级的数据仓库里，从而得到企业数据的一个全局视图，在此基础上利用合适的查询和分析工具、数据挖掘工具、OLAP工具等对其进行分析和处理（这时信息变为辅助决策的知识），最后将知识呈现给管理者，为管理者的决策过程提供支持。

企业导入BI的优点

1随机查询动态报表

2掌握指标管理

3随时线上分析处理

4视觉化之企业仪表版

5协助预测规划

导入BI的目的

1促进企业决策流程(Facilitate the Business Decision-Making Process)：BIS增进企业的资讯整合与资讯分析的能力，汇总公司内、外部的资料，整合成有效的决策资讯，让企业经理人大幅增进决策效率与改善决策品质。

>>

问题八：数据库有哪几种？ 常用的数据库：oracle、sqlserver、mysql、access、sybase 2、特点。 -oracle： 1数据库安全性很高，很适合做大型数据库。支持多种系统平台（HPUX、SUNOS、OSF/1、VMS、 WINDOWS、WINDOWS/NT、OS/2）。 2支持客户机/服务器体系结构及混合的体系结构（集中式、分布式、 客户机/服务器）。 -sqlserver: 1真正的客户机/服务器体系结构。 2图形化用户界面，使系统管理和数据库管理更加直观、简单。 3具有很好的伸缩性，可跨越从运行Windows 95/98的膝上型电脑到运行Windows 2000的大型多处理器等多种平台使用。 -mysql: MySQL是一个开放源码的小型关系型数据库管理系统，开发者为瑞典MySQL AB公司，92HeZu网免费赠送MySQL。目前MySQL被广泛地应用在Internet上的中小型网站中。提供由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。 -access Access是一种桌面数据库，只适合数据量少的应用，在处理少量数据和单机访问的数据库时是很好的，效率也很高。 但是它的同时访问客户端不能多于4个。 -

问题九：什么是大数据 大数据是一个体量特别大，数据类别特别大的数据集，并且这样的数据集无法用传统数据库工具对其内容进行抓取、管理和处理。 大数据首先是指数据体量(volumes)大，指代大型数据集，一般在10TB规模左右，但在实际应用中，很多企业用户把多个数据集放在一起，已经形成了PB级的数据量；其次是指数据类别(variety)大，数据来自多种数据源，数据种类和格式日渐丰富，已冲破了以前所限定的结构化数据范畴，囊括了半结构化和非结构化数据。接着是数据处理速度（Velocity）快，在数据量非常庞大的情况下，也能够做到数据的实时处理。最后一个特点是指数据真实性（Veracity）高，随着社交数据、企业内容、交易与应用数据等新数据源的兴趣，传统数据源的局限被打破，企业愈发需要有效的信息之力以确保其真实性及安全性。

数据采集：ETL工具负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。

数据存取：关系数据库、NOSQL、SQL等。

基础架构：云存储、分布式文件存储等。

数据处理：自然语言处理(NLP，NaturalLanguageProcessing)是研究人与计算机交互的语言问题的一门学科。处理自然语言的关键是要让计算机理解自然语言，所以自然语言处理又叫做自然语言理解(NLU，NaturalLanguage Understanding)，也称为计算语言学(putational Linguistics。一方面它是语言信息处理的一个分支，另一方面它是人工智能(AI, Artificial Intelligence)的核心课题之一。

统计分析：假设检验、显著性检验、差异分析、相关分析、T检验、方差分析、卡方分析、偏相关分析、距离分析、回归分析、简单回归分析、多元回归分析、逐步回归、回归预测与残差分析、岭回归、logistic回归分析、曲线估计、因子分析、聚类分析、主成分分析、因子分析、快速聚类法与聚类法、判别分析、对应分析、多元对应分析（最优尺度分析）、bootstrap技术等等。

数据挖掘：分类 （Classification）、估计（Estimation）、预测（Prediction）、相关性分组或关联规则（Affinity grouping or association rules）、聚类（Clustering）、描述和可视化、Description and Visualization）、复杂数据类型挖掘(Text, Web ,图形图像，视频，音频等)

模型预测：预测模型、机器学习、建模仿真。

结果呈现：云计算、标签云、关系图等。

要理解大数据这一概念，首先要从大入手，大是指数据规模，大数据一般指在10TB(1TB=1024GB)规模以上的数据量。大数据同过去的海量数据有所区别，其基本特征可以用4个V来总结(Vol-ume、Variety、Value和Veloc-ity)，即体量大、多样性、价值密度低、速度快。

第一，数据体量巨大。从TB级别，跃升到PB级别。

第二，数据类型繁多，如前文提到的网络日志、视频、、地理位置信息，等等。

第三，价值密度低。以视频为例，连续不间断监控过程中，可能有用的数据仅仅有一两秒。

第四，处理速度快。1秒定律。最后这一点也是和传统的>>

问题十：国内真正的大数据分析产品有哪些 国内的大数据公司还是做前端可视化展现的偏多，BAT算是真正做了大数据的，行业有硬性需求，别的行业跟不上也没办法，需求决定市场。

说说更通用的数据分析吧。

大数据分析也属于数据分析的一块，在实际应用中可以把数据分析工具分成两个维度：

第一维度：数据存储层――数据报表层――数据分析层――数据展现层

第二维度：用户级――部门级――企业级――BI级

1、数据存储层

数据存储设计到数据库的概念和数据库语言，这方面不一定要深钻研，但至少要理解数据的存储方式，数据的基本结构和数据类型。SQL查询语言必不可少，精通最好。可从常用的selece查询，update修改，delete删除，insert插入的基本结构和读取入手。

Access2003、Access07等，这是最基本的个人数据库，经常用于个人或部分基本的数据存储；MySQL数据库，这个对于部门级或者互联网的数据库应用是必要的，这个时候关键掌握数据库的库结构和SQL语言的数据查询能力。

SQL Server2005或更高版本，对中小企业，一些大型企业也可以采用SQL Server数据库，其实这个时候本身除了数据存储，也包括了数据报表和数据分析了，甚至数据挖掘工具都在其中了。

DB2，Oracle数据库都是大型数据库了，主要是企业级，特别是大型企业或者对数据海量存储需求的就是必须的了，一般大型数据库公司都提供非常好的数据整合应用平台。

BI级别，实际上这个不是数据库，而是建立在前面数据库基础上的，企业级应用的数据仓库。Data Warehouse，建立在DW机上的数据存储基本上都是商业智能平台，整合了各种数据分析，报表、分析和展现！BI级别的数据仓库结合BI产品也是近几年的大趋势。

2、报表层

企业存储了数据需要读取，需要展现，报表工具是最普遍应用的工具，尤其是在国内。传统报表解决的是展现问题，目前国内的帆软报表FineReport已经算在业内做到顶尖，是带着数据分析思想的报表，因其优异的接口开放功能、填报、表单功能，能够做到打通数据的进出，涵盖了早期商业智能的功能。

Tableau、FineBI之类，可分在报表层也可分为数据展现层。FineBI和Tableau同属于近年来非常棒的软件，可作为可视化数据分析软件，我常用FineBI从数据库中取数进行报表和可视化分析。相对而言，可视化Tableau更优，但FineBI又有另一种身份――商业智能，所以在大数据处理方面的能力更胜一筹。

3、数据分析层

这个层其实有很多分析工具，当然我们最常用的就是Excel，我经常用的就是统计分析和数据挖掘工具；

Excel软件，首先版本越高越好用这是肯定的；当然对excel来讲很多人只是掌握了5%Excel功能，Excel功能非常强大，甚至可以完成所有的统计分析工作！但是我也常说，有能力把Excel玩成统计工具不如专门学会统计软件；

SPSS软件：当前版本是18，名字也改成了PASW Statistics；我从30开始Dos环境下编程分析，到现在版本的变迁也可以看出SPSS社会科学统计软件包的变化，从重视医学、化学等开始越来越重视商业分析，现在已经成为了预测分析软件；

SAS软件：SAS相对SPSS其实功能更强大，SAS是平台化的，EM挖掘模块平台整合，相对来讲，SAS比较难学些，但如果掌握了SAS会更有价值，比如离散选择模型，抽样问题，正交实验设计等还是SAS比较好用，另外，SAS的学习材料比较多，也公开，会有收获的！

JMP分析：SAS的一个分析分支

XLstat：Excel的插件，可以完>>

我们在前文中给大家简单介绍了关于大数据运维师的一些基本技能需求的内容。下面我们就一起来了解一下，在学习大数据的时候不同学习阶段都需要了解哪些知识。

数据存储阶段：SQL，oracle，IBM等等都有相关的课程，昌平java课程培训机构建议根据公司的不同，学习好这些企业的开发工具，基本可以胜任此阶段的职位。

数据挖掘清洗筛选：大数据工程师，要学习JAVA，Linux，SQL，Hadoop，数据序列化系统Avro，数据仓库Hive，分布式数据库HBase，数据仓库Hive，Flume分布式日志框架，Kafka分布式队列系统课程，Sqoop数据迁移，pig开发，Storm实时数据处理。学会以上基本可以入门大数据工程师，如果想有一个更好的起点，建议前期学习scala编程，Spark，R语言等基本现在企业里面更专业的技能。

数据分析：一方面是搭建数据分析框架，比如确定分析思路需要营销、管理等理论知识;还有针对数据分析结论提出有指导意义的分析建议。

产品调整：经过分析后的数据交由老板和PM经过协商后进行产品的更新，然后交由程序员进行修改(快消类进行商品的上下架调整)。

接着再来了解大数据需要掌握那些技术

Hadoop核心

(1)分布式存储基石：HDFS

HDFS简介入门演示构成及工作原理解析：数据块，NameNode,DataNode、数据写入与读取过程、数据复制、HA方案、文件类型、HDFS常用设置JavaAPI代码演示

(2)分布式计算基础：MapReduce

MapReduce简介、编程模型、JavaAPI介绍、编程案例介绍、MapReduce调优

(3)Hadoop集群资源管家：YARN

YARN基本架构资源调度过程调度算法YARN上的计算框架

离线计算

(1)离线日志收集利器：Flume

Flume简介核心组件介绍Flume实例：日志收集、适宜场景、常见问题。

(2)离线批处理必备工具：Hive

Hive在大数据平台里的定位、总体架构、使用场景之AccessLog分析HiveDDL&DML介绍视图函数(内置，窗口，自定义函数)表的分区、分桶和抽样优化。

几个简单的步骤大幅提高Oracle性能 我优化数据库的三板斧

数据库优化的讨论可以说是一个永恒的主题 资深的Oracle优化人员通常会要求提出性能问题的人对数据库做一个statspack 贴出数据库配置等等 还有的人认为要抓出执行最慢的语句来进行优化 但实际情况是 提出疑问的人很可能根本不懂执行计划 更不要说statspack了 而我认为 数据库优化 应该首先从大的方面考虑 网络 服务器硬件配置 *** 作系统配置 Oracle服务器配置 数据结构组织 然后才是具体的调整 实际上网络 硬件等往往无法决定更换 应用程序一般也无法修改 因此应该着重从数据库配置 数据结构上来下手 首先让数据库有一个良好的配置 然后再考虑具体优化某些过慢的语句 我在给我的用户系统进行优化的过程中 总结了一些基本的 简单易行的办法来优化数据库 算是我的三板斧 呵呵 不过请注意 这些不一定普遍使用 甚至有的会有副作用 但是对OLTP系统 基于成本的数据库往往行之有效 不妨试试 （注 附件是Burleson写的用来报告数据库性能等信息的脚本 本文用到）

一．设置合适的SGA

常常有人抱怨服务器硬件很好 但是Oracle就是很慢 很可能是内存分配不合理造成的 ( )假设内存有 M 这通常是小型应用 建议Oracle的SGA大约 M 其中 共享池（SHARED_POOL_SIZE）可以设置 M到 M 根据实际的用户数 查询等来定 数据块缓冲区可以大致分配 M M i下需要设置DB_BLOCK_BUFFERS DB_BLOCK_BUFFERDB_BLOCK_SIZE等于数据块缓冲区大小 i 下的数据缓冲区可以用db_cache_size来直接分配

( )假设内存有 G Oracle 的SGA可以考虑分配 M 共享池分配 M到 M 数据缓冲区分配 M到 M

( )内存 G SGA可以考虑分配 G 共享池 M到 M 剩下的给数据块缓冲区

( )内存 G以上 共享池 M到 M就足够啦 再多也没有太大帮助 (Biti_rainy有专述)数据缓冲区是尽可能的大 但是一定要注意两个问题 一是要给 *** 作系统和其他应用留够内存 二是对于 位的 *** 作系统 Oracle的SGA有 G的限制 有的 位 *** 作系统上可以突破这个限制 方法还请看Biti的大作吧

二．分析表和索引 更改优化模式

Oracle默认优化模式是CHOOSE 在这种情况下 如果表没有经过分析 经常导致查询使用全表扫描 而不使用索引 这通常导致磁盘I/O太多 而导致查询很慢 如果没有使用执行计划稳定性 则应该把表和索引都分析一下 这样可能直接会使查询速度大幅提升 分析表命令可以用ANALYZE TABLE 分析索引可以用ANALYZE INDEX命令 对于少于 万的表 可以考虑分析整个表 对于很大的表 可以按百分比来分析 但是百分比不能过低 否则生成的统计信息可能不准确 可以通过DBA_TABLES的LAST_ANALYZED列来查看表是否经过分析或分析时间 索引可以通过DBA_INDEXES的LAST_ANALYZED列

下面通过例子来说明分析前后的速度对比 （表CASE_GA_AJZLZ大约有 万数据 有主键）首先在SQLPLUS中打开自动查询执行计划功能 (第一次要执行\RDBMS\ADMIN\utlxplan sql来创建PLAN_TABLE这个表)

SQL> SET AUTOTRACE ON SQL>SET TIMING ON

通过SET AUTOTRACE ON 来查看语句的执行计划 通过SET TIMING ON 来查看语句运行时间

SQL> select count() from CASE_GA_AJZLZ; COUNT() 已用时间: : : Execution Plan SELECT STATEMENT Optimizer=CHOOSE SORT (AGGREGATE) TABLE ACCESS (FULL) OF CASE_GA_AJZLZ ……………………

请注意上面分析中的TABLE ACCESS(FULL) 这说明该语句执行了全表扫描 而且查询使用了 秒 这时表还没有经过分析 下面我们来对该表进行分析

SQL> yze table CASE_GA_AJZLZ pute statistics;

表已分析 已用时间: : : 然后再来查询

SQL> select count() from CASE_GA_AJZLZ; COUNT() 已用时间: : : Execution Plan SELECT STATEMENT Optimizer=FIRST_ROWS (Cost= Card= ) SORT (AGGREGATE) INDEX (FAST FULL SCAN) OF PK_AJZLZ (UNIQUE) (Cost= Card= ) …………………………

请注意 这次时间仅仅用了 秒！这要归功于INDEX(FAST FULL SCAN) 通过分析表 查询使用了PK_AJZLZ索引 磁盘I/O大幅减少 速度也大幅提升！下面的实用语句可以

用来生成分析某个用户的所有表和索引 假设用户是GAXZUSR

SQL> set pagesize SQL> spool d:\ yze_tables sql; SQL> select yze table ||owner|| ||table_name|| pute statistics; from dba_tables where owner= GAXZUSR ; SQL> spool off SQL> spool spool d:\ yze_indexes sql; SQL> select yze index ||owner|| ||index_name|| pute statistics; from dba_indexes where owner= GAXZUSR ; SQL> spool off SQL> @d:\ yze_tables sql SQL> @d:\ yze_indexes sql

解释 上面的语句生成了两个sql文件 分别分析全部的GAXZUSR的表和索引 如果需要按照百分比来分析表 可以修改一下脚本 通过上面的步骤 我们就完成了对表和索引的分析 可以测试一下速度的改进啦 建议定期运行上面的语句 尤其是数据经过大量更新

当然 也可以通过dbms_stats来分析表和索引 更方便一些 但是我仍然习惯上面的方法 因为成功与否会直接提示出来

另外 我们可以将优化模式进行修改 optimizer_mode值可以是RULE CHOOSE FIRST_ROWS和ALL_ROWS 对于OLTP系统 可以改成FIRST_ROWS 来要求查询尽快返回结果 这样即使不用分析 在一般情况下也可以提高查询性能 但是表和索引经过分析后有助于找到最合适的执行计划

三．设置cursor_sharing=FORCE 或SIMILAR

这种方法是 i才开始有的 oracle 不支持 通过设置该参数 可以强制共享只有文字不同的语句解释计划 例如下面两条语句可以共享

SQL> SELECT FROM MYTABLE WHERE NAME= tom SQL> SELECT FROM MYTABLE WHERE NAME= turner

这个方法可以大幅降低缓冲区利用率低的问题 避免语句重新解释 通过这个功能 可以很大程度上解决硬解析带来的性能下降的问题 个人感觉可根据系统的实际情况 决定是否将该参数改成FORCE 该参数默认是exact 不过一定要注意 修改之前 必须先给ORACLE打补丁 否则改之后oracle会占用 %的CPU 无法使用 对于ORACLE i 可以设置成SIMILAR 这个设置综合了FORCE和EXACT的优点 不过请慎用这个功能 这个参数也可能带来很大的负面影响！

四．将常用的小表 索引钉在数据缓存KEEP池中

内存上数据读取速度远远比硬盘中读取要快 据称 内存中数据读的速度是硬盘的 倍！如果资源比较丰富 把常用的小的 而且经常进行全表扫描的表给钉内存中 当然是在好不过了 可以简单的通过ALTER TABLE tablename CACHE来实现 在ORACLE i之后可以使用ALTER TABLE table STORAGE(BUFFER_POOL KEEP) 一般来说 可以考虑把 数据块之内的表放在keep池中 当然要根据内存大小等因素来定 关于如何查出那些表或索引符合条件 可以使用本文提供的access sql和access_report sql 这两个脚本是著名的Oracle专家 Burleson写的 你也可以在读懂了情况下根据实际情况调整一下脚本 对于索引 可以通过ALTER INDEX indexname STORAGE(BUFFER_POOL KEEP)来钉在KEEP池中

将表定在KEEP池中需要做一些准备工作 对于ORACLE i 需要设置DB_KEEP_CACHE_SIZE 对于 i 需要设置buffer_pool_keep 在 i中 还要修改db_block_lru_latches 该参数默认是 无法使用buffer_pool_keep 该参数应该比 CPU数量少 但是要大于 才能设置DB_KEEP_CACHE_BUFFER buffer_pool_keep从db_block_buffers中分配 因此也要小于db_block_buffers 设置好这些参数后 就可以把常用对象永久钉在内存里

五．设置optimizer_max_permutations

对于多表连接查询 如果采用基于成本优化(CBO) ORACLE会计算出很多种运行方案

从中选择出最优方案 这个参数就是设置oracle究竟从多少种方案来选择最优 如果设置太大 那么计算最优方案过程也是时间比较长的 Oracle 和 i默认是 建议改成 对于 i 已经默认是 了

六．调整排序参数

( ) SORT_AREA_SIZE:默认的用来排序的SORT_AREA_SIZE大小是 K 通常显得有点小 一般可以考虑设置成 M（ ） 这个参数不能设置过大 因为每个连接都要分配同样的排序内存

lishixinzhi/Article/program/Oracle/201311/18879

大数据技术的体系庞大且复杂，基础的技术包含数据的采集、数据预处理、分布式存储、数据库、数据仓库、机器学习、并行计算、可视化等。

1、数据采集与预处理：FlumeNG实时日志收集系统，支持在日志系统中定制各类数据发送方，用于收集数据；Zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，提供数据同步服务。

2、数据存储：Hadoop作为一个开源的框架，专为离线和大规模数据分析而设计，HDFS作为其核心的存储引擎，已被广泛用于数据存储。HBase，是一个分布式的、面向列的开源数据库，可以认为是hdfs的封装，本质是数据存储、NoSQL数据库。

3、数据清洗：MapReduce作为Hadoop的查询引擎，用于大规模数据集的并行计算。

4、数据查询分析：Hive的核心工作就是把SQL语句翻译成MR程序，可以将结构化的数据映射为一张数据库表，并提供HQL(HiveSQL)查询功能。Spark启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。

5、数据可视化：对接一些BI平台，将分析得到的数据进行可视化，用于指导决策服务。

考虑到现有技术解决方案的复杂性与多样化，企业往往很难找到适合自己的大数据收集与分析工具。然而，混乱的时局之下已经有多种方案脱颖而出，证明其能够帮助大家切实完成大数据分析类工作。下面昌平IT培训将整理出一份包含十款工具的清单，从而有效压缩选择范畴。

OpenRefine

这是一款高人气数据分析工具，适用于各类与分析相关的任务。这意味着即使大家拥有多川不同数据类型及名称，这款工具亦能够利用其强大的聚类算法完成条目分组。在聚类完成后，分析即可开始。

Hadoop

大数据与Hadoop可谓密不可分。这套软件库兼框架能够利用简单的编程模型将大规模数据集分发于计算机集群当中。其尤为擅长处理大规模数据并使其可用于本地设备当中。作为Hadoop的开发方，Apache亦在不断强化这款工具以提升其实际效果。

Storm

同样来自Apache的Storm是另一款伟大的实时计算系统，能够极大强化无限数据流的处理效果。其亦可用于执行多种其它与大数据相关的任务，具体包括分布式RPC、持续处理、在线机器学习以及实时分析等等。使用Storm的另一大优势在于，其整合了大量其它技术，从而进一步降低大数据处理的复杂性。

Plotly

这是一款数据可视化工具，可兼容JaScript、MATLAB、Python以及R等语言。Plotly甚至能够帮助不具备代码编写技能或者时间的用户完成动态可视化处理。这款工具常由新一代数据科学家使用，因为其属于一款业务开发平台且能够快速完成大规模数据的理解与分析。

Rapidminer

作为另一款大数据处理必要工具，Rapidminer属于一套开源数据科学平台，且通过可视化编程机制发挥作用。其功能包括对模型进行修改、分析与创建，且能够快速将结果整合至业务流程当中。Rapidminer目前备受瞩目，且已经成为众多知名数据科学家心目中的可靠工具。

Cassandra

ApacheCassandra是另一款值得关注的工具，因为其能够有效且高效地对大规模数据加以管理。它属于一套可扩展NoSQL数据库，能够监控多座数据中心内的数据并已经在Netflix及eBay等知名企业当中效力。

HadoopMapReduce

这是一套软件框架，允许用户利用其编写出以可靠方式并发处理大规模数据的应用。MapReduce应用主要负责完成两项任务，即映射与规约，并由此提供多种数据处理结果。这款工具最初由谷歌公司开发完成。

Bokeh

这套可视化框架的主要目标在于提供精致且简洁的图形处理结果，用以强化大规模数据流的交互能力。其专门供Python语言使用。

WolframAlpha

这是一套搜索引擎，旨在帮助用户搜索其需要的计算素材或者其它内容。举例来说，如果大家输入“Facebook”，即可获得与Facebook相关的HTML元素结构、输入解释、Web托管信息、网络统计、子域、Alexa预估以及网页信息等大量内容。

对于互联网业务来说，传统的直接访问数据库方式，主要通过数据分片、一主多从等方式来扛住读写流量，但随着数据量的积累和流量的激增，仅依赖数据库来承接所有流量，不仅成本高、效率低、而且还伴随着稳定性降低的风险。

鉴于大部分业务通常是读多写少（读取频率远远高于更新频率），甚至存在读 *** 作数量高出写 *** 作多个数量级的情况。因此， 在架构设计中，常采用增加缓存层来提高系统的响应能力 ，提升数据读写性能、减少数据库访问压力，从而提升业务的稳定性和访问体验。

根据 CAP 原理，分布式系统在可用性、一致性和分区容错性上无法兼得，通常由于分区容错无法避免，所以一致性和可用性难以同时成立。对于缓存系统来说， 如何保证其数据一致性是一个在应用缓存的同时不得不解决的问题 。

需要明确的是，缓存系统的数据一致性通常包括持久化层和缓存层的一致性、以及多级缓存之间的一致性，这里我们仅讨论前者。持久化层和缓存层的一致性问题也通常被称为双写一致性问题，“双写”意为数据既在数据库中保存一份，也在缓存中保存一份。

对于一致性来说，包含强一致性和弱一致性 ，强一致性保证写入后立即可以读取，弱一致性则不保证立即可以读取写入后的值，而是尽可能的保证在经过一定时间后可以读取到，在弱一致性中应用最为广泛的模型则是最终一致性模型，即保证在一定时间之后写入和读取达到一致的状态。对于应用缓存的大部分场景来说，追求的则是最终一致性，少部分对数据一致性要求极高的场景则会追求强一致性。

为了达到最终一致性，针对不同的场景，业界逐步形成了下面这几种应用缓存的策略。

— 1 —

Cache-Aside

Cache-Aside 意为旁路缓存模式，是应用最为广泛的一种缓存策略。下面的图示展示了它的读写流程，来看看它是如何保证最终一致性的。在读请求中，首先请求缓存，若缓存命中（cache hit），则直接返回缓存中的数据；若缓存未命中（cache miss），则查询数据库并将查询结果更新至缓存，然后返回查询出的数据（demand-filled look-aside ）。在写请求中，先更新数据库，再删除缓存（write-invalidate）。

1、为什么删除缓存，而不是更新缓存？

在 Cache-Aside 中，对于读请求的处理比较容易理解，但在写请求中，可能会有读者提出疑问，为什么要删除缓存，而不是更新缓存？站在符合直觉的角度来看，更新缓存是一个容易被理解的方案，但站在性能和安全的角度，更新缓存则可能会导致一些不好的后果。

首先是性能 ，当该缓存对应的结果需要消耗大量的计算过程才能得到时，比如需要访问多张数据库表并联合计算，那么在写 *** 作中更新缓存的动作将会是一笔不小的开销。同时，当写 *** 作较多时，可能也会存在刚更新的缓存还没有被读取到，又再次被更新的情况（这常被称为缓存扰动），显然，这样的更新是白白消耗机器性能的，会导致缓存利用率不高。

而等到读请求未命中缓存时再去更新，也符合懒加载的思路，需要时再进行计算。删除缓存的 *** 作不仅是幂等的，可以在发生异常时重试，而且写-删除和读-更新在语义上更加对称。

其次是安全 ，在并发场景下，在写请求中更新缓存可能会引发数据的不一致问题。参考下面的图示，若存在两个来自不同线程的写请求，首先来自线程 1 的写请求更新了数据库（step 1），接着来自线程 2 的写请求再次更新了数据库（step 3），但由于网络延迟等原因，线程 1 可能会晚于线程 2 更新缓存（step 4 晚于 step 3），那么这样便会导致最终写入数据库的结果是来自线程 2 的新值，写入缓存的结果是来自线程 1 的旧值，即缓存落后于数据库，此时再有读请求命中缓存（step 5），读取到的便是旧值。

2、为什么先更新数据库，而不是先删除缓存？

另外，有读者也会对更新数据库和删除缓存的时序产生疑问，那么为什么不先删除缓存，再更新数据库呢？在单线程下，这种方案看似具有一定合理性，这种合理性体现在删除缓存成功。

但更新数据库失败的场景下，尽管缓存被删除了，下次读 *** 作时，仍能将正确的数据写回缓存，相对于 Cache-Aside 中更新数据库成功，删除缓存失败的场景来说，先删除缓存的方案似乎更合理一些。那么，先删除缓存有什么问题呢？

问题仍然出现在并发场景下，首先来自线程 1 的写请求删除了缓存（step 1），接着来自线程 2 的读请求由于缓存的删除导致缓存未命中，根据 Cache-Aside 模式，线程 2 继而查询数据库（step 2），但由于写请求通常慢于读请求，线程 1 更新数据库的 *** 作可能会晚于线程 2 查询数据库后更新缓存的 *** 作（step 4 晚于 step 3），那么这样便会导致最终写入缓存的结果是来自线程 2 中查询到的旧值，而写入数据库的结果是来自线程 1 的新值，即缓存落后于数据库，此时再有读请求命中缓存（ step 5 ），读取到的便是旧值。

另外，先删除缓存，由于缓存中数据缺失，加剧数据库的请求压力，可能会增大缓存穿透出现的概率。

3、如果选择先删除缓存，再更新数据库，那如何解决一致性问题呢？

为了避免“先删除缓存，再更新数据库”这一方案在读写并发时可能带来的缓存脏数据，业界又提出了延时双删的策略，即在更新数据库之后，延迟一段时间再次删除缓存，为了保证第二次删除缓存的时间点在读请求更新缓存之后，这个延迟时间的经验值通常应稍大于业务中读请求的耗时。

延迟的实现可以在代码中 sleep 或采用延迟队列。显而易见的是，无论这个值如何预估，都很难和读请求的完成时间点准确衔接，这也是延时双删被诟病的主要原因。

4、那么 Cache-Aside 存在数据不一致的可能吗？

在 Cache-Aside 中，也存在数据不一致的可能性。在下面的读写并发场景下，首先来自线程 1 的读请求在未命中缓存的情况下查询数据库（step 1），接着来自线程 2 的写请求更新数据库（step 2），但由于一些极端原因，线程 1 中读请求的更新缓存 *** 作晚于线程 2 中写请求的删除缓存的 *** 作（step 4 晚于 step 3），那么这样便会导致最终写入缓存中的是来自线程 1 的旧值，而写入数据库中的是来自线程 2 的新值，即缓存落后于数据库，此时再有读请求命中缓存（step 5），读取到的便是旧值。

这种场景的出现，不仅需要缓存失效且读写并发执行，而且还需要读请求查询数据库的执行早于写请求更新数据库，同时读请求的执行完成晚于写请求。足以见得，这种 不一致场景产生的条件非常严格，在实际的生产中出现的可能性较小 。

除此之外，在并发环境下，Cache-Aside 中也存在读请求命中缓存的时间点在写请求更新数据库之后，删除缓存之前，这样也会导致读请求查询到的缓存落后于数据库的情况。

虽然在下一次读请求中，缓存会被更新，但如果业务层面对这种情况的容忍度较低，那么可以采用加锁在写请求中保证“更新数据库&删除缓存”的串行执行为原子性 *** 作（同理也可对读请求中缓存的更新加锁）。 加锁势必会导致吞吐量的下降，故采取加锁的方案应该对性能的损耗有所预期。

— 2 —

补偿机制

我们在上面提到了，在 Cache-Aside 中可能存在更新数据库成功，但删除缓存失败的场景，如果发生这种情况，那么便会导致缓存中的数据落后于数据库，产生数据的不一致的问题。

其实，不仅 Cache-Aside 存在这样的问题，在延时双删等策略中也存在这样的问题。针对可能出现的删除失败问题，目前业界主要有以下几种补偿机制。

1、删除重试机制

由于同步重试删除在性能上会影响吞吐量，所以常通过引入消息队列，将删除失败的缓存对应的 key 放入消息队列中，在对应的消费者中获取删除失败的 key ，异步重试删除。这种方法在实现上相对简单，但由于删除失败后的逻辑需要基于业务代码的 trigger 来触发 ，对业务代码具有一定入侵性。

鉴于上述方案对业务代码具有一定入侵性，所以需要一种更加优雅的解决方案，让缓存删除失败的补偿机制运行在背后，尽量少的耦合于业务代码。一个简单的思路是通过后台任务使用更新时间戳或者版本作为对比获取数据库的增量数据更新至缓存中，这种方式在小规模数据的场景可以起到一定作用，但其扩展性、稳定性都有所欠缺。

一个相对成熟的方案是基于 MySQL 数据库增量日志进行解析和消费，这里较为流行的是阿里巴巴开源的作为 MySQL binlog 增量获取和解析的组件 canal（类似的开源组件还有 Maxwell、Databus 等）。

canal sever 模拟 MySQL slave 的交互协议，伪装为 MySQL slave，向 MySQL master 发送 dump 协议，MySQL master 收到 dump 请求，开始推送 binary log 给 slave （即 canal sever ），canal sever 解析 binary log 对象（原始为 byte 流），可由 canal client 拉取进行消费，同时 canal server 也默认支持将变更记录投递到 MQ 系统中，主动推送给其他系统进行消费。

在 ack 机制的加持下，不管是推送还是拉取，都可以有效的保证数据按照预期被消费。当前版本的 canal 支持的 MQ 有 Kafka 或者 RocketMQ。另外， canal 依赖 ZooKeeper 作为分布式协调组件来实现 HA ，canal 的 HA 分为两个部分：

那么，针对缓存的删除 *** 作便可以在 canal client 或 consumer 中编写相关业务代码来完成。这样，结合数据库日志增量解析消费的方案以及 Cache-Aside 模型，在读请求中未命中缓存时更新缓存（通常这里会涉及到复杂的业务逻辑），在写请求更新数据库后删除缓存，并基于日志增量解析来补偿数据库更新时可能的缓存删除失败问题，在绝大多数场景下，可以有效的保证缓存的最终一致性。

另外需要注意的是，还应该隔离事务与缓存，确保数据库入库后再进行缓存的删除 *** 作。 比如考虑到数据库的主从架构，主从同步及读从写主的场景下，可能会造成读取到从库的旧数据后便更新了缓存，导致缓存落后于数据库的问题，这就要求对缓存的删除应该确保在数据库 *** 作完成之后。所以，基于 binlog 增量日志进行数据同步的方案，可以通过选择解析从节点的 binlog，来避免主从同步下删除缓存过早的问题。

3、数据传输服务 DTS

— 3 —

Read-Through

Read-Through 意为读穿透模式，它的流程和 Cache-Aside 类似，不同点在于 Read-Through 中多了一个访问控制层，读请求只和该访问控制层进行交互，而背后缓存命中与否的逻辑则由访问控制层与数据源进行交互，业务层的实现会更加简洁，并且对于缓存层及持久化层交互的封装程度更高，更易于移植。

— 4 —

Write-Through

Write-Through 意为直写模式，对于 Write-Through 直写模式来说，它也增加了访问控制层来提供更高程度的封装。不同于 Cache-Aside 的是，Write-Through 直写模式在写请求更新数据库之后，并不会删除缓存，而是更新缓存。

这种方式的 优势在于读请求过程简单 ，不需要查询数据库更新缓存等 *** 作。但其劣势也非常明显，除了上面我们提到的更新数据库再更新缓存的弊端之外，这种方案还会造成更新效率低，并且两个写 *** 作任何一次写失败都会造成数据不一致。

如果要使用这种方案， 最好可以将这两个 *** 作作为事务处理，可以同时失败或者同时成功，支持回滚，并且防止并发环境下的不一致 。另外，为了防止缓存扰动的频发，也可以给缓存增加 TTL 来缓解。

站在可行性的角度，不管是 Write-Through 模式还是 Cache-Aside 模式，理想状况下都可以通过分布式事务保证缓存层数据与持久化层数据的一致性，但在实际项目中，大多都对一致性的要求存在一些宽容度，所以在方案上往往有所折衷。

Write-Through 直写模式适合写 *** 作较多，并且对一致性要求较高的场景，在应用 Write-Through 模式时，也需要通过一定的补偿机制来解决它的问题。首先，在并发环境下，我们前面提到了先更新数据库，再更新缓存会导致缓存和数据库的不一致，那么先更新缓存，再更新数据库呢？

这样的 *** 作时序仍然会导致下面这样线程 1 先更新缓存，最后更新数据库的情况，即由于线程 1 和 线程 2 的执行不确定性导致数据库和缓存的不一致。这种由于线程竞争导致的缓存不一致，可以通过分布式锁解决，保证对缓存和数据库的 *** 作仅能由同一个线程完成。对于没有拿到锁的线程，一是通过锁的 timeout 时间进行控制，二是将请求暂存在消息队列中顺序消费。

在下面这种并发执行场景下，来自线程 1 的写请求更新了数据库，接着来自线程 2 的读请求命中缓存，接着线程 1 才更新缓存，这样便会导致线程 2 读取到的缓存落后于数据库。同理，先更新缓存后更新数据库在写请求和读请求并发时，也会出现类似的问题。面对这种场景，我们也可以加锁解决。

另在，在 Write-Through 模式下，不管是先更新缓存还是先更新数据库，都存在更新缓存或者更新数据库失败的情况，上面提到的重试机制和补偿机制在这里也是奏效的。

— 5 —

Write-Behind

Write behind 意为异步回写模式，它也具有类似 Read-Through/Write-Through 的访问控制层，不同的是，Write behind 在处理写请求时，只更新缓存而不更新数据库，对于数据库的更新，则是通过批量异步更新的方式进行的，批量写入的时间点可以选在数据库负载较低的时间进行。

在 Write-Behind 模式下，写请求延迟较低，减轻了数据库的压力，具有较好的吞吐性。但数据库和缓存的一致性较弱，比如当更新的数据还未被写入数据库时，直接从数据库中查询数据是落后于缓存的。同时，缓存的负载较大，如果缓存宕机会导致数据丢失，所以需要做好缓存的高可用。显然，Write behind 模式下适合大量写 *** 作的场景，常用于电商秒杀场景中库存的扣减。

— 6 —

Write-Around

如果一些非核心业务，对一致性的要求较弱，可以选择在 cache aside 读模式下增加一个缓存过期时间，在写请求中仅仅更新数据库，不做任何删除或更新缓存的 *** 作，这样，缓存仅能通过过期时间失效。这种方案实现简单，但缓存中的数据和数据库数据一致性较差，往往会造成用户的体验较差，应慎重选择。

— 7 —

总结

在解决缓存一致性的过程中，有多种途径可以保证缓存的最终一致性，应该根据场景来设计合适的方案，读多写少的场景下，可以选择采用“Cache-Aside 结合消费数据库日志做补偿”的方案，写多的场景下，可以选择采用“Write-Through 结合分布式锁”的方案 ，写多的极端场景下，可以选择采用“Write-Behind”的方案。

故障现象:

如何计算磁盘响应时间？

解决方案:

磁盘规格:

机械硬盘的性能指标有三个重要的参数：

寻道时间 – 在磁道之间移动磁头所花费的时间 ;

旋转延迟 – 盘片将数据旋转至磁头下的时间 ;

传输速率 – 磁盘的带宽;

理解这些参数之间的关系有助于了解一块磁盘的性能，这些值在决定磁盘性能的两个基本度量的时候非常有用：吞吐量和响应时间;

寻道时间：

寻道时间以毫秒（ms）来计算，不同磁盘的寻道时间不同。平均寻道时间是经常使用的度量，对于一块15k rpm的35英寸SAS盘，其平均寻道时间是38ms。减少磁盘寻道所花费的时间能增强性能。i/o类型也会影响寻道时间，连续i/o拥有最少的寻道时间，因为读写头可以在盘片上连续 *** 作，而随机i/o就相对有较长的寻道时间，因为磁头始终需要在不同的磁道间切换。

延迟：

延迟以毫秒（ms）来计算，更高转速的磁盘其延迟更小。

传输速率：

传输速率以MB/s来计算，它又可以进一步分为内部/外部速率。内部速率是指在盘片上读写数据的快慢，盘片外圈速率要高于盘片里圈，而且对于同样的线性距离，也拥有更多的扇区。比如对于一个使用连续带宽的应用，35-inch 15k rpm SAS磁盘可以提供50MB/s的内圈速率以及100MB/s的外圈速率。

外部传输速率是指磁盘的连线头到HBA或NIC的传输速率。厂商通常给出的都是突发速率，且假定是内部连接（DAS）。对于存储系统来说，比如VNX，同一个RAID组内的磁盘是共享后端此部分速率的，因此通常达不到厂商给出的突发速率。存储系统的总线架构，实际传输速率更多是由后端传输协议、仲裁时间以及后端端口容量来决定的。

计算平均响应时间：

平均响应时间是指一个请求从排队开始一直到执行结束所花费的时间，计算公式为：响应时间 = （队列长度+1）平均响应时间

比如，某块磁盘的平均响应时间为6ms，队列长度为6，那么响应时间 = 42ms = （6+1）6 ms

联想网站提供的技术方案或与您产品的实际情况有所差异，您需在完整阅读方案并知晓其提示风险的情况下谨慎 *** 作，避免造成任何损失。

以上就是关于“大数据架构”用哪种框架更为合适全部的内容，包括:“大数据架构”用哪种框架更为合适、大数据数据库有哪些、昌平java课程培训机构分享大数据学习都需要掌握哪些知识等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！