企业官网建设流程全解析

j动态加载网站开发,苏州网站建设用哪种好,WordPress 黑镜2.0破解主题,用html5设计个人网站本文字数#xff1a;15137#xff1b;估计阅读时间#xff1a;38 分钟作者#xff1a;ClickHouse Team本文在公众号【ClickHouseInc】首发又到每月更新的时间了#xff0c;本月的新版本已经发布#xff01;发布概要ClickHouse 25.11 版本带来了 24 项新功能 #x1f983…本文字数15137估计阅读时间38 分钟作者ClickHouse Team本文在公众号【ClickHouseInc】首发又到每月更新的时间了本月的新版本已经发布发布概要ClickHouse 25.11 版本带来了 24 项新功能 、27 项性能优化 ⌚以及 97 个 Bug 修复 。本次发布新增了 ACMELets Encrypt集成、小型 GROUP BY 的并行合并、投影作为辅助索引等多项实用功能新贡献者热烈欢迎所有在 25.11 版本中首次贡献的开发者ClickHouse 社区的不断壮大令人感动我们始终心怀感激感谢所有为 ClickHouse 的流行和发展做出贡献的人。以下是本次新增的贡献者名单AbdAlRahman Gad、Aleksei Shadrunov、Alex Bakharew、Alex Shchetkov、Animesh、Animesh Bilthare、Antony Southworth、Cheuk Fung KeithChuckChow、Danylo Osipchuk、David K、John Zila、Josh、Julian Virguez、Kaviraj Kanagaraj、Ken LaPorte、Leo Qu、Lin Zhong、Manuel、Mohammad Lareb Zafar、Nihal Z. Miaji、NilSper、Nils Sperling、Saksham10-11、Saurav Tiwary、Sergey Lokhmatikov、Shreyas Ganesh、Spencer Torres、Tanin Na Nakorn、Taras Polishchuk、Todd Dawson、Zacharias Knudsen、Zicong Qu、luxczhang、r-a-sattarov、tiwarysaurav、tombo、wake-up-neo、zicongquACMELets Encrypt集成贡献者Konstantin Bogdanov、Sergey LokhmatikovClickHouse 25.11 版本引入了自动申请和使用 TLS 证书的功能。这些证书可通过 ClickHouse Keeper 在整个集群中共享并支持与 Lets Encrypt、ZeroSSL 等多个证书颁发机构集成。以下是一个配置示例# /etc/clickhouse-server/config.d/ssl.yaml http_port: 80 acme: email: feedbackclickhouse.com terms_of_service_agreed: true # zookeeper_path: /clickhouse/acme # by default domains: - domain: play.clickhouse.com小型 GROUP BY 的并行合并贡献者Jianfei Hu“我们优化 ClickHouse然后继续优化 ClickHouse还是不满足于是再继续优化”——ClickHouse 创始人 Alexey Milovidov 在最近的版本发布研讨会上如是说。GROUP BY 一直是 ClickHouse 中最重要的关系操作符之一。它具备最丰富的专用实现方式、最多样化的算法选择并持续进行性能优化。继上个版本中对使用简单 count() 聚合的 GROUP BY 操作进行了内存和 CPU 使用率的优化后本次更新再次带来性能提升在处理小范围的 8 位和 16 位整数键时GROUP BY 操作将变得更加高效。我们通过对某个专用聚合结构的合并步骤进行并行化实现了这一优化。这一优化主要适用于某些特定场景的查询但在 ClickHouse我们始终致力于通过各种方式让查询变得更快不论性能提升是全面性的还是针对性的。在介绍一个具体示例之前我们先来简单看看这个优化背后的原理。GROUP BY 当前是如何并行执行的正如我们在之前的版本发布中所介绍的那样ClickHouse 会在所有 CPU 核心上对 GROUP BY 操作进行高度并行化处理① 数据以块为单位流入引擎② 每个 CPU 核心处理自身负责的数据范围包括过滤、聚合和排序③ 然后将所有流的部分聚合状态 ④ 合并为最终结果。在聚合阶段内部① 每个数据流维护一张属于自己的哈希表用于将每个键映射到对应的部分聚合状态。例如avg() 聚合函数会为每个键分别记录本地的总和和计数。随后这些部分聚合状态会被 ② 合并并进行 ③ 最终计算处理在常规情况下ClickHouse 会使用一种两级哈希表结构键对应的聚合状态存储在一个共享的内存池中此时合并步骤本身如上方动画中的 ②也会通过多个合并线程并行执行。此外如果查询中使用了多个聚合函数例如 COUNT、SUM 或 MAX每个聚合函数都会维护独立的部分状态它们的合并操作也会彼此并行进行。但 GROUP BY 是高度特化的ClickHouse 并不依赖单一类型的哈希表实现而是拥有超过 30 种针对不同场景的专用变体并会根据如下因素自动选择合适的实现键的类型、预期的基数cardinality、所使用的聚合函数、以及其他查询特征。例如在 GROUP BY … count() 的场景中ClickHouse 会完全跳过内存池直接将计数值写入哈希表的单元格。在对小整数键8 位、16 位进行分组的查询中ClickHouse 会采用高度优化的 FixedHashMap这本质上是一个以键值为索引的数组。而这类针对性的优化正是本文的重点。尽管在通用的两级哈希表结构下合并步骤是并行执行的但在本次发布之前当聚合使用 FixedHashMap 时合并过程仍是单线程的。这就意味着那些对小整数字段在维度分析和类别分析中非常常见进行分组的查询之前无法受益于多线程的合并优化。25.11 新特性FixedHashMap 支持并行合并在 ClickHouse 25.11 中针对使用 8 位和 16 位小整数键的 GROUP BY 查询合并步骤现已实现并行化。虽然每个处理流仍各自构建一个 FixedHashMap但最终的合并过程现在可以由多个线程并行完成每个线程负责处理哈希表中不同的区域。示例按房产类型计算平均价格以下是一个基于 8 位键的查询示例用于计算英国房产价格数据集中不同房产类型的平均价格SELECT type, avg(price) AS price_avg FROM uk_price_paid GROUP BY typetype 列的数据类型为 Enum8terraced 1semi-detached 2detached 3flat 4other 0在 ClickHouse 内部以 8 位整数进行存储。在执行该查询时每个处理流会将部分聚合状态存储于一个 FixedHashMap 中——本质上是一个以键值为索引的数组。这种结构不仅具备极高的插入和查找效率更关键的是它允许多个合并线程在彼此互不冲突的键区间上并行工作从而避免了锁竞争问题。下方的三幅图展示了在一台拥有三个 CPU 核心的机器上三个处理流各自独立产生的部分 avg 状态ClickHouse 随后通过三个并行合并线程来整合这些部分状态。每个线程分配一个编号0 到 2仅处理对应编号的键位。例如线程 0 处理位置 0、3、6…线程 1 处理 1、4、7…线程 2 处理 2、5、8…。下图示意了三个线程以不同颜色标示如何对多个 map 中的对应条目进行合并在实际运行中所有的部分 map 都会合并为一个最终结果的 FixedHashMap。每个合并线程将其负责的键所对应的平均值写入该表。由于该设计确保线程间可安全并行写入不同部分而传统哈希表在插入时并不具备线程安全性因此无法实现类似的优化。性能提升本次优化对于需要执行复杂合并操作的聚合函数效果最为显著。在典型的 GROUP BY 查询中合并阶段只是整个执行流程的一部分其他环节还包括数据读取、表达式计算以及排序等。像 count、avg、max、min 这类简单聚合函数中合并阶段对整体查询时间的影响很小。而对于类似 uniqExact 这类会维护较大中间状态的聚合函数其在合并阶段的开销显著因此也最能从本次优化中获益。为了更直观地展示优化效果我们选择了 uniqExact 函数作为测试对象。它的中间状态会存储原始的唯一值或根据类型存储其哈希值合并时通过去重并集distinct union的方式完成。我们在一台 AWS EC2 m6i.8xlarge 实例32 核心、128 GB 内存上进行了基准测试使用了 gp3 类型的 EBS 存储卷16K IOPS、最高吞吐量 1000 MiB/s并执行了如下查询SELECT type, uniqExact(street) AS u FROM uk.uk_price_paid GROUP BY type ORDER BY u ASC;你可以按照文档说明自行创建表格并加载测试数据。https://clickhouse.com/docs/getting-started/example-datasets/uk-price-paid在 25.10 版本中三次运行中最快的一次在操作系统页面缓存已清空的前提下耗时为 0.143 秒5 rows in set. Elapsed: 0.159 sec. Processed 30.73 million rows, 100.09 MB (193.80 million rows/s., 631.22 MB/s.) Peak memory usage: 153.28 MiB. 5 rows in set. Elapsed: 0.143 sec. Processed 30.73 million rows, 100.09 MB (214.45 million rows/s., 698.48 MB/s.) Peak memory usage: 152.92 MiB. 5 rows in set. Elapsed: 0.148 sec. Processed 30.73 million rows, 100.09 MB (207.14 million rows/s., 674.66 MB/s.) Peak memory usage: 154.35 MiB.而在 25.11 中在相同测试条件下最快运行时间为 0.089 秒5 rows in set. Elapsed: 0.101 sec. Processed 30.73 million rows, 100.09 MB (302.84 million rows/s., 986.37 MB/s.) Peak memory usage: 113.11 MiB. 5 rows in set. Elapsed: 0.089 sec. Processed 30.73 million rows, 100.09 MB (344.56 million rows/s., 1.12 GB/s.) Peak memory usage: 112.69 MiB. 5 rows in set. Elapsed: 0.092 sec. Processed 30.73 million rows, 100.09 MB (335.41 million rows/s., 1.09 GB/s.) Peak memory usage: 112.61 MiB.最终结果为0.089 秒 对比 0.143 秒 —— 性能提升约 40%。此外如果在执行查询时启用追踪日志SETTINGS send_logs_level trace在 25.11 中可以清楚确认系统使用了并行合并路径。... AggregatingTransform: Use parallel merge for single level fixed hash map. ...总结来说所有基于小整数键的 GROUP BY 查询现在都能充分利用并行合并的能力从而实现进一步的性能加速。作为辅助索引的投影贡献者Amos Bird主索引是 ClickHouse 加速筛选查询的核心机制之一。通过将表的数据按排序键有序存储在磁盘上ClickHouse 能够维护一个稀疏索引从而快速定位相关数据范围。但由于这个索引依赖于表的物理排序方式因此每个表只能拥有一个主索引。为了提升那些筛选条件与主索引不匹配的查询性能ClickHouse 提供了“投影”功能 —— 这是以不同排序顺序维护的自动化隐藏表副本因此具备不同的主索引。这样的替代存储结构能够加快对特定列排序优化的查询。不过过去这项功能的缺点是较高的存储成本投影会在磁盘上复制整张基础表的数据。自 25.6 版本起ClickHouse 支持创建更轻量的投影它们的行为类似于辅助索引但无需复制完整的数据行。这些轻量投影只存储排序键和一个 _part_offset 指针指向基础表中的原始数据从而大幅降低存储开销。当查询条件匹配时ClickHouse 会将这种投影的主索引作为辅助索引来定位匹配行而实际数据仍从基础表中读取。多个轻量级投影可联合使用因此当查询包含多个过滤条件时所有符合条件的投影都能协同参与如果其中某个条件也匹配基础表的主索引那么主索引也会参与进来。在此之前这种机制仅能在 part 级别进行数据裁剪无法细化到 granule块标记级别。而在本次版本中基于 _part_offset 的投影已实现 granule 级裁剪真正具备辅助索引能力能够实现更精细的筛选大幅提升查询效率。为演示该特性我们再次使用英国房产成交价格数据集并定义包含两个基于 _part_offset 的轻量级投影的表结构by_time 和 by_town。CREATE OR REPLACE TABLE uk.uk_price_paid_with_proj ( price UInt32, date Date, postcode1 LowCardinality(String), postcode2 LowCardinality(String), type Enum8( terraced 1, semi-detached 2, detached 3, flat 4, other 0), is_new UInt8, duration Enum8(freehold 1, leasehold 2, unknown 0), addr1 String, addr2 String, street LowCardinality(String), locality LowCardinality(String), town LowCardinality(String), district LowCardinality(String), county LowCardinality(String), PROJECTION by_time ( SELECT _part_offset ORDER BY date ), PROJECTION by_town ( SELECT _part_offset ORDER BY town ) ) ENGINE MergeTree ORDER BY (postcode1, postcode2, addr1, addr2);接着我们按照文档说明加载数据https://clickhouse.com/docs/getting-started/example-datasets/uk-price-paid。下图展示了基础表及其两个轻量投影的大致结构① 基础表按 (postcode1, postcode2, addr1, addr2) 排序构成其主索引使得基于这些字段过滤的查询效率极高。② by_time 和 ③ by_town 投影只存储各自的排序键和 _part_offset 指针指向基础表中对应的数据避免重复存储。它们的主索引可作为辅助索引参与过滤操作从而加快按日期或城市字段过滤的查询。我们在 AWS EC2 m6i.8xlarge 实例32 核心128 GB 内存上进行测试使用 gp3 EBS16K IOPS最大吞吐 1000 MiB/s作为存储。本次查询将对 date 和 town 两列进行过滤。需要注意的是这两列并不属于基础表的主索引。我们首先在关闭投影支持的情况下运行该查询以获取基准性能数据。同时我们关闭了查询条件缓存和 PREWHERE以确保仅观察索引对数据裁剪的影响SELECT * FROM uk.uk_price_paid_with_proj WHERE (date 2008-09-26) AND (town BARNARD CASTLE) FORMAT Null SETTINGS use_query_condition_cache 0, optimize_move_to_prewhere 0, optimize_use_projections 0;三次测试中最快一次耗时 0.077 秒0 rows in set. Elapsed: 0.084 sec. Processed 30.73 million rows, 1.29 GB (363.92 million rows/s., 15.26 GB/s.) Peak memory usage: 129.07 MiB. 0 rows in set. Elapsed: 0.076 sec. Processed 30.73 million rows, 1.29 GB (406.96 million rows/s., 17.07 GB/s.) Peak memory usage: 129.29 MiB. 0 rows in set. Elapsed: 0.077 sec. Processed 30.73 million rows, 1.29 GB (398.51 million rows/s., 16.71 GB/s.) Peak memory usage: 129.27 MiB.该查询为全表扫描读取了约 3000 万行数据。随后启用投影支持再次执行相同查询SELECT * FROM uk.uk_price_paid_with_proj WHERE (date 2008-09-26) AND (town BARNARD CASTLE) FORMAT Null SETTINGS use_query_condition_cache 0, optimize_move_to_prewhere 0, optimize_use_projections 1; -- default value最快运行耗时 0.010 秒0 rows in set. Elapsed: 0.010 sec. Processed 16.38 thousand rows, 644.86 KB (1.60 million rows/s., 63.06 MB/s.) Peak memory usage: 4.89 MiB. 0 rows in set. Elapsed: 0.010 sec. Processed 16.38 thousand rows, 644.86 KB (1.69 million rows/s., 66.36 MB/s.) Peak memory usage: 4.88 MiB. 0 rows in set. Elapsed: 0.011 sec. Processed 16.38 thousand rows, 644.86 KB (1.54 million rows/s., 60.57 MB/s.) Peak memory usage: 4.89 MiB.结果显示0.077 秒对比 0.010 秒 —— 性能提升近 90%。此外本次仅扫描了约 1.6 万行而非之前的全部 3000 万行。通过 EXPLAIN 我们可以验证 ClickHouse 使用了两个投影的主索引作为辅助索引对基础表 granule 进行了裁剪EXPLAIN projections 1 SELECT * FROM uk.uk_price_paid_with_proj WHERE (date 2008-09-26) AND (town BARNARD CASTLE) SETTINGS use_query_condition_cache 0, optimize_move_to_prewhere 0, optimize_use_projections 1; -- default value┌─explain────────────────────────────────────────────────────────────┐ 1. │ Expression ((Project names Projection)) │ 2. │ Filter ((WHERE Change column names to column identifiers)) │ 3. │ ReadFromMergeTree (uk.uk_price_paid_with_proj) │ 4. │ Projections: │ 5. │ Name: by_time │ 6. │ Description: Projection has been analyzed... │ 7. │ Condition: (date in [14148, 14148]) │ 8. │ Search Algorithm: binary search │ 9. │ Parts: 5 │ 10. │ Marks: 7 │ 11. │ Ranges: 5 │ 12. │ Rows: 57344 │ 13. │ Filtered Parts: 0 │ 14. │ Name: by_town │ 15. │ Description: Projection has been analyzed... │ 16. │ Condition: (town in [BARNARD CASTLE, BARNARD CASTLE]) │ 17. │ Search Algorithm: binary search │ 18. │ Parts: 5 │ 19. │ Marks: 5 │ 20. │ Ranges: 5 │ 21. │ Rows: 40960 │ 22. │ Filtered Parts: 0 │ └────────────────────────────────────────────────────────────────────┘在 EXPLAIN 的第 10 行中by_time 投影通过其主索引首先将扫描范围缩小至 7 个 granule。每个 granule 包含 8192 行合计需扫描 7 × 8192 57,344 行如第 12 行所示。这些 granule 分布于 5 个数据 part 中第 9 行因此需读取 5 个对应的数据范围第 11 行。随后从第 14 行起by_town 投影的主索引被进一步应用从先前选出的 7 个 granule 中排除 2 个。最终引擎仅需扫描 5 个 granule分布于基础表的 5 个 part 中这些 granule 可能包含满足时间与城市双重过滤条件的行。为支持该优化ClickHouse 新增了两个参数max_projection_rows_to_use_projection_index如果预估读取投影的行数不超过该值则启用投影索引。min_table_rows_to_use_projection_index如果预估读取基础表的行数不小于该值则考虑使用投影索引。曾经ClickHouse 的每张表只能有一个主索引。现在它可以拥有多个“类主索引”每个都可在查询中充当辅助索引。当查询包含多个过滤条件时ClickHouse 会充分利用所有可用的索引为你带来更快的查询性能。使用投影加速 DISTINCT 查询贡献者Nihal Z. Miaji本次版本新增了另一项基于投影的优化功能。正如前文所述投影是 ClickHouse 自动维护的、以不同排序方式或预聚合布局存储的隐藏表副本旨在加速能够从特定数据组织中获益的查询。当查询执行时ClickHouse 会自动选择最具成本优势的数据路径无论是读取基础表还是投影以尽可能减少扫描的数据量。从本版本开始这一机制也可用于加速 DISTINCT 查询如果读取唯一值时从投影中读取的行数更少ClickHouse 将自动使用投影作为数据来源。一种常见的优化方式是为包含 DISTINCT 字段的查询创建一个以该字段为 GROUP BY 键的预聚合投影。这样投影虽然行数远少于原始表但仍包含所有唯一值因此非常适合用作 DISTINCT 查询的高效数据源。为演示这一优化我们再次使用英国房产成交数据集这次我们在表中定义了一个名为 sales 的投影CREATE TABLE uk.uk_price_paid_with_sales_proj ( price UInt32, date Date, postcode1 LowCardinality(String), postcode2 LowCardinality(String), type Enum8( terraced 1, semi-detached 2, detached 3, flat 4, other 0), is_new UInt8, duration Enum8(freehold 1, leasehold 2, unknown 0), addr1 String, addr2 String, street LowCardinality(String), locality LowCardinality(String), town LowCardinality(String), district LowCardinality(String), county LowCardinality(String), PROJECTION sales ( SELECT count(), sum(price), avg(price) GROUP BY county, town, district ) ) ENGINE MergeTree ORDER BY (postcode1, postcode2, addr1, addr2);随后我们按照文档说明加载了数据。这个投影本身并不是专门为 DISTINCT 查询设计的性能提升只是一个额外收获。其最初的设计目的是支持诸如统计英国热门区域或高价值地区等查询。对于 DISTINCT 加速而言投影的 SELECT 子句内容并不重要关键是去重字段包含在投影的 GROUP BY 中即可。需要注意的是GROUP BY 中的字段即使未出现在投影的 SELECT 子句中也依然会作为排序键存在并自动构建主索引用于高效过滤。在查询中依然可以选取这些字段SELECT type, sorting_key FROM system.projections WHERE (database uk) AND (table uk_price_paid_with_sales_proj) AND (name sales);┌─type──────┬─sorting_key──────────────────┐ 1. │ Aggregate │ [county,town,district] │ └───────────┴──────────────────────────────┘因此像 county、town 和 district 等字段的所有唯一值都已被包含在投影表中但行数远远少于基础表SELECT sum(rows) FROM system.projection_parts WHERE (database uk) AND (table uk_price_paid_with_sales_proj) AND (name sales) AND active;┌─sum(rows)─┐ 1. │ 9761 │ └───────────┘而随着后台的 part 合并操作持续执行这些投影中的行数还会逐步减少。对应的基础表包含超过 3000 万行数据SELECT count() from uk.uk_price_paid_with_sales_proj;┌──count()─┐ 1. │ 30729146 │ -- 30.73 million └──────────┘我们在 AWS EC2 的 m6i.8xlarge 实例32 核128 GB 内存上进行以下查询的基准测试存储使用的是 gp3 类型的 EBS16K IOPS最大吞吐 1000 MiB/s。首先我们在禁用投影功能的情况下对 town 列执行 DISTINCT 查询SELECT DISTINCT town FROM uk.uk_price_paid_with_sales_proj SETTINGS optimize_use_projections 0;三次运行中最快一次耗时为 0.062 秒1173 rows in set. Elapsed: 0.062 sec. Processed 30.73 million rows, 61.46 MB (494.48 million rows/s., 988.97 MB/s.) Peak memory usage: 2.11 MiB. 1173 rows in set. Elapsed: 0.064 sec. Processed 30.73 million rows, 61.46 MB (483.01 million rows/s., 966.02 MB/s.) Peak memory usage: 1.51 MiB. 1173 rows in set. Elapsed: 0.063 sec. Processed 30.73 million rows, 61.46 MB (487.14 million rows/s., 974.28 MB/s.) Peak memory usage: 1.20 MiB.这是一场完整的全表扫描处理了全部约 3000 万行数据。接着我们启用投影功能运行相同的查询SELECT DISTINCT town FROM uk.uk_price_paid_with_sales_proj SETTINGS optimize_use_projections 1; -- the default value1173 rows in set. Elapsed: 0.003 sec. Processed 9.76 thousand rows, 59.46 KB (3.29 million rows/s., 20.05 MB/s.) Peak memory usage: 472.22 KiB. 1173 rows in set. Elapsed: 0.003 sec. Processed 9.76 thousand rows, 59.46 KB (3.29 million rows/s., 20.01 MB/s.) Peak memory usage: 472.22 KiB. 1173 rows in set. Elapsed: 0.003 sec. Processed 9.76 thousand rows, 59.46 KB (3.37 million rows/s., 20.54 MB/s.) Peak memory usage: 472.22 KiB.最快运行耗时仅为 0.003 秒 —— 性能提升约 96%。这一次ClickHouse 并没有扫描基础表中全部 3000 万行数据来找出唯一的 town 值而是只读取了 9760 行投影数据因为这个路径的数据量显著更小。这正是投影的优势所在ClickHouse 会自动选择更高效、更具性价比的数据来源。argAndMin 和 argAndMax贡献者AbdAlRahman Gad在 ClickHouse 25.11 中新增了两个聚合函数argAndMax 和 argAndMin。我们仍然以英国房产价格数据集为例来展示它们的用法。假设我们希望查询 2025 年售价最高的房产可以写出如下 SQLSELECT max(price) FROM uk_price_paid WHERE toYear(date) 2025;┌─max(price)─┐ │ 127700000 │ -- 127.70 million └────────────┘但如果我们还想知道这套房产所在的城市town可以使用 argMax 函数来实现SELECT argMax(town, price) FROM uk_price_paid WHERE toYear(date) 2025;┌─argMax(town, price)─┐ │ PURFLEET-ON-THAMES │ └─────────────────────┘现在通过 argAndMax 函数我们可以一次性获取城市以及对应的最高价格SELECT argAndMax(town, price) FROM uk_price_paid WHERE toYear(date) 2025;┌─argAndMax(town, price)───────────┐ │ (PURFLEET-ON-THAMES,127700000) │ └──────────────────────────────────┘同理使用 argAndMin 函数可以查出价格最低的房产及其所在城市SELECT argAndMin(town, price) FROM uk_price_paid WHERE toYear(date) 2025;┌─argAndMin(town, price)─┐ │ (CAMBRIDGE,100) │ └────────────────────────┘这个最低价似乎有些异常 —— 2025 年居然有房产以 100 英镑售出这显然不太可能可能是数据质量问题。支持小数形式的 LIMIT 和 OFFSET贡献者Ahmed GoudaClickHouse 25.11 还支持了 LIMIT 和 OFFSET 的小数形式fractional limit / offset。继续使用房产价格数据集下面这个查询通过将 limit 设置为 0.1可以获取平均房价排名前 10% 的县countySELECT county, round(avg(price), 0) AS price FROM uk_price_paid GROUP BY county ORDER BY price DESC LIMIT 0.1;┌─county──────────────────────────────┬──price─┐ │ GREATER LONDON │ 431459 │ │ WINDSOR AND MAIDENHEAD │ 427476 │ │ WEST NORTHAMPTONSHIRE │ 417312 │ │ BOURNEMOUTH, CHRISTCHURCH AND POOLE │ 403415 │ │ SURREY │ 386667 │ │ BUCKINGHAMSHIRE │ 349638 │ │ CENTRAL BEDFORDSHIRE │ 343227 │ │ NORTH NORTHAMPTONSHIRE │ 338155 │ │ WOKINGHAM │ 332415 │ │ WEST BERKSHIRE │ 326481 │ │ BEDFORD │ 318778 │ │ OXFORDSHIRE │ 317245 │ │ HERTFORDSHIRE │ 317055 │ │ BATH AND NORTH EAST SOMERSET │ 304950 │ └─────────────────────────────────────┴────────┘此外我们还可以设置小数形式的 offset。例如如果我们希望从列表中间开始选取 10 个县按平均房价排序只需设置 offset 为 0.5 即可SELECT county, round(avg(price), 0) AS price FROM uk_price_paid GROUP BY county ORDER BY price DESC LIMIT 10 OFFSET 0.5;┌─county───────────────────┬──price─┐ │ TORBAY │ 170050 │ │ CITY OF NOTTINGHAM │ 169037 │ │ PEMBROKESHIRE │ 167116 │ │ WEST MIDLANDS │ 166271 │ │ LUTON │ 165885 │ │ NORTHUMBERLAND │ 164153 │ │ NORTHAMPTONSHIRE │ 164133 │ │ EAST RIDING OF YORKSHIRE │ 163334 │ │ ISLE OF ANGLESEY │ 162621 │ │ DERBYSHIRE │ 161320 │ └──────────────────────────┴────────┘EXECUTE AS user贡献者ShankarClickHouse 25.11 新增了 EXECUTE AS 功能允许当前用户以另一个用户的身份执行查询。这一功能非常适合于以下场景应用程序以某个用户身份登录系统但在实际操作中需要以其他配置用户的权限来执行任务以满足访问控制、资源限制、参数设置、配额管理以及审计合规等要求。我们可以通过如下命令将代理执行权限授权给指定用户GRANT IMPERSONATE ON user1 TO user2;之后便可通过以下方式代表其他用户执行单条查询EXECUTE AS target_user SELECT * FROM table;也可以为当前会话设置代理用户身份EXECUTE AS target_user;此后该会话中的所有查询都将以 target_user 的身份运行。征稿启示面向社区长期正文文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出图文并茂。质量合格的文章将会发布在本公众号优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至Tracy.Wangclickhouse.com