我有一个系统(Cassandra(，它包含我想单向"sync"；使用我的Tinkerpop商店(我使用AWS Neptune(。所谓单向同步，我的意思是数据只会由同步过程从真相源更新到图形存储，并且对于图形存储的用户来说是只读的。
真理的来源持有相对较小的数据集，当构建为图时，它包括<1MM顶点和边。
我正在研究以下两种方法：
A( 使用Neptune散装装载机：
- 每当真相的来源发生变化时，将所有数据作为快照转储到文件中(将来可能会对delta使用更改事件(
- 从图形存储中读取所有感兴趣的数据，并计算要追加启动的节点和顶点
- 将所有节点和顶点写入csv文件并加载到Neptune中
优点：
- 将数据加载到Neptune的最快方法
缺点：
- 不安全：如果大容量加载中途失败，则图存储处于不一致状态
B(使用带有Tinkerpop会话客户端的会话
- 每当真相的来源发生变化时，将所有数据作为快照转储到文件中(将来可能会对delta使用更改事件(
- 从图形存储中读取所有感兴趣的数据，并计算要追加的节点和顶点
- 使用单个会话发送一批Gremlin查询以追加和删除节点和顶点
优点：
- safe：由于在整个同步过程中使用相同的会话，如果一个Gremlin查询失败，所有内容都会回滚
缺点：
- 仅限脚本：SessiondClient只允许Gremlin脚本，因此我不能使用字节码，而是必须连接字符串来制作Gremlin剧本。虽然不理想，但似乎有效
- 比散装装载机慢
- 10分钟限制：海王星将同步时间限制为10分钟，会话最多只能打开10分钟。由于数据的大小，我认为加载不会超过10分钟
我用小数据集尝试了这两个选项。我还尝试过使用常规的每个请求一个事务的java客户端，但在一个请求中发送所有更改并不能经得起未来的考验。我说得对吗？
我即将开始生产方法B，我想知道是否有我应该注意的陷阱或其他我没有考虑过的选择？
一些想法-您已经很好地思考了一些利弊。
-
对于Neptune，如果您经常以非追加启动的方式进行大量写入以添加数据，那么批量加载程序是一个不错的选择。然而，正如您所注意到的，批量加载程序的语义是"；尽你所能"并且加载每个有效的CSV行，或者一旦发现一行无效就失败。如果您可以通过提前筛选来保证数据是干净的，那么批量加载程序可能仍然是一个不错的选择。
-
Gremlin会话为您提供了对交易的更多控制，但正如您所指出的，目前查询必须以文本形式发送。然而，在TinkerPop 3.5.0版本中，添加了对ByteCode交易的支持。最初，Java客户端和其他客户端将很快跟进。Node已经在工作中了，希望Python很快就会出现。一旦AmazonNeptune升级到TinkerPop 3.5.x级别，您将能够利用新的ByteCode交易语法/语义。请注意，会话的10分钟限制适用于会话空闲时。任何活动都会将计时器重新设置回10分钟。