F1 是起源于 Google AdWords 的分布式 SQL 查询引擎，跟底下的 Spanner 分布式存储搭配，开启了分布式关系数据库——所谓 NewSQL 的时代。我们今天说的是 F1 团队在 VLDB2018 上发的文章 F1 Query: Declarative Querying at Scale，它和之前我们说的 F1 几乎是两个东西。
F1 Query 是一个分布式的 SQL 执行引擎，现在大数据领域流行的 Presto、Spark SQL、Hive 等等，都可以算在这个范畴里。类似地，F1 Query 也支持对各种不同数据源的查询，既可以是传统的关系表、也可以是 Parquet 这样的半结构化数据。
Apache Spark 是当今最流行的开源大数据处理框架。和人们耳熟能详的 MapReduce 一样，Spark 用于进行分布式、大规模的数据处理，但 Spark 作为 MapReduce 的接任者，提供了更高级的编程接口、更高的性能。除此之外，Spark 不仅能进行常规的批处理计算，还提供了流式计算支持。
Apache Spark 诞生于大名鼎鼎的 AMPLab（这里还诞生过 Mesos 和 Alluxio），从创立之初就带有浓厚的学术气质，其设计目标是为各种大数据处理需求提供一个统一的技术栈。如今 Spark 背后的商业公司 Databricks 创始人也是来自 AMPLab 的博士毕业生。
在上一篇文章《处理海量数据：列式存储综述（存储篇）》 中，我们介绍了几种 Apache ORC、Dremel 等几种典型列式存储的数据组织格式。实践中，很多数据系统构建在 HDFS 等分布式文件系统之上，使用这些规范的格式保存数据，方便各方的业务进行分析查询。
本文将介绍若干个典型的列式存储数据库系统。作为完整的 OLAP 或 HTAP 数据库系统，他们大多使用了自主设计的存储方式，运行在多台机器节点上，使用网络进行通讯协作。
列式存储（Column-oriented Storage）并不是一项新技术，最早可以追溯到 1983 年的论文 Cantor。然而，受限于早期的硬件条件和使用场景，主流的事务型数据库（OLTP）大多采用行式存储，直到近几年分析型数据库（OLAP）的兴起，列式存储这一概念又变得流行。
总的来说，列式存储的优势一方面体现在存储上能节约空间、减少 IO，另一方面依靠列式数据结构做了计算上的优化。本文中着重介绍列式存储的数据组织方式，包括数据的布局、编码、压缩等。在下一篇文章中将介绍计算层以及 DBMS 整体架构设计。
免费 SSL 证书提供商 Let's Encrypt 去年承诺的 ACME v2 以及通配符证书（Wildcard Certificate）终于在 3 月 14 日正式发布了。ACME 全称“自动化证书管理环境”，用于自动验证域名所有权并颁发 SSL 证书；本次发布的新版 ACME v2 添加了通配符证书的支持，再也不用每次添加子域名都重新申请证书。
ACME v2 目前只有一种方案支持通配符证书的验证—— DNS-01 challenge，即：通过向域名添加一条 TXT 记录来证明用户对域名的所有权。一般只要提供了 Token 访问的 DNS 服务商都可以支持，例如 GoDaddy、CloudFlare、DNSPod 等。
F1/Spanner 的论文于 2012 年发表，至今仍是世界上最先进的、规模最大的分布式数据库架构，毫无疑问对现代数据库设计产生了深远影响。其最大的亮点莫过于 TrueTime API，凭借原子钟和 GPS 的加持在全球范围实现了单调递增的时间戳，从而达到外部一致性；其次则是验证了分布式 MVCC 的高性能实现，为业界指明一条发展方向。
不过，论文对存储层实现只作了模糊的阐述：原文中说到 tablet 的实现类似于 Bigtable（复用了不少 Bigtable 的代码），底层基于 Colossus —— 继承 GFS 的下一代分布式文件系统。可以确定的一点是，存储层要为 read-only 和 read-write 事务提供支持：
本文从 F1/Spanner 论文出发，结合开源实现 TiDB 和 CockroachDB，谈谈如何设计一个具备 ACID 事务存储层。本文假设读者阅读过原论文 Spanner: Google's Globally-Distributed Database。
最近程序员圈子悄悄流行起斯坦福的 CS 007: Personal Finance For Engineers 课程，每个人都应该有所了解。但在如何投资的问题上，课程并没有给出适合我国国情的操作建议。
在雪球潜水多年，其中有位大 V 近期出版了适合所有人的《指数基金投资指南》，读后收益良多，故将读书笔记分享到这里，备忘。
数据库的索引和机器学习里的预测模型其实有一些相似之处，比如 B 树是把 key 映射到一个有序数组中的某个位置，Hash 索引是把 key 映射到一个无序数组中的某个位置，bitmap 是把 key 映射成是一个布尔值（存在与否）。
这些事，似乎拿预测模型都是可以做的。Yes, but...B 树那是精确的映射关系，和预测模型能一样吗？
所以这就是本论文 NB 的地方了，以上的想法是可以实现的。实验表明，在某些数据集上，用 RM-Index 预测模型代替 B 树之类的数据结构，可以提升 70% 的速度、并节约相当可观的空间。
Sharding-JDBC 是由当当网推出的一款开源的分布式数据库中间件。它以 JDBC 的形式嵌入到应用程序中，无需额外部署。Sharding-JDBC 实现了分库分表、读写分离和分布式主键功能，并初步实现了柔性事务。
本文主要介绍 Sharding-JDBC 的事务处理。
Sharding-JDBC 由于性能方面的考量，决定不支持强一致性分布式事务。我们已明确规划线路图，未来会支持最终一致性的柔性事务。