- 博客(268)
- 收藏
- 关注
RSS订阅原创 【Clickhouse系列】join查询优化
在 ClickHouse 中使用 JOINs | ClickHouse DocsClickHouse Joins Under the Hood - Hash Join, Parallel Hash Join, Grace Hash Join
2025-06-22 12:05:48
199
原创 【Clickhouse系列】事务
ClickHouse 在 单分区块写入 场景提供完整的 ACID 保证，适用于实时分析场景的原子写入。分布式写入、缓冲区表等功能存在明确限制。实验性事务 扩展了多语句事务能力，但受限于环境与功能范围，暂不推荐生产关键系统使用。
2025-06-22 12:05:17
405
原创 【Clickhouse系列】索引
表设计时，ORDER BY子句（即主键）的选择至关重要。优先选择最常用作过滤条件（尤其是范围过滤）的1-N个列。良好的主键设计能解决大部分高效查询问题。当查询条件无法有效利用主键前缀或涉及高基数的非主键列时，考虑创建合适的跳数索引。优先尝试minmax（对有序类型）。对低基数的IN用set。对高基数的IN或字符串用。对LIKE/子串搜索用ngrambf_v1tokenbf_v1。使用查看查询是否使用了索引以及跳过了多少数据块。监控索引的存储开销和查询性能提升是否成正比。
2025-06-22 12:02:59
648
原创 【Clickhouse系列】表引擎
绝大多数生产分析场景选择MergeTree系列引擎(尤其是用于高可用)。根据数据特点（是否需去重、预聚合、处理变更）选择合适的变种。构建集群必须使用引擎作为访问入口。使用Kafka引擎 +组合实现实时数据流处理。使用表函数(fileurlmysql等) 或MySQLJDBC引擎进行联邦查询。小数据集、中间结果、维表考虑Memory或SetJoin。日志引擎 (LogStripeLogTinyLog或Memory。使用S3HDFS引擎或配合TTL将MergeTree数据移动到S3/HDFS。
2025-06-22 12:01:19
682
原创 【Clickhouse系列】增删改查：对比mysql
操作写入 (INSERT高吞吐，批量优先，异步落盘，延迟较高。分区高效。低延迟，实时，支持高并发小事务写入。删除 (DELETE极低效（异步Mutation），避免单行删除。分区删除高效。高效（行级），事务性，空间可复用。TRUNCATE极快。更新 (UPDATE极低效（异步Mutation），强烈避免。引擎模拟更新或分区替换更优。高效（行级），事务性，OLTP核心操作。查询 (SELECT聚合、扫描、大范围JOIN极快（列存、向量化、稀疏索引、MPP）。点查效率低，不擅长高并发小查询。
2025-06-22 12:00:29
877
原创 【Clickhouse系列】核心概念：对比Mysql
高压缩比、批量写入优化、时间分区。优化完善的JOIN执行与索引机制。亚秒级响应百亿级GROUP BY。列存+向量化聚合性能碾压行存。复杂多表关联查询（OLTP）强一致性事务与行级更新能力。频繁单行读写（如用户登录）高并发订单处理/账户更新。日志/时序数据存储与分析。基于B+树的毫秒级点查。
2025-06-22 11:59:44
533
原创 【Clickhouse系列】介绍：对比mysql
ClickHouse 是由俄罗斯Yandex公司开源的一个面向联机分析处理的高性能列式数据库管理系统。它专为需要超快查询速度和海量数据（PB级）扫描的实时分析场景而设计，尤其擅长大规模数据集的聚合查询。海量数据分析速度（聚合、扫描）、高吞吐写入数据压缩率实时性。它是数据仓库、实时BI、用户行为分析、日志分析、时序数据处理（IoT/监控）的理想选择。高并发事务处理（OLTP）、点查速度（通过索引）、数据强一致性（ACID）、复杂SQL支持生态成熟度。
2025-06-22 11:58:53
887
原创 【StarRocks系列】查询优化–Runtime Filter机制
Runtime Filter（RF），它是StarRocks提升Join查询性能的关键优化技术之一。
2025-06-21 19:02:59
708
原创 【StarRocks系列】join查询优化
表设计阶段，对于需要高频 Join 且数据量大的表，优先考虑使用相同的分区分桶策略。这是性能最高的 Join 方式。当无法 Colocate 时，确保事实表（左表）按 Join Key 分桶，并让 Join Key 包含分桶列。仅对小表使用 Broadcast Join。通过控制优化器选择 Broadcast 的阈值。这是加速大表 Join 的利器。通常保持默认开启即可，效果显著。定期是 CBO 发挥效力的基础。根据业务语义和数据特点选择INNER JOINSEMI JOINANTI JOIN等。
2025-06-21 17:13:23
584
原创 【StarRocks系列】分区分桶、前缀索引
StarRocks 采用分区+分桶的两级数据分布策略，将数据均匀分布各个 BE 节点。查询时能够有效裁剪数据扫描量，最大限度地利用集群的并发性能，从而提升查询性能。表中数据可以根据分区列（通常是时间和日期）分成一个个更小的数据管理单元。查询时，通过分区裁剪，可以减少扫描的数据量，显著优化查询性能。同一个分区中的数据通过分桶，划分成更小的数据管理单元。StarRocks 提供简单易用的分区方式，即表达式分区。此外还提供较灵活的分区方式，即 Range 分区和 List 分区。
2025-06-21 15:15:16
331
原创 【StarRocks系列】Update语句
解析 -> 定位主键 -> 分发 -> (BE)读原始数据 -> 改内存数据 -> 排序去重 -> 写新文件 -> 提交元数据 -> 异步回收旧文件。基于主键批量处理，读-改-写模式，写时复制（创建新文件），利用主键索引和排序去重保证效率与主键唯一性。单条 UPDATE 语句具有原子性和持久性，通过 MVCC 提供快照隔离级别的读一致性。社区版不支持多语句事务，企业版提供有限的多语句事务支持。
2025-06-21 15:06:48
937
原创 【StarRocks系列】事务
为了支持和 Apache Flink®、Apache Kafka® 等其他系统之间实现跨系统的两阶段提交，并提升高并发 Stream Load 导入场景下的性能，StarRocks 自 2.4 版本起提供 Stream Load 事务接口。• 原子性目标：设计目标是确保所有参与事务的 BE 节点上的临时数据都被清除，保证事务的原子性（要么全做，要么全不做）。StarRocks Stream Load 事务接口的回滚操作是针对事务涉及的所有 BE（Backend）节点的。update语句不支持事务。
2025-06-21 15:05:38
851
原创 【StarRocks系列】存算一体 vs 存算分离
数据存储与计算耦合在相同节点（BE），通过本地磁盘实现高速数据访问，建议配置大容量SSD缓存并监控命中率（可通过。，BE节点无状态化，实现存储与计算独立伸缩。弹性分析、混合负载、云原生数仓。以下是StarRocks。共享存储（S3/HDFS）存储计算耦合，扩缩容成本高。毫秒级（依赖缓存命中率）亚毫秒级（本地SSD）计算/存储独立扩缩容。
2025-06-21 12:25:03
604
原创 【StarRocks系列】架构、核心概念
通过以上设计，StarRocks在实时数仓、交互式分析、高并发报表等场景表现卓越，适合替代传统Hadoop+MPP混合架构。
2025-06-21 11:44:31
876
原创 【StarRocks系列】StarRocks vs Mysql
StarRocks 是一款高性能、全场景、分布式、实时分析型的数据库（MPP - 大规模并行处理）。它诞生于解决现代企业对海量数据进行快速、复杂分析的需求，尤其是在实时数据仓库、用户行为分析、日志分析、统一数仓等场景下表现卓越。这是最根本的区别，决定了后续所有架构和优化的方向。列存（分析优化） vs 行存（事务优化）。原生分布式、并行计算（MPP） vs 单机为主（通过主从复制扩展读）。擅长处理扫描大量数据、复杂计算的分析型查询 vs 擅长基于索引的点查和简单范围查询。
2025-06-21 11:32:53
1126
原创 【Nacos系列】服务发现：一致性实现
围绕进行实例存储，通过注册、心跳、订阅、推送+查询、主动健康检查实现动态管理。依赖心跳租约服务端健康检查兜底变更推送触发主动查询客户端定时轮询兜底共同保证客户端缓存最终与服务端状态一致。基于Distro 协议。通过数据分片与责任节点写请求路由/转发责任节点本地处理+异步复制任意节点本地读取定时校验和比对+差异数据拉取等机制，在保证高可用和分区容错的前提下，实现数据的最终一致性。这是 Nacos 服务发现高可用架构的核心。
2025-06-19 07:15:44
790
原创 【Nacos系列】配置存储、读取机制
内存（临时实例）+ 磁盘（持久实例）Raft日志重放 + 快照恢复。本地配置文件 + 长轮询监听。哈希分片（Distro协议）服务列表缓存 + 定时拉取。自动重新分片（节点宕机时）低（内存操作+异步复制）较高（需多数节点同步）
2025-06-19 07:11:45
675
原创 【Nacos系列】健康检查：临时实例 VS 持久实例
服务端主动探测（Server-Side Health Check）仅存储在内存（重启 Nacos Server 会丢失）默认类型（客户端 SDK 默认注册为临时实例）客户端主动发送心跳（Client Beat）动态扩缩容的云原生服务（如 K8s Pod）传统物理机/虚拟机部署的长期服务。✔️（必须通过 API/控制台）的服务发现机制中，实例分为。✔️（通过 API/控制台）必须手动调用 API 注销。持久化到磁盘（重启后保留）健康状态依赖服务端探活结果。，两者的核心区别在于。
2025-06-19 07:10:47
544
原创 【Nacos系列】一致性协议：Raft协议 & Distro协议
如果需要更深入的源码分析（如 Raft 日志复制实现），请告诉我！的对比解析，包含核心原理、实现差异和应用场景。服务发现（容忍短暂不一致）较高（本地写入+异步复制）低（无选举，简单异步同步）强一致性（线性一致性）较低（需多数节点同步）脑裂时部分分区不可用。配置管理（需强一致）高（选举、日志复制）
2025-06-19 07:09:58
920
原创 【Nacos系列】重要概念
的核心概念解析，涵盖配置管理、服务发现的关键术语和设计理念。根据场景选择一致性协议（配置强一致，服务发现最终一致）。定义服务的基本单位、实例信息、逻辑集群划分和环境隔离。标识配置的唯一性、分组管理、多租户隔离。客户端心跳、服务端探活。维护实例的可用性状态。
2025-06-19 07:08:21
1331
原创 【Nacos1.x】Nacos架构
服务发现核心模块，管理服务实例注册、心跳检测、健康状态等。数据持久化层，支持本地文件存储、MySQL 等数据库。配置管理核心模块，提供配置的发布、查询、监听等功能。集群管理模块，处理节点间通信、元数据同步和故障转移。的架构解析，包含核心模块、交互流程和关键设计思想。Nacos 架构分为。
2025-06-19 07:06:59
382
原创 http1.x VS http2.x 协议
• HTTP/1.1 是一个成熟的、广泛部署的基础协议，但它的文本格式、队头阻塞和缺乏压缩等问题限制了其性能。• HTTP/2 通过引入二进制分帧、强制多路复用、高效头部压缩、服务器推送和优先级控制，从根本上解决了 HTTP/1.1 的性能瓶颈。它在单一连接上实现高效并行，显著减少了延迟，提高了网络带宽的利用率，从而大大加快了现代复杂网页的加载速度。同时，主流浏览器要求在 HTTPS 上使用 HTTP/2，也提升了整体安全性。
2025-06-14 12:10:50
567
原创 【Netty系列】自定义协议
这个注释版本应该能帮助更好地理解Netty的工作机制和自定义协议的处理流程。实际开发中还需要添加超时处理、心跳机制等增强健壮性。
2025-06-01 10:30:00
312
原创 【Netty系列】自定义协议 vs HTTP协议
每个请求/响应需携带Header（约200-800字节）每次请求需TCP + SSL握手（如需HTTPS）利用Range头实现断点续传，浏览器直接支持。队头阻塞（HOL Blocking）仅需必要元数据（如4字节长度字段）1-5ms/消息（根据消息复杂度）直接读取长度字段 + 内容字节流。兼容性强，工具链成熟，便于调试。文本格式（JSON/XML）多路复用（Stream并行）高（文本解析、字符串处理）节省带宽，适合资源受限设备。二进制格式（紧凑无冗余）0.1-0.5ms/消息。低（二进制直接操作）
2025-06-01 10:30:00
736
原创 【Netty系列】实现HTTP协议
可根据具体业务需求扩展处理逻辑（如添加路由、参数解析、Session管理等）。聚合请求（HttpObjectAggregator）聚合响应（HttpObjectAggregator）解码响应（HttpResponseDecoder）编码响应（HttpResponseEncoder）解码请求（HttpRequestDecoder）编码请求（HttpRequestEncoder）
2025-05-31 15:33:01
466
原创 【Netty系列】消息编码解码框架
在网络通信中，消息的编码（序列化）和解码（反序列化）是核心环节，直接影响通信性能和开发效率。建议根据具体场景组合使用，例如：Netty + Protobuf 构建高性能网关，Kafka + Avro 实现流数据处理。人性化格式，适合配置文件。结构严谨，验证能力强。
2025-05-31 15:29:46
1026
原创 【Netty系列】Protobuf编码解码：客户端、服务端实现
这个示例完整展示了Netty与Protobuf的整合，实现了二进制数据的高效传输。实际生产环境中可根据需要添加心跳机制、重连策略等扩展功能。
2025-05-31 15:29:04
284
原创 【Netty系列】解决TCP粘包和拆包：LengthFieldBasedFrameDecoder
运行示例后，你将在控制台看到完整的请求-响应日志，验证粘包问题的解决效果。通过这种方式，Netty 会自动根据长度字段切分完整的数据包，长度字段值后的内容长度调整（若长度字段包含自身长度，需调整）长度字段占用的字节数（例如4字节表示int）解析后跳过的字节数（例如跳过长度字段本身）解决 TCP 粘包/拆包问题的。允许的最大帧长度（防止内存溢出）长度字段的起始偏移量（通常为0）
2025-05-31 11:19:45
458
原创 【Netty系列】TCP协议：粘包和拆包
问题是网络编程中常见的技术挑战，尤其是在基于流的传输协议（如TCP）中。通过合理设计协议，结合Netty的解码器，能高效解决粘包/拆包问题，确保数据的完整性和正确性。TCP协议传输数据时的。
2025-05-31 11:04:50
484
原创 【Netty系列】Reactor 模式 1
在示例中，主 Reactor 处理连接，子 Reactor 处理 I/O，多个客户端请求被高效分发到不同线程，最终由。：将网络连接的建立（Accept）与 I/O 读写（Read/Write）分离到不同的线程处理，避免单线程阻塞。下面通过一个服务端处理多请求的例子，详细解释 Reactor 模式在 Netty 中的实现。Reactor 模式是 Netty 高性能的核心设计思想之一，它通过。在 Netty 中，Reactor 模式的实现体现为。Reactor 模式的核心是。高（单线程处理多连接）
2025-05-30 17:20:30
1278
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人