TL;DR
这篇文章讲的是如何实现自己的“云原生”数据库，以及探索S3是否适合作为DB的共享存储。
S3的优点是安全、无需运维、按使用付费，缺点是访问延时高、使用廉价硬件可能会牺牲一致性（这里作者引用了Dynamo，不太确定Dynamo和S3的关系）、更新不保证顺序。
本文的贡献：
本文的目的是在保证可用性和资源利用率的前提下，探索如何将DB的性质尽可能多地搬到云上。
结论：显然只是一次实验，验证了使用S3作为共享存储的可行性，但实用性不高。如果换成EBS的话可能更好一些。它的PU queue有点像Bw-tree。
TL;DR
这篇文章是两位大佬（DeWitt和Stonebraker）对“MapReduce可以革掉传统的并行RDBMS的命”的论点的回击。
MapReduce对于DB社区而言：
（因此之后若干年大家用高度的热情将这两者又统一起来了）
原文：Megastore: Providing scalable, highly available storage for interactive services
TL;DR
Megastore结合了NoSQL的扩展性和RDBMS的便利性，支持局部的ACID、多datacenter间的无缝failover。
Megastore在每个datacenter有一个instance，数据存储在对应的Bigtable中，instance之间使用Paxos协调。
从性能指标来看读写延时有点高，平均在100ms以上。
TL;DR
FlumeJava是基于MapReduce的计算框架。它的特点：
（FlumeJava这套框架目前仍在被大量使用，但底下应该已经不是MapReduce了。）
原文：The End of an Architectural Era (It’s Time for a Complete Rewrite)
TL;DR
本文针对新硬件带来的新的趋势，提出了一种全新的OLTP DBMS，H-Store，可以大幅度提高传统的DBMS的性能。
传统的DBMS主要还是沿用System R的架构：
本文观点是在这套架构上小修小补已经不够了，我们需要全新的设计。
尤其是传统RDBMS想用一套系统满足全部需求的想法已经过时了。
H-Store针对OLTP场景，打破了上面这种架构，主要是充分利用大内存和多节点，结合对OLTP场景的若干假设，省掉log和lock相关的很多机制，从而大幅度提升了性能。
原文：SCOPE: Easy and Efficient Parallel Processing of Massive Data Sets
TL;DR
SCOPE是一种分布式批处理语言，将类SQL的脚本编译为可以运行在Cosmos平台上的分布式作业。
它的特点：
原文：Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks
TL;DR
Dryad是一个分布式批处理框架，相比MapReduce，它的特点是：
Dryad属于是底层框架，用户真正用到的还是上面的框架，类似于MapReduce和Sawzall的关系。
原文：Improving MapReduce Performance in Heterogeneous Environments
TL;DR
这篇文章讲的是如何优化Hadoop在异构环境下的任务调度性能。
任务调度的关键在于如何让长尾任务尽快完成。MapReduce会在最后阶段冗余运行长尾任务，Google的数据显示这么做能提升44%的任务响应速度。
Hadoop的调度策略是冗余运行最慢的任务，而这篇文章提出的LATE（Longest Approximate Time to End)策略则是找最可能最慢结束的任务。在异构环境下LATE可以让任务响应速度达到Hadoop原有策略的2倍。
TL;DR
Hive在MapReduce模型上实现了支持类SQL查询的数据仓库，它的改进点主要为：