Sybase IQ 15 新特性介绍
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Sybase IQ 15 新特性介绍

on

  • 2,010 views

 

Statistics

Views

Total Views
2,010
Views on SlideShare
2,005
Embed Views
5

Actions

Likes
0
Downloads
8
Comments
0

1 Embed 5

http://www.slideshare.net 5

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Feature: As many have noted, IQ 12.7 and earlier versions often use fewer CPUs for individual queries than we would like Our development efforts in prior versions mostly concentrated on speeding up queries by using fewer resources and being more efficient – that way we improved both single and multiuser performance at the same time. With newer multi-core chips, we recognize that soon even many desktop workstations may be 4 to 8 cores, and that IQ can make better use of all of those CPUs; plus many large queries can now be improved by simply adding CPUs rather than by spending valuable DBA time tuning queries
  • Cheaper: Even if a query using in-memory compression does not get much faster, it will not use as many resources, which will help other users
  • option
  • SQL Remote is no longer used by the multiplex configuration for replicating version data. This eliminates the overhead of the dbremote processes previously required on every multiplex node.
  • online, offline, or dynamically offline. Dynamically offline means that the dbspace is marked offline in memory, as opposed to marked offline in the catalog.
  • The IQ_SYSTEM_MAIN dbspace is created at database creation or when you upgrade an older IQ database to Sybase IQ 15.0. IQ_SYSTEM_MAIN is a special dbspace that contains all structures necessary for the database to open: the IQ db_identity blocks, the IQ checkpoint log, the IQ rollforward/rollback bitmaps of each committed transaction and each active checkpointed transaction, the incremental backup bitmaps, and the freelist root pages. IQ_SYSTEM_MAIN is always online when the database is open. -- create user dbspace CREATE DBSPACE user_main USING FILE user_main 'user_main1' SIZE 10000; -- grant privilege of user dbspace to public GRANT CREATE ON user_main TO PUBLIC; --revoke create from public user REVOKE CREATE ON IQ_SYSTEM_MAIN FROM PUBLIC; --set default dbspace of public user. SET OPTION PUBLIC.DEFAULT_DBSPACE = 'user_main'; • If you use a raw device for your current IQ_SYSTEM_MAIN, assign a new unused raw device of your standard size. • If you prefer a file system file, use 1/100 total database size, with a minimum 100GB main and 100GB reserve
  • Loading partitioned tables There are a few special considerations for loading partitioned tables: When modifying a partitioned table, the best performance is achieved when the partitioning column is the first column in the column list of the statement. List partitioning columns before large object (LOB) columns in the SELECT statement clause of an INSERT...LOCATION statement and load data from a primary file, if possible. The data in the primary file should be rearranged using a pre-load process, if possible. The START ROW ID clause of the LOAD TABLE and INSERT statements is not allowed on a partitioned table. The following error is reported and a rollback is performed on the load operation: “ Option START ROW ID not allowed on a partitioned table.” (SQLCODE -1009416L, SQLSTATE QCB14, Sybase error code 21054) Partial width inserts are not recommended, as the START ROW ID clause of the INSERT statement is not supported on a partitioned table. Be sure to include the partition key column of the partitioning columns of the table in the column list of the load operation and leave all non-specified columns as NULL, if you do perform a partial width insert. If the partition key column is omitted from the column list, the following error is reported: “ Operation not allowed — partition key column %2 not specified.” (SQLCODE -1009418L, SQLSTATE QCB16, Sybase error code 21056) where %2 is the name of the partition key. The APPEND_LOAD database option behaves differently for partitioned and non-partitioned tables. Row ID ranges are assigned to each partition in a partitioned table. For partitioned tables, when APPEND_LOAD is ON, new rows are appended at the end of the appropriate partition. When APPEND_LOAD is OFF, the load reuses the first available row IDs and space from deleted rows of the appropriate partition. For non-partitioned tables, when APPEND_LOAD is ON, new rows are added after the maximum row ID that is at the end of the table rows. When APPEND_LOAD is OFF, the load reuses the deleted row IDs. With non-partitioned tables, you can also control where rows are inserted by using the LOAD or INSERT START ROW ID clause to specify the row at which to start inserting. An attempt to update the contents of a partitioning column results in the following error: “ Updating partition key column on a partitioned table is not allowed.” (SQLCODE -1009417L, SQLSTATE QCB15, Sybase error code 21055)
  • APSHB In the same linux box contains 8 cores CPU , two versions of Sybase IQ were installed, one is Sybase IQ 127, the other Sybase IQ 15. They have almost the same configure files. Loaded the same data into the same table 12 times, and recorded the time of pass 1, pass 2 and the total time of every process.
  • 相同的表结构, 10 次增量加载,每次加载 2 百万数据,共加载 2 千万数据。 表中有一个多列的 hg 索引。 硬件环境为 2C ( double cores ) 8G 的 pc server 上。环境为 linux 。
  • Feature: As many have noted, IQ 12.7 and earlier versions often use fewer CPUs for individual queries than we would like Our development efforts in prior versions mostly concentrated on speeding up queries by using fewer resources and being more efficient – that way we improved both single and multiuser performance at the same time. With newer multi-core chips, we recognize that soon even many desktop workstations may be 4 to 8 cores, and that IQ can make better use of all of those CPUs; plus many large queries can now be improved by simply adding CPUs rather than by spending valuable DBA time tuning queries
  • Unlike nested-loop joins or hash joins, sort-merge joins are parallel within the node itself - that is, each of the sorts on both sides of the join can be themselves internally parallel. The hash, nested-loop, and nested-loop pushdown joins, as well as the final comparison/merge phase of the sort-merge join, only actually do one thing at a time inside. Note this is different from being able to start up one or both children at the same time. So with a simple 2-table join, a sort-merge join could potentially be utilizing more than one CPU, while a hash join would only be able to use one CPU for most of the duration of the join. Parallel GROUP BY Under some circumstances, the optimizer ma modify a GROUP BY over a single table (or over a join index as discussed later) into a form that can be executed in parallel using multiple CPUs. This will only be done for a GROUP BY which can not be done efficiently in the indexes and which has few enough groups that it can be done using the hash-based grouping algorithm with plenty of temporary cache space left over. This transformation can, when necessary, be controlled by three options in addition to those controlling all other grouping decisions. The Enable_Parallel_GBH option, which defaults to ON, controls whether the optimizer will consider this optimization. When the optimizer decides to apply this optimization, it normally selects the degree of parallelism appropriate based on available CPU and cache resources. The Parallel_GBH_Units option can be used to force the optimizer to use the specified degree of parallelism. The default value of 0 for Parallel_GBH_Units option means that the optimizer should decide. Normally, this optimization is of very limited value if there are too few rows flowing from the table being grouped. The threshold for this decision is set by the Parallel_GBH_Min_Rows_Per_Unit option. The Parallel_GBH_Min_Rows_Per_Unit option can indirectly limit the degree of parallelism chosen within the optimizer for GROUP BY operations by requiring that each unit of work to be done in parallel must have at least this many rows. The default of 3 million rows means that a table must have at least 6 million rows remaining after all local predicates before the optimizer will consider executing the GROUP BY in parallel over that table.
  • Parallel GROUP BY Under some circumstances, the optimizer ma modify a GROUP BY over a single table (or over a join index as discussed later) into a form that can be executed in parallel using multiple CPUs. This will only be done for a GROUP BY which can not be done efficiently in the indexes and which has few enough groups that it can be done using the hash-based grouping algorithm with plenty of temporary cache space left over. This transformation can, when necessary, be controlled by three options in addition to those controlling all other grouping decisions. The Enable_Parallel_GBH option, which defaults to ON, controls whether the optimizer will consider this optimization. When the optimizer decides to apply this optimization, it normally selects the degree of parallelism appropriate based on available CPU and cache resources. The Parallel_GBH_Units option can be used to force the optimizer to use the specified degree of parallelism. The default value of 0 for Parallel_GBH_Units option means that the optimizer should decide. Normally, this optimization is of very limited value if there are too few rows flowing from the table being grouped. The threshold for this decision is set by the Parallel_GBH_Min_Rows_Per_Unit option. The Parallel_GBH_Min_Rows_Per_Unit option can indirectly limit the degree of parallelism chosen within the optimizer for GROUP BY operations by requiring that each unit of work to be done in parallel must have at least this many rows. The default of 3 million rows means that a table must have at least 6 million rows remaining after all local predicates before the optimizer will consider executing the GROUP BY in parallel over that table.
  • The new compression uses more memory (temp cache during loads, main cache for queries) to get better compression. For systems with huge memory we may get better compression, while a 32-bit windows system will get less main cache setting of 32 MB and a default FP_LOOKUP_SIZE_PPM setting of 2500,
  • Most queries will show much more parallelism than 12.7, but some parts of queries will not; for example: OLAP operators, Group By queries with distinct aggregates, one join algorithm (nested-loop push-down)
  • SELECT pno, qty, (SELECT city FROM s WHERE s.sno = sp.sno) FROM sp

Sybase IQ 15 新特性介绍 Presentation Transcript

  • 1. IQ 15.0 新特性 夏小涛
  • 2. 日程
    • IQ 15 新特性概述
    • 新特性详细介绍
      • 表空间和分区
      • Load 性能提升
      • 并发查询
    • Q&A
  • 3. Sybase IQ 产品优势
    • 速度
    •  快速响应
    • 10-100 倍的快速查询响应
    • 基于列的存储结构
    • 高性能的数据访问
    • 无处不索引
    • I/O 减少 90%
    • 可扩展性
    •  适应大量的用户数
    • 同时支持成百上千的用户数
    • 从 GB 到上百个 TB 的数据
    • 接近实时的新数据装入—数据仓库的用户查询几乎不受影响
    • 低 TCO
    •  经济性
    • 30-70% 数据压缩 , 而不是数据膨胀
    • 低成本
      • 更少硬件
      • 更少的数据存储设备
      • 更少的支持维护人员
    • 灵活性
    •  开放的标准
      • ANSI SQL (ODBC,JDBC)
      • Unix, Linux, Windows
      • 任何的查询
      • 任何的 schema
  • 4. Sybase IQ 技术路线
    • 增强数据生命周期管理支持
      • 提高灾难恢复能力
      • 有效利用不同类型的存储设备
      • 降低日常数据管理规模
    • 适应硬件趋势
      • 增强 cluster 能力
      • 增强并发能力
      • 降低磁盘和内存使用
    • 降低管理成本
  • 5. IQ 15 新特性概述
  • 6. IQ 15.0 主要改进
    • 并行查询架构
    • 表空间和分区
    • Load 性能提升
    • Multiplex 架构
    • Sybase central 管理工具
    • 安全性
  • 7. 并行查询架构
  • 8. 查询性能提升
    • 在 IQ 15.0 中 :
      • 更多的并发处理
      • 更大的磁盘压缩
      • In-memory 压缩
      • 更灵活的查询处理
      • 子查询优化
  • 9. 并行架构概述
    • 优势
      • 查询速度更快
      • 单个查询更充分的利用可用的 CPU 资源
      • 增加 CPU 资源扩充系统处理能力。
    • 特点
      • 大部分查询并行度更高
        • 特别是 joins, Group Bys, and sorts
      • 查询计划能够清晰地反映出并行处理查询的细节。
  • 10. 更强的压缩能力
    • 优点
      • 优化 Cache 分配
      • 占用更少的磁盘空间
      • 查询处理更快
      • 查询使用的资源更少
    • 特点
      • 一种新的索引带来更好的数据压缩能力。
      • In-memory 压缩提高查询执行效率、降低查询执行代价。
      • Hash 对象处理更高效。
  • 11. 更强的压缩能力( cont. ) IQ FP 索引 : FP(1) , FP(2) , FP(3)
      • 唯一值数量
    • - FP(1): <256
    • - FP(2): 256 -65536
    • - FP(3): 65537-1677216
    • - Flat FP: >1677216
    3-byte FP 索引巩固了 Sybase IQ 数据压缩的领先优势。
  • 12. Multiplex 架构
  • 13. Multiple 新特性概述
    • Multiple 多个写节点
    • 配置更简单
    • 管理更容易
    • 全局 DDL
  • 14. 多个写结点
    • 多个写节点
    • 任何写节点都可以修改数据
    • 通过 Multiplex Global Transaction Framework 保证并行的读 / 写操作
    并行读写 并行读 Coordinator Node Shared Main IQ Store Inter Node Communication Inter Node Communication Reader Node(s) Writer Node(s)
  • 15. Multiplex 配置
    • 使用 SQL 语句,而不是存储过程
      • CREATE MULTIPLEX SERVER
      • ALTER MULTIPLEX SERVER
      • DROP MULTIPLEX SERVER
    • Local store 不再支持
      • 不影响 Temporary Store
      • 使用 IQ Shared Store
    • 不再使用 SQL Remote
    • Single-version multiplex
  • 16. Sybase Central
  • 17. Sybase Central 概述
    • 监控功能是最重要的提升
    • 对 server 的性能影响很小
      • 自动激活 / 暂停数据收集线程
      • 可以为不同 server 配置不同的监控指标
  • 18. 拓扑视图
  • 19. 预定义常用的监控指标
  • 20. 表空间和分区
  • 21. 表空间和分区
    • 数据生命周期管理( Information Life Cycle Management ) :
      • 提高数据管理的扩展性 .
        • Storage 分区为 tablespaces
        • table 分区为 partitions
      • 提高 VLDB 的易管理性、可用性
        • 提供比数据库和表更小的管理和应用粒度
        • 指定数据存放位置 .
        • 分等级的存储管理,支持数据的迁移( relocation ),比如历史数据向低端存储的转储。
        • 缩短 Backup/Restore 时间 .
  • 22. 表空间
    • Sybase IQ 中对应的名词是 DBSpace.
    • DBSpace 是一个逻辑上存在的容器
        • 包含一个或者多个文件
        • 有 read-only (RO) 、 read-write (RW) 、 online 、 offline 、动态 offline 状态 .
        • 文件有 RO 、 RW 两种状态 .
    Finance Files Low Cost Files User HR Files High Speed Files IQ MAIN Files IQ TEMP Files IQ CATALOG Files System IQ TEMP Files
  • 23. 表空间作用
    • 缩短 backup/restore 时间 .
      • 把一个 dbspace(file) 状态改为 RO
      • 备份这个 RO dbspace(file) 一次
      • 以后的备份和恢复只需要针对所有 RW 状态的 dbspace(file)
      • 可以在数据库 ONLINE 状态 restore RO 的 dbspace(file)
    • 数据验证时间
      • sp_iqcheckdb 支持更小的粒度(表分区、 dbspace )
    • 部分 Dbspace file 文件不可用数据库也可以启动。
  • 24. 特殊的 DBSpace IQ_SYSTEM_MAIN
    • IQ_SYSTEM_MAIN 中存放的信息
        • db_identity blocks
        • checkpoint log
        • rollforward/rollback bitmaps
        • incremental backup bitmaps
        • freelist root pages.
        • Multiplex
      • 只能是 online 、 readwrite 状态
      • 至少包含一个 file
      • 大小
        • IQ_SYSTEM_MAIN 建议大小为总大小的 1 % . Multiplex 环境建议 2 %
      • 不要使用它存放用户数据
  • 25. 特殊的 DBSpace IQ_SYSTEM_MAIN
    • 创建用户 DBSpace
      • CREATE DBSPACE user_main USING FILE user_main 'user_main1' SIZE 10000;
    • 为用户分配创建的 user DBSpace 的写权限
      • GRANT CREATE ON user_main TO PUBLIC;
    • 删除 public 用户对 IQ_SYSTEM_MAIN 的写权限
      • REVOKE CREATE ON IQ_SYSTEM_MAIN FROM PUBLIC;
    • 设置用户 DBSpace 为默认的 DBSpace
      • SET OPTION PUBLIC.DEFAULT_DBSPACE = 'user_main';
  • 26. 表分区
    • 支持范围分区 .
      • 单列
    • 分区表中所有的 Index 都是全局( global )的。
    • 不同分区的数据可以分布在不同的 DBSpace 上。
      • 可以在表空间之间移动一个表分区
      • 支持对分区的数据验证 .
      • 可以修改分区
    • add/drop 一个分区 ,
    • 划分一个分区为多个连续的分区
    • 转化为一个非分区表。
  • 27. 表分区的作用
    • 支持 “ roll on”, “roll off” 模式
      • 加载数据到最新的分区
      • 分区为 RO 并进行备份
      • Drop 最老的分区
      • 维护一个固定的时间窗口的数据。
    • 支持 “ add forever” 模式
      • 加载数据到最新的分区
      • 把最老的或者最不常用的数据分区到低端存储
      • 设置为只读状态
      • 备份
  • 28. 其它
    • Out of space 的处理
      • IQ 12.7 中 Out of space 的处理是等待添加设备
      • IQ 15 中会报错,并 Rollback 当前事务。
  • 29. 数据加载提升
  • 30. 数据加载提升
    • 客户端加载
    • Load pass 1 内存使用
    • Load pass 2 并发处理
    • 多个写节点的并发写扩展能力
  • 31. 客户端加载
    • LOAD TABLE … USING CLIENT FILE …
      • 真正的 bulk loader
        • 性能 ~ 服务器端 LOAD TABLE + 网络延迟
      • 更安全
        • 只有 client 端有访问数据文件的权限
        • Client 端不需要拥有服务器上文件系统的访问权限
      • 支持所有的 LOAD 选项
      • 完全支持大对象。
      • 加载信息记录在客户端。
  • 32. 客户端加载
    • Load 语句上的变化 : “USING CLIENT FILE” 子句
    • Client 端可以使用 DBLib, ODBC, OLE DB, ADO.Net or JDBC
      • 不支持 TDS protocol
    • 客户端和服务器都需要是 IQ15 版本
    • 数据文件的字符集要和 server 的 collation 一致。
  • 33. Client-side Loader (cont.)
  • 34. LOAD Recovery When Using Client-side files
    • Transaction logging on the server is self contained, and must not need the information from the client once the statement has been logged
      • You must use client side loading with ‘ROW LOGGING ON’
        • ROW LOG writes rows rejected by the LOAD into the specified log file
      • You should also use client side loading with the ‘WITH CHECKPOINT ON’ option
        • If WITH CHECKPOINT ON is specified, a checkpoint is carried out after loading, and recovery is guaranteed even if the data file is then removed from the system
  • 35. Pass 1 改善
      • IQ 15 使用内部内存分页代替 Heap memory
        • 使用分隔符分割的文本
        • 定宽的数据文件
        • LOAD_MEMORY_MB
      • 动态调整 Load 操作的资源使用。
      • 建议:
        • 使用分隔符分割的文本
        • Row delimited by
  • 36. Pass 2 改善
    • Pass 2 ,创建 HG , WD 索引
      • 多个 CPU 参与 HG 索引创建
        • HG 索引创建会被划分为多个工作单元分配给不同的 CPU
        • 多核环境大幅提高 Pass 2 效率。
      • 动态资源管理。
  • 37. pass 2 提升的案例 APSHB Load 20,000,000 records per time
  • 38. 并行多表数据加载 DEMO Scale out R/W Node 1 Sybase ETL v4.8 Grid ETL project 1 ETL project 2 ETL project 3 R/W Node 1 RO Node 1 RO Node 1 R/W Node 1 Scale out Scale out Scale out Sybase IQ v15 Grid
  • 39. 查询性能提升
  • 40. 并发查询概述
    • 优点
      • 大部分查询更快
      • 查询可以更充分的利用系统资源
      • 增加 CPU 资源可以成为扩展系统处理能力的有效手段。
    • 特点
      • 更多的查询结点可以并发执行
        • 尤其是 many joins, Group Bys 和 sorts
      • 图形化的查询计划提供一个友好的并发处理视图。
  • 41. 并发查询概述
    • In IQ 15.0:
      • 更多的并发处理
      • 更好地使用内存
      • 更灵活的查询处理
      • 优化子查询
      • Other query enhancements
      • 查询计划
  • 42. 1. 更多的并发处理
      • 并发 Hash Join
      • 并发 Merge Join
      • 并发 Group-By
      • 并发 Complex Predicates
  • 43. 1. 更多的并发处理 - 并发 Hash Join
    • 并发的 Hash Join 操作 :
      • Inner Hash Join
      • Left Outer Hash Join
    • 选择小表(或者结果集)
    • 按照 Join 的 key 形成 Hash table 对大表(或者结果集)中的每一行
    • 和 Hash 表逐行比对
    • 返回符合 join 行
  • 44. 1. 更多的并发处理
    • 并发 Hash Join
      • Inner Hash Join
      • Left Outer Hash Join
      • Right Outer Hash Join
    • 并发 Merge Join
      • Inner Merge Join
      • Left Outer Merge Join
      • Right Outer Merge Join
      • Merge Join with Order By
      • Merge Join with Ordered Leaf
      • Merge Join with Ordered Leaf and Order By
      • Merge Semi-Join
      • Merge Join with mixed join key nullability
      • Merge Join with mixed datatypes
  • 45. 1. 更多的并发处理 (cont.)
    • 并发 Group By
      • Hash Group-By
      • Ordered Group-By
      • Group-by single
    • 并发 Complex Predicates
      • Top N
      • 复杂的 vertical local conditions
      • horizontal filter
      • 不同数据类型之间的 Merge Join
  • 46. 2. 更好地使用内存
    • In IQ 15.0:
      • 更多的并发处理
      • 更好地使用内存
      • 更灵活的查询处理
      • 优化子查询
      • Other query enhancements
      • 查询计划
  • 47. 2. 更好地使用内存 cont.
      • 唯一值数量
            • - FP(1): <256
            • - FP(2): 256 -65536
            • - FP(3): 65537-1677216
            • - Flat FP: >1677216
    3-byte FP 索引巩固了 Sybase IQ 数据压缩的领先优势。
  • 48. 2. 更好地使用内存 cont. – 使用 FP3
    • 创建 :
      • 和 IQ12.7 一样
        • IQ UNIQUE 或者 MINIMIZE_STORAGE
      • 已经创建的优化的 FP 索引可以直接升级
    • 管理 :
      • 16M 是技术上的最大限制,实践上可能小于这个值
      • FP_LOOKUP_SIZE_PPM 2500
      • FP_LOOKUP_SIZE 32M
  • 49. 2. 更好地使用内存
      • 优化的 FP 索引( 1-byte, 2-byte 或者 3-byte FP )内存中使用的是序号
      • Tokenized FP
      • 带来的收益
        • 高效的 in memory 压缩
        • 更小的 temp space 使用
  • 50. 2. 更好地使用内存 示例
    • 一个基于 6 亿记录表的查询:
    • select top 100 l_orderkey, sum(l_quantity), max(l_shipdate), count(*)
    • from lineitem group by l_orderkey
    • having sum(l_quantity) > 300
    • 查询包括一个大的查询操作
      • 查询速度提高 25%
      • temp space 资源使用
        • 9.2 GBytes in 12.7
        • 4.6 GBytes in 15.0
  • 51. 3. 更灵活的查询处理
    • 目标 : 在不影响多用户查询的情况下,提供比 IQ 12.7 更好的查询性能
    • 更灵活并发架构
      • 允许单个查询动态的调整使用的 CPU 资源
      • 只有一个查询运行时,它能够使用所有的 CPU 资源
      • 如果有其它的查询此时也开始运行,系统自动释放出部分 CPU 资源。
    • 这是 IQ 的一个全新的并发架构。
  • 52. 4. 优化子查询
    • 加速一些相关子查询
      • 有些子查询可能就是系统的瓶颈
      • IQ 15 能够自动的转化“大多数”相关子查询为基于索引的 join 。
    • 更多的谓词可以使用索引
      • 索引、索引、索引。
      • 在 15.0 一些比较复杂的表达式计算也可以选用正确的索引 (e.g. “WHERE RAND(ROWID(T1)) < 0.02” )
  • 53. 4. 优化子查询
    • 包含多个外部引用( outer references )的相关子查询会被转化为基于索引的 Join 操作
      • EXISTS & NOT EXISTS 子查询 .
      • 范围子查询 .
      • SELECT pno, qty, (SELECT city FROM s WHERE s.sno = sp.sno) FROM sp
    • 子查询被重写( flattened) 来执行后,查询性能更好,使用的资源也更小。
  • 54. 多列索引使用
    • An ordered leaf is used to evaluate an order by query if the table has a multicolumn index that spans the columns in the select list
    • Multi-column index with lots of columns.
    • Ordered leaf not used if few columns in index are selected
    • Ordered leaf not used if columns selected are not the leading columns in the multicolumn index.
  • 55. 5. IQ 15.0 Query Tree 双线条表示并行数据流 线条粗细表示数据量大小 结点深度表示最大线程数 最大线程数 红色表示有索引建议
  • 56. IQ 15.0 Query Tree: Group By
    • 12.7
      • 使用 Union All 结点合并结果集
      • 显示并行处理结点
    • 15.0
      • 使用 Parallel Combiner 结点合并结果集
      • 隐藏并行处理结点
  • 57. Query Timing
    • 12.7
      • 显示并行节点
    • 15.0
      • 不显示并行处理节点时间
      • Thread 视图显示线程分配情况
      • CPU 视图显示 CPU 使用情况
  • 58. 总结
    • 数据加载
    • 数据压缩
    • 查询性能
    • 可用性和易用性
  • 59. Q&A