LinkBench —— 社交图谱的数据库性能测试工具 已翻译 100%

Facebook社交图谱(social graph)和MySQL

MySQL作为公司基础架构的重要组件，早期就被Facebook用于存储像文章，评论，赞(likes)和页面之类的数据。

我们展现数据的一种方式就是社交图谱(social graph)，其中的对象如人(people),文章(posts),评论(comments)和页面(pages)是通过节点间不同的关系类型(模型)相互关联(图中的有向边-directed edges)的。不同的关联关系类型可以表示好友关系(friendship between two users)，用户喜欢某个对象的关系(user like another object)，还可以表示文章属主(ownership of post)关系等等。

为什么需要一款新的数据库性能测试工具？

过去的5到10年里，数据库领域又迎来了一次创新的高潮，像NoSQL和NewSQL已经成为了关系数据库(relational databases)的强力竞争者。与此同时硬件领域也在迅速地发展，固态存储设备和多核CPU已经成为业界的主流，能够为数据库提供巨大的性能提升。虽然我们已经能够通过让MySQL使用FlashCache来发挥出固态存储设备的优势，但是对基于固态存储的数据库优化还有很多工作要做，只有这样才能最大限度的发掘出硬件的性能。

这些改变对Facebook来说意味着什么？首先，它意味着在提高响应速度的同时我们有更多的机会来提高数据库基础设施(infrastructure)的效率，如降低能源的使用和硬件的开销。其次，它意味着我们需要对那些为解决Facebook负载而即将上线的数据库系统在适应性(suitability)和性能方面做一次系统的评估。

理解Facebook社交图谱的工作负载

我实习的大部分时间都用于分析社交图谱的数据和数据库查询时的负载，因而我提取了许多LinkBench可以用来对负载进行建模的关键参数。

LinkBench使用的一个特别重要的属性就是出度分布(out-degree distribution)，它控制图中每个节点的出度。出度在过去人们研究过的许多网络中像人际关系网或网页间的链接都遵循着幂律分布(power-law distributions)，这对于包含着各种节点类型的社交图谱也同样适用，如下图所示：

LinkBench也需要模拟在生产环境下对数据库的查询操作。Facebook网站和手机应用所使用的数据大部分来自于内存缓存，只有所有写操作和小部分读缓存缺失(cache-miss)情况下才会使用到MySQL。Facebook的工作负载主要是以大量的读操作为主的，因此即使在缓存命中率很高时，读操作缺失(read miss)也远大于写操作的。

下面的图展示了在生产环境中的某个数据库实例上不同的操作随着时间的推移而产生的负载变化。从图中可以看到对于边的操作和读操作，特别是边界扫描(edge range scan)会给系统带来极大的负担。举个边界扫描的例子，如“按最早到最近的时间顺序找出某个文章的所有评论”或“找出某个用户的所有好友”。

在真实环境中的MySQL实例上，对社交图谱的各种操作随着时间的变化图。百分比是按相对于当前实例上每秒平均操作数计算得来的。

• 通过对数据库中一些使用频繁(hot)、次频繁(warm)和大量不频繁(cold)的行(rows)进行实验，发现对节点(nodes)和边(edges)的读、写访问模式也都遵循着幂律分布(power-law distribution)。这对一般的数据库来说是正常的，但是由于Facebook使用了像memcached之类的内存缓存技术，我们不确定这是否对访问模式产生了影响。
• 图谱的结构对访问模式也有重要的影响：与高出度节点相连接的边通常比那些与低出度节点相连接的边会有更频繁的读、写操作。

LinkBench的架构

LinkBench被设计为可定制和可扩展的。它允许我们通过生成社交图谱的子集来模拟负载，这一特性对评估数据库处理特定关联类型的性能来说是至关重要的。例如，将以写为主(write-heavy)和读为主(read-heavy)的关联类型分别存储到不同的数据库后端是有必要的，因此我们可以针对每种类型做单独的性能测试。它也允许我们使用比较容易的方法来编写适配器从而支持新的数据库系统，因此我们可以比较出在相同的负载下它与MySQL的性能差异。

真正的性能测试工作是由LinkBench driver负责的，它是一个用于生成社交图谱和各种操作的Java程序。测试工作分为两个阶段：载入阶段(load phase)，会生成一个初始的图谱并载入(loaded in bulk)到数据库中;请求阶段(request phase)，许多请求线程会用各种操作对数据库进行并发访问。在请求阶段，各种操作的延迟和吞吐量都会被统计并给出报告。

测试结果

我们对打了Facebook补丁(请看http://www.facebook.com/MySQLatFacebook)的MySQL 5.1.53进行性能测试。我们在数据库中生成了12亿个节点和49亿条边，用MySQL标准的未经压缩的InnoDB表存储，占用了1.4TB硬盘空间。MySQL服务器拥有2个CPU，8+核心(8+ cores/socket)，144G内存，以及16kB读取延迟(read latency at 16kB)小于500μs的固态硬盘。