轻淘客轻网站怎么做工业设计公司经营范围有哪些

当前位置： 首页 > news >正文

轻淘客轻网站怎么做,工业设计公司经营范围有哪些,东莞市官网网站建设哪家好,周浦手机网站策划建设公司单表查询 Prewhere 替代 where prewhere与where相比#xff0c;在过滤数据的时候会首先读取指定的列数据#xff0c;来判断数据过滤#xff0c;等待数据过滤之后再读取 select 声明的列字段来补全其余属性 简单来说就是先过滤再查询#xff0c;而where过滤是先查询出对应…单表查询 Prewhere 替代 where prewhere与where相比在过滤数据的时候会首先读取指定的列数据来判断数据过滤等待数据过滤之后再读取 select 声明的列字段来补全其余属性 简单来说就是先过滤再查询而where过滤是先查询出对应的列字段来再根据过滤条件过滤数据因此对比之下使用prewhere过滤处理的数据量要更少效率也就更高 但需注意prewhere只可适用于mergetree引擎 默认情况下where 条件会自动优化成 prewhere通过参数optimize_move_to_prewhere来控制 参数值为1表示使用怕prewhere 使用where和prewhere的对比 ①使用where 关闭prewhere自动优化之后执行语句 select WatchID, JavaEnable, Title, GoodEvent, EventTime, EventDate, CounterID, ClientIP, ClientIP6, RegionID, UserID, CounterClass, OS, UserAgent, URL, Referer, URLDomain, RefererDomain, Refresh, IsRobot, RefererCategories, URLCategories, URLRegions, RefererRegions, ResolutionWidth, ResolutionHeight, ResolutionDepth, FlashMajor, FlashMinor, FlashMinor2 from datasets.hits_v1 where UserID3198390223272470366; 结果如下耗时2.467s ②使用prewhere 开启优化后执行相同语句结果如下耗时仅用0.172s可以看到效率提升很明显 在一些场景下自动优化不生效如下 使用常量表达式使用默认值为 alias 类型的字段包含了 arrayJOINglobalInglobalNotIn 或者 indexHint 的查询select 查询的列字段和 where 的谓词相同使用了主键字段 例如select 查询的列字段和 where 的谓词相同的情况 explain syntax select UserID from hits_v1 where UserID3198390223272470366; 结果如下 可以看到并没有进行优化 因此我们在使用prewhere的时候最好直接在sql中使用prewhere而不是依赖于自动优化 例如 explain syntax select UserID from hits_v1 prewhere UserID3198390223272470366; 结果如下是可以生效的 数据采样 SAMPLE 示例 SELECT Title,count(*) AS PageViews FROM hits_v1 SAMPLE 0.1 WHERE CounterID 57 GROUP BY Title ORDER BY PageViews DESC LIMIT 1000 采样语法SAMPLE 样本比例(1代表100%) SAMPLE Clause | ClickHouse Docs 注意采样修饰符只有在 MergeTree engine 表中才有效且在创建表时需要指定采样策略 这里的采样策略是在建表时指定的 表示根据UserID字段的哈希值进行采样 列裁剪与分区裁剪 列裁剪数据量太大时应避免使用 select * 操作 分区裁剪就是只读取需要的分区在过滤条件中指定 例如 select WatchID, JavaEnable, Title, GoodEvent, EventTime, EventDate, CounterID, ClientIP, ClientIP6, RegionID, UserID from datasets.hits_v1 where EventDate2014-03-23; 这里的EventDate就是分区字段 orderby 结合 where、limit 千万以上数据集进行 order by 查询时需要搭配 where 条件和 limit 语句一起使用 对比 ①仅使用order by SELECT UserID,Age FROM hits_v1 ORDER BY Age DESC; ②使用where和limit SELECT UserID,Age FROM hits_v1 WHERE CounterID57 ORDER BY Age DESC LIMIT 1000; 可以看到处理的数据量大幅降低效率提示十分明显 ③仅使用limit SELECT UserID,Age FROM hits_v1 ORDER BY Age DESC LIMIT 1000; 处理的数据量虽然没有降低但是效率提升也比较明显 避免构建虚拟列 什么是虚拟列在select查询的字段中非建表时指定的字段即为虚拟列 例如 SELECT Income,Age,Income/Age as IncRate FROM datasets.hits_v1; 这里的Income/Age就是虚拟列由于每次查一条语句都需要进行一次计算所以十分影响性能 使用虚拟列 没有虚拟列 uniqCombined 替代 distinct uniqCombined 底层采用类似 HyperLogLog 算法实现能接收 2%左右的数据误差可直接使用这种去重方式提升查询性能 而Count(distinct)会使用 uniqExact精确去重 示例 explain syntax select count(distinct UserID) from hits_v1; 对UserID进行去重 使用uniqCombined SELECT uniqCombined(UserID) from datasets.hits_v1; 使用uniqExact select count(distinct UserID) from hits_v1; 其他 查询熔断 为了避免因个别慢查询引起的服务雪崩的问题除了可以为单个查询设置超时以外还可以配置周期熔断在一个查询周期内如果用户频繁进行慢查询操作超出规定阈值后将无法继续进行查询操作 关闭虚拟内存 物理内存和虚拟内存的数据交换会导致查询变慢资源允许的情况下关闭虚拟内存 配置 join_use_nulls 为每一个账户添加 join_use_nulls 配置左表中的一条记录在右表中不存在右表的相应字段会返回该字段相应数据类型的默认值而不是标准 SQL 中的 Null 值 批量写入时先排序 批量写入数据时必须控制每个批次的数据中涉及到的分区的数量在写入之前最好对需要导入的数据进行排序。无序的数据或者涉及的分区太多会导致 ClickHouse 无法及时对新导入的数据进行合并从而影响查询性能 关注 CPU cpu 一般在 50%左右会出现查询波动达到 70%会出现大范围的查询超时cpu 是最关键的指标要非常关注 使用top命令查看CPU使用情况 参数含义如下 %us表示用户空间程序的cpu使用率没有通过nice调度 %sy表示系统空间的cpu使用率主要是内核程序。 %ni表示用户空间且通过nice调度过的程序的cpu使用率。 %id空闲cpu %wacpu运行时在等待io的时间 %hicpu处理硬中断的数量 %sicpu处理软中断的数量 %st被虚拟机偷走的cpu 注99.0 id表示空闲CPU即CPU未使用率100%-99.0%1%即系统的cpu使用率为1%。 多表关联 准备数据 由于clickhouse的join操作效率很低因此根据官方提供的数据集准备两张小表 #创建小表CREATE TABLE visits_v2 ENGINE CollapsingMergeTree(Sign) PARTITION BY toYYYYMM(StartDate) ORDER BY (CounterID, StartDate, intHash32(UserID), VisitID) SAMPLE BY intHash32(UserID) SETTINGS index_granularity 8192 as select * from visits_v1 limit 10000;#创建 join 结果表避免控制台疯狂打印数据 CREATE TABLE hits_v2 ENGINE MergeTree() PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDate, intHash32(UserID)) SAMPLE BY intHash32(UserID) SETTINGS index_granularity 8192 as select * from hits_v1 where 10; 这里的visits_v2是一张小表用于join测试 hits_v2是一张结果表用于保存join之后的数据 注意where 10这个条件保留了hits_v1这张表的结构但里面没有数据 用 IN 代替 JOIN ①使用IN insert into hits_v2 select a.* from hits_v1 a where a. CounterID in (select CounterID from visits_v1); ②使用JOIN insert into table hits_v2 select a.* from hits_v1 a left join visits_v1 b on a. CounterIDb. CounterID; 对比可知使用IN效率提升很多 同时在执行join的时候观察CPU使用情况 发现CPU的占用率接近80% 小表在右原则 多表 join 时要满足小表在右的原则右表关联时被加载到内存中与左表进行比较ClickHouse 中无论是 Left join 、Right join 还是 Inner join 永远都是拿着右表中的每一条记录到左表中查找该记录是否存在所以右表必须是小表 对比以下 ①小表在右 insert into table hits_v2 select a.* from hits_v1 a left join visits_v2 b on a. CounterIDb. CounterID; ②大表在右 insert into table hits_v2 select a.* from visits_v2 b left join hits_v1 a on a. CounterIDb. CounterID; 执行没几秒就内存超限了 谓词下推join查询无法自动实现 ClickHouse 在 join 查询时不会主动发起谓词下推的操作需要每个子查询提前完成过滤操作 需要注意的是是否执行谓词下推对性能影响差别很大 子查询不提前过滤 insert into hits_v2 select a.* from hits_v1 a left join visits_v2 b on a. CounterIDb. CounterID where a.EventDate 2014-03-17; 子查询提前过滤 insert into hits_v2 select a.* from (select * from hits_v1 where EventDate 2014-03-17 ) a left join visits_v2 b on a. CounterIDb. CounterID; 可以看出效率上有一定差别 所谓谓词下推就是在join之前根据条件进行过滤从而筛选出一部分数据来减少进行join的数据量从而提升join的效率 查看上面两个select语句的优化计划分别如下 可以看到如果不手动通过子查询提前完成过滤是不会自动进行谓词下推的 分布式表使用GLOBAL关键字 两张分布式表上的 IN 和 JOIN 之前必须加上 GLOBAL 关键字这样的话右表只会在接收查询请求的那个节点查询一次并将其分发到其他节点上 如果不加 GLOBAL 关键字的话每个节点都会单独发起一次对右表的查询而右表又是分布式表就导致右表一共会被查询 N²次N是该分布式表的分片数量这就是查询放大会带来很大开销 官网相关描述 详细用法可见IN Operators | ClickHouse Docs 字典表 将一些需要关联分析的业务创建成字典表进行 join 操作前提是字典表不宜太大因为字典表会常驻内存 参考Dictionaries | ClickHouse Docs