原文：Map-reduce-merge: simplified relational data processing on large clusters

TL;DR

这篇文章为MapReduce模型增加了一步Merge，增强了Join的能力。原理如图。

原文：Cassandra: a decentralized structured storage system

可以参考Cassandra: structured storage system on a P2P network加深理解。

原文：Dremel: interactive analysis of web-scale datasets

TL;DR

这篇文章讲了两方面：

• 支持嵌套结构（Protocol Buffers）的列式存储（Google内部叫ColumnIO，可以参考开源的Parquet）。
• 并行执行架构。

能列式存储复杂的嵌套结构，极大地扩展了列存的应用范围。相比而言Dremel的并行执行架构不是很新颖。

原文：HadoopDB: An Architectural Hybrid of MapReduce and DBMS Technologies for Analytical Workloads

TL;DR

这篇文章在尝试结合MapReduce（Hadoop）与DBMS（PostgreSQL），取MapReduce的伸缩性与容错性、DBMS的性能。

实现：

• PostgreSQL作为Hadoop的DataNode。
• 将SQL翻译为MR任务，
• 通过兼容于JDBC的InputFormat将具体查询交给PostgreSQL执行。

结论：结合“A comparison of approaches to large-scale data analysis”的性能测试结果，HadoopDB相比Hadoop的分析性能好了一些，仍然达不到并行DBMS的水平，但验证了这个方向是有意义的。

HadoopDB将Hive中对数据源的scan换成了单节点PostgreSQL的查询，但仍然是传输数据而不是传输逻辑，且还是要物化中间结果，这些提高了容错性，但显著降低了性能。

原文：A comparison of approaches to large-scale data analysis

TL;DR

本文的背景是随着MapReduce的兴起，越来越多的人抛弃了传统的DBMS，直接使用MapReduce来做数据分析。本文对比了MapReduce（Hadoop）、Vertica（列存的并行DBMS）、DBMS-X（某个商用的行存的并行DBMS）的性能，指出并行RDBMS仍然有它的优势，不会被MapReduce取代。

并行DBMS的优势：

• 速度远快于MapReduce（热数据、有组织、强大的优化器）。
• 更少的代码（SQL的表达能力优势）。

劣势：

• 冷数据的加载时间长。
• 容错能力弱（任意子query失败都会导致 整个query失败）。
• 灵活性差，难以处理非关系型数据。

但本文指出，并行DBMS可以用更少的节点完成同样的任务，因此它不一定需要MapReduce那么强的容错能力。

原文：The Google File System

Introduction

GFS在设计上与传统的文件系统的几个区别：

• 分布式系统中错误是常态，因此持续监控、错误检测、容错机制、自动恢复都是必要的。
• 文件普遍非常大，达到GB级别以上，要重新审视对I/O操作和块大小的预期。
• 文件的追加写远多于覆盖写。

原文：OLTP Through the Looking Glass, and What We Found There

本文观点：随着硬件的发展和需求的变化，OLTP需要有新的设计；测量传统OLTP架构中各部分对性能的影响。

原文：Column-Stores vs. Row-Stores: How Different Are They Really?

TL;DR

本文主要观点：单纯把一个RowStore的存储格式换成ColumnStore，而不做其它优化，是达不到一个原生的ColumnStore的性能的。

本文针对的场景：星型的data warehouse，OLAP。

原文：The Chubby lock service for loosely-coupled distributed systems

TL;DR

本文idea：基于普通商用机构建出强一致的、高可用的分布式锁服务。

论证过程：

1. 如何实现强一致：Paxos。
2. 实现为库还是外部服务：库是侵入式的，应用接入困难；外部服务能把应用与Chubby解耦开。
3. 提供什么样的接口：类UNIX文件系统，建议式锁，尽可能降低应用接入和开发者的使用难度。
4. 针对读远多于写的使用场景，如何降低server负载：尽可能地cache，为了降低开发者的理解难度，使用一致性cache而不是基于TTL的cache。
5. 如何提高可用性：粗粒度锁，client在session过期后有一个grace period。
6. 未来可以做哪些改进：使用proxy和partitioning进一步提升服务规模。

随便看看

如何理解悖论「每个自然数都能被三十字以内的句子刻画（唯一描述）」？ - 灵剑的回答 - 知乎

从停机问题角度看待这个悖论，很有意思。

李白一辈子没怎么工作过，整日游山玩水，他的钱从哪儿来？ - 瞻云的回答 - 知乎

李白的生平。

《人民的名义》里的李达康是个好官吗？ - 佐伊23的回答 - 知乎

而李达康就是这样下指标、压任务、威胁下属、胡乱问责的人；基层公务员的视角；配合阅读今天通知明天要，只能是假报告。

31 省养老金已全部上调，你父母的退休工资比自己的在职工资高吗？ - 王海的回答 - 知乎

现阶段养老基金投资实践中，负债端最大的问题就是资金短期化，委托规模低，资产负债不匹配这三点。

揭阳食物中毒案中，为什么一碗河粉就能要人命？ - 厨房人类的文章 - 知乎

河粉、米粉不能久放，木耳不能泡太长时间，在外面吃少点这些东西。

一战后，德国人为什么觉得凡尔赛合约很屈辱？ - 塔列朗的回答 - 知乎

凡尔赛条约最大的失误，就是在侮辱德国的同时，没有伤害德国基本盘；讽刺的是，从事后看，凡尔赛合约在保留德国基本盘的同时，彻底摧毁了中欧及东南欧的强权，德国的战略态势相比于1914年反而还好了，中欧和东南欧没有了任何制衡力量。

一战后，德国人为什么觉得凡尔赛合约很屈辱？ - 路易-拿破仑的回答 - 知乎

凡尔赛条约的一个典型特点是它在政治上非常宽松，另一个特点是在经济惩罚上非常严厉。在赔款以外，凡尔赛体系在民族自决这一原则上的“真双标”也是“屈辱”说的一个助推剂。

如何评价电影《1917》？ - 电影榨汁的回答 - 知乎

《1917》中的行军路线、所属部队和战役历史。

计算机相关

浅谈OLAP系统核心技术点 - neoReMinD的文章 - 知乎

不错的科普，参考文献很棒。

作为 IT 行业的过来人，你有什么话想对后辈说的？ - 二律背反的回答 - 知乎

世界上没有技术驱动型公司；IT领域最重要的是经验而不是你有多聪明；能大规模商用的技术，都不需要智商；要有分享精神；现代管理学的精髓，就是让每个人都变得可替代；程序员工作创造的价值，至少一半是通过文档体现出来才对。

评论里对什么是技术驱动吵了起来。我的理解：做决定时，技术 or 市场，这条线该划在哪，无论什么公司，总会有一些决定偏向市场，程序员要接受这些决定，但这不妨碍我们尝试把线往技术那边推一推。

为什么shell脚本会有赋值语句的等号两边不能有空格这种奇葩语法? - 崔晨的回答 - 知乎

为什么shell脚本会有赋值语句的等号两边不能有空格这种奇葩语法? - 大宽宽的回答 - 知乎

shell的历史包袱；奇怪的设计一定是有原因的。

如何理解「面向对象编程的精髓在于将操作绑定在数据上」？ - 冯东的回答 - 知乎

data structure over procedure。

关于程序员的59条搞笑但却真实无比的编程语录 - 动力节点的文章 - 知乎

很多条很有道理。

Amazon’s website crashed as soon as Prime Day began

Amazon在2018年的一次崩溃。

如何看待sqlite作者放弃sqlite4的开发，说使用LSM Tree是一种失败？ - auxten的回答 - 知乎

重点关注其中Dr. D. Richard Hipp关于测试的看法。

100％MC / DC只是一个阈值，一个很高的阈值，一个易于测量且难以作弊的门槛。100％MC / DC 的主要好处之一并不是每个分支都经过测试，而是你必须编写如此多的测试，然后你就可以发现问题，并修复了许多你从未想过的问题。