更新日志

版本兼容性

JanusGraph 项目与图和大数据生态系统的其他部分以及所使用的存储和索引后端一起发展。下面是组件各个版本之间的版本兼容性。对于依赖的后端系统，通常也支持不同的次要版本。强烈建议在部署 JanusGraph 之前验证版本兼容性。

尽管 JanusGraph 可能与不再受支持的旧版本依赖项兼容，但用户请注意，运行不再受支持或更新的软件可能存在风险和安全隐患。请与软件提供商核实以了解其支持的版本。强烈建议用户使用最新版本的软件。

版本兼容性矩阵

当前支持

下面列出了所有当前支持的 JanusGraph 版本。

信息

您当前正在查看 JanusGraph 1.1.0 版本的文档页面。为确保以下信息是最新的，请仔细检查这是否不是文档的存档版本。

JanusGraph	存储版本	Cassandra	HBase	Bigtable	ScyllaDB	Elasticsearch	Solr	TinkerPop	Spark	Scala
1.1.z	2	3.11.z, 4.0.z	2.6.z	1.3.0, 1.4.0, 1.5.z, 1.6.z, 1.7.z, 1.8.z, 1.9.z, 1.10.z, 1.11.z, 1.14.z	6.y	6.y, 7.y, 8.y	8.y	3.7.z	3.2.z	2.12.z
1.0.z	2	3.11.z, 4.0.z	2.5.z	1.3.0, 1.4.0, 1.5.z, 1.6.z, 1.7.z, 1.8.z, 1.9.z, 1.10.z, 1.11.z, 1.14.z	5.y	6.y, 7.y, 8.y	8.y	3.7.z	3.2.z	2.12.z

信息

尽管 ScyllaDB 在 1.0.0 版本之前被标记为 N/A，但它实际上是使用 cql 存储选项支持的。唯一的区别是，从 1.0.0 版本开始，JanusGraph 正式支持使用 scylla 和 cql 存储选项的 ScyllaDB，并扩展了对 ScyllaDB 的测试覆盖。

终止生命周期

下面列出的 JanusGraph 版本已过时，将不再接收错误修复。

JanusGraph	存储版本	Cassandra	HBase	Bigtable	ScyllaDB	Elasticsearch	Solr	TinkerPop	Spark	Scala
0.1.z	1	1.2.z, 2.0.z, 2.1.z	0.98.z, 1.0.z, 1.1.z, 1.2.z	0.9.z, 1.0.0-preZ, 1.0.0	不适用	1.5.z	5.2.z	3.2.z	1.6.z	2.10.z
0.2.z	1	1.2.z, 2.0.z, 2.1.z, 2.2.z, 3.0.z, 3.11.z	0.98.z, 1.0.z, 1.1.z, 1.2.z, 1.3.z	0.9.z, 1.0.0-preZ, 1.0.0	不适用	1.5-1.7.z, 2.3-2.4.z, 5.y, 6.y	5.2-5.5.z, 6.2-6.6.z, 7.y	3.2.z	1.6.z	2.10.z
0.3.z	2	1.2.z, 2.0.z, 2.1.z, 2.2.z, 3.0.z, 3.11.z	1.0.z, 1.1.z, 1.2.z, 1.3.z, 1.4.z	1.0.0, 1.1.0, 1.1.2, 1.2.0, 1.3.0, 1.4.0	不适用	1.5-1.7.z, 2.3-2.4.z, 5.y, 6.y	5.2-5.5.z, 6.2-6.6.z, 7.y	3.3.z	2.2.z	2.11.z
0.4.z	2	2.1.z, 2.2.z, 3.0.z, 3.11.z	1.2.z, 1.3.z, 1.4.z, 2.1.z	不适用	不适用	5.y, 6.y	7.y	3.4.z	2.2.z	2.11.z
0.5.z	2	2.1.z, 2.2.z, 3.0.z, 3.11.z	1.2.z, 1.3.z, 1.4.z, 2.1.z	1.3.0, 1.4.0, 1.5.z, 1.6.z, 1.7.z, 1.8.z, 1.9.z, 1.10.z, 1.11.z, 1.14.z	不适用	6.y, 7.y	7.y	3.4.z	2.2.z	2.11.z
0.6.z	2	3.0.z, 3.11.z	1.6.z, 2.2.z	1.3.0, 1.4.0, 1.5.z, 1.6.z, 1.7.z, 1.8.z, 1.9.z, 1.10.z, 1.11.z, 1.14.z	不适用	6.y, 7.y	7.y, 8.y	3.5.z	3.0.z	2.12.z

发布说明

版本 1.1.0（发布日期：2024 年 11 月 7 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>1.1.0</version>
</dependency>

compile "org.janusgraph:janusgraph-core:1.1.0"

测试兼容性

• Apache Cassandra 3.11.10, 4.0.6
• Apache HBase 2.6.0
• Oracle BerkeleyJE 7.5.11
• ScyllaDB 6.2.0
• Elasticsearch 6.0.1, 6.6.0, 7.17.8, 8.15.3
• Apache Lucene 8.11.1
• Apache Solr 8.11.1
• Apache TinkerPop 3.7.3
• Java 8, 11

预打包分发版中安装的版本

• Cassandra 4.0.6
• Elasticsearch 7.14.0

变更

有关 1.1.0 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/27?closed=1

资产

• JavaDoc
• GitHub 发布
• JanusGraph zip
• 带有嵌入式 Cassandra 和 ElasticSearch 的 JanusGraph zip

升级说明

将顶点属性内联到复合索引中

将顶点属性内联到复合索引结构中可以提供显著的性能和效率优势。有关如何将顶点属性内联到复合索引中的信息，请参阅文档。

警告

兼容性重要注意事项。1. 向后不兼容：一旦 JanusGraph 实例采用此新模式功能，就不能回滚到 JanusGraph 的早期版本。模式结构中的更改与系统的早期版本不兼容。2. 迁移注意事项：用户必须仔细规划到此新版本的迁移，因为一旦使用了此功能，就没有自动化或手动回滚过程可以恢复到 JanusGraph 的旧版本。

BerkeleyJE 能够在 EnvironmentConfig 创建时覆盖任意设置

新的命名空间 storage.berkeleyje.ext 现在允许设置 JanusGraph 未直接公开的自定义配置。可能设置的完整列表可在 Java 类 com.sleepycat.je.EnvironmentConfig 中找到。所有配置值应指定为 String 并以与官方 sleepycat 文档中指定格式相同的方式进行格式化。示例：storage.berkeleyje.ext.je.lock.timeout=5000 ms

JSON 模式初始化器

为简化起见，JanusGraph 中已添加 JSON 模式初始化选项。请参阅文档以了解有关 JSON 模式初始化过程的更多信息。

批处理查询增强：引入 JanusGraphNoOpBarrierVertexOnlyStep

在以前的版本中，当执行一个可以从批处理查询优化（多查询）中受益的查询而没有用户定义的屏障步骤时，JanusGraph 默认会注入一个 NoOpBarrierStep。这种方法允许对边和属性进行批处理，而这些并不从多查询优化中获得优势。

从 JanusGraph 1.1.0 开始，此行为已得到改进。当未检测到屏障步骤时，系统现在会注入一个 JanusGraphNoOpBarrierVertexOnlyStep 而不是标准的 NoOpBarrierStep。此更改确保批处理仅应用于从批处理查询中受益的顶点，同时将边和属性排除在批处理过程之外。

如果用户在查询中明确定义了 .barrier() 步骤，系统将继续按预期使用 NoOpBarrierStep。

批处理查询优化现支持包含 drop() 步骤的遍历

从 JanusGraph 1.1.0 开始，已在 drop() 步骤中引入顶点删除的批处理优化，并默认启用。以前，对于包含至少一个 drop() 步骤的查询，任何批处理优化都将被跳过。但是，通过此更新，此类查询现在有资格进行批处理查询优化（多查询）。

请注意，对于包含至少一个 drop() 步骤的任何查询，LazyBarrierStrategy（TinkerPop 策略）都被禁用。

要禁用 drop() 步骤优化并保持以前的行为，用户可以设置以下配置

query.batch.drop-step-mode=none

关系延迟加载

新增了事务配置选项 lazyLoadRelations()，它为顶点的所有属性和边设置延迟加载。如果启用，则按需反序列化 ID 和值。
如果只从顶点读取某些类型的关系，启用此功能可以提高大规模读取操作的性能。
请参阅 GitHub PR #4343 中的性能比较。

文本谓词支持扩展到远程连接

以下文本谓词现在可以与远程连接一起使用

• textNotContains
• textNotContainsFuzzy
• textNotContainsPrefix
• textNotContainsRegex
• textContainsPhrase
• textNotContainsPhrase
• textNotFuzzy
• textNotPrefix
• textNotRegex

顶点突变优化

在添加新顶点或更新顶点属性方面进行了以下改进

• 改进了事务提交期间检测顶点变化的从 O(N) 到 O(1) 的操作；
• 优化了为新创建的顶点按键搜索属性；
• 优化了顶点更新期间以前的属性/边搜索；

有关更多信息，请参阅 GitHub PR #4292

版本 1.0.1（发布日期：2024 年 11 月 6 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>1.0.1</version>
</dependency>

compile "org.janusgraph:janusgraph-core:1.0.1"

测试兼容性

• Apache Cassandra 3.11.10, 4.0.6
• Apache HBase 2.5.8
• Oracle BerkeleyJE 7.5.11
• ScyllaDB 5.1.4
• Elasticsearch 6.0.1, 6.6.0, 7.17.8, 8.15.3
• Apache Lucene 8.11.1
• Apache Solr 8.11.1
• Apache TinkerPop 3.7.3
• Java 8, 11

预打包分发版中安装的版本

• Cassandra 4.0.6
• Elasticsearch 7.14.0

变更

有关 1.0.1 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/28?closed=1

资产

• JavaDoc
• GitHub 发布
• JanusGraph zip
• 带有嵌入式 Cassandra 和 ElasticSearch 的 JanusGraph zip

版本 1.0.0（发布日期：2023 年 10 月 21 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>1.0.0</version>
</dependency>

compile "org.janusgraph:janusgraph-core:1.0.0"

测试兼容性

• Apache Cassandra 3.11.10, 4.0.6
• Apache HBase 2.5.0
• Oracle BerkeleyJE 7.5.11
• ScyllaDB 5.1.4
• Elasticsearch 6.0.1, 6.6.0, 7.17.8, 8.10.4
• Apache Lucene 8.11.1
• Apache Solr 8.11.1
• Apache TinkerPop 3.7.0
• Java 8, 11

注意

Google Bigtable 已从该列表中移除，因为没有专门针对该后端的自动测试。然而，由于 Bigtable 的适配器仅使用 HBase 适配器，因此它也包含在 HBase 的测试中。

我们邀请任何对 Bigtable 存储适配器感兴趣的人通过贡献来帮助解决这个问题，以便 HBase 的测试也能自动为 Bigtable 执行。更多信息可以在此 GitHub 问题中找到：janusgraph/janusgraph#415。

预打包分发版中安装的版本

• Cassandra 4.0.6
• Elasticsearch 7.14.0

变更

有关 1.0.0 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/21?closed=1

资产

• JavaDoc
• GitHub 发布
• JanusGraph zip
• 带有嵌入式 Cassandra 和 ElasticSearch 的 JanusGraph zip

升级说明

TinkerPop 从 3.5.x 升级到 3.7.0（破坏性变更）

gremlin-driver 下的一些包已移至 gremlin-util 模块。这意味着您需要更改一些序列化器类名，例如从 org.apache.tinkerpop.gremlin.driver.ser.* 到 org.apache.tinkerpop.gremlin.util.ser.*。有关更多详细信息，请参阅此处。

GraphSON 序列化器已重命名，例如从 org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV3d0 到 org.apache.tinkerpop.gremlin.util.ser.GraphSONMessageSerializerV3。有关更多详细信息，请参阅此处。

字符串顶点 ID 支持（破坏性变更）

用户现在可以使用自定义字符串顶点 ID。请参阅自定义顶点 ID 文档。在此更改之前，JanusGraph 尽可能自动将字符串类型的 ID 转换为 long 类型。现在此自动转换已被禁用。如果您的顶点 ID 为 1234，g.V("1234") 将不再帮助您找到该顶点 - 您现在必须执行 g.V(1234)。

此功能对 GraphBinary 序列化器带来了破坏性变更。因此，使用 GraphBinary 序列化格式的用户必须一次性更新 JanusGraph 服务器和所有客户端，因为此更改是向后不兼容的。

警告

即使您不启用字符串顶点 ID 功能，只要您使用 GraphBinary 序列化器，您仍然会受到影响。

log4j 升级到版本 2

此更改需要新的 log4j 配置。您可以在 conf/log4j2-server.xml 中找到示例配置。由于配置格式已更改，我们清理了所有配置。这可能导致意外的新日志行。如果您看到任何不需要的日志行，请提出问题。

注意

Log4j 仅用于独立服务器部署和 JanusGraph 测试。

移除 cassandra-all 依赖

JanusGraph 仅为了某些 Hadoop 相关类而依赖 cassandra-all。我们将这些少量类移至新模块 cassandra-hadoop-util，以减少 JanusGraph 的依赖项。如果您使用 Cassandra 运行嵌入式 JanusGraph，则必须从 janusgraph-cql 中排除 cassandra-hadoop-util。

放弃对 HBase 1 的支持

我们正在放弃对 HBase 1 的支持。

放弃对 Solr 7 的支持

我们正在放弃对 Solr 7 的支持。

放弃对 Gryo MessageSerializer 的支持

TinkerPop 3.6.0 已放弃对 Gryo MessageSerializer 的支持，因此我们也不再在 JanusGraph 中支持它。GraphBinary 现在用作默认的 MessageSerializer。

移除对 JanusGraph 谓词旧序列化格式的支持

我们正在放弃对 JanusGraph 谓词旧序列化格式的支持。旧谓词序列化格式仅由早于 0.6 版本的客户端使用。此更改仅影响 GraphSON。

允许移除配置键

用户现在可以在 ConfiguredGraphFactory 的配置中删除配置键

ConfiguredGraphFactory.removeConfiguration("<graph_name>", Collections.singleton("<config_key>"))

或全局配置

mgmt = graph.openManagement()
mgmt.remove("<config_key>")
mgmt.commit()

请注意，上述命令应谨慎使用。例如，如果外部索引后端有混合索引，则不能用于删除它。

新索引管理

索引管理已进行大修，可实现正确的索引删除。模式操作 REMOVE_INDEX 已不再可用，并已被 DISCARD_INDEX 取代。有关更多详细信息，请参阅 索引生命周期文档。

直接索引查询的 totals 现在应用提供的偏移量和限制

直接索引查询（搜索总数计数，例如 vertexTotals、edgeTotals、propertyTotals 和 IndexProvider.totals 的直接执行）现在应用提供的 limit 和 offset。以前，提供的 limit 和 offset 被忽略。
例如，以前，如果存在 500 个索引元素，以下查询将返回 500

gremlin> graph.indexQuery("textIndex", "v.\"text\":fooBar").limit(10).vertexTotals()

现在，上述查询将返回 10 个元素，因为我们将结果限制为 10 个元素。offset 也适用。以前，如果存在 500 个索引元素，以下查询将返回 500

gremlin> graph.indexQuery("textIndex", "v.\"text\":fooBar").offset(10).vertexTotals()

现在，上述查询将返回 490 个结果，因为我们跳过了前 10 个元素的计数。
与 limit 一起提供的 offset 将首先应用 offset，然后应用 limit。
例如，如果存在 500 个索引元素，上述查询现在将返回 10 个元素

gremlin> graph.indexQuery("textIndex", "v.\"text\":fooBar").limit(10).offset(10).vertexTotals()

新逻辑类似地应用于直接索引查询 vertexTotals()、edgeTotals()、propertyTotals() 以及内部 JanusGraph 方法 IndexProvider.totals。

添加对 Java 11 的支持

JanusGraph 现在除了 Java 8 之外，还正式支持 Java 11。我们鼓励所有人更新到 Java 11。

注意

预打包分发版现在需要 Java 11。

默认启用批处理。配置变更。

query.batch 现在是一个配置命名空间。因此，以前的 query.batch 配置已被 query.batch.enabled 替换。query.limit-batch-size 配置选项已更改为 query.batch.limited。

query.batch-property-prefetch 已被一个更好的可配置选项取代。如果需要以前的行为，则使用 query.batch.has-step-mode = none 作为 query.batch-property-prefetch = false 的替代，或者使用 query.batch.has-step-mode = all_properties 作为 query.batch-property-prefetch = true 的替代。

当 query.batch.enabled 为 true 时，query.fast-property 对 values、properties、valueMap、propertyMap、elementMap 不再有影响。默认情况下，这些步骤配置为仅获取所需的属性（每个属性单独查询），但可以通过配置 query.batch.properties-mode 更改此行为。如果需要以前的行为，请使用 query.batch.properties-mode = required_properties_only 用于 query.fast-property = false，或者使用 query.batch.properties-mode = all_properties 用于 query.fast-property = true。

label 步骤现在默认使用预取策略。使用 query.batch.label-step-mode = none 禁用 label 步骤的预取优化。

批处理允许 JanusGraph 将一批顶点从存储后端一起获取，而不是单独请求每个顶点，这会导致大量的后端查询。然而，这在 JanusGraph 中默认是禁用的，因为这些批次可能远大于遍历所需的批次，因此对某些遍历会产生负面性能影响。这就是为什么在 JanusGraph 0.6.0 中添加了一种改进的批处理模式，该模式限制了从存储后端检索的这些批次的大小，称为有限批处理。因此，此模式解决了批次大小可能无限大的问题。这就是为什么我们现在默认启用此模式，因为大多数用户都将受益于此有限批处理。

如果您想继续在不进行批处理的情况下使用 JanusGraph，则必须通过将 query.batch.enabled 设置为 false 来手动禁用它。

如果使用有限批处理（query.batch.limited 设置为 true），可以通过使用 barrier() 步骤来限制批处理的大小。存在一种特殊策略，默认情况下会为某些步骤插入 barrier() 步骤，即 LazyBarrierStrategy。存在一个新的配置选项 query.batch.limited-size，用于配置当 LazyBarrierStrategy 未应用 .barrier 步骤且批处理查询部分不存在用户提供的屏障步骤时，批处理的默认屏障步骤大小。请注意，query.batch.limited-size 仅在 query.batch.limited 为 true（此版本中默认）时使用。

嵌套批处理兼容步骤的批处理注册对于 repeat 步骤已更改

以前，任何批处理兼容步骤（如 out、in、values 等）都会从所有 repeat 父步骤接收用于批处理注册的顶点，但仅限于多嵌套 repeat 步骤的开始（跳过其后续迭代注册）。在 JanusGraph 1.0.0 中，也使用多嵌套 repeat 步骤的后续迭代的批处理注册。

g.V(startVertexId).emit().
    repeat(__.repeat(__.in("connects")).emit()).
    until(__.loops().is(P.gt(2)))

在上面的示例中，多嵌套 repeat 情况将不会注册从内部 emit() 步骤返回的顶点用于下一个外部迭代，这将导致下一个外部迭代的 in("connects") 顺序调用。现在，行为已更改为注册这些顶点用于下一个子 repeat 步骤的开始。

该行为可以通过 query.batch.repeat-step-mode 配置选项控制。
如果首选旧行为，则应将 query.batch.repeat-step-mode 设置为 starts_only_of_all_repeat_parents。

但是，在事务缓存很小且 repeat 步骤遍历深度超过一级别的情况下，可能会导致某些顶点再次被重新获取，这意味着在不必要时浪费操作。在这种情况下，closest_repeat_parent 模式可能比 all_repeat_parents 更可取。
在 closest_repeat_parent 模式下，用于批处理注册的顶点将从最近的 repeat 步骤的开始以及最近的 repeat 步骤的结束（用于下一次迭代）接收。任何其他父 repeat 步骤都将被忽略。

ConfiguredGraphFactory 现在为 Elasticsearch 中的每个图创建单独的索引

如果 ConfiguredGraphFactory 与 Elasticsearch 作为索引后端一起使用，那么所有图都将使用相同的 Elasticsearch 索引（如果不同图使用相同的索引名称）。现在，如果模板配置中未提供 index.[X].index-name，则可以通过使用 graph.graphname 让 JanusGraph 动态创建索引名称。这与 CQL 键空间名称的情况完全相同。

不想使用此功能的用户可以简单地继续通过模板配置中的 index.[X].index-name 提供索引名称。

混合索引聚合优化

添加了一个新的优化，用于使用混合索引引擎计算聚合（min、max、sum 和 avg）（如果聚合函数遵循索引查询）。如果索引后端是 Elasticsearch，则使用 double 值来保存结果。因此，对大于 2^53 的长整数进行聚合是近似的。在这种情况下，如果需要精确结果，可以通过删除策略 JanusGraphMixedIndexAggStrategy 来禁用优化：g.traversal().withoutStrategies(JanusGraphMixedIndexAggStrategy.class)。

添加对 ElasticSearch 8 的支持

JanusGraph 现在支持 ElasticSearch 8。
注意，使用新的 ElasticSearch 8 索引，Mapping.PREFIX_TREE 映射不再适用于地理形状映射。
ElasticSearch 6、ElasticSearch 7、Solr、Lucene 仍然支持 Mapping.PREFIX_TREE。
对于 ElasticSearch，新增了地理形状映射 Mapping.BKD。
建议使用 Mapping.BKD 映射，因为它比 Mapping.PREFIX_TREE 具有更好的性能特性。
Mapping.BKD 的缺点是它不支持圆形。因此，JanusGraph 提供了 BKD 圆形处理器，用于将圆形转换为其他形状进行索引，但在存储级别使用圆形。有关圆形处理器的更多信息，请参阅配置命名空间 index.[X].bkd-circle-processor。
ElasticSearch 8 不允许使用 Mapping.PREFIX_TREE 映射创建新索引，但使用 Mapping.PREFIX_TREE 的现有索引在迁移后仍可在 ElasticSearch 8 中工作。请参阅 ElasticSearch 8 迁移指南。

添加对 ScyllaDB 驱动程序的支持

一个新的模块 janusgraph-scylla 提供了使用 ScyllaDB 驱动程序运行 JanusGraph 的能力，该驱动程序是 DataStax Java 驱动程序的优化分支版本，用于 ScyllaDB 存储后端。
对于 ScyllaDB 存储后端，您可以使用 janusgraph-scylla 或 janusgraph-cql（它是一个通用的 CQL 存储驱动程序实现）。也就是说，由于内部优化，建议对 ScyllaDB 使用 janusgraph-scylla（有关 ScyllaDB 驱动程序优化的更多信息可以在此处找到）。

请注意，janusgraph-cql 和 janusgraph-scylla 互斥。一次只使用一个模块，切勿在同一个类路径中同时提供这两个依赖项。有关如何使 scylla storage.backend 选项可用的更多信息，请参阅ScyllaDB 存储后端文档。

CQL ExecutorService 用途变更

以前，CQL ExecutorService 用于控制 CQL IO 操作和结果反序列化的并行性。从 JanusGraph 1.0.0 开始，CQL ExecutorService 现在仅用于 CQL 结果反序列化。所有 CQL IO 操作现在都使用内部异步方法。
默认池大小现在设置为 核心数乘以 2。此 ExecutorService 现在是强制性的，不能禁用。不建议更改默认 ExecutorService 核心池大小，因为默认值被认为是最佳的，除非用户希望人为地限制 CQL 结果反序列化作业的并行性。

KeyColumnValueStore 中新增了一个多查询方法（仅影响存储适配器实现）

KeyColumnValueStore 中添加了一个新方法 Map<SliceQuery, Map<StaticBuffer, EntryList>> getMultiSlices(MultiKeysQueryGroups<StaticBuffer, SliceQuery> multiKeysQueryGroups, StoreTransaction txh)，现在推荐用于具有多个切片查询的多查询（批处理查询）。
如果一个多查询在每次多查询执行中执行多个切片查询，则这些切片查询将按相同的键集分组，并且新的 getMultiSlices 查询将与相同键集的不同 SliceQuery 组一起执行。

请注意，如果存储未启用 multiQuery 功能，则不使用此方法。因此，无需实现它。

如果存储后端已启用 multiQuery 功能，则强烈建议覆盖默认（未优化）实现并优化此方法执行，以便在尽可能短的时间内为所有请求的键执行所有切片查询（例如，通过使用异步编程、切片查询分组、多线程执行或任何其他对相应存储适配器有效的技术）。

通过 CQL 存储后端新增了将多个切片查询分组在一起的可能性

从 JanusGraph 1.0.0 开始，CQL 存储实现现在将获取具有 Cardinality.SINGLE 属性的查询分组到同一个 CQL 查询中。此行为可以通过设置配置 storage.cql.grouping.slice-allowed = false 来禁用。

CQL 存储实现还能够将不同分区键的查询分组在一起，如果它们属于相同的令牌范围或相同的副本集（分组策略可通过 storage.cql.grouping.keys-class 配置选项获得）。此行为默认禁用，但可通过 storage.cql.grouping.keys-allowed = true 启用。请注意，启用键分组功能可能会增加相关查询的返回大小。这是因为 CQL 查询中的每一行（包含分组键）都需要返回其特定的键。此外，它可能会导致存储集群上的负载不平衡。然而，它减少了发送的 CQL 查询量，这在某些情况下可能会对吞吐量产生积极影响，并影响某些无服务器部署的定价点。我们建议在启用键分组（storage.cql.grouping.keys-allowed）之前对每个用例进行基准测试。

请注意，键分组（storage.cql.grouping.keys-allowed）只能用于支持 PER PARTITION LIMIT 的存储后端。因此，此功能不能用于 Amazon Keyspaces，因为它不支持 PER PARTITION LIMIT。

不同的存储后端可能还会对通过 IN 操作符（分组所需）提供的最大键数设置限制。需要确保 storage.cql.grouping.keys-limit 或 storage.cql.grouping.slice-limit 小于或等于通过存储后端提供的限制。在 ScyllaDB 上，可以使用 max-partition-key-restrictions-per-query 配置选项配置此限制（默认为 100）。在 AstraDB 端，需要通过 partition_keys_in_select_failure_threshold 和 in_select_cartesian_product_failure_threshold 阈值配置（https://docs.datastax.com/en/astra-serverless/docs/plan/planning.html#_cassandra_yaml）进行更改，这些配置默认为 20 和 25。

请参阅命名空间 storage.cql.grouping 下的其他属性来控制分组配置。

移除弃用的类/方法/功能

方法

• JanusGraphIndexQuery.vertices 替换为 JanusGraphIndexQuery.vertexStream
• JanusGraphIndexQuery.edges 替换为 JanusGraphIndexQuery.edgeStream
• JanusGraphIndexQuery.properties 替换为 JanusGraphIndexQuery.propertyStream
• IndexQueryBuilder.vertices 替换为 IndexQueryBuilder.vertexStream
• IndexQueryBuilder.edges 替换为 IndexQueryBuilder.edgeStream
• IndexQueryBuilder.properties 替换为 IndexQueryBuilder.propertyStream
• IndexTransaction.query 替换为 IndexTransaction.queryStream

类/接口

• EdgeLabelDefinition 类
• PropertyKeyDefinition 类
• RelationTypeDefinition 类
• SchemaContainer 类
• SchemaElementDefinition 类
• SchemaProvider 接口
• VertexLabelDefinition 类
• JanusGraphId 类
• AllEdgesIterable 类
• AllEdgesIterator 类
• ConcurrentLRUCache 类
• PriorityQueue 类
• RemovableRelationIterable 类
• RemovableRelationIterator 类
• ImmutableConfiguration 类

版本 0.6.4（发布日期：2023 年 10 月 14 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.6.4</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.6.4"

测试兼容性

• Apache Cassandra 3.0.14, 3.11.10
• Apache HBase 1.6.0, 2.2.7
• Oracle BerkeleyJE 7.5.11
• Elasticsearch 6.0.1, 6.6.0, 7.14.0
• Apache Lucene 8.9.0
• Apache Solr 7.7.2, 8.11.0
• Apache TinkerPop 3.5.7
• Java 1.8

变更

有关 0.6.4 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/26?closed=1

资产

• JavaDoc
• GitHub 发布
• JanusGraph zip
• 带有嵌入式 Cassandra 和 ElasticSearch 的 JanusGraph zip

升级说明

默认日志库更改为 Reload4j

预打包分发版中使用的默认日志库在 0.6.3 版本中意外从 Log4j 更改为 Logback。虽然此更改避免了 Log4j 的一些安全问题，但它也是一个意料之外的破坏性更改。这导致默认情况下仅记录警告，并且 Log4j 配置文件被忽略。为了修复此破坏性更改，在此版本中，我们将默认日志库更改为 Reload4j，它与 Log4j 完全兼容，但修复了 Log4j 的安全问题。这意味着 Log4j 配置文件将继续在此版本中工作。

请注意，这仅适用于 JanusGraph 0.6。JanusGraph 1.0.0 默认使用 Log4j2。

版本 0.6.3（发布日期：2023 年 2 月 18 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.6.3</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.6.3"

测试兼容性

• Apache Cassandra 3.0.14, 3.11.10
• Apache HBase 1.6.0, 2.2.7
• Oracle BerkeleyJE 7.5.11
• Elasticsearch 6.0.1, 6.6.0, 7.14.0
• Apache Lucene 8.9.0
• Apache Solr 7.7.2, 8.11.0
• Apache TinkerPop 3.5.5
• Java 1.8

注意

Google Bigtable 已从该列表中移除，因为没有专门针对该后端的自动测试。然而，由于 Bigtable 的适配器仅使用 HBase 适配器，因此它也包含在 HBase 的测试中。

我们邀请任何对 Bigtable 存储适配器感兴趣的人通过贡献来帮助解决这个问题，以便 HBase 的测试也能自动为 Bigtable 执行。更多信息可以在此 GitHub 问题中找到：janusgraph/janusgraph#415。

变更

有关 0.6.3 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/24?closed=1

资产

• JavaDoc
• GitHub 发布
• JanusGraph zip
• 带有嵌入式 Cassandra 和 ElasticSearch 的 JanusGraph zip

版本 0.6.2（发布日期：2022 年 5 月 31 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.6.2</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.6.2"

测试兼容性

• Apache Cassandra 3.0.14, 3.11.10
• Apache HBase 1.6.0, 2.2.7
• Google Bigtable 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0, 1.14.0
• Oracle BerkeleyJE 7.5.11
• Elasticsearch 6.0.1, 6.6.0, 7.14.0
• Apache Lucene 8.9.0
• Apache Solr 7.7.2, 8.9.0
• Apache TinkerPop 3.5.3
• Java 1.8

变更

有关 0.6.2 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/23?closed=1

资产

• JavaDoc
• GitHub 发布
• JanusGraph zip
• 带有嵌入式 Cassandra 和 ElasticSearch 的 JanusGraph zip

版本 0.6.1（发布日期：2022 年 1 月 18 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.6.1</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.6.1"

测试兼容性

• Apache Cassandra 3.0.14, 3.11.10
• Apache HBase 1.6.0, 2.2.7
• Google Bigtable 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0, 1.14.0
• Oracle BerkeleyJE 7.5.11
• Elasticsearch 6.0.1, 6.6.0, 7.14.0
• Apache Lucene 8.9.0
• Apache Solr 7.7.2, 8.9.0
• Apache TinkerPop 3.5.1
• Java 1.8

变更

有关 0.6.1 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/22?closed=1

资产

• JavaDoc
• GitHub 发布
• JanusGraph zip
• 带有嵌入式 Cassandra 和 ElasticSearch 的 JanusGraph zip

升级说明

GraphManager 更改为 JanusGraphManager

GraphManager 用于实例化图实例。JanusGraph Server 默认使用 TinkerPop 的 DefaultGraphManager，如果 JanusGraph Server YAML 配置文件中未指定其他 GraphManager。此 DefaultGraphManager 的行为在 TinkerPop 3.5.0 中发生了变化（JanusGraph 0.6.0 中包含），它在解析配置值的方式上发生了变化，使得无法提供逗号分隔的值，例如，为存储后端指定多个主机名。JanusGraphManager 没有此限制，这就是为什么它现在在 JanusGraph Server 配置文件中配置为 GraphManager。

[...]
channelizer: org.apache.tinkerpop.gremlin.server.channel.WebSocketChannelizer
graphManager: org.janusgraph.graphdb.management.JanusGraphManager
graphs: {
  graph: conf/janusgraph-berkeleyje-es.properties
}
[...]

但是，如果您想继续使用 DefaultGraphManager，那么您可以简单地再次删除该设置，或将其更改为以前默认的 TinkerPop GraphManager：org.apache.tinkerpop.gremlin.server.util.DefaultGraphManager。

版本 0.6.0（发布日期：2021 年 9 月 3 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.6.0</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.6.0"

测试兼容性

• Apache Cassandra 3.0.14, 3.11.10
• Apache HBase 1.6.0, 2.2.7
• Google Bigtable 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0, 1.14.0
• Oracle BerkeleyJE 7.5.11
• Elasticsearch 6.0.1, 6.6.0, 7.14.0
• Apache Lucene 8.9.0
• Apache Solr 7.7.2, 8.9.0
• Apache TinkerPop 3.5.3
• Java 1.8

变更

有关 0.6.0 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/17?closed=1

资产

• JavaDoc
• GitHub 发布
• JanusGraph zip
• 带有嵌入式 Cassandra 和 ElasticSearch 的 JanusGraph zip

升级说明

对 Amazon Keyspaces 的实验性支持

Amazon Keyspaces 是 Amazon 提供的无服务器托管式 Apache Cassandra 兼容数据库服务。有关更多详细信息，请参阅在 Amazon Keyspaces 上部署。

Configuration 对象的破坏性变更

在 JanusGraph 0.6.0 之前，Configuration 对象来自 Apache commons-configuration 库。为了符合 TinkerPop 更改，JanusGraph 现在使用 commons-configuration2 库。配置对象的典型用法是使用 ConfigurationGraphFactory 创建配置。现在您需要使用新的 configuration2 库。请参阅 commons-configuration 2.0 迁移指南获取详细信息。请注意，这很可能不会影响 gremlin 控制台的使用，因为新库是自动导入的，并且基本 API 保持不变。对于 java 代码使用，您需要导入 configuration2 库而不是旧的配置库。

Gremlin 服务器配置的破坏性变更

scriptEvaluationTimeout 已重命名为 evaluationTimeout。您可以参考 conf/gremlin-server/gremlin-server.yaml 获取示例。

Gremlin EventStrategy 使用的破坏性变更

如果您正在使用 EventStrategy，请注意现在您每次启动新事务时都需要注册它。一个示例可在 ThreadLocalTxLeakTest::eventListenersCanBeReusedAcrossTx 找到。有关此破坏性变更的更多背景信息，请参阅此 拉取请求。

默认禁用 smart-limit 并更改 HARD_MAX_LIMIT

在 0.6.0 之前，smart-limit 默认启用。它尝试在内部为每个以图为中心的查询（例如 g.V().has("prop", "value")）猜测一个小的限制，如果用户需要更多结果，它会再次使用更大的限制查询后端，并重复直到结果用尽或用户停止查询。然而，这与分页机制不同。所有中间结果将在下一轮中再次获取，使得整个查询成本高昂。更糟糕的是，如果您的数据后端不以一致的顺序返回结果，那么最终结果中可能会缺少一些条目。在 JanusGraph 能够充分利用后端提供的分页功能（例如 Elasticsearch 滚动）之前，建议关闭此选项。例外情况是当您有大量结果但只需要其中少数几个时，启用 smart-limit 可以减少延迟和内存使用。一个例子是

Iterator<Vertex> iter = graph.traversal().V().has("prop", "value");
while (iter.hasNext()) {
    Vertex v = iter.next();
    if (canStop()) break;
}

在 0.6.0 之前，即使禁用 smart-limit，JanusGraph 也会添加一个相当于 100,000 的 HARD_MAX_LIMIT，以避免一次获取太多结果。现在此限制是可配置的，默认情况下，它是 Integer.MAX_VALUE，可以解释为无限制。

添加对 Java 11 的实验性支持

我们已开始支持 Java 11。如果升级到 Java 11 后一切正常，我们希望收到反馈。

移除 LoggingSchemaMaker

schema.default=logging 选项不再有效。如果您正在使用 LoggingSchemaMaker，请同时使用 schema.default=default 和 schema.logging=true 选项以保持应用程序行为不变。

替换服务器启动脚本

gremlin-server.sh 被 janusgraph-server.sh 取代。janusgraph-server.sh 带来了一些新功能，例如使用 jvm.options 文件轻松配置 Java 选项。

jvm.options 文件包含一些基于 Cassandra 的 JVM 配置、Elasticsearch 和旧 gremlin-server.sh 的 JVM 默认配置。

JanusGraph 谓词的序列化已更改

此版本中 JanusGraph 谓词的序列化已更改，适用于 GraphSON 和 Gryo。最新版本的 JanusGraph Driver 要求 JanusGraph Server 版本为 0.6.0 及更高版本。服务器包含对旧驱动程序客户端的后备，以便更轻松地升级到 0.6.0 版本。这意味着可以先升级服务器，而无需同时更新所有客户端。但是，后备将在 JanusGraph 的未来版本中移除，因此客户端也应升级。

现在支持 GraphBinary

GraphBinary 是 TinkerPop 提供的一种新的二进制序列化格式，它取代了 Gryo，最终也将取代 GraphSON。GraphBinary 与语言无关，具有较低的序列化开销，从而提高了性能。

如果您想使用 GraphBinary，您必须在 gremlin-server.yaml 中的 serializers 关键字后添加以下内容。这将添加服务器端的支持。

    - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1, 
        config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
    - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1, 
        config: { serializeResultToString: true }}

注意

Java 驱动程序是目前唯一支持 GraphBinary 的驱动程序，请参阅使用 Java 连接到 JanusGraph。

注意

版本 1.0.0 将 org.apache.tinkerpop.gremlin.driver.ser 包下的所有内容移至 org.apache.tinkerpop.gremlin.util.ser 包。

注意

版本 1.0.0 对 GraphBinary 进行了破坏性更改，涉及地理形状序列化，请参阅1.0.0 更新日志以获取更多信息。

新索引选择算法

在版本 0.6.0 中，索引选择算法已更改。如果查询可能索引的数量足够小，新算法将执行穷举搜索以最小化需要查询的索引数量。默认限制设置为 10。为了保持旧的选择算法，无论可用索引如何，请将键 query.index-select-threshold 设置为 0。有关更多信息，请参阅 配置参考

移除 Cassandra Thrift 支持

Thrift 将在 Cassandra 4 中完全移除。所有弃用的 Cassandra Thrift 后端已在 JanusGraph 0.6.0 中移除。我们已在 JanusGraph 0.2.0 中添加了对 CQL 的支持，并且自 0.2.1 版本以来，我们一直鼓励用户从 Thrift 切换到 CQL。

这意味着以下后端已被移除：cassandrathrift、cassandra、astyanax 和 embeddedcassandra。仍在使用这些 Thrift 后端之一的用户应迁移到 CQL。我们的迁移指南解释了所需的步骤。但是，在与 JanusGraph 相同的 JVM 中运行嵌入式 Cassandra 的选项不再受 CQL 支持。

注意

Thrift 后端的源代码将移至 专用存储库。虽然我们不再支持它们，但如果用户因某种原因无法迁移到 CQL，他们仍然可以使用它们。

放弃对 Cassandra 2 的支持

随着 Cassandra 4 的发布，对 Cassandra 2 的支持将停止。因此，您应该升级到 Cassandra 3 或更高版本。

注意

Cassandra 3 及更高版本不支持紧凑存储。如果您已激活或从未更改 storage.cql.storage-compact=true 的值，则在升级过程中必须确保您的数据已正确迁移。

引入 JanusGraph 服务器启动类以替代 Gremlin 服务器启动

gremlin-server.sh 和 janusgraph.sh 配置为使用新的 JanusGraph 启动类。如果 gremlin-server.yaml 中未配置任何序列化器，此新类将引入一组默认的 TinkerPop 序列化器。此外，JanusGraph 将在新 JanusGraph 标题之后记录 JanusGraph 和 TinkerPop 的版本。

注意

如果您有自定义脚本来启动 JanusGraph，您可能希望将 Gremlin Server 类替换为 JanusGraph Server 类

org.apache.tinkerpop.gremlin.server.GremlinServer => org.janusgraph.graphdb.server.JanusGraphServer

放弃对 Ganglia 指标的支持

我们正在放弃 Ganglia，因为我们正在使用 Dropwizard 进行指标收集。Dropwizard 在最新主要版本中放弃了 Ganglia。

DataStax cassandra 驱动程序从 3.9.0 升级到 4.13.0

所有 DataStax cassandra 驱动程序指标现在默认禁用。要启用 DataStax 驱动程序指标，您需要提供要启用的会话级别指标和/或节点级别指标列表。要提供已启用指标列表，您可以使用以下配置选项：storage.cql.metrics.session-enabled 和 storage.cql.metrics.node-enabled。请注意，DataStax 指标仅在基本指标启用时启用（即 metrics.enabled = true）。有关其他 DataStax 指标配置，请参阅配置参考 storage.cql.metrics。

一个启用通过 JMX 报告某些 CQL 会话级别和节点级别指标的示例配置

metrics.enabled=true
metrics.jmx.enabled=true
metrics.jmx.domain=com.datastax.oss.driver
metrics.jmx.agentid=agent
storage.cql.metrics.session-enabled=bytes-sent,bytes-received,connected-nodes,cql-requests,throttling.delay
storage.cql.metrics.node-enabled=pool.open-connections,pool.available-streams,bytes-sent,cql-messages

有关可用会话级别和节点级别指标的完整列表，请参阅 DataStax 指标配置中的 advanced.metrics.session.enabled 和 advanced.metrics.node.enabled 部分。

由于驱动程序升级，以下 cql 配置选项已被移除

• local-core-connections-per-host
• remote-core-connections-per-host
• local-max-requests-per-connection
• remote-max-requests-per-connection
• cluster-name

storage.connection-timeout 现在用于控制与 CQL 存储的初始连接超时，而不是请求超时。请改用 storage.cql.request-timeout 配置请求超时。

应使用新的 cql 配置选项进行升级

• max-requests-per-connection
• session-name

storage.cql.local-datacenter 现在是强制性的，默认为 datacenter1。

有关 storage.cql 部分下的更多新 cql 配置选项，请参阅配置参考。

动态图绑定的自动配置

如果配置了 JanusGraphManager，将自动设置动态图绑定，请参阅 动态图。

注意

gremlin-server.yaml 配置中的破坏性更改。

以下类已被移除，必须由 TinkerPop 等效类替换

移除的类	替换类
org.janusgraph.channelizers.JanusGraphWebSocketChannelizer	org.apache.tinkerpop.gremlin.server.channel.WebSocketChannelizer
org.janusgraph.channelizers.JanusGraphHttpChannelizer	org.apache.tinkerpop.gremlin.server.channel.HttpChannelizer
org.janusgraph.channelizers.JanusGraphNioChannelizer	org.apache.tinkerpop.gremlin.server.channel.NioChannelizer
org.janusgraph.channelizers.JanusGraphWsAndHttpChannelizer	org.apache.tinkerpop.gremlin.server.channel.WsAndHttpChannelizer

Lucene 和 Solr 模糊谓词的破坏性变更

文本谓词 text.textFuzzy 和 text.textContainsFuzzy 已在 Lucene 和 Solr 索引后端中更新，以与 JanusGraph 和 Elastic 对齐。这些谓词现在检查查询长度以确定 Levenshtein 距离，而以前它们使用后端的默认最大距离 2。

• 对于一个或两个字符的字符串为 0（精确匹配）
• 对于三、四或五个字符的字符串为 1
• 对于超过五个字符的字符串为 2

更改矩阵

文本	查询	以前的结果	新结果
啊	啊	真	真
啊	ai	真	false
跳	跳	真	真
跳	哈	真	真
跳	箍	真	真
跳	呼呼	真	false
惊喜	惊喜	真	真
惊喜	惊奇	真	真
惊喜	惊喜	真	真
惊喜	惊喜	false	false

版本 0.5.3（发布日期：2020 年 12 月 24 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.5.3</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.5.3"

测试兼容性

• Apache Cassandra 2.2.10, 3.0.14, 3.11.0
• Apache HBase 1.2.6, 1.3.1, 1.4.10, 2.1.5
• Google Bigtable 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0, 1.14.0
• Oracle BerkeleyJE 7.5.11
• Elasticsearch 6.0.1, 6.6.0, 7.6.2
• Apache Lucene 7.0.0
• Apache Solr 7.0.0
• Apache TinkerPop 3.4.6
• Java 1.8

变更

有关 0.5.3 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/20?closed=1

资产

• JavaDoc
• GitHub 发布
• JanusGraph zip
• 带有嵌入式 Cassandra 和 ElasticSearch 的 JanusGraph zip

版本 0.5.2（发布日期：2020 年 5 月 3 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.5.2</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.5.2"

测试兼容性

• Apache Cassandra 2.2.10, 3.0.14, 3.11.0
• Apache HBase 1.2.6, 1.3.1, 1.4.10, 2.1.5
• Google Bigtable 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0, 1.14.0
• Oracle BerkeleyJE 7.5.11
• Elasticsearch 6.0.1, 6.6.0, 7.6.2
• Apache Lucene 7.0.0
• Apache Solr 7.0.0
• Apache TinkerPop 3.4.6
• Java 1.8

有关 0.5.2 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/19?closed=1

升级说明

ElasticSearch 索引存储名称缓存现已为每个存储的任何数量的索引启用

在 JanusGraph 0.5.0 和 0.5.1 版本中，所有 ElasticSearch 索引存储名称都进行了缓存以提高索引存储名称检索效率，并且如果每个索引存储有超过 50000 个索引可用，则禁用缓存。从 JanusGraph 0.5.2 版本开始，索引存储名称缓存不再限制为 50000，而是可以通过使用新添加的参数 enable_index_names_cache 来禁用。如果每个索引存储使用超过 50000 个索引，仍然建议禁用索引存储名称缓存。

版本 0.5.1（发布日期：2020 年 3 月 25 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.5.1</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.5.1"

测试兼容性

• Apache Cassandra 2.2.10, 3.0.14, 3.11.0
• Apache HBase 1.2.6, 1.3.1, 1.4.10, 2.1.5
• Google Bigtable 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0, 1.14.0
• Oracle BerkeleyJE 7.5.11
• Elasticsearch 6.0.1, 6.6.0, 7.6.1
• Apache Lucene 7.0.0
• Apache Solr 7.0.0
• Apache TinkerPop 3.4.6
• Java 1.8

有关 0.5.1 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/18?closed=1

升级说明

分布式包分为两个版本

分发包的默认版本不再包含 janusgraph.sh。这包括 Cassandra 和 Elasticsearch 的打包版本。如果您想要 janusgraph.sh，则必须下载带有后缀 -full 的分发版。

发布时分发的 Gremlin Server 默认使用内存存储后端和无搜索后端

通过 bin/gremlin-server.sh 启动时，Gremlin Server 默认配置为内存存储后端和无搜索后端。
您可以通过提供相应配置文件的路径作为第二个参数来为另一个存储后端和/或搜索后端提供配置（./bin/gremlin-server.sh ./conf/gremlin-server/[...].yaml）。

版本 0.5.0（发布日期：2020 年 3 月 10 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.5.0</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.5.0"

测试兼容性

• Apache Cassandra 2.2.10, 3.0.14, 3.11.0
• Apache HBase 1.2.6, 1.3.1, 1.4.10, 2.1.5
• Google Bigtable 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0
• Oracle BerkeleyJE 7.5.11
• Elasticsearch 6.0.1, 6.6.0, 7.6.1
• Apache Lucene 7.0.0
• Apache Solr 7.0.0
• Apache TinkerPop 3.4.6
• Java 1.8

有关 0.5.0 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/13?closed=1

升级说明

分布式包已重命名

分发版不再带有后缀 -hadoop2。

重新排序 Hadoop 依赖

Hadoop 现在是受支持后端的依赖项。因此，MapReduceIndexJobs 现在分为不同的类

旧功能	新功能
MapReduceIndexJobs.cassandraRepair	CassandraMapReduceIndexJobsUtils.repair
MapReduceIndexJobs.cassandraRemove	CassandraMapReduceIndexJobsUtils.remove
MapReduceIndexJobs.cqlRepair	CqlMapReduceIndexJobsUtils.repair
MapReduceIndexJobs.cqlRemove	CqlMapReduceIndexJobsUtils.remove
MapReduceIndexJobs.hbaseRepair	HBaseMapReduceIndexJobsUtils.repair
MapReduceIndexJobs.hbaseRemove	HBaseMapReduceIndexJobsUtils.remove

注意

现在，您可以轻松支持任何后端。

警告

Cassandra3InputFormat 替换为 CqlInputFormat

ElasticSearch：从 6.6.0 升级到 7.6.1 并放弃对 5.x 版本的支持

ElasticSearch 版本已更改为 7.6.1，该版本移除了对 max-retry-timeout 选项的支持。因此，JanusGraph 中不再提供此选项。用户应注意，默认情况下，JanusGraph 为 ElasticSearch 7.y 设置的最大开放滚动上下文数量为 2147483647，参数为 setup-max-open-scroll-contexts。此选项可以在 ElasticSearch 中手动禁用和更新，但您应该注意，ElasticSearch 从版本 7 开始的默认限制是 500 个开放上下文，这很可能在正常使用 JanusGraph 和 ElasticSearch 的情况下达到。默认情况下，ElasticSearch 版本 7 中禁用了弃用的映射。如果您正在将 ElasticSearch 索引后端从较低版本升级到版本 7，建议重新索引您的 JanusGraph 索引，以避免使用映射。如果您无法重新索引您的索引，您可以将参数 use-mapping-for-es7 设置为 true，这将告诉 JanusGraph 使用 ElasticSearch 版本 7 的映射类型。由于放弃了对 5.x 版本的支持，不再支持弃用的多类型索引。JanusGraph 不再支持参数 use-deprecated-multitype-index。

BerkeleyDB

BerkeleyDB 存储配置了 SHARED_CACHE 以获得更好的内存使用。

默认日志位置已更改

如果您使用 janusgraph.sh 启动实例，默认日志记录已从 log 更改为 logs

内存后端移至专用模块

内置的内存后端已移至专用模块。在测试中使用的用户必须明确将其声明为依赖项

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-inmemory</artifactId>
    <scope>test</scope>
    <version>0.5.0</version>
</dependency>

implementation 'org.janusgraph:janusgraph-inmemory:0.5.0'

版本 0.4.1（发布日期：2020 年 1 月 14 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.4.1</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.4.1"

测试兼容性

• Apache Cassandra 2.2.10, 3.0.14, 3.11.0
• Apache HBase 1.2.6, 1.3.1, 1.4.10, 2.1.5
• Google Bigtable 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0
• Oracle BerkeleyJE 7.5.11
• Elasticsearch 5.6.14, 6.0.1, 6.6.0
• Apache Lucene 7.0.0
• Apache Solr 7.0.0
• Apache TinkerPop 3.4.4
• Java 1.8

有关 0.4.1 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/15?closed=1

升级说明

TinkerPop：从 3.4.1 升级到 3.4.4

在同一查询中向新顶点属性添加多个值，且没有明确定义的类型（即使用 Automatic Schema Maker 创建属性类型），则如果 VertexProperty.Cardinality 与 VertexProperty.Cardinality.single 不同，则每次调用都需要明确使用 VertexProperty.Cardinality（仅适用于定义属性的第一个查询）。

版本 0.4.0（发布日期：2019 年 7 月 1 日）

旧文档：https://old-docs.janusgraph.org/0.4.0/index.html

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.4.0</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.4.0"

测试兼容性

• Apache Cassandra 2.2.10, 3.0.14, 3.11.0
• Apache HBase 1.2.6, 1.3.1, 1.4.10, 2.1.5
• Google Bigtable 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0
• Oracle BerkeleyJE 7.5.11
• Elasticsearch 5.6.14, 6.0.1, 6.6.0
• Apache Lucene 7.0.0
• Apache Solr 7.0.0
• Apache TinkerPop 3.4.1
• Java 1.8

有关 0.4.0 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/8?closed=1

升级说明

HBase：从 1.2 升级到 2.1

JanusGraph 分发版中包含的 HBase 版本从 1.2.6 升级到 2.1.5。HBase 2.x 客户端与 HBase 1.x 服务器不完全向后兼容。操作自己的 HBase 1.x 集群的用户可能需要将其集群升级到 2.x 版本。另外，用户可以从源代码构建自己的 JanusGraph 分发版，其中包含 HBase 1.x，并使用 maven 标志 -Dhbase.profile -Phbase1。

Cassandra：从 2.1 升级到 2.2

JanusGraph 分发版中包含的 Cassandra 版本已从 2.1.20 升级到 2.2.13。有关执行此升级的详细说明，请参阅 Cassandra 的升级文档。操作自己的 Cassandra 集群而不是使用与 JanusGraph 一起分发的 Cassandra 的用户不受此升级的影响。这也不会更改 JanusGraph 支持的不同 Cassandra 版本（有关支持版本的详细列表，请参阅 <>）。

BerkeleyDB：从 7.4 升级到 7.5

BerkeleyDB 版本已更新，它包含对磁盘上存储的文件格式的更改（请参阅 BerkeleyDB 更改日志）。此文件格式更改与以前的 BerkeleyDB 版本向前兼容，因此可以使用 JanusGraph 读取现有图数据。但是，一旦数据已使用较新版本的 BerkeleyDB 读取，旧版本将无法再读取这些文件。建议用户在尝试与 JanusGraph 发布版本一起使用 BerkeleyDB 存储目录之前备份它。

Solr：分布式配置中兼容的 Lucene 版本从 5.0.0 更改为 7.0.0

JanusGraph 分发版包含一个 solrconfig.xml 文件，可用于配置 Solr。此配置中告知 Solr 根据该 Lucene 版本行为的 luceneMatchVersion 值已从 5.0.0 更改为 7.0.0，因为这是 JanusGraph 目前使用的默认版本。用户通常应将此值设置为其 Solr 安装的版本。如果 JanusGraph 分发的配置用于以前使用较低版本（如来自此文件以前版本的 5.0.0）的现有 Solr 安装，强烈建议执行重新索引。

版本 0.3.3（发布日期：2020 年 1 月 11 日）

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.3.3</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.3.3"

测试兼容性

• Apache Cassandra 2.1.20, 2.2.10, 3.0.14, 3.11.0
• Apache HBase 1.2.6, 1.3.1, 1.4.4
• Google Bigtable 1.0.0, 1.1.2, 1.2.0, 1.3.0, 1.4.0
• Oracle BerkeleyJE 7.4.5
• Elasticsearch 1.7.6, 2.4.6, 5.6.5, 6.0.1
• Apache Lucene 7.0.0
• Apache Solr 5.5.4, 6.6.1, 7.0.0
• Apache TinkerPop 3.3.3
• Java 1.8

有关 0.3.3 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/14?closed=1

版本 0.3.2（发布日期：2019 年 6 月 16 日）

旧文档：https://old-docs.janusgraph.org/0.3.2/index.html

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.3.2</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.3.2"

测试兼容性

• Apache Cassandra 2.1.20, 2.2.10, 3.0.14, 3.11.0
• Apache HBase 1.2.6, 1.3.1, 1.4.4
• Google Bigtable 1.0.0, 1.1.2, 1.2.0, 1.3.0, 1.4.0
• Oracle BerkeleyJE 7.4.5
• Elasticsearch 1.7.6, 2.4.6, 5.6.5, 6.0.1
• Apache Lucene 7.0.0
• Apache Solr 5.5.4, 6.6.1, 7.0.0
• Apache TinkerPop 3.3.3
• Java 1.8

有关 0.3.2 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/10?closed=1

版本 0.3.1（发布日期：2018 年 10 月 2 日）

旧文档：https://old-docs.janusgraph.org/0.3.1/index.html

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.3.1</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.3.1"

测试兼容性

• Apache Cassandra 2.1.20, 2.2.10, 3.0.14, 3.11.0
• Apache HBase 1.2.6, 1.3.1, 1.4.4
• Google Bigtable 1.0.0, 1.1.2, 1.2.0, 1.3.0, 1.4.0
• Oracle BerkeleyJE 7.4.5
• Elasticsearch 1.7.6, 2.4.6, 5.6.5, 6.0.1
• Apache Lucene 7.0.0
• Apache Solr 5.5.4, 6.6.1, 7.0.0
• Apache TinkerPop 3.3.3
• Java 1.8

有关 0.3.1 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/7?closed=1

版本 0.3.0（发布日期：2018 年 7 月 31 日）

旧文档：https://old-docs.janusgraph.org/0.3.0/index.html

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.3.0</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.3.0"

测试兼容性

• Apache Cassandra 2.1.20, 2.2.10, 3.0.14, 3.11.0
• Apache HBase 1.2.6, 1.3.1, 1.4.4
• Google Bigtable 1.0.0, 1.1.2, 1.2.0, 1.3.0, 1.4.0
• Oracle BerkeleyJE 7.4.5
• Elasticsearch 1.7.6, 2.4.6, 5.6.5, 6.0.1
• Apache Lucene 7.0.0
• Apache Solr 5.5.4, 6.6.1, 7.0.0
• Apache TinkerPop 3.3.3
• Java 1.8

有关 0.3.0 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/4?closed=1

升级说明

重要

您应该在尝试升级之前备份您的数据！另请注意，一旦升级完成，您将无法再使用 0.3.0 之前的客户端版本连接到您的图。

JanusGraph 0.3.0 实现了 模式约束，这使得引入模式版本概念成为必要。有一个检查可以防止客户端连接，这些连接期望不同的模式版本或没有模式版本概念。要执行升级，必须在您希望升级的每个图上设置配置选项 graph.allow-upgrade=true。图必须使用 0.3.0 或更高版本的 JanusGraph 打开，因为旧版本没有 graph.storage-version 的概念，并且不允许设置它。

janusgraph.properties 文件中的示例摘录

# JanusGraph configuration sample: Cassandra over a socket
#
# This file connects to a Cassandra daemon running on localhost via
# Thrift.  Cassandra must already be started before starting JanusGraph
# with this file.

# This option should be removed as soon as the upgrade is complete. Otherwise if this file
# is used in the future to connect to a different graph it could cause an unintended upgrade.
graph.allow-upgrade=true

gremlin.graph=org.janusgraph.core.JanusGraphFactory

# The primary persistence provider used by JanusGraph.  This is required.
# It should be set one of JanusGraph's built-in shorthand names for its
# standard storage backends (shorthands: berkeleyje, cassandrathrift,
# cassandra, astyanax, embeddedcassandra, cql, hbase, inmemory) or to the
# full package and classname of a custom/third-party StoreManager
# implementation.
#
# Default:    (no default value)
# Data Type:  String
# Mutability: LOCAL
storage.backend=cassandrathrift

# The hostname or comma-separated list of hostnames of storage backend
# servers.  This is only applicable to some storage backends, such as
# cassandra and hbase.
#
# Default:    127.0.0.1
# Data Type:  class java.lang.String[]
# Mutability: LOCAL
storage.hostname=127.0.0.1

如果将 graph.allow-upgrade 设置为 true，则 graph.storage-version 和 graph.janusgraph-version 将自动升级以匹配打开图的服务器或本地客户端的版本级别。您可以通过打开管理 API 并验证 graph.storage-version 和 graph.janusgraph-version 的值来验证升级是否成功。

设置存储版本后，您应该从属性文件中移除 graph.allow-upgrade=true 并重新打开您的图，以确保升级成功。

版本 0.2.3（发布日期：2019 年 5 月 21 日）

旧文档：https://old-docs.janusgraph.org/0.2.3/index.html

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.2.3</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.2.3"

测试兼容性

• Apache Cassandra 2.1.20, 2.2.10, 3.0.14, 3.11.0
• Apache HBase 0.98.24-hadoop2, 1.2.6, 1.3.1
• Google Bigtable 1.0.0
• Oracle BerkeleyJE 7.3.7
• Elasticsearch 1.7.6, 2.4.6, 5.6.5, 6.0.1
• Apache Lucene 7.0.0
• Apache Solr 5.5.4, 6.6.1, 7.0.0
• Apache TinkerPop 3.2.9
• Java 1.8

有关 0.2.3 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/9?closed=1

版本 0.2.2（发布日期：2018 年 10 月 9 日）

旧文档：https://old-docs.janusgraph.org/0.2.2/index.html

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.2.2</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.2.2"

测试兼容性

• Apache Cassandra 2.1.20, 2.2.10, 3.0.14, 3.11.0
• Apache HBase 0.98.24-hadoop2, 1.2.6, 1.3.1
• Google Bigtable 1.0.0
• Oracle BerkeleyJE 7.3.7
• Elasticsearch 1.7.6, 2.4.6, 5.6.5, 6.0.1
• Apache Lucene 7.0.0
• Apache Solr 5.5.4, 6.6.1, 7.0.0
• Apache TinkerPop 3.2.9
• Java 1.8

有关 0.2.2 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/6?closed=1

版本 0.2.1（发布日期：2018 年 7 月 9 日）

旧文档：https://old-docs.janusgraph.org/0.2.1/index.html

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.2.1</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.2.1"

测试兼容性

• Apache Cassandra 2.1.20, 2.2.10, 3.0.14, 3.11.0
• Apache HBase 0.98.24-hadoop2, 1.2.6, 1.3.1
• Google Bigtable 1.0.0
• Oracle BerkeleyJE 7.3.7
• Elasticsearch 1.7.6, 2.4.6, 5.6.5, 6.0.1
• Apache Lucene 7.0.0
• Apache Solr 5.5.4, 6.6.1, 7.0.0
• Apache TinkerPop 3.2.9
• Java 1.8

有关 0.2.1 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/5?closed=1

升级说明

HBase TTL

在 JanusGraph 0.2.0 中，为 HBase 存储后端添加了生存时间 (TTL) 支持。为了利用 HBase 的 TTL 功能，图时间戳需要是 MILLI。如果未明确将 graph.timestamps 属性设置为 MILLI，则 JanusGraph 0.2.0 中的默认值为 MICRO，这不适用于 HBase TTL。由于 graph.timestamps 属性是 FIXED 的，因此需要创建一个新图才能使 graph.timestamps 属性的任何更改生效。

版本 0.2.0（发布日期：2017 年 10 月 11 日）

旧文档：https://old-docs.janusgraph.org/0.2.0/index.html

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.2.0</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.2.0"

测试兼容性

• Apache Cassandra 2.1.18, 2.2.10, 3.0.14, 3.11.0
• Apache HBase 0.98.24-hadoop2, 1.2.6, 1.3.1
• Google Bigtable 1.0.0-pre3
• Oracle BerkeleyJE 7.3.7
• Elasticsearch 1.7.6, 2.4.6, 5.6.2, 6.0.0-rc1
• Apache Lucene 7.0.0
• Apache Solr 5.5.4, 6.6.1, 7.0.0
• Apache TinkerPop 3.2.6
• Java 1.8

有关 0.2.0 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/2?closed=1

升级说明

Elasticsearch

JanusGraph 0.1.z 与 Elasticsearch 1.5.z 兼容。有几个可用的配置选项，包括传输客户端、节点客户端和旧版配置跟踪。JanusGraph 0.2.0 与 Elasticsearch 1.y 到 6.y 版本兼容，但它仅提供使用 REST 客户端的单个配置选项。

传输客户端

TRANSPORT_CLIENT 接口已替换为 REST_CLIENT。将现有图迁移到 JanusGraph 0.2.0 时，连接到图时必须设置 interface 属性

index.search.backend=elasticsearch
index.search.elasticsearch.interface=REST_CLIENT
index.search.hostname=127.0.0.1

连接到图后，可以通过使用 JanusGraphManagement 进行更改来使属性更新永久生效

mgmt = graph.openManagement()
mgmt.set("index.search.elasticsearch.interface", "REST_CLIENT")
mgmt.commit()

节点客户端

使用 JanusGraph 的节点客户端可以通过几种方式配置。如果节点客户端配置为仅客户端或非数据节点，请按照传输客户端部分的步骤使用 REST_CLIENT 连接到现有集群。如果节点客户端是数据节点（本地模式），则将其转换为独立 Elasticsearch 节点，在与应用程序进程分离的 JVM 中运行。这可以通过使用 JanusGraph 配置中的节点配置来启动独立 Elasticsearch 1.5.z 节点来完成。例如，我们从这些 JanusGraph 0.1.z 属性开始

index.search.backend=elasticsearch
index.search.elasticsearch.interface=NODE
index.search.conf-file=es-client.yml
index.search.elasticsearch.ext.node.name=alice

其中配置文件 es-client.yml 具有属性

node.data: true
path.data: /var/lib/elasticsearch/data
path.work: /var/lib/elasticsearch/work
path.logs: /var/log/elasticsearch

配置文件 es-client.yml 中找到的属性以及 index.search.elasticsearch.ext.* 属性可以插入到 $ES_HOME/config/elasticsearch.yml 中，以便可以使用相同的属性启动独立的 Elasticsearch 1.5.z 节点。请记住，如果任何 path 位置具有相对路径，则可能需要相应地更新这些值。一旦启动了独立的 Elasticsearch 节点，请按照传输客户端中的说明完成向 REST_CLIENT 接口的迁移。请注意，REST_CLIENT 接口不使用 index.search.conf-file 和 index.search.elasticsearch.ext.* 属性，因此可以从配置属性中删除它们。

传统配置

旧版配置跟踪在 JanusGraph 0.1.z 中不推荐使用，并且在 JanusGraph 0.2.0 中不再受支持。用户应参考前面的部分并迁移到 REST_CLIENT。

版本 0.1.1（发布日期：2017 年 5 月 11 日）

文档：https://old-docs.janusgraph.org/0.1.1/index.html

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.1.1</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.1.1"

测试兼容性

• Apache Cassandra 2.1.9
• Apache HBase 0.98.8-hadoop2, 1.0.3, 1.1.8, 1.2.4
• Google Bigtable 0.9.5.1
• Oracle BerkeleyJE 7.3.7
• Elasticsearch 1.5.1
• Apache Lucene 4.10.4
• Apache Solr 5.2.1
• Apache TinkerPop 3.2.3
• Java 1.8

有关 0.1.1 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/3?closed=1

版本 0.1.0（发布日期：2017 年 4 月 11 日）

文档：https://old-docs.janusgraph.org/0.1.0/index.html

MavenGradle

<dependency>
    <groupId>org.janusgraph</groupId>
    <artifactId>janusgraph-core</artifactId>
    <version>0.1.0</version>
</dependency>

compile "org.janusgraph:janusgraph-core:0.1.0"

测试兼容性

• Apache Cassandra 2.1.9
• Apache HBase 0.98.8-hadoop2, 1.0.3, 1.1.8, 1.2.4
• Google Bigtable 0.9.5.1
• Oracle BerkeleyJE 7.3.7
• Elasticsearch 1.5.1
• Apache Lucene 4.10.4
• Apache Solr 5.2.1
• Apache TinkerPop 3.2.3
• Java 1.8

自 Titan 1.0.0 版本以来添加的功能

• TinkerPop 3.2.3 兼容性

  • 包括更新到 Spark 1.6.1

• 查询优化：JanusGraphStep 折叠 HasId 和 HasContainers 甚至可以在遍历中间折叠

• 通过 HBase 接口支持 Google Cloud Bigtable 作为后端

• 与后端和索引存储的更新版本兼容

  • HBase 1.2

  • BerkeleyJE 7.3.7

• 包括多项错误修复和优化

有关 0.1.0 中的功能和错误修复的更多信息，请参阅 GitHub 里程碑

• https://github.com/JanusGraph/janusgraph/milestone/1?closed=1

升级说明

JanusGraph 基于 Titan 仓库的 titan11 分支的最新提交。

JanusGraph 对 Titan 进行了以下更改，因此您需要相应地调整您的代码和配置

1. 模块名称：titan-* 现在是 janusgraph-*

2. 包名称：com.thinkaurelius.titan 现在是 org.janusgraph

3. 类名称：Titan* 现在是 JanusGraph*，但在某些情况下会重复一个词，例如 TitanGraph 简称为 JanusGraph 而不是 JanusGraphGraph

有关如何配置 JanusGraph 以读取以前由 Titan 写入的数据的更多信息，请参阅从 Titan 迁移。