版本1.1.0

下载以及安装这个版本的Trafodion，请看安装页

1.1.0 新功能

这个版本包括下面这些新增及加强的功能

分类功能
市场化、结构化、可扩展化
  • 紧急与严重问题的修复
  • 基础结构的更新，支持HDP 2.2与CDH 5.3
性能
  • 通过PoC/benchmark提高查询计划质量，比如，在适当的时候，改变消耗以帮助生成MDAM计划。
  • 用户定义的日常事务（UDRs）的性能提升。（即存储过程以及C标量的用户定义函数（UDFs））
  • 混合查询高速缓存（Hybrid query cache），通过将编译器的SQL相似性检查迁移到解析阶段，会带来事务性能与效率的提升。查询缓存区允许对事先优化过的SQL执行计划再使用，从而消除额外开销的编译代价并减少花费。
  • Skew buster，Trafodion中的一个显著功能是可以识别查询中间阶段的数据扭曲的情形，并调整执行计划与执行时间，重新分配中间数据，用以确保所有数据均匀分布在处理节点上。
  • 立即更新统计信息 用在快速数据加载时，基于样本选取的整张表上（技术性预览--实现但并未全部测试）
高可用性（HA）以及交易分配管理（DTM）
  • 交易管理效率以及性能加强
  • 提升整个集群HA。现在Trafodion事务管理（TM）进程连续运作，用以消除因为TM出错导致的node错误。
  • ”DTM本地事务支持“能够减少事务的花销，这是通过在事务开始的时候，并且事务规模仅仅在本地，减少与TM进程的交互而达到的。（技术性预览--正在工作中）
  • 在事务中执行DDL语句的能力，因此能为DDL操作提供数据一致性保护（技术性预览--正在工作中）
  • 有状态和无状态并发控制（Stateless/Stateful Concurrency Control，SSCC），这能确保事务阻止数据争论异常，这种异常会破坏数据库的一致性。它通过阻止用户交易来工作，这种事务能介入用户间的数据。SSCC是快照隔离算法（Snapshot Isolation，SI）的延伸。SI能阻止大多数与数据陈腐相关的异常，并能出色地隔离多版本并发控制（Multi-Version Concurrency Control，MVCC），现在正被DTM使用着。（技术性预览--正在工作中）
使用性
管理
  • 支持HP数据服务管理（HP Data Services Manager，即HP DSM），这是一款基于浏览器的工具，能够实现对Hadoop，Vertica，以及现在的Trafodion数据服务的统一管理。 注： 整合了Trafodion的HP DSM版本现在还不可用。
  • 稳定性以及开销的优化能够减少在抓取以及维护查询性能信息的费用（参考数据库中的表）
  • 对DDL，更新统计信息，以及附加子查询操作的取消操作。详细信息请参考Trafodion SQL Reference Manual (pdf, 3.98 MB)中‘CONTROL QUERY CANCEL’语句。
安全
  • 安全子系统的强化提高，包括性能以及QA测试
  • 对Trafodion元数据、数据加载器以及数据连接服务（Data Connectivity Services，即DCS）的安全提升
  • 升级授权
  • 授权的能力，代表某个角色使用GRANTED BY子句。详细信息，请参考Trafodion SQL Reference Manual (pdf, 3.98 MB)中的GRANT语句。
安装脚本增强
  • 提示配置与激活安全性
  • 支持最新分配，HDP 2.2以及CDH 5.3

1.1.0 修复的问题

这个版本涵盖了96个问题的修复，包括17个紧急问题，53个严重问题，以及20个中等问题跟2个一般问题。这些问题被列在Launchpad。

1.1.0 临时解决的已知问题

Bug #1274962: EXECUTE.BATCH update creates core-file

症状： EXECUTE.BATCH在更新时，系统长时间未响应，并产生了core文件。

起因： 待定。

解决方案： Batch更新以及ODBC行部署不能工作。

Bug #1391271: Random update statistics failures with HBase OutOfOrderScannerNextException

症状： 在执行update statistics命令时，遇见HBase OutOfOrderScannerNextException的错误。

起因： 当给定一张表时，默认的hbase.rpc.timeout以及hbase.client.scanner.timeout.period的值可能太小了。更新统计信息的采样是使用 HBase 随机 RowFilter 来实现的。对于几个亿行这样非常大的表，用100万行作为样本，其采样率是非常小的。这可能会导致HBase 客户端连接超时错误，因为可能在一个长时间里，RegionServer 没有行返回。

解决方案： 提高hbase.rpc.timeout与hbase.client.scanner.timeout.period的值。我们发现，将这两个值增加到600秒（10分钟），有时会阻止许多与超时有关的错误。更多信息，请参考HBase配置与调优推荐.

如果提高hbase.rpc.timeout与hbase.client.scanner.timeout.period的值并不能起效，那试试增加选取样本的大小。对大表采用高于默认100万行的样本。例如，假设表 T 有 10 亿行，下面的UPDATE STATISTICS语句将用100万行，也就是大约总体的千分之一作为样本：

update statistics for table T on every column sample;

如果想用所有行的百分之一作为样本，而不管表的具体大小，你必须明确取样率：

update statistics for table T on every column sample random 1 percent;

Bug #1409937: Following update statistics, stats do not take effect immediately.

症状： 统计信息刚更新好的时候，生成的查询计划似乎并不反映该统计信息。例如，在一个会话中，你创建一张表，并插入值，然后在表上运行更新统计信息（update statistics），再prepare一条查询语句，最后退出。这时系统生成了一个执行计划，并得到了预估基数100。如果打开一个新的连接（session），你prepare一条相同的语句，这时也会有一条平行的执行计划生成，这时预估基数就能反应统计信息。

起因： 这是一个day-one的问题。

解决方案： 两分钟之后重试该查询语句。设置CQD HIST_NO_STATS_REFRESH_INTERVAL为'0'并执行UPDATE STATISTICS语句。在不同的连接（session）中执行DML操作。

  • No labels