系统与基础设施adamdrake.com编辑精选
命令行工具能比 Hadoop 集群快得多（2014）
Command-line tools can be faster than a Hadoop cluster (2014)
2018 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Adam Drake 的一篇经典博文：作者用一个日志分析任务做对比，发现只用 grep、awk、sort、uniq 等命令行工具在一台机器上并行处理，比在 Hadoop 集群上跑等价的 MapReduce 作业快约 235 倍。文章的结论是：大多数所谓的“大数据”其实小到一台普通服务器就能轻松处理，上集群之前应该先量一量数据的规模和实际开销。
为什么经久不衰：它用一个简单、可复现的基准反复提醒人们：分布式系统自带巨大开销，单机加好工具往往更快、更省钱、也更好维护；在硬件越来越强的今天，这个道理比 2014 年更成立。
HN 评论精选
用约百分之一的成本达到同等的日志处理性能，说明时髦技术常被过度采用。
最近涌现的各种时髦技术，让这个标题里的结论不幸地对很多事情都成立。我们最近在公司讨论新的日志工具：要么用冗余的 Amazon EC2 集群加 ElasticSearch，每月 5 万美元；要么用两台大型裸金属服务器跑 rsyslog 加 grep，每月 400 美元。日志摄入和搜索性能大致相同。补充一下规模：那两台每台 200 美元的裸金属服务器配置是 2 颗 Intel Xeon 6 核 + 256GB 内存 + 15 块 10TB 7200 转硬盘。我们保留 30 天日志，每天处理 4-5TB。
fxtentacle查看英文原文
With all the Hipster tech being released recently, the headline statement holds true for a lot of things, unfortunately. We recently discussed new logging tools at work. It was either a redundant Amazon EC2 cluster with ElasticSearch for $50K monthly, or two large bare metal servers with rsyslog and grep for $400 monthly. The log ingestion and search performance was roughly the same... EDIT: To give everyone a sense of scale, those $200 each bare metal servers are 2x Intel Xeon 6-core + 256GB RAM + 15x 10TB 7200 rpm. We retain logs for 30 days and handle 4-5TB per day.
实测命令行与 Flink 性能相当，选工具应看具体场景而非迷信集群。
我在类似的数据集和任务上做了测试。单个 2.9GB 文件：rg 约 1.7 秒，sort --radixsort 约 5.9 秒，uniq -c 约 5.9 秒；而用 Apache Flink 的朴素实现耗时 13.97 秒。把同一数据集拆成 4 个文件后，命令行组合总耗时约 10.6 秒，Flink 为 12.7 秒。结论：这类工作负载下两种方式运行时间相当，命令行略占优势（对单纯过滤文本文件本就该如此），两边实现花的时间也差不多，各有适用场景。测试在 4 逻辑核的笔记本上本地完成。
maxmunzel查看英文原文
I did some testing on the same (kind of) dataset and task: First test: A single 2.9GB file time rg Result all.pgn | sort --radixsort | uniq -c 13 [Result ""] 1106547 [Result "0-1"] 1377248 [Result "1-0"] 1077663 [Result "1/2-1/2"] rg Result all.pgn 1.12s user 0.55s system 99% cpu 1.680 total sort --radixsort 3.87s user 0.37s system 71% cpu 5.911 total uniq -c 2.69s user 0.02s system 45% cpu 5.909 total Using Apache Flink and a naive implementation It took 13.969 seconds. Second test: same dataset, split between 4 files time rg Result chessdata/ | awk -F ':' '{print $2}' - | sort --radixsort | uniq -c 13 [Result ""] 1106547 [Result "0-1"] 1377248 [Result "1-0"] 1077663 [Result "1/2-1/2"] rg Result chessdata/ 1.70s user 0.97s system 42% cpu 6.292 total awk -F ':' '{print $2}' - 5.47s user 0.07s system 88% cpu 6.289 total sort --radixsort 4.13s user 0.42s system 43% cpu 10.559 total uniq -c 2.73s user 0.03s system 26% cpu 10.559 total Flink: 12.724s Conclusion: For this kind of workload, both approaches have comparable runtimes, even tough taco bell programming has the upper hand (as is should for simply filtering a text file). It took me about equally long to implement both. I think both approaches have their use case. I ran this locally on my Laptop with 4 logical cores.
单机优化到位后，分布式框架反而成了纯粹的负担。
我曾把一个纯 Python 的模拟改成 Cython。因为数据能放进 CPU 缓存，单机加速约 10000 倍（数值模拟嘛）。因为快太多，所有把它拆到多台服务器做 MapReduce 的代码都可以删掉——单机几个核跑几毫秒就够了。因为不再是 MapReduce 作业，我还能把它从 worker 队列里拿出来，直接在 Web 请求中处理。有时候值得退一步做点实验。
3pt14159查看英文原文
I once converted a simulation into cython from plain old python. Because it fit in the CPU cache the speedup was around 10000x on a single machine (numerical simulations, amirite?). Because it was so much faster all the code required to split it up between a bunch of servers in a map reduce job could be deleted, since it only needed a couple cores on a single machine for a ms or three. Because it wasn't a map-reduce job, I could take it out of the worker queue and just handle it on the fly during the web request. Sometimes it's worth it to just step back and experiment a bit.
工具用法上的小调整能带来数量级的性能差异。
最近我在按第二列（数值）排序一个 1000 万行的 CSV。过了一小时还没跑完，我上网查了一下，看到有人建议把要排序的字段放到第一列。一条 awk 命令就把列换过来了。用同样的 sort 命令、不指定字段再跑，12 秒完成。教训：一、小改动可能带来 3 个数量级以上的性能差异；二、多查 Google，比自己深挖每个工具的原理容易。
ikeboy查看英文原文
Recently was sorting a 10 million line CSV by the second field which was numerical. After an hour went by and it wasn't done, I poked around online and saw a suggestion to put the field sorted on first. One awk command later my file was flipped. Run same exact sort command on this but without specifying field. Completed in 12 seconds. Morals: 1. Small changes can have a 3+ orders of magnitude effect on performance 2. Use the Google, easier than understanding every tool on a deep enough level to figure this out yourself ;)
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选