JanusGraph — 缓存（janusgraph caching）

• 2019 年 10 月 4 日
• 筆記

13.1 Caching

JanusGraph采用多层数据缓存来促进快速图形遍历。这里按照从JanusGraph事务中访问它们的顺序列出了缓存层。缓存越接近事务，缓存访问越快，内存占用和维护开销就越高。

13.2 Transaction-Level 缓存

在一个打开的事务中，JanusGraph维护着两个缓存：

• Vertex 缓存：缓存访问的顶点及其邻接列表（或其子集），以便后续访问在同一事务中明显更快。因此，该缓存加速了迭代遍历。
• Index 缓存：缓存索引查询的结果，以便后续索引调用可以从内存中提供，而不是调用索引后端，并且（通常）等待一次或多次网络往返。

这两者的大小由 transaction cache size决定。事务缓存大小可以通过缓存配置 cache.tx-cache-size配置。通过事务构建器graph.buildTransaction()打开事务并使用setVertexCacheSize(int)方法，可以根据每个事务打开一个事务。

13.2.1 Vertex 缓存

顶点缓存包含顶点及其在特定事务中检索的邻接列表的子集。此高速缓存中维护的最大顶点数等于事务高速缓存大小。如果事务工作负载是迭代遍历，则顶点缓存将显着加快速度。如果在事务中不再访问相同的顶点，则事务级缓存将没有区别。

请注意，堆上顶点缓存的大小不仅取决于它可以容纳的顶点数量，还取决于它们的邻接列表的大小。换句话说，具有大邻接列表（即许多入射边缘）的顶点将比具有较小列表的顶点消耗更多空间。

此外，请注意，修改后的顶点固定在缓存中，这意味着它们无法被驱逐，因为这将导致失去其更改。因此，包含大量修改的事务最终可能会使用大于配置的顶点缓存。

13.2.2 Index缓存

索引缓存包含在此事务的上下文中执行的索引查询的结果。随后的相同索引调用将从此缓存提供，因此明显更便宜。如果同一个索引调用在同一个事务中永远不会发生两次，则索引缓存没有区别。

索引高速缓存中的每个条目的权重等于，2 + result set size并且高速缓存的总权重不会超过事务高速缓存大小的一半。

13.3 Database Level 缓存

数据库级高速缓存在多个事务中并且在单个事务的持续时间之外保留邻接列表（或其子集）。数据库级缓存由数据库中的所有事务共享。它比事务级别缓存更节省空间，但访问速度也稍慢。与事务级别缓存相比，数据库级缓存在关闭事务后不会立即过期。因此，数据库级缓存显着加快了跨越事务的读取繁重工作负载的图形遍历。

第15章，配置参考列出了与JanusGraph的数据库级缓存有关的所有配置选项。此页面解释了它们的用法。

最重要的是，默认情况下，在当前版本的JanusGraph中禁用数据库级缓存。要启用它，请设置cache.db-cache=true。

13.3.1 缓存到期时间

性能和查询行为最重要的设置是通过配置的缓存过期时间cache.db-cache-time。缓存将保存图形元素最多几毫秒。如果元素到期，则在下次访问时将从存储后端重新读取数据。

如果只有一个JanusGraph实例访问存储后端，或者此实例是唯一修改图形的实例，则缓存过期可以设置为0，从而禁用缓存过期。这允许缓存无限期地保存元素（除非它们由于空间限制或更新而被逐出），这提供了最佳的缓存性能。由于没有其他JanusGraph实例正在修改图形，因此不存在保持过时数据的危险。

如果有多个JanusGraph实例访问存储后端，则应将时间设置为修改图形的另一个 JanusGraph实例与查看数据的JanusGraph实例之间允许的最长时间。如果所有JanusGraph实例都应立即看到任何更改，则应在分布式设置中禁用数据库级缓存。但是，对于大多数应用程序来说，特定的JanusGraph实例可以通过一些延迟看到远程修改。最大允许延迟越大，缓存性能越好。请注意，无论配置的缓存过期时间如何，给定的JanusGraph实例将始终立即看到自己对图形的修改。

13.3.2 缓存大小

配置选项cache.db-cache-size控制允许JanusGraph的数据库级缓存消耗多少堆空间。缓存越大，它就越有效。但是，较大的高速缓存大小可能导致GC过多和性能不佳。

高速缓存大小可以配置为运行JanusGraph的JVM可用的总堆空间的百分比（表示为0到1之间的小数）或绝对字节数。

请注意，缓存大小是指缓存专用的堆空间量。JanusGraph的其他数据结构和每个打开的事务都将占用额外的堆空间。如果其他软件层在同一JVM中运行，那么这些软件层也可能占用大量的堆空间（例如Gremlin Server，嵌入式Cassandra等）。保守堆内存估计。配置太大的缓存可能导致内存不足异常和过多的GC。

13.3.3 清理等待时间

当本地修改顶点（例如添加边）时，所有顶点的相关数据库级缓存条目都被标记为已过期并最终被逐出。这将导致JanusGraph在下次访问时从存储后端刷新顶点数据并重新填充缓存。

但是，当存储后端最终一致时，触发驱逐的修改可能尚不可见。通过配置cache.db-cache-clean-wait，缓存将在使用从存储后端检索的条目重新填充缓存之前至少等待这么多毫秒。

如果JanusGraph在本地运行或针对存储后端运行，以确保立即可见修改，则此值可以设置为0。

13.4 Storage Backend 缓存

每个存储后端都维护自己的数据缓存层。这些缓存受益于压缩，数据紧凑性，协调过期，并且通常在堆外维护，这意味着可以使用大型缓存而不会遇到垃圾收集问题。虽然这些缓存可能比数据库级缓存大得多，但它们访问速度也较慢。

如果转载此博文，请附上本文链接https://blog.csdn.net/csdn___lyy，谢谢合作~ 如果感觉这篇文章对您有所帮助，请点击一下“喜欢”或者“关注”博主，您的喜欢和关注将是我前进的最大动力！=.=