本文转载自微信公众号「工匠小猪猪的技术世界」

主流数据库连接池

常用的主流开源数据库连接池有C3P0、DBCP、Tomcat Jdbc Pool、BoneCP、Druid等

C3p0: 开源的JDBC连接池，实现了数据源和JNDI绑定，支持JDBC3规范和JDBC2的标准扩展。目前使用它的开源项目有Hibernate、Spring等。单线程，性能较差，适用于小型系统，代码600KB左右。

DBCP (Database Connection Pool):由Apache开发的一个Java数据库连接池项目， Jakarta commons-pool对象池机制，Tomcat使用的连接池组件就是DBCP。单独使用dbcp需要3个包：common-dbcp.jar,common-pool.jar,common-collections.jar，预先将数据库连接放在内存中，应用程序需要建立数据库连接时直接到连接池中申请一个就行，用完再放回。单线程，并发量低，性能不好，适用于小型系统。

Tomcat Jdbc Pool：Tomcat在7.0以前都是使用common-dbcp做为连接池组件，但是dbcp是单线程，为保证线程安全会锁整个连接池，性能较差，dbcp有超过60个类，也相对复杂。Tomcat从7.0开始引入了新增连接池模块叫做Tomcat jdbc pool，基于Tomcat JULI，使用Tomcat日志框架，完全兼容dbcp，通过异步方式获取连接，支持高并发应用环境，超级简单核心文件只有8个，支持JMX，支持XA Connection。

BoneCP：官方说法BoneCP是一个高效、免费、开源的Java数据库连接池实现库。设计初衷就是为了提高数据库连接池性能，根据某些测试数据显示，BoneCP的速度是最快的，要比当时第二快速的连接池快25倍左右，完美集成到一些持久化产品如Hibernate和DataNucleus中。BoneCP特色：高度可扩展，快速；连接状态切换的回调机制；允许直接访问连接；自动化重置能力；JMX支持；懒加载能力；支持XML和属性文件配置方式；较好的Java代码组织，100%单元测试分支代码覆盖率；代码40KB左右。

Druid：Druid是Java语言中最好的数据库连接池，Druid能够提供强大的监控和扩展功能，是一个可用于大数据实时查询和分析的高容错、高性能的开源分布式系统，尤其是当发生代码部署、机器故障以及其他产品系统遇到宕机等情况时，Druid仍能够保持100%正常运行。主要特色：为分析监控设计；快速的交互式查询；高可用；可扩展；Druid是一个开源项目，源码托管在github上。

主流连接池各项功能对比如下：

我们再看一组有HikariCP的

HikariCP性能分析：

HikariCP通过优化(concurrentBag，fastStatementList )集合来提高并发的读写效率。HikariCP使用threadlocal缓存连接及大量使用CAS的机制，最大限度的避免lock。单可能带来cpu使用率的上升。从字节码的维度优化代码。 (default inline threshold for a JVM running the server Hotspot compiler is 35 bytecodes ）让方法尽量在35个字节码一下，来提升jvm的处理效率。HikariCP做的优化补充如下：

mysql connecter 源码里用的就是ping命令

比HikariCP更快的数据库连接池

一个同事告诉我，比hikari还快的连接池他也用过、研究过 https://github/mauricio/postgresql-async 这是scala生态圈的东西。用netty实现了mysql协议，没用mysql官方的connector，纯异步的，它的连接池是写的比较随便，但是性能依然很好。

前瞻，未来到底是HikariCP还是Druid的天下？

很多人都在问，站在巨人肩膀上的第二代连接池HikariCP和druid到底孰强孰弱？其实我觉得这是一个不必讨论的问题。

我们先来看看未来的趋势：单机的操作系统将会被抛弃，取而代之的是容器调度加编排的云操作系统。裸机或者虚拟机的运行时也将会被容器取代。通信方面将会使用Service Mesh。

也就是说中间件最后的趋势一定是弱化到无感知，这才是最终的一个大道至简的方向。那些maven依赖问题，把二方库写在pom里，监控等代码的硬编码进应用里都将逐渐弱化到不复存在，取而代之的那些java agent（如pinpoint、skywalking之类），抑或是service mesh这种side car模式都是可以做中间件（包括连接池）的监控的。

一个有赞的朋友告诉我，在有赞核心应用，用HikariCP替换durid后，RT出现断崖式下滑（1.5ms ～ 1.2ms） 并且持续稳定毛刺少。性能测试与压测之后，一核心系统与druid相比，性能提高一倍左右。

阿飞做了如下统计工作，都是基于最新tag统计的，只统计java文件和xml文件，druid(alibaba-druid)总行数:430289，HikariCP(brettwooldridge-HikariCP)总行数:18372。 只统计java代码，druid(alibaba-druid)总行数:428749，HikariCP(brettwooldridge-HikariCP)总行数:17556。 再过滤一下test目录，(alibaba-druid)总行数:215232，(brettwooldridge-HikariCP)总行数:7960。 光一个DruidDataSource就3000行，且不说性能，druid是在jdbc的基础上，自己编码做得增强。

如果这么说，druid准确的说是生活在第一代和第二代连接池的面向过程的年代。druid可能忘了松耦合这个概念，把监控和数据库连接池做在一个项目里，本身就是紧耦合。既然微服务提倡业务隔离性，那么这种难道不应该隔离么？让组件工具一次只做一件事不好么？监控的事情在service mesh的将来毕竟是有别的其天然的监控手法的而不是硬编码在一个小小的连接池里。综上所述，放在现在或是未来的趋势去拼，大概率比不过拥抱springboot 2.0以及大道至简精简到极致的HikariCP。

未来的中间件，一定是和spring生态圈和servich mesh一样，大道至简，越来越薄，升级中间件不再是需要用户强行升级maven依赖解决依赖冲突，而是通过mesh的方式极致到升级让业务方无感知。所以那些热部署、潘多拉boot、容器隔离等解决依赖冲突的妥协方式也将可能大概率被置换掉。

从Sharding-jdbc架构演进看未来

Database Mesh，一个搭乘 Service Mesh 浪潮衍生出来的新兴词汇。顾名思义，Database Mesh 使用一个啮合层，将散落在系统各个角落中的数据库统一治理起来。通过啮合层集中在一起的应用与数据库之间的交互网络，就像蜘蛛网一样复杂而有序。它的首要目标并非啮合存储于数据库中的数据，而是啮合应用与数据库间的交互。

Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互有效的梳理。

使用 Database Mesh，访问数据库的应用和数据库终将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。

Sharding-JDBC 一直以来，以 JDBC 层分片作为其核心理念。它的架构图如下：

Sharding-JDBC 将分别实现 Driver、Server 以及 Sidecar 这三个不同的版本，一起组成 Sharding-JDBC 的生态圈，为不同的需求与环境提供更加具有针对性的差异化服务。

由于 Sharding-JDBC-Server 的出现，使得原来 DBA 通过 Sharding-JDBC-Driver 无法对数据进行操作的缺憾得到了补偿。由于 Sharding-JDBC-Driver 无需通过代理层进行二次转发，因此线上性能更佳，可以通过以下的混合部署方案使用 Sharding-JDBC:

线上应用使用 Sharding-JDBC-Driver 直连数据库以获取最优性能，使用 MySQL 命令行或 UI 客户端连接 Sharding-JDBC-Server 方便的查询数据和执行各种 DDL 语句。它们使用同一个注册中心集群，通过管理端配置注册中心中的数据，即可由注册中心自动将配置变更推送至 Driver 和 Server 应用。若数据库拆分的过多而导致连接数会暴涨，则可以考虑直接在线上使用 Sharding-JDBC-Server，以达到有效控制连接数的目的。

在不久的将来，Sharding-JDBC-Sidecar 也将问世，它的部署架构是这样的：

基于 Sharding-JDBC 的 Database Mesh 与 Service Mesh 互不干扰，相得益彰。服务之间的交互由 Service Mesh Sidecar 接管，基于 SQL 的数据库访问由 Sharding-JDBC-Sidecar 接管。

对于业务应用来说，无论是 RPC 还是对数据库的访问，都无需关注其真实的物理部署结构，做到真正的零侵入。由于 Sharding-JDBC-Sidecar 是随着宿主机的生命周期创建和消亡的，

因此，它并非静态 IP，而是完全动态和弹性的存在，整个系统中并无任何中心节点的存在。对于数据运维等操作，仍然可以通过启动一个 Sharding-JDBC-Server 的进程作为静态 IP 的入口，通过各种命令行或 UI 客户端进行操作。

什么是性能调优？(what)为什么需要性能调优？(why)什么时候需要性能调优？(when)什么地方需要性能调优？(where)什么人来进行性能调优？(who)怎么样进行性能调优？(How)

硬件配置：CUP Xeon E5620 x 2 8核心， 内存 16G ， 硬盘 RAID 10

操作系统： CentOS 6.4 x86_64（64位）

注：5w+1h就是对所做工作进行科学的分析，对某一工作在调查研究的基础上:

就其工作内容责任者工作岗位工作时间（When怎样操作（How以及为何这样做

即对”5W”、”1H”进行书面描述，并按此描述进行操作，达到完成职务任务的目标。

什么是性能调优？(what)

》

在说什么是性能调优之前我们先来说一下，计算机的体系结构。

如上图，简单来说包括三块：硬件、操作系统、应用程序。其实，性能调优就是调节这些内容，包括硬件、操作系统、应用程序。其中，这三大方面中又包含了若干的内容。

硬件包括: CPU、内存、磁盘、网卡、其它……

操作系统包括 进程、虚拟内存、文件系统、网络、其它……

应用程序我就不用说了大家都懂，常见的有Apache、MySQL、Nginx、Memcahed等。

那什么是性能调优呢？

性能调优就是对计算机硬件、操作系统和应用有相当深入的了解，调节三者之间的关系，实现整个系统（包括硬件、操作系统、应用）的性能最大化，并能不断的满足现有的业务需求。

这就是我们说的性能调优，客官你懂了嘛？

为什么需要性能调优？(why)

》

下面我们来说一说为什么需要性能调优，其实说到底就两原因：一是为了获得更好的系统性能（就是你现有的系统运行的还不错，但优化一下可以运行的更好）。二是通过性能调优来满足不断增加的业务需求。为了更直观的帮助大家来理解为什么要性能调优？

我们分别从三个方面来说：

硬件选型（根据服务器应用类型来选购服务器）操作系统发行版本 （选择发行版本）应用程序 （Nginx、MySQL等）1.硬件选型

不管你是租服务器也好还是自己买服务器也好都要遇到一个问题，我们选择什么样硬件配置的服务器。

一般我们是根据应用类型来选择服务器，因为你不可能一种硬件配置来满足所有的应用需求，因为每个应用的具体需求不一样。下面我们来看一下在项目实施中有哪些应用类型：

负载均衡：性能要求相对较低，因为只负责转发数据，但要保证选一性能突出的网卡即可。（推荐配置：CPU E5620 x １ 内存 ８G 硬盘 500G)

web 服务器：一般只处理一些静态页面或者图片等，因此要求也不是很高，主流的服务器都可以。（推荐配置：CPU E5620 x １ 内存 16G 硬盘 500G）

应用服务器：一般应用程序服器，他承担网站功能的实现，在架构中占有比较重的位置，特别是网站架构中只有一台应用服务器，对CPU、内存、磁盘要求都比较高。（推荐配置：CPU E5620 x 2 内存 32G 硬盘 500G）

缓存服务器：分为前端页面缓存与后面数据缓存，他们典型的应用分别是Varnish与Memcached，对内存的要求比较大，一般我们配置服务器时使用较大有内存。（推荐配置：CPU E5620 x 1 内存 32G 硬盘 500G）

数据库服务器：数据服务器对CPU、内存、磁盘的要求都很高，一但某个硬件是短板都会带来性能问题。（推荐配置：CPU E5620 x 2 内存 64G 固态硬盘 500G）

备份服务器：备份服务器一般就没有什么要求，但有点可以肯定是必须有足够大的硬盘空间。（推荐配置：CPU E5620 x 1 内存 4G 硬盘 2TB）

监控服务器：一般也没什么需要，普通的PC服务器就可以。（推荐配置：CPU E5620 x 1 内存 4G 硬盘 500）

其它服务器：至于其它服务器就看各位的具体需要具体分析了。

这下各位知道什么是硬件的性能调优了吧，根据你具体的应用，进行具体分析特别是像MySQL这样的服务器，对CPU、内存、磁盘要求都比较高。

所以，对硬件的性能调优我们必须做到选择合适的硬件配置。这是网站架架构或者项目实施首先要解决的问题！

2.操作系统

有本书叫《Linux Performance Tuning》（Linux 性能调优）这本书是老外写的，作者是 Fernando Apesteguia 。

为什么我们需要性能调优？他得出的结论是这样的:

“当一个发行版打包发送到客户手中的时候，它是为了完全兼容市场中大部分计算机而设计的。这是一个相当混杂的硬件集合（硬盘，显卡，网卡，等等）。

所以Red Hat，SUSE，Mandriva，Ubuntu和其他的一些发行版厂商选择了一些保守的设置来确保安装成功。”

简单说，你的操作系统已经运行的不错了，但是你可以调节它获得更高的性能，比如你有个高性能的磁盘，但你的操作系统中一些选项参数默认没有启动，就不能实现这些高级功能来提高硬盘性能。

还有我想说就是对操作系统发行版选择的问题，RedHat或CentOS这些操作系统在项目实施或网站架构中用的比较多，主要针对企业应用而开发的操作系统。

而Ubuntu之类的操作系统对桌面支持的比较好，所以选择发行版本时得注意。（一般企业中用的比较多的是CentOS）再有就是我们一般不要选择最新的发行版，因为刚出来的发行版相对来说bug还比较多，不要先当“小白鼠”了，

比如：刚刚出来CentOS 7 等过一段时间稳定了再使用，目前我们可以选择 CentOS 6.4 或 6.5即可。

（但新版本也有很多好处，新版本中加入了很多新功能，去掉习已知bug，对于一些不重要的应用，可尝试使用新的操作系统）

3.应用程序

最后，我们得来说说应用程序了，我们先来简单看到一下Apache的MPM配置文件:

prefork 模型：

大家可以从上面的配置文件中可以看出，apache 开始启动时启用 8个进程，最小 5个进程，最大20个进程，每个进程限制请求数为256个，最多可以接受请求 4000个，超过这个限制数自动销毁。

worker 模型：

再看一下，worker模型的配置文件，默认启动2个进程，每个进程可以接受的请求为150个，每个进程中最小线程数25个，最大线程数为75个，默认线程数25个，每个线程可以接受的请求没有限制为0。

好了，大家看完上面的配置文件，可以看出默认的Apache配置文件，设置的比较保守，只适于一些中小网站，想要获得高性能的Apache服务器还必须进行性能调优，包括apache编译选项，配置文件优化等，具体的调优我们在这里先不细说。

通过我们上面的讲解，我们分别从硬件、操作系统、应用程序，这三个方面入手和大家谈谈为何需要性能调优，相信大家已经知道并了解，相信大家都迫不及待了吧。

嘿嘿，我们先不急还有很多问题没有说清楚，下面我们和大家来说说，什么时候需要性能调优？

什么时候需要性能调优？(when)

》

一般分为两个时间段：

上线前（基本优化）上线后（持续优化）为什么这样说呢，一般我们在项目实施到项目上线这段时间，不但要准备硬件服务器、安装操作系统、环境搭建，还有个很重要的问题就是进行性能优化，包括操作系统优化和应用环境优化等，我称上线前的优化为基本优化也称为经验优化。

根据你做过的项目和你工作中的经验对上线前的服务器或架构进行基本的性能优化来满足业务需求。

再有就是项目上线后的优化，在上线前我们已经经过基本的性能优化，解决大部分的性能问题，但毕竟上线前的所以测试都是模拟测试并进行相关的性能优化，与上线后的真实环境还是有相当大的区.

我们首先要做的就是对上线后的项目进行性能监控包括服务器性能监控和服务性能监控。

服务器性能监控包括：

CPU使用率、CPU负载、内存使用率、磁盘I/O、磁盘空间使用率、网络流量、系统进程等，服务性能监控包括apache、nginx、mysql。

以上架构中所有的服务都需要进行性能监控，一但发现有问题我们都得去进行性能优化，在这个过程中我称为持续优化也称为监控优化。下面我们来具体的说一下，具体什么地方需要性能调优？

什么地方需要性能调优？(where)

》

在上面我们说性能调优只说一些大的方面，包括硬件、操作系统、应用程序这三大块。

其实还有一块就是程序本身的优化，开发人员根据需求开发出来的程序本身就需要性能优化，但对于我们运维人员来说接触的比较少而已。

下面我们就来看看这三大块：

硬件 （CPU、内存、磁盘、网卡）操作系统（进程、文件系统、内核 ……）应用程序（Nginx、MySQL ……）1.硬件

硬件优化一般也包括两块：

上线前（硬件选型）上线后（硬件扩展）一般项目搭建时都需要根据具体的应用进行硬件配置选型，在这方面需要一定的运维经验刚接触的朋友可以在这方面有点欠缺，但没事一般做过一两个项目以后，对硬件配置选型也就会了，嘿嘿。

但有个不成文的经验，硬件配置还是越高越好（别说是我说的）。

我们为什么说需要根据具体的应用来选型呢，一方是什么样的应用需要什么样的硬件配置，还有点很重要就是节约成本，钱得要在刀刃上不该花的钱我们不能乱花，也是为公司节约成本，实现资源利用最大化。

上面我们说的是项目搭建初期，你运气比较好项目一开始你就在这边。

一般有经验的运维工程师在硬件选型是不会有问题的，所以我们在性能优化时就不考虑硬件这块，从理论上讲我们服务器硬件配置一般不会出现在这种性能问题上。

但是呢，由于我们业务做的越来越好，项目创建初期没有考虑到会有这么大的性能需要（访问量），现在有的硬件不能满足业务需求，所我们这时需要更换更好的CPU、更大的内存和更快的磁盘。

至于如何找出硬件是性能瓶颈我们先在这里不细说，在后面的文章中我们将会细说。最后我们来看一张硬件架构图，能帮你更好的理解硬件优化，如下图（Dell R 710 架构）：

2.操作系统

下面我们来说操作系统，其实绝大部分的优化都在操作系统和应用程序的优化，除了上线前的硬件选型和上线后的硬件扩展，下面我们就来看看操作系统优化包括哪些：

操作系统安装优化系统初始化进程调优内存调优IO 调优文件系统调优网络调化

下面我们来看一张图，可以更直观的帮且我们理解，如下图：

3.应用程序

最后我们来说说应用程序优化，这里我们来说一下MySQL优化例子，让大家更直观的了解。

MySQL 编译安装优化MySQL 配置文件优化索引优化MySQL 引擎优化查询缓存优化SQL 语句优化优化表类型（MyISAM或InnoDB）锁机制优化MySQL 服务器优化（换SSD）

通达上面的对硬件、操作系统、应用程序的具体说明相信，大家对性能优化有了更深层次的了解，下面我们来说一个重要的问题，什么人来进行性能优化？

什么人来进行性能调优？(who)

》

一说起性能优化我们第一个想到的是运维工程师，他们来进行优化。

其实我想说，这么说是片面的性能优化不仅仅是运维工程师的事。

其实呢，性能优化是一个团队的事。我为什么这么说呢？

下面我们就来说一下，大家想啊一公司需要做一项目，我们就拿最常见的电子商务中商城的项目来说吧，公司确认由于业务需要我们需要在网上做一个建材商城，那项目的具体流程是什么呢？可能不是很详细，但大体过程是样的：

运营提出需求产品整理需求开发开发具体的业务应用运维搭建开发环境QA 进行项目测试运维进行项目上线监控进行项目监控

开发一个具体的应用需要运营部、产品部、开发部、运维部、QA （测试）、监控等所以有部门的参加。

同样的一个项目（业务）存在性能问题，不会只是运维部门需要性能调优而是所以部门一起解决这个性能问题，这是缺一不可的。

可能出现在产品，也可能出现在程序上（*.php）,也可能是业务需要本身就有问题，也可能是运维的环境搭建有问题。但参加性能调优的更多的是开发、运维、测试和监控。

怎么样进行性能调优？(How)

》

下面进入正题了我们说一说怎么进行性能调优，具体步骤如下：

性能指标 –> 确认衡量标准性能测试 –> 验证性能指标性能分析 –> 找出性能瓶颈性能调优 –> 解决性能问题性能监控 –>检验调优效果

1.性能指标

上面我们说了，我们优化的目的是为了获得更好的性能，那么性能指标是什么呢？我们怎么样来衡量，一般衡量一个项目（这里指的网站）的指标有三个：

吞吐量 –> 是单位时间内完成的用户或系统的请求数量。并发数 –> 同时能接受多少用户的访问请求响应时间 –>用户发出请求到收到响应的时间间隔。

2.性能测试

我们做产品或者说项目（更直白的说是网站）目的是为了让用户使用，我们得先站在用户的角度分析一下，用户需要关注哪些性能。

对于用户来说，当点击一个按钮、链接或发出一个操作指令，到系统把请求处理好发给用户并用网页的形式展现出来为止，这个过程中所消耗的时间是用户对这个网站性能的直观印象。

也就是我们所说的响应时间，当响应时间较小时，用户体验相对来说就会好，当然用户体验的响应时间包括个人主观因素和客观响应时间。

在网站开发与搭建�...

“本文作者 陈睿 ，优知学院创始人新技术、新趋势往往趋之若鹜却又很难说的透彻，希望这篇文章能让大家完整的理解什么是大数据:该篇包含：大数据、技术、场景应用以及大数据的岗位。

什么是大数据

说起大数据，估计大家都觉得只听过概念，但是具体是什么东西，怎么定义，没有一个标准的东西，因为在我们的印象中好像很多公司都叫大数据公司，业务形态则有几百种，感觉不是很好理解，所以我建议还是从字面上来理解大数据，在维克托迈尔-舍恩伯格及肯尼斯库克耶编写的《大数据时代》提到了大数据的4个特征：

一个是数量大一个是价值大一个是速度快一个是多样性第一个是数量比较大，只有数据体量达到了PB级别以上，才能被称为大数据。1PB等于1024TB，1TB等于1024G，那么1PB等于1024*1024个G的数据。

第二个是价值大，你如果有1PB以上的全国所有20-35年轻人的上网数据的时候，那么它自然就有了商业价值，比如通过分析这些数据，我们就知道这些人的爱好，进而指导产品的发展方向等等。如果有了全国几百万病人的数据，根据这些数据进行分析就能预测疾病的发生，这些都是大数据的价值。

第三个就是多样性，如果只有单一的数据，那么这些数据就没有了价值，比如只有单一的个人数据，或者单一的用户提交数据，这些数据还不能称为大数据，所以说大数据还需要是多样性的，比如当前的上网用户中，年龄，学历，爱好，性格等等每个人的特征都不一样，这个也就是大数据的多样性，当然了如果扩展到全国，那么数据的多样性会更强，每个地区，每个时间段，都会存在各种各样的数据多样性。

第四个是速度快，就是通过算法对数据的逻辑处理速度非常快，1秒定律，可从各种类型的数据中快速获得高价值的信息，这一点也是和传统的数据挖掘技术有着本质的不同。

大数据的行业应用

大数据无处不在，大数据应用于各个行业，包括金融、汽车、餐饮、电信、能源、体能和娱乐等在内的社会各行各业都已经融入了大数据的印迹。

制造业，利用工业大数据提升制造业水平，包括产品故障诊断与预测、分析工艺流程、改进生产工艺，优化生产过程能耗、工业供应链分析与优化、生产计划与排程。

金融行业，大数据在高频交易、社交情绪分析和信贷风险分析三大金融创新领域发挥重大作用。

汽车行业，利用大数据和物联网技术的无人驾驶汽车，在不远的未来将走入我们的日常生活。

互联网行业，借助于大数据技术，可以分析客户行为，进行商品推荐和针对性广告投放。

电信行业，利用大数据技术实现客户离网分析，及时掌握客户离网倾向，出台客户挽留措施。

能源行业，随着智能电网的发展，电力公司可以掌握海量的用户用电信息，利用大数据技术分析用户用电模式，可以改进电网运行，合理设计电力需求响应系统，确保电网运行安全。

物流行业，利用大数据优化物流网络，提高物流效率，降低物流成本。

城市管理，可以利用大数据实现智能交通、环保监测、城市规划和智能安防。

生物医学，大数据可以帮助我们实现流行病预测、智慧医疗、健康管理，同时还可以帮助我们解读DNA,了解更多的生命奥秘。

体育娱乐，大数据可以帮助我们训练球队，决定投拍哪种题财的影视作品，以及预测比赛结果。

安全领域，政府可以利用大数据技术构建起强大的国家安全保障体系，企业可以利用大数据抵御网络攻击，警察可以借助大数据来预防犯罪。

个人生活， 大数据还可以应用于个人生活，利用与每个人相关联的“个人大数据”，分析个人生活行为习惯，为其提供更加周到的个性化服务。

大数据的价值，远远不止于此，大数据对各行各业的渗透，大大推动了社会生产和生活，未来必将产生重大而深远的影响。

大数据使用的技术

说起大数据，大数据有三个层数据采集、存储、计算三层。

第一个是数据采集层，以App、saas为代表的服务。

大数据基础阶段需掌握的技术有：Linux、Docker、KVM、MySQL基础、Oracle基础、MongoDB、redis以及hadoopmapreduce hdfs yarn等。

第二个数据存储层，比如云存储，需掌握的技术有：hbase、hive、sqoop等。

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

HBase是一种Key/Value系统，部署在hdfs上，克服了hdfs在随机读写这个方面的缺点，与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。

第三个是数据计算应用层，以数据为基础，为将来的移动社交、交通、教育，金融进行服务，涉及到大数据架构设计阶段需掌握的技术有：Flume分布式、Zookeeper、Kafka等，以及大数据实时计算阶段需掌握的技术有：Mahout、Spark、storm。

大数据的岗位

1.数据分析师Data analyst

指熟悉相关业务，熟练搭建数据分析框架，掌握和使用相关的分析常用工具和基本的分析方法，进行数据搜集、整理、分析，针对数据分析结论给管理销售运营提供指导意义的分析意见。

2.数据架构师Data architect

对Hadoop解决方案的整个生命周期进行引导，包括需求分析，平台选择，技术架构设计，应用设计和开发，测试和部署。深入掌握如何编写MapReduce的作业及作业流的管理完成对数据的计算，并能够使用Hadoop提供的通用算法， 熟练掌握Hadoop整个生态系统的组件如： Yarn，HBase、Hive、Pig等重要组件，能够实现对平台监控、辅助运维系统的开发。

3.大数据工程师Big DataEngineer

收集和处理大规模的原始数据（包括脚本编写，网页获取，调用APIs，编写SQL查询等）；将非结构化数据处理成适合分析的一种形式，然后进行分析；根据所需要的和专案分析商业决策。

4.数据仓库管理员

Data warehousemanager：指定并实施信息管理策略；协调和管理的信息管理解决方案；多个项目的范围，计划和优先顺序安排；管理仓库的各个方面，比如数据外包，移动，质量，设计和实施。

5.数据库管理员Database manager

提高数据库工具和服务的有效性；确保所有的数据符合法律规定；确保信息得到保护和备份；做定期报告；监控数据库性能；改善使用的技术；建立新的数据库；检测数据录入程序；故障排除。

6.商业智能分析员Businessintelligence analyst

就工具，报告或者元数据增强来进行传播信息；进行或协调测试，以确保情报的定义与需求相一致；使用商业智能工具来识别或监测现有和潜在的客户；综合目前的商业只能和趋势数据，来支持采取行动的建议；维护或更新的商业智能工具，数据库，仪表板，系统或方法；及时的管理用户流量的商业情报。

数据库中数据的基本结构

定义一：数据元素集合（也可称数据对象）中各元素的关系。

定义二：相互之间存在特定关系的数据元素集合。

一个表(数据库)，我们就称它为一个数据结构，它由很多记录(数据元素)组成，每个元素又包括很多 字段(数据项)组成数据库测试分类系统测试、集成测试、单元测试、功能测试、性能测试、安全测试系统测试、数据库在初期设计中需要进行分析测试。

对于各种数据元素进行完美融合，并理清相互之间的关系便是数据库结构的基本定义。

在数据库中，不同数据之间会存在既定的特殊关系，其属于各种数据元素的集合。对于数据库来说，其可以称之为数据结构，其将会由大量数据元素记录组成，而每一个元素又可以划分为很多字段，在组成的数据库中，总体可以划分为系统测试、集成测试、单元测试、功能测试、性能测试、安全测试以及数据库测试等。

存储过程，视图，触发器，约束，规则等我们都需要进行需求的验证确保这些功能设计是符合需求的。

确认数据库设计文档和最终的数据库相同，当设计文档变化时我们同样要验证修改是否落实到数据库上。

数据库设计评审来实现集成测试

数据项的修改操作、数据项的增加操作、数据项的删除操作、数据表增加满、数据表删除空、删除空表中的记录、数据表的并发操作、针对存储过程的接口测试、结合业务逻辑做关联表的接口测试 ，需要对这些接口考虑采用等价类、边界值、错误猜测等方法进行测试单元测试

单元测试侧重于逻辑覆盖，数据库开发的单元测试相对简单

– 语句覆盖

– 通过走读方式功能测试

DBunit

– 一款开源的数据库功能测试框架，可以使用类似与Junit的方式对数据库的基本操作进行白盒的单元测试，对输入输出进行校验。

QTP

– 通过对对象的捕捉识别，我们可以通过QTP来模拟用户的操作流程，通过其中的校验方法或者结合数据库后台的监控对整个数据库中的数据进行测试。

DataFactory

一款优秀的数据库数据自动生成工具，通过它你可以轻松的生成任意结构数据库，对数据库进行填充，帮助你生成所需要的大量数据从而验证我们数据库中的功能是否正确。这是属于黑盒测试。

数据库性能

性能优化分4部分

物理存储方面、逻辑设计方面、数据库的参数调整、SQL语句优化数据库性能。

数据库系统的SQL语句分析工具，分析得到数据库语句执行的瓶颈，从而优化SQL语句

Loadrunner

通过对协议的编程来对数据库做压力测试

Swingbench

专门针对oracle

oracle11g提供了real application test，提供数据库性能测试，分析系统的应用瓶颈数据库安全测试

SQL 注入攻击 、跨站点脚本攻击、未经授权的用户访问所谓SQL注入（SQL Injection），就是利用程序员对用户输入数据的合法性检测不严或不检测的特点，故意从客户端提交特殊的代码，从而收集程序及服务器的信息，从而获取想得到的资料。通常别有用心者的目标是获取网站管理员的帐号和密码。

想要写出高质量、高性能的SQL查询语句：

一、首先要搞明白什么叫执行计划？

执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生的，比如一条SQL语句如果用来从一个 10万条记录的表中查1条记录，那查询优化器会选择“索引查找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用“全表扫描”方式。

可见，执行计划并不是固定的，它是“个性化的”。产生一个正确的“执行计划”有两点很重要：

(1)SQL语句是否清晰地告诉查询优化器它想干什么？

(2)查询优化器得到的数据库统计信息是否是最新的、正确的？

二、统一SQL语句的写法

对于以下两句SQL语句，程序员认为是相同的，数据库查询优化器认为是不同的。

select*from dual

select*From dual

其实就是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两次解析。生成2个执行计划。所以作为程序员，应该保证相同的查询语句在任何地方都一致，多一个空格都不行！

三、SQL语句编写注意问题

下面就某些SQL语句编写注意问题做一下详细的介绍。在这些where子句中，即使某些列存在索引，但是由于编写了劣质的SQL，系统在运行该SQL语句时也不能使用该索引，而同样使用全表扫描，这就造成了响应速度的极大降低。

1.IS NULL 与 IS NOT NULL不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。任何在where子句中使用is null或is not null的语句优化器是不允许使用索引的。2.避免使用不兼容的数据类型。不兼容的数据类型代表着全表检索数据的类型转换，访问将变为全表扫描select * from employee where last_name = 100;注last_name为varchar类型

3.联接列

对于有联接的列，即使最后的联接值为一个静态值，优化器是不会使用索引的。我们一起来看一个例子，假定有一个职工表(employee)，对于 一个职工的姓和名分成两列存放(FIRST_NAME和LAST_NAME)，现在要查询一个叫比尔.克林顿(Bill Cliton)的职工。

下面是一个采用联接查询的SQL语句，

select * from employss where first_name||''||last_name ='Beill Cliton';

上面这条语句完全可以查询出是否有Bill Cliton这个员工，但是这里需要注意，系统优化器对基于last_name创建的索引没有使用。

当采用下面这种SQL语句的编写，Oracle系统就可以采用基于last_name创建的索引。

*** where first_name ='Beill' and last_name ='Cliton';4. 通配符（%）开头的like语句目前的需求是这样的，要求在职工表中查询名字中包含cliton的人。可以采用如下的查询SQL语句：select * from employee where last_name like '%cliton%'这里由于通配符（%）在搜寻词首出现，所以Oracle系统不使用last_name的索引。然而当通配符出现在字符串其他位置时，优化器就能利用索引。在下面的查询中索引得到了使用：select * from employee where last_name like 'c%'

5.索引字段上进行运算会使索引失效。尽量避免在WHERE子句中对字段进行函数或表达式操作，这将导致引擎放弃使用索引而进行全表扫描。eg：SELECT * FROM T1 WHERE F1/2=100 应改为: SELECT * FROM T1 WHERE F1=100*2

6. Order by语句ORDER BY语句决定了Oracle如何将返回的查询结果排序。Order by语句对要排序的列没有什么特别的限制，也可以将函数加入列中（象联接或者附加等）。任何在Order by语句的非索引项或者有计算表达式都将降低查询速度。仔细检查order by语句以找出非索引项或者表达式，它们会降低性能。解决这个问题的办法就是重写order by语句以使用索引，也可以为所使用的列建立另外一个索引，同时应绝对避免在order by子句中使用表达式。7. NOT我们在查询时经常在where子句使用一些逻辑表达式，如大于、小于、等于以及不等于等等，也可以使用and(与)、or(或)以及not(非)。NOT可用来对任何逻辑运算符号取反。下面是一个NOT子句的例子:

... where not (status ='VALID')

如果要使用NOT，则应在取反的短语前面加上括号，并在短语前面加上NOT运算符。NOT运算符包含在另外一个逻辑运算符中，这就是不等于(<>)运算符。换句话说，即使不在查询where子句中显式地加入NOT词，NOT仍在运算符中，见下例:

... where status <>'INVALID';

对这个查询，可以改写为不使用NOT:

select * from employee where salary<3000 or salary>3000;

虽然这两种查询的结果一样，但是第二种查询方案会比第一种查询方案更快些。第二种查询允许Oracle对salary列使用索引，而第一种查询则不能使用索引。8. IN和EXISTS有时候会将一列和一系列值相比较。最简单的办法就是在where子句中使用子查询。在where子句中可以使用两种格式的子查询。

第一种格式是使用IN操作符：

... where column in(select * from ... where ...);

第二种格式是使用EXIST操作符：

... where exists (select 'X' from ...where ...);

我相信绝大多数人会使用第一种格式，因为它比较容易编写，而实际上第二种格式要远比第一种格式的效率高。在Oracle中可以几乎将所有的IN操作符子查询改写为使用EXISTS的子查询。

第二种格式中，子查询以‘select 'X'开始。运用EXISTS子句不管子查询从表中抽取什么数据它只查看where子句。这样优化器就不必遍历整个表而仅根据索引就可完成工作（这里假定在where语句中使用的列存在索引）。相对于IN子句来说，EXISTS使用相连子查询，构造起来要比IN子查询困难一些。

通过使用EXIST，Oracle系统会首先检查主查询，然后运行子查询直到它找到第一个匹配项，这就节省了时间。Oracle系统在执行IN子查询时，首先执行子查询，并将获得的结果列表存放在一个加了索引的临时表中。在执行子查询之前，系统先将主查询挂起，待子查询执行完毕，存放在临时表中以后再执行主查询。这也就是使用EXISTS比使用IN通常查询速度快的原因。

同时应尽可能使用NOT EXISTS来代替NOT IN，尽管二者都使用了NOT（不能使用索引而降低速度），NOT EXISTS要比NOT IN查询效率更高。

9.应尽量避免在 where 子句中使用or来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from employee where num=10 or num=20可以这样查询：select id from employee where num=10 union all select id from employeewhere num=20

10.应尽量避免在 where 子句中对字段进行表达式操作

这将导致引擎放弃使用索引而进行全表扫描。如：select id from t where num/2=100应改为:select id from t where num=100*2

11.应尽量避免在where子句中对字段进行函数操作

这将导致引擎放弃使用索引而进行全表扫描。如：select id from t where substring(name,1,3)=’abc’ ，name以abc开头的id应改为:

select id from t where name like ‘abc%’

12.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

13.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。

14. 索引并不是越多越好

索引固然可以提高相应的select的效率，但同时也降低了insert 及update的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。

15.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。

16.尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。

17.任何地方都不要使用select * fromt，用具体的字段列表代替“*”，不要返回用不到的任何字段。

四、总结：通过这些查询优化方法，我们设法将查询从8秒降低到2秒，并且将查询次数从4次减少到1次。需要说明的是，这些查询时间是在我们开发环境运行时记录的，生产环境速度会更快。

这对追踪查询缓慢及其修复等问题是一个有用的指南。优化查询看起来可能像一个可怕的任务，但只要你尝试一下，并取得一些初步的胜利，你就会开始找到错误，并希望做出进一步改善。

在MySQL中，如何分析一条SQL语句的执行性能？需要关注哪些信息？

答案如下所示：

答案：使用EXPLAIN命令，观察TYPE列，可以知道是否是全表扫描，可以知道索引的使用形式，观察KEY可以知道使用了哪个索引，观察KEY_LEN可以知道索引是否使用完成，观察ROWS可以知道扫描的行数是否过多，观察EXTRA可以知道是否使用了临时表和进行了额外的排序操作。

一 数据分析处理需求分类

1 事务型处理

在我们实际生活中，事务型数据处理需求非常常见，例如：淘宝网站交易系统、12306网站火车票交易系统、超市POS系统等都属于事务型数据处理系统。

这类系统数据处理特点包括以下几点：

一是事务处理型操作都是细粒度操作，每次事务处理涉及数据量都很小。

二是计算相对简单，一般只有少数几步操作组成，比如修改某行的某列;

三是事务型处理操作涉及数据的增、删、改、查，对事务完整性和数据一致性要求非常高。

四是事务性操作都是实时交互式操作，至少能在几秒内执行完成;

五是基于以上特点，索引是支撑事务型处理一个非常重要的技术。

在数据量和并发交易量不大情况下，一般依托单机版关系型数据库，例如ORACLE、MYSQL、SQLSERVER，再加数据复制(DataGurad、 RMAN、MySQL数据复制等)等高可用措施即可满足业务需求。

在数据量和并发交易量增加情况下，一般可以采用ORALCE RAC集群方式或者是通过硬件升级(采用小型机、大型机等，如银行系统、运营商计费系统、证卷系统)来支撑。

事务型操作在淘宝、12306等互联网企业中，由于数据量大、访问并发量高，必然采用分布式技术来应对，这样就带来了分布式事务处理问题，而分布式事务处理很难做到高效，因此一般采用根据业务应用特点来开发专用的系统来解决本问题。

2 数据统计分析

数据统计主要是被各类企业通过分析自己的销售记录等企业日常的运营数据，以辅助企业管理层来进行运营决策。典型的使用场景有：周报表、月报表等固定时间提供给领导的各类统计报表;市场营销部门，通过各种维度组合进行统计分析，以制定相应的营销策略等。

数据统计分析特点包括以下几点：

一是数据统计一般涉及大量数据的聚合运算，每次统计涉及数据量会比较大。

二是数据统计分析计算相对复杂，例如会涉及大量goupby、 子查询、嵌套查询、窗口函数、聚合函数、排序等;有些复杂统计可能需要编写SQL脚本才能实现。

三是数据统计分析实时性相对没有事务型操作要求高。但除固定报表外，目前越来越多的用户希望能做做到交互式实时统计;

传统的数据统计分析主要采用基于MPP并行数据库的数据仓库技术。主要采用维度模型，通过预计算等方法，把数据整理成适合统计分析的结构来实现高性能的数据统计分析，以支持可以通过下钻和上卷操作，实现各种维度组合以及各种粒度的统计分析。

另外目前在数据统计分析领域，为了满足交互式统计分析需求，基于内存计算的数据库仓库系统也成为一个发展趋势，例如SAP的HANA平台。

3 数据挖掘

数据挖掘主要是根据商业目标，采用数据挖掘算法自动从海量数据中发现隐含在海量数据中的规律和知识。

数据挖掘主要过程是：根据分析挖掘目标，从数据库中把数据提取出来，然后经过ETL组织成适合分析挖掘算法使用宽表，然后利用数据挖掘软件进行挖掘。传统的数据挖掘软件，一般只能支持在单机上进行小规模数据处理,受此限制传统数据分析挖掘一般会采用抽样方式来减少数据分析规模。

数据挖掘的计算复杂度和灵活度远远超过前两类需求。一是由于数据挖掘问题开放性，导致数据挖掘会涉及大量衍生变量计算，衍生变量多变导致数据预处理计算复杂性;二是很多数据挖掘算法本身就比较复杂，计算量就很大，特别是大量机器学习算法，都是迭代计算，需要通过多次迭代来求最优解，例如K-means聚类算法、PageRank算法等。

因此总体来讲，数据分析挖掘的特点是:

1、数据挖掘的整个计算更复杂，一般是由多个步骤组成计算流，多个计算步骤之间存在数据交换，也就是会产生大量中间结果，难以用一条sql语句来表达。

2、计算应该能够非常灵活表达，很多需要利用高级语言编程实现。

二 大数据背景下事务型处理系统相关技术

在google、facebook、taobao等大互联网公司出现之后，这些公司注册和在线用户数量都非长大，因此该公司交易系统需要解决“海量数据+高并发+数据一致性+高可用性”的问题。

为了解决该问题，从目前资料来看，其实没有一个通用的解决方案，各大公司都会根据自己业务特点定制开发相应的系统,但是常用的思路主要包括以下几点：

(1)数据库分片，结合业务和数据特点将数据分布在多台机器上。

(2)利用缓存等机制，尽量利用内存，解决高并发时遇到的随机IO效率问题。

(3)结合数据复制等技术实现读写分离，以及提高系统可用性。

(4)大量采用异步处理机制，对应高并发冲击。

(5)根据实际业务需求，尽量避免分布式事务。

1相关系统介绍

1) 阿里CORBAR系统

阿里COBAR系统是一个基于MYSQL数据库的分布式数据库系统，属于基于分布式数据库中间件的分布式数据库系统。该系统是前身是陈思儒开发的“变形虫”系统(以前调研过)，由于陈思儒离开阿里去了盛大，阿里当心“变形虫”稳定性等问题，重新开发该项目。

该系统主要采用数据库分片思路，实现了：数据拆分、读写分离、复制等功能。由于此系统由于只需要满足事务型操作即可，因此相对真正并行数据库集群(例如TeraData等)，此类系统提供操作没有也不需要提供一些复杂跨库处理，因此该系统存在以下限制：

(1)不支持跨库的join、分页、排序、子查询。

(2)insert等变更语句必须包括拆分字段等。

(3)应该不支持跨机事务(以前变形虫不支持)。

说白了此类系统不具备并行计算能力,基本上相当于数据库路由器!

另外此类系统的在实际应用的关键问题是，根据什么对数据进行切分，因为切分不好会导致分布式的事务问题。

2) 阿里OceanBase系统

该系统也是淘宝为了解决高并发、大数据环境下事务型处理而定制开发的一个系统。该系统主要思路和特点如下：

(1)他们发现在实际生成环境中，每天更新的数据只占总体数据的1%不到，因此他们把数据分为：基线数据和增量更新数据。

(2)基线数据是静态数据，采用分布式存储方式进行存储。

(3)只在一台服务器上存储和处理增量更新数据，并且是在内存中存储和处理更新数据。

(4)在系统负载轻的时候，把增量更新批量合并到基线数据中。

(5)数据访问时同时访问基线数据和增量更新数据并合并。

因此这样好处是：

(1)读事务和写事务分离

(2)通过牺牲一点扩展性(写是一个单点)，来避免分布式事务处理。

说明：该系统虽然能处理高并发的事务型处理，号称很牛逼，但其实也只是根据电商的事务处理来定制开发的专用系统，个人认为其技术难度小于oracle等通用型的数据库。该系统无法应用到银行或者12306等，因为其事务处理的逻辑远远比电商商品买卖处理逻辑复杂。

在目前的大数据时代，一定是基于应用定制才能找到好的解决方案!

3) 基于Hbase的交易系统

在hadoop平台下，HBASE数据库是一个分布式KV数据库，属于实时数据库范畴。支付宝目前支付记录就是存储在HBASE数据库中。

HBASE数据库接口是非SQL接口，而是KV操作接口(基于Key的访问和基于key范围的scan操作)，因此HBASE数据库虽然可扩展性非常好，但是由于其接口限制导致该数据库能支持上层应用很窄。基于HBASE应用的设计中，关键点是key的设计，要根据需要支持的应用来设计key的组成。

可以认为HBASE数据库只支持作为KEY的这一列的索引。虽然目前HBASE有支持二级索引的方案，二级索引维护将会比较麻烦。

2并发和并行区别

并发是指同时执行通常不相关的各种任务，例如交易型系统典型属于高并发系统。

并行是通过将一个很大的计算任务，划分为多个小的计算任务，然后多个小计算任务的并行执行，来缩短该计算任务计算时间。

两者主要区别在于：

(1)通讯与协调方面：在并行计算中，由于多个小任务同属一个大的计算任务，因此小任务之间存在依赖关系，小任务之间需要大量通讯和协调;相反，并发中的多个任务之间基本相互独立，任务与任务之间相关性很小。

(2)容错处理方面：由于并发任务之间相互独立，某个任务执行失败并不会影响其它的任务。但是并行计算中的多个任务属于一个大任务，因此某个子任务的失败，如果不能恢复(粗粒度容错与细粒度容错)，则整个任务都会失败。

3本章总结

数据量大不一定需要并行计算，虽然数据量大，数据是分布存储，但是如果每次操作基本上还是针对少量数据，因此每次操作基本上都是在一台服务器上完成，不涉及并行计算。只是需要通过数据复制、数据缓存、异步处理等方式来支撑高并发访问量

三 大数据背景下数据统计分析技术介绍

随数据量变大，和事务处理不同的是，单个统计分析涉及数据量会非常大，单个统计分析任务涉及数据会分散在多台服务器上，且由于计算量大，采用单台服务器进行计算，会导致计算时间非常长，单个统计分析任务必须采用并行计算方式来加快单个统计分析任务执行速度。

1并行查询与并行计算技术介绍

在大数据背景下的数据统计分析技术门类很多，常见的有：

n MPP并行数据库 : TeraData、GreenPlum、Vertica等。

n 基于MapReduce并行计算框架的数据仓库：

HIVE(Hadoop平台) 、Tenzing(Google公司)

n 基于Hbase的Phoenix系统

n HadoopDB系统

n EMC公司的hapt系统

n MPP分布式查询引擎： Dremel、Impala、Presto、Shard query、Citusdb。

n 基于SPARK的Shark、基于Dryad的SCOPE、基于Tez的stinger。

n 基于hadoop+index的JethroData系统

n 基于内存计算的Druid系统

这些系统都解决了海量数据下的数据统计分析的问题，并且这些系统另外一个共同特点是都提供了SQL或者类SQL接口。

为了能够较好研究这些系统，我们需要对并行查询与并行计算的相关技术做一个简要的介绍。

首先所有的系统都可以分为三个层次: 语义层、并行计算引擎层、分布式存储层。语义层提供一个编程接口让用户表达所需要计算，并负责把该计算翻译成底层并行计算引擎可以执行的执行计划，并由并行计算引擎来执行，最下面一层是分布式存储层。

对于提供类SQL接口并行计算系统，语义层可以认为是SQL解析层。

1) 语义层

SQL语言是一种声名式语言，SQL只是表达了要做什么，而没有表达怎么做。为此，SQL解析层主要作用是：将用户提交的基于SQL的统计分析请求，转化为底层计算引擎层可以执行的执行计划。也就是解决“怎么做”的问题。

SQL解析层工作主要包括两个大方面:

(1) 通过语法分析技术来理解要做什么。在关系数据库中，一般会把SQL语言分析后，形成树型结构的执行计划。

(2) 在语法分析技术上，利用各种优化技术和算法，找出一种最经济物理执行计划。

优化可以分为两个方面：一是逻辑层面优化、二是物理执行层面优化。

(1) 逻辑层优化

逻辑层面个人认为主要是因为同样表达一个分析请求，有的人SQL写的好，有的人SQL写的烂，因此在逻辑层面可以通过一些等价关系代数变换，实现查询重写，将写的比较烂的sql变换为好的写法。

比较典型优化是：“把投影和过滤下沉，先执行过滤和投影操作”，减少中间结果。

(2) 物理层优化

物理层面优化是在逻辑优化后，结合实际物理执行过程，找出最优的物理执行计划。生成物理查询计划的工作包括:

ü 增加一些操作符： 包括扫描和排序等。

ü 确定各个操作符实现算法。例如扫描是全表扫描还是利用索引;Join是采用HASH连接、索引连接、合并排序等实现算法中的那一种。

ü 确定操作符之间的数据流转方法：物化还是流水线方式。

ü 采用基于代价估算方法确定最优的物理执行计划，目前代价估算主要是以估算该物理计划需要的IO量。另外对于并行数据库，则还要考虑通讯代价，即尽量减少数据在各个机器之间的传递。

在物理层优化的代价估算过程中，代价估算需要依靠很多统计信息，如表有多大，表中相关列的值分布是什么样子等。传统数据库在数据Load过程中会事先计算好这些统计信息。并行计算中还需要考虑通讯代价。

需要指出是，由于imapla、Presto、HIVE等系统只是一个查询引擎，它们可以直接查询以普通文件方式存储在HDFS系统上的文件，因此这些系统一般无法使用索引和各种统计信息来进行物理执行计划的优化，这些系统一般只能在逻辑层进行一些基于规则静态优化。根据SHARK论文，SHARK系统支持根据前面一些节点计算获得的信息，来动态优化后面执行计划。

(3) 物化与流水线执行方法

一条SQL语句对开发人员而言，感觉只是一次调用，但是实际上在数据库内部，一条SQL语句执行其实是有多个操作符组合而成的的树型结构计算流。如下图：

针对该计算流有两种执行方式：一是基于物化或者是实体化执行方式，另外一种是基于数据流的执行方式。

第一种方法的过程是： 把各个操作运算排序，并把每个操作运算的输出的中间结果存储在磁盘上，直到被另外一个操作运算所...

目前大部分测试人员对操作系统资源、中间件、数据库等性能监控分析都是各自分析各自的监控指标方式造成收集到各项性能指标数据无法完全对映出来组建性能问题最终无法及时准确定位问题。本次交流讨论主要是从操作系统、数据库的角度分别对的参数进行了分析，梳理参数关系，来充分发挥监控软件性能。

对于windows系统和SQL SERVER数据库监控一部分人都喜欢使用loadrunner直接远程连接监控或者通过使用perfmon进行监控，两者监控收集的性能指标一样，只是如果使用LR是可以很好的的结合响应时间等以资源使用情况图合并等更好更形象的图形化分析，确实不错只是多了额外的网络等性能开销。

对于如何通过perfmon.exe对windows系统与SQL SERVER 2008数据库服务性能监控分析-------性能监控大部分人都会，但是对于少部分性能测试初学者他们对系统资源、中间件、数据库等性能监控分析都是各自分析各自的性能指标没有很好的把系统性能指标和数据库应对于得性能指标结合一起监控分析等方式造成收集到各项性能指标数据无法完全对映出来组建性能问题最终无法及时准确定位问题。因此对于从操作系统、数据库的角度出发分别对其各项性能指标参数进行了分析，梳理它们之间性能参数之间的关系，进而才能充分发挥性能测试监控诊断分析的优势才能更好的为性能优化提供有价值的参考依据。

2.1 操作系统监控CPU与SQL SERVER

CPU性能指标：Privileged Time：（CPU内核时间）是指处理线程执行代码所花时间的百分比。如果该参数值和“Physical Disk”参数值一直很高，表明I/O有问题。

SQL compilations/sec，每秒的SQL编译数，表示编译SQL路径被引入的次数，包括需要重新编译的。

SQL SERVER用户活动稳定后，该值也达到某一稳定状态值。

recompilations/sec（每秒SQL重编译数）每秒的SQL重新编译数。计算重新编译被触发的次数。一般来说，重新编译计数器最好保持较低值。

假如SQL SERVER数据库服务器的CPU值很高高，而没有抓取到相应影响CPU使用率的的SQL语句等这时可以尝试把该性能指标值加入

监控范围内，查看该指标是否很高，如果很高说明系统在不断的编译，而影响服务器CPU资源的使用开销。

2.2 内存与SQL SERVER：

内存 sql server可使用的内存量是sql server性能最关键因素之一。而内存同i/o子系统的关系也是一个非常重要的因素。例如，在i/o操作频繁的系统中，sql server用来缓存数据的可用内存越多，必须执行的物理i/o也就越少。这是因为数据将从数据缓存中读取而不是从磁盘读取。同样，内存量的不足会引起明显的磁盘读写瓶颈，因为系统缓存能力不足会引起更多的物理磁盘i/o。

这时可以利用system monitor检查sql server的buffer cache hit ratio计数器，如果命中率经常低于90%，就应该添加更多的内存。

以及IO 与CPU 内存之间的互相影响关系等等

2.3 内存与IO性能指标结合分析问题：

Page Reads/sec：这个值如果很高往往意味着内存存在瓶颈，如果这个值比较低，而%Disk Time 和Avg. Disk Queue Length比较高的话，则意味着瓶颈在磁盘

磁盘、CPU、内存如何结合分析因为有时问题不是单一性而是连锁反应的，可能由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶颈混淆。

建议在测试过程中不是每项指标都要去监控收集还有采集时间也要根据被测对象当时测试场景设计情况去划分（结合软件性能测试生命周期各阶段实施过程介绍中第一章节介绍的场景去设计监控场景），而且还要结合系统与应用软件的特性进行结合监控分析，才能更好的定位问题，如SQL Server与操作系统相关性，操作系统性能的好坏直接影响数据库的使用性能，如果操作系统存在问题，如cpu过载、过度内存交换、磁盘i/o瓶颈等，在这种情况下，单纯进行数据库内部性能调整是不会改善系统性能的。通过Windows NT的系统监视器(system monitor)来监控各种设备，发现性能瓶颈。

如：数据库设计的好坏也直接影响系统资源的使用，如大量全表扫描检索数据最终导致CPU、I/O、内存、网络的使用。

--------以上只是简要介绍，如果有心研究的朋友可以多多结合学习数据库工作的机制原理，与操作系统之间的工作原理结合，就能更好的分析性能问题，当然离不开业务的分析和支持。当我们所测试的业务系统因为随着时间的流逝，数据量的增加而且业务数据最终是落地到磁盘中，最简单的某种业务的数据查询也是从磁盘中获取，因此磁盘是会被大量使用，然而磁盘的存取速度与内存和处理器相比要慢很多，如果在出现磁盘的争用可能显著的降低SQL SERVER的性能，因此对磁盘资源的使用瓶颈分析和解决能够显著地增进SQL SERVER性能，当然这是也要考虑数据库设计以及SQL写法等等--这些就是第三节介绍的《SQL SERVER 2008数据库服务性能监控分析优化方法》。

总之不是表示每次监控都是收集所有的各项指标来分析表示最好的。因为监控分析以及收集本身也是一个很大的性能开销，所以做为性能测试人员我们要设计合理的性能监控数据收集，以最小化监控工具对系统的影响。

日常一提数据分析和可视化，就想到这个工具操作要多简单易用，图表要多美多炫，然而总是忽略背后的数据支撑。

excel 几十万行数据就卡死崩，谈何数据透视表、可视化？近千万行的数据，订单提交数据库，sql sever处理要5分多钟，如果频繁入库/取数的话.....

要知道，为了支撑起业务人员的数据分析，以及日常不考虑计算逻辑和技术难度，IT人员也是要花费很大的心血和精力啊（心疼运维人员n秒）。

随着公司业务的发展，数据量变大是必然的事实。那么，数据部门要做分析，业务部门要看报表，要跑数据，要用BI，大数据量（千万级及以上）的分析，性能该如何优化？

这里借某公司的真实案例，来阐述一下方案。

----------------------------------

作为公司的科技部门人员，经常听到业务部门对自己使用的数据库各种吐槽：

竟然存放在mongoDB中啊，震惊(ΩДΩ)。

数据库慢慢熟悉了还好啊，但是现在每天的数据量越来越大，而且还在增加啊，增加大家很开心，然而数据库并不开心啊，简单的查询统计10多分钟还出不来结果，更不用说有稍微复杂点的统计分析了。

我天天找DBA优化啊，然而并没有什么水花。

数据量还在不断增长，到现在都上亿啦，全量查询统计根本出不来结果啊。

... ...

最终业务人员找到科技部门提需求要弄个BI系统给处理下。

对mongodb瞄了一大通，这就是个业务库。那直接对接mongodb自然不行，速度慢不说，mongodb挂了，分析系统也瘫了。自然就想到了使用中间库，emm mysql oracle 倒是有，可以跑调度抽过来，但是速度依旧不快呢，还要花功夫优化，性价比不高。公司有自己的hadoop平台，将数据抽过来再对接倒是可以，但是要花很大精力跑调度，而且这个数据库不能随意给这个业务部门提供，万一玩挂了可就得不偿失。假设有个具备离线数据存储功能的BI工具，岂不美哉。

于是将市面上有离线数据存储功能的BI工具翻了个遍。期望找到个性能好，可以支持大数据量数据分析的BI工具。

Tableau的hyper功能看起来OK，经不起实际使用，数据量过了亿，等了好久数据抽不好，pass；

其他某BI工具有mpp离线存储，看起来很棒，还能横向扩展，不错。抱有最大期望的用，结果数据量一上亿，直接崩了，崩了，pass；

另一个BI工具去看了看，咦，数据是放在vertica里面的......

后来，找到了FineBI的分布式计算引擎方案，拿的『定制的 Alluxio』作为分布式内存存储框架，内存存储有数据安全性的担心，所以持久化层存储用了HDFS。为了数据分析嘛，自然是列式存储的。计算核心则以熟知的Spark，加上自研算法来处理的。使用熟知的zookeeper整合框架，并用于调度通信。

分布式嘛，横向扩展自然不在话下。而列式存储、并行内存计算、计算本地化加上高性能算法，在FineBI中数据展示速度超快。有意思的是其计算本地化的操作，能减少不必要的shuffle，节省数据传输的消耗，提升数据计算速度。

以下记录利用FineBI4.1工具的系统建设过程。

一、需求分析

针对以上的需求，可以预估到，18年内，常用分析预计最大数据量会达到4.7kw，不常用分析会达到3亿到4亿（包含淡季），数据总的体量最多会达到100G。后面的情况难以预估，就需要系统可横向扩展节点。

二、方案描述

1.系统架构

根据官方推荐，将FineBI的web应用端与数据存储的分布式引擎放在一个机器上（处于安全考虑，也可以分开。这里不涉及太多部门使用，放一起即可），架构如下所示。

架构图难以理解的话，可以看看灵魂画手的杰作~

结合分布式引擎说明的技术原理，将各个机器再细分化各个组件的作用。

以上，将系统架构规划完成，即可具体完成系统。

2.完成从MongoDB取数

在使用BI工具对接MongoDB的时候，使用MongoDB的BI连接器。

感兴趣可以看：MongoDB Download Center

方案原理：mongodb是非结构的数据库，而要想BI来连接，通过建模的方式取表，拆表，建模来分析。通过MONGODB CONNECTOR FOR BI连接器的方式，使用mysql的JDBC驱动来获取数据。

实现过程：

第一步：安装MONGODB CONNECTOR FOR BI

从官网选择版本：MongoDB Download Center

第二步：生成DRDL文件

mongodrdl是生成该文件的主命令。通过添加monogdb的相关参数来获取其中的表生成drdl文件。从官方文档上我们可以找到生成DRDL文件命令的范式：

1 mongodrdl --host myhost.example:27017 \2 --username dbUser \3 --password myPassword \4 --db reports \5 --authenticationDatabase admin \6 --out schema.drdl

范式说明：

--host 是mongodb的ip+端口号，通常可为127.0.0.1:27017--username 是mongodb的用户，需具备相关的数据权限--password 是username的密码--db 是要生成DRDL的数据库实例名--authenticationDatabase 是指定创建用户的数据库。即username创建时被指定到的数据库名。--out 是DRDL输出文件定义。值使用.drdl的文件即可。

第三步：启动连接器，连接上monogdb

启动连接器的主命令服务是mongosqld，由于mongodb开启用户认证了（auth=true）。从官方文档上可知，连接器的启动需要使用-auth参数，再使用auth参数的情况下，mysql驱动来取数就需要SSLl加密认证。

所以第一步需要配置mongosqld的SSL认证；才能启动连接器来取数！！！！！！！！！！这一步神坑，也是踩了多少坑，才找到的解决办法。

此处认证关系是FineBi端的mysql连接与mongosqld的连接之间的SSL认证。在认证时，只需要配置单向SSL的认证即可（mongosqld认证FineBI的连接）。

（1）生成SSL认证文件

SSL认证文件通常采用openSSL来生成，先看看是否安装了openSSL；执行命令：

rpm -qa|grep -i openssl

如安装了会返回信息，未安装需要自行安装OpenSSL。

采用以下命令来生成证书：（由于是测试，就直接自己生成证书，密钥）

openssl req -newkey rsa:2048 -new -x509 -days 365 -nodes -out mongodb-cert.crt -keyout mongodb-cert.key

命令返回会让填写一些值，在后面填写即可。

一般情况下，文件会生成到你所使用的linux用户的要根目录下：比如我用的root用户，就到/root下面查找。

再使用以下命令，将key合到.pem的文件里。

cat mongodb-cert.key mongodb-cert.crt >mongodb.pem

将该文件移动/etc/ssl下面用于验证使用：

mv mongodb.pem /etc/ssl

（2）启动连接器&SSL

再来看官方文档，从所有的参数命令里面，找一找需要的参数；得出以下的范式，在bin目录下启动即可。

mongosqld --auth --sslMode --sslPEMKeyFile --sslAllowInvalidCertificates --defaultAuthSource --mongo-uri --mongo-username --mongo-password --mongo-authenticationSource --schema

说明：

--auth 是开启用户认证的参数，默认值是true--sslMode是开启SSL的标识，如开启可以选择值为“requireSSL”--sslPEMKeyFile是SSL认证文件，一般为.pem结尾的文件；单向认证的时候。--sslAllowInvalidCertificates--defaultAuthSource是mongosqld使用username指向mongodb的有权限的库，默认值是admin--mongo-uri是mongodb的host，一般为ip+端口号--mongo-usrname是drdl生成的用户名--mongo-password是drdl生成的密码--mongo-authenticationSource指定用户的创建库--schema是要连接的drdl文件。

注：一般还是要用nohup 的命令来生成，保证shell断掉，连接器依然可用。

第四步：启动FineBI连接到连接器上

启动FineBI，打开FineBI>数据配置>数据连接：添加数据连接选择mysql，配置如下：

连接名：mongodbURL：jdbc：mysql：//127.0.0.1:3307/test?ssl-key=/etc/ssl/mongodb.pem用户名：密码：注：URL：jdbc：mysql://ip+3307/dbname?ssl-key=xx.pem，后面ssl-key是ssl参数

点击测试连接即可。

过程坑点：mongodb的BI连接器神坑，官网文档不多，踩过了几脚坑。

（1）mongosqld按ssl认证开启成功，打印也不错，但是BI连接的时候，还是抛错1043 SQLSTATE: 08S01 (ER_HANDSHAKE_ERROR):this server only allows SSL xxxxx该抛错是mysql抛出来的，握手不良的错误。按道理SSL已经开启了，不应该是这样。后来查了mysql的文档，mysql5.5以上的版本才支持SSL；更换新的driver驱动，使用的是5.1.44完全没问题的。

（2）BI连接的时候抛错 handshake error: ERROR 1043 (08S01): error performing authentication: unable to authenticate conversation 0: unable to authenticate using mechanism "SCRAM-SHA-1": (AuthenticationFailed) Authentication failed.

该抛错的意思，使用“SCRAM-SHA-1”的认证方式，没有认证成功。SCRAM-SHA-1是指用户名密码的方式，这里看是不是用户名/密码错误，注意mongosqld启动时的使用的用户名/密码

（3）一定要开启SSL认证啊！！！

（4）期间有设计器无故死掉的情况，发现是由于内存不足导致。记得空闲内存要足够！！

三.系统效果

1.数据更新

（1） 单个表先全量抽取，之后每天对单表依据时间戳，做增量增加。其中有错误数据做增量删除即可。

（2）有些内部使用的实时性较高的表，设定每2小时更新一次，从上午9点到下午6点。直接从业务库抽取其实是有风险的，当时数据库压力大，抽取比较慢，因此这部分仅作为非重点用户需求场景。

2.数据展示速度

做了一个简单的依据时间的group by，时间在1s之内，翻页速度也很快。

至此，对接mongodb完成，一个用户可以随便玩的系统就好了。即使偶尔mongodb发疯修整，有离线数据在，也不担心业务部门来嚷嚷了。而且速度超快，体验很棒~

最后

如果你也在寻求一个高性能展示分析、数据分析的BI工具的话，不妨尝试下FineBI。

一、由Oracle数据库性能管理引发的思考

当前，Oracle数据库成为大中型企业的主流数据库，这主要得益于Oracle数据库的高安全性。不过，就管理和维护Oracle数据库而言，常常有以下问题，困扰着管理员。

其一，Oracle数据库处理高并发访问时，性能明显下降，此时会出现很多性能瓶颈。管理员通常很难全面发现这些性能瓶颈。这种情况下，及时发现这些性能瓶颈，并且可视化呈现，对于管理员而言，是大有裨益的。

其二，Oracle数据库对于大量数据的信息统计，不够完善，明显加重了管理员管理和维护的负担。比如，对于各种语句的执行次数、执行情况的统计，对于网络、应用各种参数的统计等等。这些统计结果，共同决定着 Oracle数据库的整体性能。

其三，Oracle数据库的分析主要是针对数据本身，如数据的检索，数据的归档等。对于自身性能的分析，触及甚少，因此出现了故障，排查起来往往很麻烦。

本任务是在实际环境下，通过可视化的智能管理平台辅助管理，提高Oracle数据库的管理、维护效率。实验平台是迪思分析系统。

二、Oracle数据库交互信息可视化

针对Oracle数据库，迪思分析系统首先直观的列出了网络层面的重要参数，如使用率、重传、吞吐率等。其次重点对SQL进行了细致的分析。宏观的展示了事务处理时间、语句、存储过程调用、登录等SQL的情况。通过网络层的重要参数，以及SQL展示，可以迅速从整体上了解Oracle数据库的状态，节约了大量人工管理的步骤。

三、生成Oracle数据库应用流——分析应用性能

根据特定的数据包的具体作用，生成对应的应用流。通过对这些应用流的分析，可以准确的衡量Oracle数据库服务器每一个操作的性能状态。综合考察所有操作的性能状态，进而知道Oracle数据库服务器的整体应用性能。

四、梯形会话图揭示错误细节

深入考察数据包的交互情况，便于发现深层次的数据库错误。偶尔一次两次出现这种错误，一般无碍；连续多次出现，就必须着重分析处理。

五、 错误日志使问题排查不再复杂

系统智能追踪、分析涉及网络层、应用层的Oracle数据库错误，即时生成错误日志。通过这些错误日志，技术人员可以清楚知道错误的根源所在，使排查问题显得游刃有余。

六、结语

通过本次培训，由此可见，通过智能的可视化分析管理平台，辅助于oracle数据库性能的管理和维护，将大幅度提升效率，明显降低管理成本。