晚餐的时候我跟印度小哥聊了一个小时。Facebook 的 team 普遍人员精简，myrocks 5 个人，cassandra 7 个人，puma 也不到 10 个。人员精简意味着一切基础架构的开发都要 depends on user cases。譬如 rocksdb 的压缩 + cache 或者 zippydb（与 Pegasus 一样为了避免 HBase GC 而设计，底层 replication 用的 ZAB protocol），这就无法像 google spanner 或者 google f1 query 那样开发一套一统天下的系统。所以面对现实把，我们没那么多人。
当我们聊到 OLTP SQL workloads 的时候，小哥给我抛来一个问题：“Why do you care so much about SQL?”。整个 Facebook 有很多数据库，所谓 TP 的应用几乎全部在 NoSQL 之上，即使是 mysql 也是当作 KV 来用。整个 SQL 的使用都是 OLAP 的生态圈。
mysql 当作 KV store 来用，何解呢？Facebook 将 MySQL 集群统一管理在一个大的 UDB (u for universal) cluster，数据通过 sharding 来保证负载均衡和 scalability。如何进行查询呢？绝大多数查询采用的方案是通过 binlog 同步到下游 streaming processing system 来做近实时处理。所以 MySQL 只负责 point query 和 point insertion。没有事务，没有 join，也没有 aggregation。表 schema 下所有的列都被序列化成一个 blob 作为 value，主键作为 key，这就使得 mysql 成为一个 KV store。
落地后为了倒时差睡了一觉，晚上九点多钟洗漱完之后，我去 lobby bar 吃晚餐，遇到一个 Cassandra team 的印度小哥。
pegasus 这边一直在思考在数据库层面我们所需要做的事，从业务端来讲，一切都 works well，不管是 hash partition 还是 PacificA replication 我们都没有遇到特别 challenging 的需求，接口层面大家也都喜欢 KV API，许多业务从 MySQL 直接迁移到 Pegasus，将 relational schema 变平，将事务拆成多个 KV writes。我们也非常惊讶地发现其实许多业务并没有多行事务上强一致的需求（有单行事务的需求），有些业务甚至没有多副本强一致的需求，更多的业务需要的是分析能力，需要的是 ingestion 的 throughput，以及读写的 low latency。
所以从某种意义上讲，如今 Pegasus 应该做的是减少 replication 时候的开销，譬如将 PacificA 用 Raft 重写来减少 long-tail，去除 shared-log 以简化 write-path；另外针对 Analytical workload，我们可以尝试支持 single-partition-SQL，或者少量个数的 cross-partition SQL，这意味着我们能提供简单的 data exploration。如果业务上需要复杂的查询，可以考虑用 spark SQL，当然我们希望用户离 pegasus 更近，这样能方便我们优化。
所以关于 pegasus 是否应该成为 newsql，成为怎样的 newsql，我也一直存在困惑。
晚餐的时候我跟印度小哥聊了一个小时。Facebook 的 team 普遍人员精简，myrocks 5 个人，cassandra 7 个人，puma 也不到 10 个。人员精简意味着一切基础架构的开发都要 depends on user cases。譬如 rocksdb 的压缩 + cache 或者 zippydb（与 Pegasus 一样为了避免 HBase GC 而设计，底层 replication 用的 ZAB protocol），这就无法像 google spanner 或者 google f1 query 那样开发一套一统天下的系统。所以面对现实把，我们没那么多人。
当我们聊到 OLTP SQL workloads 的时候，小哥给我抛来一个问题：“Why do you care so much about SQL?”。整个 Facebook 有很多数据库，所谓 TP 的应用几乎全部在 NoSQL 之上，即使是 mysql 也是当作 KV 来用。整个 SQL 的使用都是 OLAP 的生态圈。
mysql 当作 KV store 来用，何解呢？Facebook 将 MySQL 集群统一管理在一个大的 UDB (u for universal) cluster，数据通过 sharding 来保证负载均衡和 scalability。如何进行查询呢？绝大多数查询采用的方案是通过 binlog 同步到下游 streaming processing system 来做近实时处理。所以 MySQL 只负责 point query 和 point insertion。没有事务，没有 join，也没有 aggregation。表 schema 下所有的列都被序列化成一个 blob 作为 value，主键作为 key，这就使得 mysql 成为一个 KV store。
对于 facebook 而言，唯一需要复杂并且低延时查询的场景其实是 social graph，但他们也并没有朝 newsql 的方向发展，而是针对业务场景专门优化，最终得到的系统是 TAO / DRAGON。 TAO: Facebook’s Distributed Data Store for the Social Graph
关于 Facebook 是否有使用开源项目例如 scylladb，cockroach，小哥回答 No，Facebook 关心 license 问题，不愿意倚赖外部系统。因为英语不好，一个小时的聊天没有说太多东西，反倒是让人家侃侃而谈，感觉比较尴尬。
Facebook 的系统在国外名气大，了解的人多，有些东西小哥可能默认我是知道的。譬如我问他知不知道 tidb，他也是黑人问号，说到 cockroach 才表示了解。而当他和我提到 puma，他也默认我了解过，其实我才刚知道不久。总的说起来下面几篇 "at facebook" 可谓是必读，很惭愧，聊天之前我看的不多：