Javers将数据保存在单个表中的潜在可伸缩性问题？

Question

我们正在调查different alternatives存储对象的变化，并发现JaVers似乎是完全用于此目的的工具。

我们已经构建了一个原型（使用MySQL进行变更回购），该原型已经很好地实现并实现了所承诺的内容。到现在为止还挺好。

但是，JaVers似乎将所有内部数据存储在4个表中。对于小数据集来说，这不是一个大问题，但是如果原始数据模式具有真正大的表格（每个数百万/数十亿记录）会发生什么？在如此大的表中更新记录意味着向JaVers审计表添加一个记录，该记录将会非常大（最有可能比原始数据库的大小更大）。

从我们之前使用大型审计表的经验来看，我们遇到了像inserts开始减慢，查询绝对年龄等问题。我们需要频繁地获得增量，所以这看起来像是一个定时炸弹。

1）是否有可能配置JaVers所以它存储在单独的表的变化，每每个实体一个 - 像

• foo_global_id，foo_snapshot，foo_commit，foo_commit_property
• bar_global_id，bar_snapshot，bar_commit，bar_commit_property

如果目前还不可能，那么添加这样的功能有多难（u愿意投入时间并提交补丁）？

2）比方说，我们有

class Foo { 
    String bar; 
} 

一段时间后，我们决定添加一个字段

class Foo { 
    String bar; 
    int baz = 0; 
} 

我怀疑，如果我们更新的Foo一个实例，并改变bar仅但保留baz = 0 ，JaVers将会报告说baz=0已被添加。 JaVers中是否有任何设计用于处理数据模型更改并避免此类误报的内容？

Answer 1

解决方法a）您建议在JaVers SQL Repository中不可能解决这个问题。这将是很难实施。考虑在SQL中实现类似child-value-objects-filter的跨级别查询。

事实上，它会是某种在SQL DB中很难实现的分片。

对于大型数据库，我们推荐使用MongoDB（http://javers.org/documentation/repository-configuration/#mongodb-configuration）。在MongoDB中，分区级别的开箱即用。

考虑到b）问题。我不会说这是一个误报。 对象：{'bar':'a'}和{'bar':'a', 'baz':0}是不同的。如果baz将为空（整数），则可以消除此类更改。