Vertica 性能非常好, 平时基本不会碰到性能问题, 即使碰到, 优化也很容易, 而且效果往往会很好. ======================优化工具====================== 1. explain 命令. 在一个大 SQL 执行之前, 使用 profile 来查看资源的预期消耗. veritica 执行计划除了有普通文本格式, 还有 graphviz 格式的文本输出, 可以使用一些 graphviz viewer网站或工具将这些文本以流程图的形式呈现. 比如这个网站

vertica是惠普公司推出的列式分布式数据库,在OLAP领域有其独到的地方,目前社区版免费,但是只能存放1T的数据.我在工作中维护的bi系统后端就是使用的vertica数据库,平时也经常需要对于数据库的查询进行一些优化.所以写下这篇博客记录一下. 定位问题所谓的数据库调优.程序优化之类的工作,实际上是一个解决问题的过程,而解决问题,第一部就是需要定位问题.找到问题的手段多种多样,可以通过分析程序.监控生产上服务器的性能.定期生成数据库的负载报告等手段,而最不应该的就是通过生产上用户的反馈来反映

本文介绍了什么 ´ 电信级大数据分析典型需求 ´ Vertica数据库特点及与其他数据库对比 ´ Vertica核心技术介绍 ´ 基于Vertica的典型分系统架构简介 电信级大数据分析典型需求 ´ 海量数据存储:年分析数据量达到PB级 Counter数据:各网元收集的统计数据,可用于监控和测量网络性能 MR详单:即手机向网络上报的无线性能测量报告,反映了用户实时无线环境真实情况 CDR数据:呼叫详单记录,由各个接口中与该事件相关的信令综合而成,是对用户在移动网络中的通话.短信.数据业务的事件记

Vertica Database Designer 分析逻辑架构,示例数据库可以分析实力查询. 创建可自动部署或手动部署的物理架构设计(一组投射) 任何不具备数据库专业知识的人员均可使用 可以随时运行和重复运行,可以实现进一步优化,而且无需停止数据库 使用策略提供最佳查询性能和数据压缩 使用Database Designer创建全面设计,为数据库中所有的表创建投射.当然也可以使用Database Designer创建增量设计,从而可以将查询中引用的所有表创建投射. 可以通过在管理控制台或者管理工

1.设计目标 Vertica数据库可以说是7年之后的C-Store,在2012年发表的这样一篇论文,描述了现在基于C-Store的一部分改进,当然,Vertica借鉴了很多C-Store的思想,但并非完全是C-Store.由于Vertica也是分析型数据库,所以数据设计的目标也是重读不重写或者说是重分析轻事务(Vertica was explicitly designed for analytic workloads rather than for transactional workloads

Vertica 数据库知识汇总篇(更新中..) 1.Vertica 集群软件部署,各节点硬件性能测试 2.Vertica 创建数据库,创建业务用户测试 3.Vertica 数据库参数调整,资源池分配 4.Vertica 表设计 5.Vertica 入库/导出数据 6.Vertica 日常维护 7.Vertica 数据库调优 8.Vertica 数据库故障处理 9.Vertica 数据库迁移 10.Vertica 数据库备份恢复 11.Vertica 数据库升级 12.Vertica Licens

一.前期准备工作 1.1各节点IP和主机名 1.2上传脚本并设定环境变量 1.3添加信任 1.4前期准备检查并调整 二.Vertica安装 三.集群性能评估 一.前期准备工作: 1.1各节点IP和主机名 192.168.1.137 DB01 192.168.1.138 DB02 192.168.1.139 DB03 192.168.1.140 DB04 在节点1配置/etc/hosts,添加上面信息. 1.2上传脚本并设定环境变量 在节点1上传两个安装脚本到/usr/local/bin clus

测试环境:RHEL 6.4 + Vertica 6.1.3-7 需求:搭建Vertica数据库3节点的测试环境,建立测试用户,建表,测试数据入库. 1.各节点关闭防火墙和SELinux,配置主机名,IP地址,统一root密码,确认系统字符集为utf-8 关闭防火墙和selinux: service iptables status;getenforce;service iptables stop;setenforce 0;service iptables status;getenforce 关闭防

环境:RHEL6.5 + Vertica7.1.0-3 1.故障现象 2.重装集群 3.再次定位 4.解决问题 5.总结 1.故障现象 故障现象:Vertica集群安装成功,但是创建数据库后一直无法up. 具体报错输出如下: Starting Vertica on all nodes. Please wait, databases with large catalogs may take a while to initialize. Node Status: v_wnop_node0001: (

Vertica数据库中的表只是一个逻辑概念. 实际存储在磁盘上的是projection. 当创建一张表,没有创建projection时,那么插入数据的时候会自动创建一个默认的projection.如果运行中发现projection不合适,可以运行dbd进行优化,得出一些建议,参考来重建projection. 如果清楚projection如何建立最优,那么建表的时候就可以在插入数据之前直接手动建立对应的projection. Projection Optimized collections of

在上篇Vertica 分区表设计中,已经提过了Vertica的分区表创建和分区删除,但举例上并不系统, 本篇文章将系统的对分区表设计及后续的删除分区进行讲解. 概述:Vertica分区表(天和月)创建以及删除分区 1.分区表创建 2.查询业务表的基本信息 3.Vertica入库测试数据 4.删除历史分区数据 Reference 1.分区表创建 Vertica分区表可以使用预定义函数创建,有特殊需求时,也可以自定义函数创建. 我这里测试均是以业务用户test登录建表: vsql -Utest 1.

之前在"Vertica 安装,建库,新建测试用户并授予权限,建表,入库"这篇文章也简单介绍过入库部分的内容. 但之前测试用例若用于生产环境有明显的局限性: 1.是用dbadmin管理员用户入库的. 2.没有建立和指定入库专用资源池. 现在我们需要规范下入库,用普通业务用户test进行入库测试,并指定入库资源池load_pool. 1.创建业务用户test和测试表t_jingyu 2.创建入库专用load_pool资源池并赋权给业务用户test 3.准备入库脚本loadData.sh和入

需求:构建简单的测试用例,完成演示Vertica导出数据的功能. 测试用例:导出test业务用户t_jingyu表中的数据. 一.初始化测试环境 二.导出数据 2.1 vsql命令说明帮助 2.2 导出全表数据 2.3 导出符合指定条件的表数据 三.验证 一.初始化测试环境 业务用户test下创建t_jingyu测试表,并初始化一些数据. 参考<Vertica 业务用户指定资源池加载数据>构建初始化测试环境. 二.导出数据 2.1 vsql命令说明帮助 [dbadmin@vertica1 ~]

Vertica增加一个数据存储的目录 操作语法为: ADD_LOCATION ( 'path' , [ 'node' , 'usage', 'location_label' ] ) 各节点添加目录,并赋予正确的权限 vsql命令行下添加对应的目录 查询验证 1. 各节点添加目录,并赋予正确的权限 比如新增/verticadata2挂节点,需求为在/verticadata2挂节点下新增目录vertica,用于Vertica的数据目录. 各节点执行 mkdir -p /verticadata2/ve

环境:RHEL 6.4 + Vertica 7.0.0-11.最终确认安装compat-libgfortran-41-4.1.2-39.el6.x86_64.rpm即可解决. # rpm -ivh vertica-R-lang--.x86_64.RHEL5.rpm error: Failed dependencies: /usr/lib64/libgfortran.so. is needed by vertica-R-lang--.x86_64 # rpm -ivh compat-libgfor

DBD = Database Designer,是Vertica数据库优化中最主要的原生工具. 首先运行admintools工具,按下面步骤依次执行: 1.选择"6 Configuration Menu" 2.选择"2 Run Database Designer"3."Select a database for design" 选择需要分析的数据库4."Enter directory for Database Designer outp

Vertica集群单节点宕机恢复方法 第一种方法: 直接通过admintools -> 5 Restart Vertica on Host 第二种方法: 若第一种方法无法恢复,则清空宕机节点的catalog 和 data目录 比如 v_testdb_node0001_catalog/ v_testdb_node0001_data/ 然后从其他节点拷贝catalog目录下的vertica.conf,然后恢复.

Vertica节点宕机处理一例: 查询数据库版本和各节点状态 常规方式启动宕机节点失败 进一步查看宕机节点的详细日志 定位问题并解决 1. 查询数据库版本和各节点状态 dbadmin=> select version(); version ------------------------------------ Vertica Analytic Database v6.1.3-7 (1 row) dbadmin=> select node_name, node_id, node_state,

环境:RHEL6.2 + Vertica 6.1.3-7 确定所有节点的vertica进程都停掉(包括agent和python),如果有运行的,停止它或者杀掉它. 确定所有节点的spread进程都正常在运行. 用admintools工具启动数据库到LGE 1. 确定所有节点的vertica进程都停掉(包括agent和python),如果有运行的,停止它或者杀掉它. 数据库为关闭状态,也就是停库后,如果还有进程,可以 ps -ef|grep vertica |grep -v spread|awk

1.基本概念介绍 2.停止某节点服务 3.测试其他节点访问 1.基本概念介绍 Vertica也是MPP架构的数据库,相比大家熟悉的MPP架构,比如Greenplum和hadoop这些产品,Vertica最大的不同就是没有主节点这个概念. 也就是说Vertica集群中(K-safe=1情况),任何一个节点宕机都不会影响到其他节点对外提供服务. 而在其他有主节点的架构中,一旦主节点挂掉,整个集群就会挂掉,所以还需要考虑进一步冗余主节点. 对架构有深入了解的朋友会问,没有主节点,那Vertica的元数

需求:在Vertica数据库上建表,表结构来源于原Oracle数据库,故需要转换成Vertica数据库库表结构.   实际转换操作需要评估源库用到的所有数据类型和数据本身特性. 下面是总结的某场景下的替换规则,仅供参考. 1.时间类型: DATE   =>   TIMESTAMP   2.数字类型:NUMBER(   =>   NUMERIC( NUMBER   =>   NUMERIC(38,0) INTEGER   =>   NUMERIC(38,0)   3.字符类型: VA