李兆龙的博客-CSDN博客

原创对于侵犯我著作权无良人员的一个汇总

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。本作品 (李兆龙博文, 由李兆龙创作)，由李兆龙确认，转载请注明版权。文章目录引言汇总侵权证据[侵权人极致Linux内核] [被侵权著作 Linux 内核网络栈分析: 接收数据][侵权人极致Linux内核] [被侵权著作浅谈内存屏障，C++内存序与内存模型][侵权人极致Linux内核] [被侵权著作浅谈内存屏障，C++内存序与内存模型]引言只要我还在写博客，这篇文章我就会永远置顶。事情总是经历过才

2022-05-04 22:53:10 2740 8

原创从一到无穷大 #45：InfluxDB MCP Server 构建：从工程实践到价值重构

本文主要聚焦于构建 Influxdb MCP Server工程实践中遇到的问题，最终的结果展现，MCP的可能性展望，和MCP给工作生活带来的变化四个方面来讨论。

2025-04-13 20:30:27 1156 1

原创问题解决：glog中的LOG(INFO)与VLOG无法打印

具体的思路是大概了解下glog框架的原理，然后直接gdb去对比LOG(INFO)，VLOG和LOG(WARNING)，LOG(ERROR)执行路径的区别，确定没有打印的实际原因是什么。

2025-04-03 18:45:19 771

原创从一到无穷大 #44：AWS Glue： Data integration + Catalog

Glue官方的定义是Data integration cloud service，我第一次认识到Glue其实是因为其一统了AWS的元数据管理市场，可以作为Hive，Trio，Spark，Athena的Catalog模块用于查询服务，但在研究了论文后，发现Glue其实是一个巨无霸系统

2025-03-30 22:29:22 984

原创从一到无穷大 #43：Presto History Based Optimizer，基于PlanNode粒度统计的查询计划选择策略

HBO（History Based Optimizer）在 `Operator Node` 级别统计 `Query Execution Statistics`，并使用这些数据来预测相似查询的未来性能。HBO基于一种假设，即用户查询虽然复杂，但本质上是重复性的，一般使用使用模版生成相同结构的查询，这会造成查询计划基本一致，进而可以通过简易的方法找到之前的统计信息，然后用来执行精确的估计。

2025-02-03 14:26:41 1016

原创从一到无穷大 #42：ClickHouse - 极致工程优化的Lightning Fast Analytics

ClickHouse当今的流行程度毋庸置疑，可以说是业界极致工程优化的代名词，ClickHouse - Lightning Fast Analytics for Everyone这篇论文整体的基调也是这样，即真正意义上的`Industrial Paper

2025-01-19 20:38:44 944

原创从一到无穷大 #41：大浪淘沙：Presto演进史

从Presto的演进史我们可以看到一个顶级OLAP系统从零到一百的关键技术发展路径；可以看到一个顶级项目在公司内开疆拓土的历程；也可以看到一个合格的基础架构团队如何支持Meta以至于全球各大公司对于计算日益增长的需求。

2024-11-23 11:27:38 810

原创问题排查：C++ exception with description “getrandom“ thrown in the test body

确定是内核版本问题

2024-11-06 19:38:28 1294

原创从一到无穷大 #40：DB & AI 融合

像TDengine的TDgpt，使用LLM做时序预测和时序异常检测的实用主义是我所推崇的。

2024-11-03 18:20:43 533

原创从一到无穷大 #39：从 Vectorized Mode vs Code Gen 权衡特定场景执行引擎技术选型标准

Vectorized Mode vs Code Gen

2024-11-03 16:27:30 1032

原创从一到无穷大 #38：讨论 “Bazel 集成仅使用 Cmake 的依赖项目” 通用方法

Bazel集成仅使用Cmake的依赖项目的通用方法就是：把所有的文件打包成一个Target

2024-10-30 19:16:31 1093 1

原创从一到无穷大 #37 Databricks Photon：打响 Spark Native Engine 第一枪

The execution engine needs to provide good performance on the raw uncurated datasets that are ubiquitous in data lakes, and excellent performance on structured data stored in popular columnar file formats like Apache Parquet.

2024-10-19 16:18:41 1113

原创从一到无穷大 #36 Lindorm 宽表：东西互联，南北互联，AI一体

从Lindorm的发展上我们可以看到其在技术架构上明确的构想。即单模型独立提供基础服务，多模型间数据互联，对外提供导入导出服务，AI赋能。宽列作为Lindorm的基本盘，把这些核心理念发挥到了淋漓尽致。

2024-09-30 19:40:42 1390

原创从一到无穷大 #35 Velox Parquet Reader 能力边界

肉眼可见的，Velox社区还有大量的核心特性的贡献机会，虽然Meta的开源社区维护一直被人诟病，但是有Presto，Spark背书近五年到不必担心项目爆雷。

2024-09-22 14:43:35 1135

原创从一到无穷大 #34 从Columnar Storage Formats评估到时序存储格式的设计权衡

本篇文章从[3]，[11]入手，分析Parquet，ORC，TsFile的数据格式和索引格式，并通过论文的实验来观察其更适合哪些场景，最后从时序数据库场景入手，推断在设计权衡下现有的存储格式是否可以满足多样化的时序场景（Metric，logging，traceing），是否需要更多的额外索引，是否需要使用开源格式本身提供的辅助结构与功能。

2024-09-01 11:43:55 902

原创从一到无穷大 #33 ESTELLE，细分场景下优化的 Cloud Log Engine

高性能基础架构领域组件化发展意味着开发一个世界顶级的OLAP系统的门槛下降了一个台阶，开发团队应该将更多的人力投入到增值功能上去。其次因为SQL的对多种模态的统一，目前各个数据模型，系统间的核心差异化竞争应该集中在存储引擎针对于不同场景的索引定制化上，更彻底的就像阿里云盘古这样从用户态内核栈，定制服务器，定制加速硬件入手了。

2024-08-17 16:09:56 1185

原创从一到无穷大 #32 TimeCloth，云上的快速 Point-in-Time Recovery

在不同的数据模型下PITR拥有不同的目标，在这个基础上有不同的预期，从而诞生不同的解决方案。

2024-08-03 15:28:21 862

原创从一到无穷大 #31 Stand on the shoulders of those who came before and not on their toes，从DBMS演化看时序数据库市场发展方向

Michael Stonebraker祖师爷和Andrew Pavlo大师合作的《What Goes Around Comes Around... And Around...》发表在sigmod2024上，作为二十年一个轮回的综述文章，这篇文章宏观上很好的概括了过去两个十年内数据模型和查询语言的演进，并由此引出几种典型系统的消亡史。

2024-07-21 15:14:25 1013

原创从一到无穷大 #30 从阿里云盘古的屠龙之术看使用blob storage作为统一存储层的优势

存算分离中统一存储层最核心的驱动因素是吞吐量足够的情况下iops/gb足够高（低成本的情况下提供强大的性能）。这意味着要在高密存储机型下达到内存/cpu/网络吞吐/io吞吐的平衡，以此增加总体资源利用率，降低总成本。

2024-06-30 11:20:23 1353

原创从一到无穷大 #29 ByteGraph的计算，内存，存储三级分离方案是否可以通用化为多模数据库

本篇文章简单阐述两篇论文中的细节优化点，而后从架构入手对比现有部分时序数据库，多模数据库的架构，讨论其通用性，并探讨其扩展至多模数据库的可能性。

2024-06-22 21:29:53 1202

原创时序数据库是Niche Market吗？

时序数据库是Niche Market吗？

2024-06-10 16:08:49 992

原创问题排查： Goalng Defer 带来的性能损耗

性能优化之路道阻且长

2024-06-09 15:18:16 754

原创从一到无穷大 #28 从S3 Storage Node的轻量级形式化方法思考交付稳定存储产品的方法论

复杂系统的质量并非一蹴而就，而是遵循客观事实逐步演进的，稳定产品的测试最佳实践唯有Early、Continuous。

2024-05-30 11:20:43 1218

原创从一到无穷大 #27 从Amazon MemoryDB视角看稳定binlog带来的无限可能性

一个稳定的binlog可以带来无限的可能性，异地复制，PITR，流计算，构建稳定副本，存算分离等等

2024-05-18 22:54:01 1044

原创从一到无穷大 #26 Velox：Meta用cpp实现的大一统模块化执行引擎

在希望提供更强工程能力的计算引擎这点来看，项目开发之初接入Velox是正确的，此时最大的风险在于接入Velox最大的问题在于将自己的身家性命与快速迭代的可能交给了Velox和它的扩展API，当Velox无法支持时必要特性时就麻烦了。如果项目开发已经有段时间，此时愿意放弃自己团队已经投入很久的实现，而完全去使用Velox的c++实现作为单机runtime需要团队有一定的魄力，其次需要技术视野清晰，明确替换后的优势，一定需要ROI确定后再动手。

2024-05-05 21:18:56 1901

原创从一到无穷大 #25 DataFusion：可嵌入，可扩展的模块化工业级计算引擎实现

使用开源的执行引擎，所有玩家都将具备同 Snowflake 十年前独有的相同向量化执行能力，当存储层对每个人来说都是相同时（云盘/对象存储），区分 DBMS 产品的关键因素将会是那些难以量化的事物，比如稳定性，UI/UX 设计，查询优化等。好在并不是所有人存储层都一致，这意味着我们可以基于不同的场景设计不同的存储引擎，针对不同场景的存储引擎插件化以及智能化引擎参数调优，并佐以智能索引构建，cache等外部能力建设有竞争力的产品。

2024-05-02 20:40:01 2096

原创 InfluxDB SHOW SERIES语句按照什么顺序返回？

所以事实上show series返回的真正顺序遵循以下规则：1. 以measurement name排序2. 每个measuremnet基于serieskey内部的tag本身做排序

2024-03-06 23:11:11 1187

原创从一到无穷大 #24 LogReducer：讨论日志中热点的影响，识别及在线解决方法

LogReducer这篇文章阐述了微信的工程师如何通过在线和离线的方式减少日志对于程序的影响，我认为这篇文章的主要贡献分为以下两个方面：1. 对真实世界系统中的日志热点进行了系统研究，以揭示日志热点的影响、日志热点出现的原因以及如何解决这些问题2. 提出了一种基于eBPF的非侵入式、不依赖语言且高效的日志缩减框架，可自动识别日志热点并即时缩减日志，将日志热点的修复时间从平均 9 天缩短到测试中的 10 分钟

2024-02-18 17:41:54 1398 2

原创从一到无穷大 #23 《流计算系统图解》书评

现有的时序数据库只是实现了窗口仅为时间，无状态的，且非DAG的简化批处理系统，想以此替代流系统的全部份额基本不太现实，但是确实可以拿下其中部分收益，领域垂直公司需要故事去活下去，但是公有云需要关注业务上真正需要解决的问题，可见的未来我们的精力不会投入到完善时序的流计算系统中去。

2024-02-09 18:32:01 1514

原创从一到无穷大 #22 基于对象存储执行OLAP分析的学术or工程经验，我们可以从中学习到什么？

这篇文章于我而言最大的启发有四点：1. 基于对象存储执行分析需求的数据支持2. 基于对象存储执行分析需求的实践经验3. 使用对象调度器平衡数据检索和数据处理的资源使用，这种思路可以用在很多地方4. 基于对象存储性能存在下降（复杂的cache策略可以部分缓解，这里的研究很多），所以这里其实是成本和性能之间的权衡

2024-02-05 22:56:15 1203

原创从一到无穷大 #21 从基于多数据模型分析负载的Benchmark讨论多模数据库的发展方向

结论1：基于统一kv/宽表底座的多模型数据库是错误的方向，只有不同模型拥有不同的存储引擎才可以带来最大的综合性能优势结论2：哪怕是最优秀的存储引擎也只是在Trade-off，没有一种设计可以保证所有情况下的最优，所以需要智能化调优，并在项目选型之初选择最适合业务场景的引擎。结论3：完全独立的多个不同模型数据库对于联合分析的场景性能较差

2024-01-21 19:12:02 1749 7

原创从一到无穷大 #20 TimeUnion，适用于混合云的时序数据库？是玩具还是真实可用

工作上有一段攻坚时期，使得距离上一次写文章已经过了两个月，终于把拖了很久的《TimeUnion: An Efficient Architecture with Unified Data Model for Timeseries Management Systems on Hybrid Cloud Storage》学习完，并有时间记录一下，结合昨天的国足比赛，有一种吃了两颗屎味巧克力的感觉。

2024-01-14 19:47:16 1084

原创从一到无穷大 #19 TagTree，倒排索引入手是否是优化时序数据库查询的通用方案？

工程不是学术，对于一个新结构我们最关心的是这个特性的普适程度以及各种负载下的稳定性

2023-11-19 22:23:28 981

原创从一到无穷大 #18 时序数据库运营SLI思考

1. 读写差异巨大，读写的SLI设定应该分离，而且写入偶尔的失败是可预料的，频繁的告警没有意义2. 数据库内的写可能只是链路的一部分，我们希望跟踪全链路的写入指标3. 时间范围不同的查询告警指标的设定应该不是一致的4. 我们希望通过session做服务降级，也希望更好的理解业务层面的SLI，单独的查询分析不能cover这一场景

2023-10-15 18:00:16 593

原创从一到无穷大 #17 Db2 Event Store，A Purpose-Built IoT Database Engine

给我的感觉Db2 Event Store是一个私有的InfluxDB IOX，只不过没有InfluxDB IOX功能那么强大而已，其在写入流程，COS的利用，存储格式，以及架构上给我的感觉是后者好像也可以这么实现，只不过后者计算节点可以不挂盘，且控制面更为强大而已

2023-09-17 20:48:37 323

原创从一到无穷大 #16 ByteSeries，思考内存时序数据库的必要性

线上负载要求写入和实时查询高性能，时序数据库+缓存（内存时序数据库）可行。

2023-09-16 16:20:20 543

原创从一到无穷大 #15 Gorilla，论黄金26H与时序数据库缓存系统的可行性

缓存系统的高效存在前提，在满足前提的情况下可以接受缺陷便没有理由不引入缓存系统，但是具体影响因素需要仔细权衡，时序数据库只有常态极端场景下缓存有显著效果。

2023-09-15 22:04:04 635 1

原创从一到无穷大 #14 Online, realistic data, querying variable Time Series Database Benchmark

通用的时序数据库BenchMark是一个看似简单，实则极具挑战的问题。

2023-09-10 20:46:41 208

原创从一到无穷大 #13 How does Lindorm TSDB solve the high cardinality problem?

云原生时序数据库目前来看还是一个没有行业标准架构特殊数据库分支，各大云厂商都有自己的集群化实现，从谷歌的Monarch，阿里的Lindorm，腾讯的CTSDB，到垂直领域的InfluxDB IOX，TDengine，IotDB，都是各有的特点和适合的领域。终究不存在银弹，强如各大头部厂商也只是在做Trade off...

2023-09-05 23:56:37 660