postgresql心得的简单介绍

如何学习linux的建议 linux 学习心得

一.为什么要学linux?

当然最重要是爱好和兴趣！如果你这种必要学，或者根本不喜欢，请不要浪费时间，你学也学不好！

二.起步

你应该为自己创造一个学习linux的环境--在电脑上装一个linux或unix

如何选择版本：北美用redhat,欧洲用SuSE,桌面mandrake较多，而debian是技术最先进的linux开发人员中用debian的最多，其次是redhat,从全球linux各应用领域市场份额来看无疑redhat是最多的，此外还有很多出名的发行版本，不再列举。

对于初学linux的人来说，我建议是使用redhat,原因如下：

1）现在很多书都是以redhat为例讲的，为了与书本协调一致

2）周围的人都用redhat,交流比较方便

3）redhat应用范围广，有典型性和代表性

4）它易于使用和安装，我们没有必要把时间浪费在“装系统”上而应集中精力学习最有用的东西。

【注】现在觉得RH很死板，AS,ES等用在服务器上或许不错，Personal desktop用mandrake,debian,suse都不错，笔者现在用Mandrake,因为她长得漂亮:)

如果你并不打算深入学习linux，而是有诸如适应北京市政府办公平台迁移到linux上这种需要，那么中软，红旗等中文linux是不错的选择

我强烈建议：自己亲自动手把linux装到你的硬盘上，你必须学会独立安装linux系统的技能，对于现在的版本来说，其实跟装WinXP一样简单

从此现在开始，请不要以windows的工作方式来考虑问题，应该尝试挖掘linux身上的“天才unix”的气质。

三.进阶

掌握至少50个以上的常用命令

理解shell管道"|",文件流重定向""及追加""等

熟悉Gnome/KDE等X-windows桌面环境操作

掌握.tgz.rpm.biz等软件包的常用安装方法

学习添加外设，安装设备驱动程序（比如modem)

熟悉Grub/Lilo引导器及简单的修复操作

熟悉系统固有目录的名称及公用

学会用mount命令访问其他文件系统

了解vi,gcc,gdb等常用编辑器，编译器，调试器

学习linux环境下的简单组网

建议：买一本不需要太厚的linux教材，大致可以满足要求（现在的书越来越多了，还带很多图，我当时可没这么多书）

四.高级应用

澄清一些概念：linux的普通操作与真正的系统管理不能相提并论，后者需要很多知识

1.英语

即使你不学linux，我也强烈建议你学好英文[U.S.english]。因为实质上计算机语言就是英文和字符,所谓的多国语言只是外部包装。你必须能无障碍的阅读大量的英文技术文档在搜索引擎找到的英文网站和网页中熟练的检索最好能有用英文直接交流的能力，摆脱了这个障碍，你的学习和理解速度就能快很多，你就有机会拉开和别人的差距。

2.shell[sed/awk]

shell是命令解释器，是内核与用户界面交流通道，shell写的小脚本有点类似于win下的.bat但shell比.bat强大的多，shell不只是解释命令，更是一种编程语言，有时候几百行的c用shell几十行就能代替完成工作，因为shell的工作方式建立在系统已有的众多应用程序之上

这也是CS中的一个重要思想。此外，shell可以实现工作自动化，这个概念也比较重要sed,awk用来处理文本，历来很常用。

3.Perl/PHP

漂亮的脚本， CGI的首选，比ASP好，应用面很广

4.C\C++

C、C++是linux/unix的核心语言，系统代码都是C写的

5.ASM

系统底层及内核，硬件，设备驱动程序，嵌入式开发都需要。//走核心路线的话，c\c++,asm最重要

6.Java,Python,Tcl,XML

五、系统管理篇

在熟悉linux的基础上还需要掌握至少一种unix。我首推Solaris，其次是FreeBSD比如运营级系统一般是Solaris+Oracle/DB2之类的学习apache、ssh、sendmail/Qmail、proftp/vsftp、Samba、Squid、MySQL/PostgreSQL/Oracle、Bind等各种应用服务器的构架及电子商务的应用熟悉TCP/IP协议族，学习诸如apache+php+proftp+mysql+quota的实现以及大型局域网，分布式集群等各种企业级应用解决方案熟悉多用户管理，数据库管理，文件系统，逻辑存储管理，日志分析，备份与灾难数据修复系统补丁，内核升级，以及在此基础上的防火墙构架等以保障系统安全在内的各种系统管理技能。

我觉得，如果在此基础上再掌握路由/交换设备便是一个不错的系统管理员

各种基于linux的解决方案可参考相关书籍和文献，必要时用google或各大linux站点站内搜索引擎寻找最新文档，以避免错误和漏洞有几本技术大全和技术内幕我认为都是这方面不错的书

六、深入学习linux

我个人理解的读linux内核需要的基础：在此之前,希望先把应用层的东西学一下,那样会比较好理解

1.C

如果学过潭浩强的大学教科书(除了编几个数学模型好像什么也做不了的那种)，建议再看一下《The C Programming Language》Second Edition这本圣经（如果想学缓冲区溢出，这点C的功力可能是不够的，还有C陷阱与缺陷,C专家编程,C\C++深层探索，反正经典书看多了是没有坏处的）

2.asm (ATT语法，保护模式)

保护模式下的比较复杂，基本上每本讲内核的书都会有介绍有80x86 Intel语法的基础就行，

有兴趣可以看看Intel的官方网站

3.数据结构（离散数学）

计算机专业的核心课程，重要性我就不说了

4.操作系统原理

看懂这个再去读linux吧

5.微机原理/组成原理（数字电路）

底层直接和硬件打交道，所以这个也要

6.了解linux/unix

我想至少你要会操作吧，了解unix的API

7.软件工程/编译原理

这方面的经典书去可以搜到很多我觉得APUE这种书不适合初学者，还是先看看UPE

相关问答

Q1: Greenplum集群部署和架构优化，我总结了5000字的心得

最近对离线数仓体系进行了扩容和架构改造，也算是一波三折，出了很多小插曲，有一些改进点对我们来说也是真空地带，通过对比和模拟压测总算是得到了预期的结果，这方面尤其值得一提的是郭运凯同学的敬业，很多前置的工作，优化和应用压测的工作都是他完成的。 

整体来说，整个事情的背景是因为服务器硬件过保，刚好借着过保服务器替换的机会来做集群架构的优化和改造。 

1.集群架构改造的目标

在之前也总结过目前存在的一些潜在问题，也是本次部署架构改进的目标：

1）之前 的GP segment数量设计过度 ，因为资源限制，过多考虑了功能和性能，对于集群的稳定性和资源平衡性考虑有所欠缺，在每个物理机节点上部署了10个Primary,10个Mirror，一旦1个服务器节点不可用，整个集群几乎无法支撑业务。

2）GP集群 的存储资源和性能的平衡不够 ，GP存储基于RAID-5,如果出现坏盘，磁盘重构的代价比较高，而且重构期间如果再出现坏盘，就会非常被动，而且对于离线数仓的数据质量要求较高，存储容量相对不是很大，所以在存储容量和性能的综合之上，我们选择了RAID-10。

3)集 群的异常场景的恢复需要完善， 集群在异常情况下（如服务器异常宕机，数据节点不可用，服务器后续过保实现节点滚动替换）的故障恢复场景测试不够充分，导致在一些迁移和改造中，相对底气不足，存在一些知识盲区。

4）集群版本过 低 ，功能和性能上存在改进空间。毕竟这个集群是4年前的版本，底层的PG节点的版本也比较旧了，在功能上和性能上都有一定的期望，至少能够与时俱进。

5）操作系统版本升 级 ，之前的操作系统是基于CentOS6，至少需要适配CentOS 7 。

6）集群TPCH 压测验收 ，集群在完成部署之后，需要做一次整体的TPCH压测验收，如果存在明显的问题需要不断调整配置和架构，使得达到预期的性能目标。

此外在应用层面也有一些考虑，总而言之，是希望能够解决绝大多数的痛点问题，无论是在系统层面，还是应用层面，都能上一个台阶。

2.集群规划设计的选型和思考

明确了目标，就是拆分任务来规划设计了，在规划设计方面主要有如下的几个问题：

1）Greenplum的版本选择 ，目前有两个主要的版本类别，一个是开源版（Open Source distribution）和Pivotal官方版，它们的其中一个差异就是官方版需要注册，签署协议，在此基础上还有GPCC等工具可以用，而开源版本可以实现源码编译或者rpm安装，无法配置GPCC。综合来看，我们选择了 开源版本的6.16.2 ，这其中也询问了一些行业朋友，特意选择了几个涉及稳定性bug修复的版本。

2）数据集市的技术选型 ，在数据集市的技术选型方面起初我是比较坚持基于PostgreSQL的模式，而业务侧是希望对于一些较为复杂的逻辑能够通过GP去支撑，一来二去之后，加上我咨询了一些行业朋友的意见，是可以选择基于GP的方案，于是我们就抱着试一试的方式做了压测，所以数据仓库和和数据集市会是两个不同规模体量的GP集群来支撑。

3）GP的容量规划 ，因为之前的节点设计有些过度，所以在数量上我们做了缩减，每台服务器部署12个segment节点，比如一共12台服务器，其中有10台服务器是Segment节点，每台上面部署了6个Primary,6个Mirror，另外2台部署了Master和Standby，就是即（6+6）*10+2，整体的配置情况类似下面的模式。

4）部署架构方案选型 ，部署架构想起来比较容易，但是落实起来有很多的考虑细节，起初考虑GP的Master和Standby节点如果混用还是能够节省一些资源，所以设计的数据仓库和数据集市的部署架构是这样考虑的，但是从走入部署阶段之后，很快就发现这种交叉部署的模式是不可行的，或者说有一些复杂度。

除此之外，在单个GP集群的部署架构层面，还有4类方案考虑。

  方案1 ：Master,Standby和segment混合部署

  方案2 ：Master,Standby和segment独立部署，整个集群的节点数会少一些

  方案3 ：Segment独立部署，Master,Standby虚拟机部署

  方案4 ：最小化单节点集群部署（这是数据集市最保底的方案）  

这方面存在较大的发挥空间，而且总体来说这种验证磨合的成本也相对比较高，实践给我上了一课， 越是想走捷径，越是会让你走一些弯路 ，而且有些时候的优化其实我也不知道改怎么往下走，感觉已经无路可走，所以上面这4种方案其实我们都做了相关的测试和验证。

3.集群架构的详细设计和实践

1）设计详细的部署架构图

在整体规划之上，我设计了如下的部署架构图，每个服务器节点有6个Primary,6个Mirror,服务器两两映射。

2）内核参数优化

按照官方文档的建议和具体的配置情况，我们对内核参数做了如下的配置：

vm.swappiness=10

vm.zone_reclaim_mode = 0

vm.dirty_expire_centisecs = 500

vm.dirty_writeback_centisecs = 100

vm.dirty_background_ratio = 0 # See System Memory

vm.dirty_ratio = 0

vm.dirty_background_bytes = 1610612736

vm.dirty_bytes = 4294967296

vm.min_free_kbytes = 3943084

vm.overcommit_memory=2

kernel.sem = 500 2048000 200 4096

4.集群部署步骤

1）首先是配置/etc/hosts，需要把所有节点的IP和主机名都整理出来。 

2）配置用户，很常规的步骤

groupadd  gpadmin

useradd gpadmin -g gpadmin

passwd gpadmin

3）配置sysctl.conf和资源配置

4）使用rpm模式安装

# yum install -y apr apr-util bzip2 krb5-devel  zip

# rpm -ivh open-source-greenplum-db-6.16.2-rhel7-x86_64.rpm

5）配置两个host文件，也是为了后面进行统一部署方便，在此建议先开启gpadmin的sudo权限，可以通过gpssh处理一些较为复杂的批量操作

6）通过gpssh-exkeys来打通ssh信任关系，这里需要吐槽这个ssh互信，端口还得是22，否则处理起来很麻烦,需要修改/etc/ssh/sshd_config文件

gpssh-exkeys -f hostlist

7）较为复杂的一步是打包master的Greenplum-db-6.16.2软件，然后分发到各个segment机器中，整个过程涉及文件打包，批量传输和配置，可以借助gpscp和gpssh，比如gpscp传输文件，如下的命令会传输到/tmp目录下

gpscp -f /usr/local/greenplum-db/conf/hostlist /tmp/greenplum-db-6.16.2.tar.gz =:/tmp

或者说在每台服务器上面直接rpm -ivh安装也可以。

8）Master节点需要单独配置相关的目录，而Segment节点的目录可以提前规划好，比如我们把Primary和Mirror放在不同的分区。 

mkdir -p /data1/gpdata/gpdatap1

mkdir -p /data1/gpdata/gpdatap2

mkdir -p /data2/gpdata/gpdatam1

mkdir -p /data2/gpdata/gpdatam2

9）整个过程里最关键的就是gpinitsystem_config配置了，因为Segment节点的ID配置和命名，端口区间都是根据一定的规则来动态生成的，所以对于目录的配置需要额外注意。

10）部署GP集群最关键的命令是

gpinitsystem -c gpinitsystem_config -s 【standby_hostname】

其中文件gpinitsystem_config的主要内容如下：

MASTER_HOSTNAME=xxxx

declare -a DATA_DIRECTORY=(/data1/gpdata/gpdatap1  /data1/gpdata/gpdatap2 /data1/gpdata/gpdatap3 /data1/gpdata/gpdatap4 /data1/gpdata/gpdatap5 /data1/gpdata/gpdatap6)

TRUSTED_SHELL=ssh

declare -a MIRROR_DATA_DIRECTORY=(/data2/gpdata/gpdatam1  /data2/gpdata/gpdatam2 /data2/gpdata/gpdatam3 /data2/gpdata/gpdatam4 /data2/gpdata/gpdatam5 /data2/gpdata/gpdatam6)

MACHINE_LIST_FILE=/usr/local/greenplum-db/conf/seg_hosts

整个过程大约5分钟~10分钟以内会完成，在部署过程中建议要查看后端的日志查看是否有异常，异常情况下的体验不是很好，可能会白等。

5.集群部署问题梳理

集群部署中还是有很多细节的问题，太基础的就不提了，基本上就是配置，目录权限等问题，我提另外几个：

1） 资源配置问题 ，如果/etc/security/limits.conf的资源配置不足会在安装时有如下的警告：

2） 网络问题 ，集群部署完成后可以正常操作，但是在查询数据的时候会抛出错误，比如SQL是这样的，看起来很简单：select count(*) from customer,但是会抛出如下的错误：

这个问题的主要原因还是和防火墙配置相关，其实不光需要配置INPUT的权限，还需要配置OUTPUT的权限。 

对于数据节点可以开放略大的权限，如：

入口的配置：

-A INPUT -p all -s xxxxx    -j ACCEPT

出口的配置：

-A OUTPUT -p all -s xxxxx    -j ACCEPT

3）网络配置问题 ，这个问题比较诡异的是，报错和上面是一样的，但是在排除了防火墙配置后，select count(*) from customer；这样的语句是可以执行的，但是执行的等待时间较长，比如表lineitem这表比较大，过亿的数据量，,在10个物理节点时，查询响应时间是10秒，但是4个物理节点，查询响应时间是在90秒，总体删感觉说不过去。

为了排查网络问题，使用gpcheckperf等工具也做过测试，4节点和10节点的基础配置也是相同的。

gpcheckperf -f /usr/local/greenplum-db/conf/seg_hosts -r N -d /tmp

$ cat /etc/hosts

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4

::1      localhost localhost.localdomain localhost6 localhost6.localdomain6

#127.0.0.1    test-dbs-gp-128-230

xxxxx.128.238 test-dbs-gp-svr-128-238

xxxxx.128.239 test-dbs-gp-svr-128-239

其中127.0.0.1的这个配置在segment和Master,Standby混部的情况是存在问题的，修正后就没问题了，这个关键的问题也是郭运凯同学发现的。

5.集群故障恢复的测试

集群的故障测试是本次架构设计中的重点内容，所以这一块也是跃跃欲试。

整体上我们包含两个场景，服务器宕机修复后的集群恢复和服务器不可用时的恢复方式。

第一种场景相对比较简单，就是让Segment节点重新加入集群，并且在集群层面将Primary和Mirror的角色互换，而第二种场景相对时间较长一些，主要原因是需要重构数据节点，这个代价基本就就是PG层面的数据恢复了，为了整个测试和恢复能够完整模拟，我们采用了类似的恢复方式，比如宕机修复使用了服务器重启来替代，而服务器不可用则使用了清理数据目录，类似于一台新配置机器的模式。

1）服务器宕机修复后集群恢复

select * from gp_segment_configuration where status!='u';

gprecoverseg  -o ./recov

gprecoverseg -r

select * from gp_segment_configuration where status='u'

2）服务器不可用时集群恢复

重构数据节点的过程中，总体来看网络带宽还是使用很充分的。

select * from gp_segment_configuration where status='u'

select * from gp_segment_configuration where status='u' and role!=preferred_role;

gprecoverseg -r

select * from gp_segment_configuration where status='u' and role!=preferred_role;

经过测试，重启节点到数据修复，近50G数据耗时3分钟左右

6.集群优化问题梳理

1）部署架构优化和迭代

对于优化问题，是本次测试中尤其关注，而且争议较多的部分。 

首先在做完初步选型后，数仓体系的部署相对是比较顺利的，采用的是第一套方案。

数据集市的集群部分因为节点相对较少，所以就选用了第二套方案

实际测试的过程，因为配置问题导致TPCH的结果没有达到预期。

所以这个阶段也产生了一些疑问和怀疑，一种就是折回第一种方案，但是节点数会少很多，要不就是第三种采用虚拟机的模式部署，最保底的方案则是单节点部署，当然这是最牵强的方案。

这个阶段确实很难，而在上面提到的修复了配置之后，集群好像突然开悟了一般，性能表现不错，很快就完成了100G和1T数据量的TPCH测试。

在后续的改造中，我们也尝试了第三套方案，基于虚拟机的模式，通过测试发现，远没有我们预期的那么理想，在同样的数据节点下，Master和Standby采用物理机和虚拟机，性能差异非常大，这个是出乎我们预料的。比如同样的SQL,方案3执行需要2秒，而方案2则需要80秒，这个差异我们对比了很多指标，最后我个人理解差异还是在网卡部分。

所以经过对比后，还是选择了方案2的混合部署模式。

2）SQL性能优化的分析

此外整个过程的TPCH也为集群的性能表现提供了参考。比如方案2的混合部署模式下，有一条SQL需要18秒，但是相比同类型的集群，可能就只需要2秒钟左右，这块显然是存在问题的。 

在排除了系统配置，硬件配置的差异之后，经典的解决办法还是查看执行计划。

性能较差的SQL执行计划：

# explain analyze select count(*)from customer;

QUERY PLAN   

Aggregate  (cost=0.00..431.00 rows=1 width=8) (actual time=24792.916..24792.916 rows=1 loops=1)

   -  Gather Motion 36:1  (slice1; segments: 36)  (cost=0.00..431.00 rows=1 width=1) (actual time=3.255..16489.394 rows=150000000 loops=1)

         -  Seq Scan on customer  (cost=0.00..431.00 rows=1 width=1) (actual time=0.780..1267.878 rows=4172607 loops=1)

Planning time: 4.466 ms

   (slice0)    Executor memory: 680K bytes.

   (slice1)    Executor memory: 218K bytes avg x 36 workers, 218K bytes max (seg0).

Memory used:  2457600kB

Optimizer: Pivotal Optimizer (GPORCA)

Execution time: 24832.611 ms

(9 rows)

Time: 24892.500 ms

性能较好的SQL执行计划：

# explain analyze select count(*)from customer;                            

QUERY PLAN

Aggregate  (cost=0.00..842.08 rows=1 width=8) (actual time=1519.311..1519.311 rows=1 loops=1)

   -  Gather Motion 36:1  (slice1; segments: 36)  (cost=0.00..842.08 rows=1 width=8) (actual time=634.787..1519.214 rows=36 loops=1)

         -  Aggregate  (cost=0.00..842.08 rows=1 width=8) (actual time=1473.296..1473.296 rows=1 loops=1)

               -  Seq Scan on customer  (cost=0.00..834.33 rows=4166667 width=1) (actual time=0.758..438.319 rows=4172607 loops=1)

Planning time: 5.033 ms

   (slice0)    Executor memory: 176K bytes.

   (slice1)    Executor memory: 234K bytes avg x 36 workers, 234K bytes max (seg0).

Memory used:  2457600kB

Optimizer: Pivotal Optimizer (GPORCA)

Execution time: 1543.611 ms

(10 rows)

Time: 1549.324 ms

很明显执行计划是被误导了，而误导的因素则是基于统计信息，这个问题的修复很简单：

analyze customer;

但是深究原因，则是在压测时，先是使用了100G压测，压测完之后保留了原来的表结构，直接导入了1T的数据量，导致执行计划这块没有更新。

3）集群配置优化

此外也做了一些集群配置层面的优化，比如对缓存做了调整。 

gpconfig -c statement_mem -m 2457600 -v 2457600

gpconfig -c gp_vmem_protect_limit -m 32000 -v 32000

7.集群优化数据

最后来感受下集群的性能：

1）10个物理节点，（6+6）*10+2

tpch_1t=# iming on

Timing is on.

tpch_1t=# select count(*)from customer;

   count   

-----------

150000000

(1 row)

Time: 1235.801 ms

tpch_1t=# select count(*)from lineitem;

   count    

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

5999989709

(1 row)

Time: 10661.756 ms

2）6个物理节点，（6+6）*6

# select count(*)from customer;

   count   

-----------

 150000000

(1 row)

Time: 1346.833 ms

# select count(*)from lineitem;

   count    

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

 5999989709

(1 row)

Time: 18145.092 ms

3）4个物理节点，（6+6）*4

# select count(*)from customer;

   count   

-----------

 150000000

(1 row)

Time: 1531.621 ms

# select count(*)from lineitem;

   count    

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

 5999989709

(1 row)

Time: 25072.501 ms

4）TPCH在不通架构模式下的性能比对 ，有19个查询模型，有个别SQL逻辑过于复杂暂时忽略，也是郭运凯同学整理的列表。

在1T基准下的基准测试表现：

Q2: 一份难得的数据库市场分析报告

目录

- 数据库分类维度：关系型/非关系型、交易型/分析型

- NoSQL数据库的进一步分类

- OLTP市场规模：关系型数据库仍占营收大头

- 数据库市场份额：云服务和新兴厂商主导NoSQL

- 开源数据库 vs. 商业数据库

- 数据库三大阵营：传统厂商和云服务提供商

最近由于时间原因我写东西少了，在公众号上也转载过几篇搞数据库朋友的大作。按说我算是外行，没资格在这个领域品头论足，而当我看到下面这份报告时立即产生了学习的兴趣，同时也想就能看懂的部分写点心得体会分享给大家。

可能本文比较适合普及性阅读，让数据库领域资深的朋友见笑了：）

数据库分类维度：关系型/非关系型、交易型/分析型

首先是分类维度，上图中的纵轴分类为Relational Database（关系型数据库，RDBMS）和Nonrelational Database （非关系型数据库，NoSQL），横轴的分类为Operational（交易型，即OLTP）和Analytical（分析型，即OLAP）。

按照习惯我们先看关系型数据库，左上角的交易型类别中包括大家熟悉的商业数据库Oracle、MS SQL Server、DB2、Infomix，也包括开源领域流行的MySQL（MariaDB是它的一个分支）、PostgreSQL，还有云上面比较常见的SQL Azure和Amazon Aurora等。

比较有意思的是，SAP HANA正好位于交易型和分析型的中间分界处，不要忘了SAP还收购了Sybase，尽管后者今天不够风光了，而早年微软的SQL Server都是来源于Sybase。Sybase的ASE数据库和分析型Sybase IQ还是存在的。

右上角的分析型产品中包括几款知名的列式数据仓库Pivotal Greenplum、Teradata和IBM Netezza（已宣布停止支持），来自互联网巨头的Google Big Query和Amazon RedShift。至于Oracle Exadata一体机，它上面运行的也是Oracle数据库，其最初设计用途是OLAP，而在后来发展中也可以良好兼顾OLTP，算是一个跨界产品吧。

再来看非关系型数据库，左下角的交易型产品中，有几个我看着熟悉的MongoDB、Redis、Amazon DynamoDB和DocumentDB等；右下角的分析型产品包括著名的Hadoop分支Cloudera、Hortonworks（这2家已并购），Bigtable（来自Google，Hadoop中的HBase是它的开源实现）、Elasticsearch等。

显然非关系型数据库的分类要更加复杂，产品在应用中的差异化也比传统关系型数据库更大。Willian Blair很负责任地对它们给出了进一步的分类。

NoSQL数据库的进一步分类

上面这个图表应该说很清晰了。非关系型数据库可以分为Document-based Store（基于文档的存储）、Key-Value Store（键值存储）、Graph-based（图数据库）、Time Series（时序数据库），以及Wide Cloumn-based Store（宽列式存储）。

我们再来看下每个细分类别中的产品：

文档存储 ：MongoDB、Amazon DocumentDB、Azure Cosmos DB等

Key-Value存储 ：Redis Labs、Oracle Berkeley DB、Amazon DynamoDB、Aerospike等

图数据库 ：Neo4j等

时序数据库 ：InfluxDB等

WideCloumn ：DataStax、Cassandra、Apache HBase和Bigtable等

多模型数据库 ：支持上面不只一种类别特性的NoSQL，比如MongoDB、Redis Labs、Amazon DynamoDB和Azure Cosmos DB等。

OLTP市场规模：关系型数据库仍占营收大头

上面这个基于IDC数据的交易型数据库市场份额共有3个分类，其中深蓝色部分的关系型数据库（RDBMS，在这里不统计数据挖掘/分析型数据库）占据80%以上的市场。

Dynamic Database（DDMS，动态数据库管理系统，同样不统计Hadoop）就是我们前面聊的非关系型数据库。这部分市场显得小（但发展势头看好），我觉得与互联网等大公司多采用开源+自研，而不买商业产品有关。

而遵循IDC的统计分类，在上图灰色部分的“非关系型数据库市场”其实另有定义，参见下面这段文字：

数据库市场份额：云服务和新兴厂商主导NoSQL

请注意，这里的关系型数据库统计又包含了分析型产品。Oracle营收份额42%仍居第一，随后排名依次为微软、IBM、SAP和Teradata。

代表非关系型数据库的DDMS分类中（这里同样加入Hadoop等），云服务和新兴厂商成为了主导，微软应该是因为云SQL Server的基础而小幅领先于AWS，这2家一共占据超过50%的市场，接下来的排名是Google、Cloudera和Hortonworks（二者加起来13%）。

上面是IDC传统分类中的“非关系型数据库”，在这里IBM和CA等应该主要是针对大型机的产品，InterSystems有一款在国内医疗HIS系统中应用的Caché数据库（以前也是运行在Power小机上比较多）。我就知道这些，余下的就不瞎写了。

开源数据库 vs. 商业数据库

按照流行度来看，开源数据库从2013年到现在一直呈现增长，已经快要追上商业数据库了。

商业产品在关系型数据库的占比仍然高达60.5%，而上表中从这列往左的分类都是开源占优：

Wide Cloumn：开源占比81.8%；

时序数据库：开源占比80.7%；

文档存储：开源占比80.0%；

Key-Value存储：开源占比72.2%；

图数据库：开源占比68.4%；

搜索引擎：开源占比65.3%

按照开源License的授权模式，上面这个三角形越往下管的越宽松。比如MySQL属于GPL，在互联网行业用户较多；而PostgreSQL属于BSD授权，国内有不少数据库公司的产品就是基于Postgre哦。

数据库三大阵营：传统厂商和云服务提供商

前面在讨论市场份额时，我提到过交易型数据库的4个巨头仍然是Oracle、微软、IBM和SAP，在这里William Blair将他们归为第一阵营。

随着云平台的不断兴起，AWS、Azure和GCP（Google Cloud Platform）组成了另一个阵营，在国外分析师的眼里还没有BAT，就像有的朋友所说，国内互联网巨头更多是自身业务导向的，在本土发展公有云还有些优势，短时间内将技术输出到国外的难度应该还比较大。（当然我并不认为国内缺优秀的DBA和研发人才）

第三个阵容就是规模小一些，但比较专注的数据库玩家。

接下来我再带大家简单过一下这前两个阵容，看看具体的数据库产品都有哪些。

甲骨文的产品，我相对熟悉一些的有Oracle Database、MySQL以及Exadata一体机。

IBM DB2也是一个庞大的家族，除了传统针对小型机、x86（好像用的人不多）、z/OS大型机和for i的版本之外，如今也有了针对云和数据挖掘的产品。记得抱枕大师对Informix的技术比较推崇，可惜这个产品发展似乎不太理想。

微软除了看家的SQL Server之外，在Azure云上还能提供MySQL、PostgreSQL和MariaDB开源数据库。应该说他们是传统软件License+PaaS服务两条腿走路的。

如今人们一提起SAP的数据库就想起HANA，之前从Sybase收购来的ASE（Adaptive Server Enterprise）和IQ似乎没有之前发展好了。

在云服务提供商数据库的3巨头中，微软有SQL Server的先天优势，甚至把它移植到了Linux拥抱开源平台。关系型数据库的创新方面值得一提的是Amazon Aurora和Google Spanner（也有非关系型特性），至于它们具体好在哪里我就不装内行了：）

非关系型数据库则是Amazon全面开花，这与其云计算业务发展早并且占据优势有关。Google当年的三篇经典论文对业界影响深远，Yahoo基于此开源的Hadoop有一段时间几乎是大数据的代名词。HBase和Hive如今已不再是人们讨论的热点，而Bigtable和BigQuery似乎仍然以服务Google自身业务为主，毕竟GCP的规模比AWS要小多了。

最后这张DB-Engines的排行榜，相信许多朋友都不陌生，今年3月已经不是最新的数据，在这里列出只是给大家一个参考。该排行榜几乎在每次更新时，都会有国内数据库专家撰写点评。

以上是我周末的学习笔记，班门弄斧，希望对大家有帮助。

参考资料《Database Software Market:The Long-Awaited Shake-up》

扩展阅读：《 数据库存储：互相最想知道的事 》

尊重知识，转载时请保留全文。感谢您的阅读和支持！

Q3: 常用的数据分析方法有哪些？

一、掌握基础、更新知识。

基本技术怎么强调都不过分。这里的术更多是（计算机、统计知识）， 多年做数据分析、数据挖掘的经历来看、以及业界朋友的交流来看，这点大家深有感触的。

数据库查询—SQL

数据分析师在计算机的层面的技能要求较低，主要是会SQL，因为这里解决一个数据提取的问题。有机会可以去逛逛一些专业的数据论坛，学习一些SQL技巧、新的函数，对你工作效率的提高是很有帮助的。

统计知识与数据挖掘

你要掌握基础的、成熟的数据建模方法、数据挖掘方法。例如：多元统计：回归分析、因子分析、离散等，数据挖掘中的：决策树、聚类、关联规则、神经网络等。但是还是应该关注一些博客、论坛中大家对于最新方法的介绍，或者是对老方法的新运用，不断更新自己知识，才能跟上时代，也许你工作中根本不会用到，但是未来呢？

行业知识

如果数据不结合具体的行业、业务知识，数据就是一堆数字，不代表任何东西。是冷冰冰，是不会产生任何价值的，数据驱动营销、提高科学决策一切都是空的。

一名数据分析师，一定要对所在行业知识、业务知识有深入的了解。例如：看到某个数据，你首先必须要知道，这个数据的统计口径是什么？是如何取出来的？这个数据在这个行业， 在相应的业务是在哪个环节是产生的？数值的代表业务发生了什么（背景是什么）？对于A部门来说，本月新会员有10万，10万好还是不好呢？先问问上面的这个问题：

对于A部门，

1、新会员的统计口径是什么。第一次在使用A部门的产品的会员？还是在站在公司角度上说，第一次在公司发展业务接触的会员？

2、是如何统计出来的。A：时间；是通过创建时间，还是业务完成时间。B：业务场景。是只要与业务发接触，例如下了单，还是要业务完成后，到成功支付。

3、这个数据是在哪个环节统计出来。在注册环节，在下单环节，在成功支付环节。

4、这个数据代表着什么。10万高吗？与历史相同比较？是否做了营销活动？这个行业处理行业生命同期哪个阶段？

在前面二点，更多要求你能按业务逻辑，来进行数据的提取（更多是写SQL代码从数据库取出数据）。后面二点，更重要是对业务了解，更行业知识了解，你才能进行相应的数据解读，才能让数据产生真正的价值，不是吗？

对于新进入数据行业或者刚进入数据行业的朋友来说：

行业知识都重要，也许你看到很多的数据行业的同仁，在微博或者写文章说，数据分析思想、行业知识、业务知识很重要。我非常同意。因为作为数据分析师，在发表任何观点的时候，都不要忘记你居于的背景是什么？

但大家一定不要忘记了一些基本的技术，不要把基础去忘记了，如果一名数据分析师不会写SQL，那麻烦就大了。哈哈。。你只有把数据先取对了，才能正确的分析，否则一切都是错误了，甚至会导致致命的结论。新同学，还是好好花时间把基础技能学好。因为基础技能你可以在短期内快速提高，但是在行业、业务知识的是一点一滴的积累起来的，有时候是急不来的，这更需要花时间慢慢去沉淀下来。

不要过于追求很高级、高深的统计方法，我提倡有空还是要多去学习基本的统计学知识，从而提高工作效率，达到事半功倍。以我经验来说，我负责任告诉新进的同学，永远不要忘记基本知识、基本技能的学习。

二、要有三心。

1、细心。

2、耐心。

3、静心。

数据分析师其实是一个细活，特别是在前文提到的例子中的前面二点。而且在数据分析过程中，是一个不断循环迭代的过程，所以一定在耐心，不怕麻烦，能静下心来不断去修改自己的分析思路。

三、形成自己结构化的思维。

数据分析师一定要严谨。而严谨一定要很强的结构化思维，如何提高结构化思维，也许只需要工作队中不断的实践。但是我推荐你用mindmanagement，首先把你的整个思路整理出来，然后根据分析不断深入、得到的信息不断增加的情况下去完善你的结构，慢慢你会形成一套自己的思想。当然有空的时候去看看《麦肯锡思维》、结构化逻辑思维训练的书也不错。在我以为多看看你身边更资深同事的报告，多问问他们是怎么去考虑这个问题的，别人的思想是怎么样的？他是怎么构建整个分析体系的。

四、业务、行业、商业知识。

当你掌握好前面的基本知识和一些技巧性东西的时候，你应该在业务、行业、商业知识的学习与积累上了。

这个放在最后，不是不重要，而且非常重要，如果前面三点是决定你能否进入这个行业，那么这则是你进入这个行业后，能否成功的最根本的因素。 数据与具体行业知识的关系，比作池塘中鱼与水的关系一点都不过分，数据（鱼）离开了行业、业务背景（水）是死的，是不可能是“活”。而没有“鱼”的水，更像是“死”水，你去根本不知道看什么（方向在哪）。

如何提高业务知识，特别是没有相关背景的同学。很简单，我总结了几点：

1、多向业务部门的同事请教，多沟通。多向他们请教，数据分析师与业务部门没有利益冲突，而更向是共生体，所以如果你态度好，相信业务部门的同事也很愿意把他们知道的告诉你。

2、永远不要忘记了google大神，定制一些行业的关键字，每天都先看看定制的邮件。

3、每天有空去浏览行业相关的网站。看看行业都发生了什么，主要竞争对手或者相关行业都发展什么大事，把这些大事与你公司的业务，数据结合起来。

4、有机会走向一线，多向一线的客户沟通，这才是最根本的。

标题写着告诫，其实谈不上，更多我自己的一些心得的总结。希望对新进的朋友有帮助，数据分析行业绝对是一个朝阳行业，特别是互联网的不断发展，一个不谈数据的公司根本不叫互联网公司，数据分析师已经成为一个互联网公司必备的职位了。

Q4: 怎样深入的学习linux，希望在linux方面有所发展

学习Linux的心得

通过这几年来对Linux的学习，一步一步摸着石头过河，到现在才刚刚上岸。我能起的作用可能可以告诉你一些学习的方法，当你遇到困难的时候有个人在旁边给予帮助。说句心里话，对于Linux的掌握我还只能算是很粗的东西，因为看了很多大师们的东西以后，发现自已离他们真得还很远。我不是要打击你的意思，是告诉你实情。但也可以告诉你，就这一点现在还是比较好混口饭吃。对她了解掌握的越深，你会发现他几乎什么都能做，有了实现自已商业机会的平台。

学习Linux分好几种层次，我个人觉得可以用中学里学的课文《疱丁解牛》来对比。说白了也就是对事物的认识一般都是由表及里的过程，学习Linux也是一样的。以前总觉的学理的人只要会数理化就行了，很多老师们由于自身的素质问题也不由自主的暗示着我们这样做。现在觉得很后悔当初没有学好文，文太重要了，很多时候他真的可以指导我们的形为和思维方式。最近看的很多管理上的书，最终上升到都是哲学方面的问题，很多东西一追踪根源到上升到哲学上来了。以前小的时候不懂事，觉得学这些东西有什么用，现在成熟一些了才发现这些东西真的不是件简单的事情。学习Linux有很多东西，我建议你首先要注意大师们在哲学上的思路。Linux是由Unix产生的，最终他的实现及他基础上很多应用软件都是基于一个哲学理念“把任务分解成一小块一小块完成”，可能现在你觉得这是件很简单的道理。但他不简单就在于所有有关Unix的东西都是基于这一理念的，看看我们常用的那些小工具吧，find,grep,gzip,tar,bash...等等，这个道理无不贯穿始终。现在IBM/MS等公司经常提到的WEB Service，实际上细想也是这样的，无非是把很多服务分散开来，然后有个总的业务逻辑来进行迅速的组合成一个新的服务，满足市场的迅速变化的需求。

结论1：首先要明白他的设计理念是缘自Unix的“把任务分解成一小块一小块完成”，建议你可以看这本电子书。是由Eric Steven Raymond写的，在google上很容易找到。这本书编重于编程，可以根据自已的兴趣选相应章节。我也没有全看完，也在研习中:-)

从使用着手，自已装个系统。建议你从Redhat开始。现在Redhat的安装基本上都是学习MS的做法，很图形化了。只要按照图形的指示，很容易让一个系统跑起来。我觉得初学者应该从这个入手，这样会快很多。因为Linux上的软件包都是由不同的开发团队做的，所以一般人不知道如果安装，redhat公司做的事情就是把这些东西组织起来，然后把这些软件卖给大家。因为他对这一行非常的精通，所以卖软件是其次，卖服务是主业。现在redhat已停止出个人版的了，改成专做企业的了，版本发行最近有些变动。现在最后一个版本好象是RH9.1。

装好系统后从使用应用软件开始，建议你先学BASH SHELL编程。因为你将业想往Oracl DBA发展的话，精通SHELL可以在管理上给你带来很大的便利。同时对于理解Linux系统的启动和一些软件的安装很有帮助。比如说你可以很清楚的了解Linux的整个启动过程，继而知道为什么要做那一步做了这个动作，对你将来处理实际碰到的问题至少可以明白知道问题出在哪。象很多我们日常在Unix/Linux的管理和脚本都是分不开的，精通BASH是我们需要完成的第一步。我指的是精通，不是一般的了解，因为你只有精通了，用的时间越长，你会发现script可以帮我们很方便的干很多事情。这里有一本电子书提供参考，是我至今见到写BASH最全，最好的一本。名叫《Advanced Bash Scripting Guide》，你可以在里找到。

这里也提一下里的文章是你学习Linux的良师益友，里面的很多文章都是非常不错的教材。主要分为几类：1、FAQ 2、HOWTO 3、Guider 4、man手册。其中的Guider有几本都是非常不错的入门书，你基本上可以不用去买本，美国出的印刷书都奇贵，你把那里的几本书看完就差不多了。插一句，现在P2P很流行，我基本上都不买专业的书了，大部分都可以找到电子版的下载。里面的HOWTO主要讲的一些具体的问题如何处理，门类也很多很杂，你可以根据自已现在的需求去看相应的文章。有空的时候可以多看看，这里面有些很好的solution，说不定什么时候就可以用上。FAQ的文章不多，建议挑些重要的看下。对于man手册，一般系统上都有，不过那里应该是最近的，平时用的不多。

结论2：自已装个Redhat，学好shell。

你用Unix/Linux时候，熟悉一个编辑器是必不可少的。用两种建议选择EmacsVIM。Emacs比较大些，要花些空间，功能具强，以前用过一段时间但没有深入下去，所以了解也是通过大师们文章中反复提到这个关键字和一些信息知道的，用好了功能具强，相当于一个MS下的IDE开发环境；vim比较小些，功能也很强，是vi的增强版，我现在主要是用她来编辑东西。vim支持多种语法，可以用来编脚本、C、Java，功能足够我们用，学好需要一定的时间实践。因为我们用Unix/Linux，免不了有时要用console来控制，如果用惯了MS的编辑的话，你会非常痛苦，建议如果以后想长时间使用unix/linux环境的话，学好一种这环境下的编辑器。vim也有windows的版本，开始用起来会觉得不方便，便很快你会发现用VIM可以解决很多MS下编辑器不能解决的问题，不信你可以试试看。

结论3：学会一种Unix/Linux下编辑器Emacs或Vim，建议Vim（因为我在用，可以给你些指导 ）

学习Linux有几种常用的服务软件需要会用，1) apache(http) 2) bind(dns) 3) pro-ftp(ftp) 4)samba(file share) 。需要掌握这些软件的安装和简单配置，这些软件在网上都有很详细的文档。至少apache要会安装和管理，因为这是最基本的WEB服务，今天在哪里都能用到。对于这些常用服务软件根据自已兴趣和环境要求做出选择，不一定要很精，但要会，建议精通。

结论4：学会常用服务软件的安装和配置，至少掌握apache

在Linux中还有很多小实用工具也需要掌握，这对你今后诊断问题和做相应的系统管理有很大帮助。如配置网卡地址的工具ifconfig，查找文件的工具find，行编辑的命令sed、awk，网络状态检查netstat、ping、nc等。这些工具可以在实践中慢慢学习。

结论5：在实践中学习一些常用小工具，如ifconfig netstat route等

掌握一到两种Opensource的数据库，如现在流行的两种数据库MySQL和PostgreSQL。MySQL用的人多些也比较简单，速度又快，做一些简单的数据库应用很多都用他做backend databaes server。如果你自已想学Oracle的话，可以直接学Oracle。Oracle的东西多且全，基本上所用的功能都能在Oracle找到。但如果你想更深一层学习DB的话，你可以考虑学PostgreSQL，他有源程序而且支持事务处理(trans-action)、子查询(sub-select)，过程(procedure)、自定义函数(function)、光标(cursor)，支持了大部份SQL92和99的标准。他的文档也比较全。

结论6：建议掌握一种Opensource的DB，如MySQL

建议对TCP/IP协议层深入了解，我想你们上研究生时应该讲的很深。但我还是建议你再多复习相关的知识点，很多时候网络上的问题可以通对你对TCP/IP的了解找到问题所在。建议你买那个steven的书叫，同时经常在身边准备好那几种状态切换的图，劳记在心，出问题的时候就可以知道是哪边网络不通，还是应用程度出了什么问题了。

结论7：建议再深入了解TCP/IP protocol

建议除了bash外，再学多一种在Unix环境下的RAD脚本语言python。我也正在学python，通过这段时间的了解发现，这个东东有很多功能而且在开发上可以比c/c++提高至少5倍效率。有时候偏向做系统管理，但掌握一本这种编程形的脚本对工作帮助很大，可以迅速的处理一些问题。BASH是侧重于人机交复的脚本，有些事情用BASH是无法完成的。Python在很多Internet应用上有很多modulepackage，你可以很方便的使用已有的功能，比如说自已做个小的WEB SERVER，做测试工具，做数据库查询等等。

结论8：建议学下Python

好了，今天先罗嗦到这里，还有很多想法愧于文笔有限，改天再详谈。

水平有限，权做参考，希望对于你的学习有所帮助。

客观来说 对你毫无用处。

Q5: 如何优化Hibernate

是设定JDBC的Statement读取数据的时候每次从数据库中取出的记录条数，一般设置为30、50、100。Oracle数据库的JDBC驱动默认的Fetch

Size=15，设置Fetch

Size设置为：30、50，性能会有明显提升，如果继续增大，超出100，性能提升不明显，反而会消耗内存。

即在hibernate配制文件中进行配制：

1 ＜property name="hibernateProperties"＞

2 ＜props＞3 ＜propkey="hibernate.dialect"＞org.hibernate.dialect.Oracle9Dialect＜/prop＞

4 ＜prop key="hibernate.show_sql"＞false＜/prop＞

5 ＜!-- Create/update the database tables automatically when the JVMstarts up

6 ＜prop key="hibernate.hbm2ddl.auto"＞update＜/prop＞ --＞

7 ＜!-- Turn batching off for better error messages underPostgreSQL

8 ＜prop key="hibernate.jdbc.batch_size"＞100＜/prop＞ --＞

9 ＜prop key="hibernate.jdbc.batch_size"＞50＜/prop＞

10 ＜/props＞

11 ＜/property＞Fetch Size设的越大，读数据库的次数越少，速度越快；Fetch

Size越小，读数据库的次数越多，速度越慢。

2、如果是超大的系统，建议生成htm文件。加快页面提升速度。

3、不要把所有的责任推在hibernate上，对代码进行重构，减少对数据库的操作，尽量避免在数据库查询时使用in操作，以及避免递归查询操作，代码质量、系统设计的合理性决定系统性能的高低。

4、 对大数据量查询时，慎用list()或者iterator()返回查询结果，（1）.

使用List()返回结果时，Hibernate会所有查询结果初始化为持久化对象，结果集较大时，会占用很多的处理时间。（2）.

而使用iterator()返回结果时，在每次调用iterator.next()返回对象并使用对象时，Hibernate才调用查询将对应的对象初始化，对于大数据量时，每调用一次查询都会花费较多的时间。当结果集较大，但是含有较大量相同的数据，或者结果集不是全部都会使用时，使用iterator()才有优势。

5、在一对多、多对一的关系中，使用延迟加载机制，会使不少的对象在使用时方会初始化，这样可使得节省内存空间以及减少数据库的负荷，而且若PO中的集合没有被使用时，就可减少互数据库的交互从而减少处理时间。

6、对含有关联的PO（持久化对象）时，若default-cascade="all"或者

“save-update”，新增PO时，请注意对PO中的集合的赋值操作，因为有可能使得多执行一次update操作。

7、对于大数据量新增、修改、删除操作或者是对大数据量的查询，与数据库的交互次数是决定处理时间的最重要因素，减少交互的次数是提升效率的最好途径，所以在开发过程中，请将show_sql设置为true，深入了解Hibernate的处理过程，尝试不同的方式，可以使得效率提升。尽可能对每个页面的显示，对数据库的操作减少到100----150条以内。越少越好。

以上是在进行struts+hibernate+spring进行项目开发中，对hibernate性能优化的几点心得。