这里是Vertica爱好者关于Vertica相关技术交流、学习和互助的社区，不负责Vertica售后支持。
关于售后支持: 对于Vertica正式客户，建议中文邮件通过 [email protected] 咨询（[email protected]只接受英文邮件），他们是专职的中文支持团队，响应会更即时。
- [email protected]: 9x5, Chinese
- [email protected]: 7x24 for production issues, English
- production critical issue support: 1-877-669-1295 or 1-617-386-4500, English.
- 本文档(https://github.com/dingqiangliu/MyVertica/blob/master/README.md)
- 官方安装介质(https://my.vertica.com/download/vertica/)
- 官方产品文档(https://my.vertica.com/documentation/vertica/)
- 在线培训(英文字幕, https://my.vertica.com/resources/web-based-training/)
- 动手训练(https://my.vertica.com/get-started-vertica/)
- 知识库(https://community.dev.hpe.com/t5/Vertica-Knowledge-Base/tkb-p/bigdata_wiki_vertica)
- Marketplace(https://saas.hpe.com/marketplace/big-data#/Home/Show)
- Vertica资源下载百度网盘(http://pan.baidu.com/s/1jXnMu#path=/vertica)
- Vertica csdn专栏(http://blog.csdn.net/column/details/vertica.html)
- 节点复原(Node Recovery, https://my.vertica.com/node-recovery-checklist/)
- Spread调试(Spread Debugging, https://my.vertica.com/spread-debugging-checklist/)
- 数据库进程无法启动(Database Process Not Starting, https://my.vertica.com/database-process-not-starting/)
- 事务号管理(Epoch Management, https://my.vertica.com/checklist-draft/)
- 节点宕掉(Node Down, https://my.vertica.com/node-down-checklist/)
- Kafka(https://my.vertica.com/apache-kafka-not-ingesting-data/)
- 停节点维护(Shutting down a node for maintenance, https://community.dev.hpe.com/t5/Vertica-Knowledge-Base/Prepare-HP-Vertica-Database-for-Maintenance/ta-p/229524)
Connectby 实质上就是表自(外)关联和列转行。如果层级不多，是可以用标准SQL来改写。
其实用Vertica的SDK来实现相同功能的自定义函数，也不太难。参见：Connectby for Veritca实现(http://pan.baidu.com/s/1jXnMu#path=/vertica/UDx/) 下的 connectby-2013.08.30.tgz
对于Oracle中如下语句的执行效果:
select id, parent_id, name , LEVEL as path_level , CONNECT_BY_ROOT id AS id_root , SYS_CONNECT_BY_PATH(id, '|') AS id_path , CONNECT_BY_ROOT name AS name_root , SYS_CONNECT_BY_PATH(name, '|') AS name_path from company c CONNECT BY PRIOR c.id = c.parent_id START WITH c.parent_id = 0 order by id;
ID PARENT_ID NAME PATH_LEVEL ID_ROOT ID_PATH NAME_ROOT NAME_PATH -----+-----------------+-----+----------+-----------+------------------------ 1 0 Patrick1 1 1 |1 Patrick1 |Patrick1 2 0 Patrick2 1 2 |2 Patrick2 |Patrick2 12 1 Jim1 2 1 |1|12 Patrick1 |Patrick1|Jim1 13 1 Sandy1 2 1 |1|13 Patrick1 |Patrick1|Sandy1 14 13 Brian1 3 1 |1|13|14 Patrick1 |Patrick1|Sandy1|Brian1 15 13 Otto1 3 1 |1|13|15 Patrick1 |Patrick1|Sandy1|Otto1 22 2 Jim2 2 2 |2|22 Patrick2 |Patrick2|Jim2 23 2 Sandy2 2 2 |2|23 Patrick2 |Patrick2|Sandy2 24 23 Brian2 3 2 |2|23|24 Patrick2 |Patrick2|Sandy2|Brian2 25 23 Otto2 3 2 |2|23|25 Patrick2 |Patrick2|Sandy2|Otto2 10 rows selected.
在Vertica中实现的UDF中执行的效果:
select connectby(parent_id, id, name) over () from item;
level | parent_id | id | name | name_root | name_path
-------+-----------+-----+----------+-----------+------------------------ 1 | 0 | 1 | Patrick1 | Patrick1 | Patrick1 1 | 0 | 2 | Patrick2 | Patrick2 | Patrick2 2 | 1 | 12 | Jim1 | Patrick1 | Patrick1/Jim1 2 | 1 | 13 | Sandy1 | Patrick1 | Patrick1/Sandy1 2 | 2 | 22 | Jim2 | Patrick2 | Patrick2/Jim2 2 | 2 | 23 | Sandy2 | Patrick2 | Patrick2/Sandy2 3 | 13 | 131 | Brian1 | Patrick1 | Patrick1/Sandy1/Brian1 3 | 13 | 132 | Otto1 | Patrick1 | Patrick1/Sandy1/Otto1 3 | 23 | 231 | Brian2 | Patrick2 | Patrick2/Sandy2/Brian2 3 | 23 | 232 | Otto2 | Patrick2 | Patrick2/Sandy2/Otto2 (10 rows)
以上说明了使用外部函数来实现列转行，如果不适用外部函数是否也可以列转行呢
SELECT node_state, MAX(DECODE(row_number, 1, a.node_name)) || NVL(MAX(DECODE(row_number, 2, ',' || a.node_name)), '') || NVL(MAX(DECODE(row_number, 3, ',' || a.node_name)), '') || NVL(MAX(DECODE(row_number, 4, ',' || a.node_name)), '') || NVL(MAX(DECODE(row_number, 5, ',' || a.node_name)), '') || NVL(MAX(DECODE(row_number, 6, ',' || a.node_name)), '') node_name FROM (select node_state,node_name,row_number() over (partition by node_state order by node_name) row_number from nodes) a group by node_state;
UP | v_csap_node0001,v_csap_node0002,v_csap_node0003,v_csap_node0004,v_csap_node0005,v_csap_node0006 STANDBY | v_csap_node007 (2 rows)
假设维度表有5000万行，每行200字节，只是数据就需要约10GB。 如果在关联/分组操作中不能用上Merge Join/Group By Pipe, 数据加上hash 表结构、关联或分组操作等，这样的Hash Join/Group 很有可能需要10+ GB内存。内存容易成为多个这中并发负载场景的瓶颈。 所以通常建议：上千万的维度表，最好按与事实表关联的键值 hash 分布到所有节点上。
Vertica 提供时间序列 插值功能，可以用来产生任意范围的数值：
create table if not exists fact
as /*+ direct /
select num as pk / 主键 /, num%1000 as fk / 构造各种外键或其他信息 */ from (
SELECT extract(epoch from ts)::int as num FROM (
SELECT '1970-01-01 00:00:01 +0'::TIMESTAMP AS tm
UNION
SELECT '1974-01-02 00:00:00 +0'::TIMESTAMP AS tm
) t0
TIMESERIES ts AS '1 second' OVER (ORDER BY tm)
) t1
order by pk
encoded by pk encoding DELTAVAL, fk encoding RLE
segmented by hash(pk) all nodes ksafe
;
任何一个生产环境数据库都要求按照规划的RPT和RTO来设计和实施。
Vertica的ROS存储方式可以保证事务提交时已经写磁盘成功，能确保进程、节点重启或故障时的数据完整性和一致性。
Vertica支持实时数据装载的WOS是暂时(缺省5分钟)驻留在内存中的，尽管在多个节点上保留有副本，但如果发生大范围故障(交换机或多个机柜电源故障)，可能会导致内存中的数据全部丢失。尽管这在系统RTO、RPO设计时候已经考虑，可以从消息流中复原，但还是会给运维临场处理带来麻烦和压力。
在一次运维活动中停止数据库前，发现 system 视图中 LGE 和 AHM 与 CE 差距较大，从 epochs 视图上看它们差距时间间隔有好几天，执行 select do_tm_task('moveout' ) 也无法改善。
如果这个时候强制停止数据库、或者发生意外导致多个节点宕机，可能会发生数据丢失问题。为了降低系统风险，需要尽快找到原因，把 WOS 中的数据写到 ROS 中。
-
首先执行下面的查询，找到 WOS 存放了哪些表的数据，结果只有一个表 hanwenfeng.tb_rp_ct_86hl_forcast_source_day
select schema_name,anchor_table_name,p.projection_name,rowcount,start as start_epoch,"end" as end_epoch from storage_containers sc, vs_wos_containers wc, projections p where sc.storage_oid=wc.wosid and sc.projection_name=p.projection_name order by start_epoch desc; -
执行 select do_tm_task('moveout' , 'hanwenfeng.tb_rp_ct_86hl_forcast_source_day') 尝试把这个表在 WOS 中的数据强制写到 ROS 中，Vertica给出错误信息"ERROR:too many data partitions"
找到问题根原了！原因在于: 这个表的分区数目超过了设计预期，导致 ROS Pushback 而无法拔 WOS 中的数据写入到 ROS 中，进而导致 LGE/AHM 差 CE 太多。
- 于是解决问题就比较简单了: 提高这个表的分区粒度(比如从天变成月份)减少分区数， WOS 数据就可以正常写入到 ROS 中了。
- 如果使用了实时分析模式，日常运维过程中需要重点监控AHM、LGE、CE等事务号的变化。
- 需要仔细设计表分区粒度。分区太多，可能会导致ROS Pushback(Vertica有参数控制每个projection在一个节点上 ROS Container 数量，缺省不能超过1024个)，但实时装载可能不能立即看到错误，因为它的数据先到内存，写磁盘是滞后的。
- 批量处理COPY和DML操作尽量加 direct 选项或 hint，避免用 WOS。
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent