图的一致性

在OrientDB v2.1.7之前, 图的一致性通过使用事务来保证。像创建边的操作这种使用事务的情况有如下问题：

  • 速度, 事务和非事务相比有一定消耗
  • 乐观重试的管理 在应用程序中，需要编程。在高延迟的远程连接上，问题更严重。
  • 高并发下较低的伸缩性 (这个问题会在OrientDB v3.0解决,提交不会锁库了)

2.1.7版本, OrientDB提供了一个新的模式来管理图而不使用事务。使用Java类OrientGraphNoTx或者通过SQL更改全局配置sql.graphConsistencyMode :

  • tx, 默认值, 使用事务保持一致性。这是v2.1.7之前的唯一方式。
  • notx_sync_repair, 避免使用事务。一致性，在JVM崩溃的时候，通过数据库的恢复操作保证，会在启动的时候同步进行。数据库只有当修复完后才能使用。
  • notx_async_repair, 和上一种的不同是，恢复在启动的时候异步进行，不阻塞数据库的启动和使用。

两种新的模式notx_sync_repair和notx_async_repair自动管理冲突，可以配置重试次数(默认50)。并发修改图的时候，任何冲突都会被OrientDB捕获，并重试。支持自动重试的操作包括：

  • CREATE EDGE
  • DELETE EDGE
  • DELETE VERTEX

使用

不使用事务的一致性模型，需要在OrientDB脚本bin/server.sh或者config/orientdb-server-config.xml配置文件设置sql.graphConsistencyMode 为notx_sync_repair或者notx_async_repair: 

...
<properties>
  ...
  <entry name="sql.graphConsistencyMode" value="notx_sync_repair"/>
  ...
</properties>

也可以在打开任意图的之前，用代码设置，如下:

OGlobalConfiguration.SQL_GRAPH_CONSISTENCY_MODE.setValue("notx_sync_repair");

使这个配置持久化，需要设置storage配置的txRequiredForSQLGraphOperations属性, 在接下来打开这个图的时候，不需要再重复设置:

g.getRawGraph().getStorage().getConfiguration().setProperty("txRequiredForSQLGraphOperations", "false");

使用Java API

在上面配置了一致性的模式后，也可以使用类OrientGraphNoTx来使用非事务操作，例如:

OrientGraphNoTx g = new OrientGraphNoTx("plocal:/temp/mydb");
...
v1.addEdge( "Friend", v2 );

在并发修改的情况下，并发的线程会重试修改图(MVCC)。默认的最大重试次数是50，可以通过setMaxRetries()改变:

OrientGraphNoTx g = new OrientGraphNoTx("plocal:/temp/mydb");
g.setMaxRetries(100);

这个配置会在当前使用的图的实例上生效。多个线程，在同一个图上操作，每个线程都有一个实例。每个线程可以有不同的配置。有些可以使用事务，有些可以不实用事务。