Потенциальная проблема масштабируемости с сохранением данных Javers в одной таблице?

Question

Мы изучали different alternatives для хранения изменений объектов и обнаружили JaVers, которые, похоже, были созданы специально для этой цели.

Мы создали прототип (с использованием MySQL for change repo), который хорошо зарекомендовал себя и выполнил то, что было обещано. Все идет нормально.

Однако, похоже, что 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

Решение а) что вы предполагаете, что это невозможно в репозитории SQL JaVers. Это было бы очень сложно реализовать. Подумайте о реализации кросс-классных запросов, таких как child-value-objects-filter в SQL.

На самом деле это будет какой-то осколок, которого довольно сложно достичь в SQL DB.

Для больших баз данных мы рекомендуем использовать MongoDB (http://javers.org/documentation/repository-configuration/#mongodb-configuration). В MongoDB шортинг доступен из коробки на уровне БД.

Учитывая b) вопрос. Я бы не сказал, что это ложный позитив. Объекты: {'bar':'a'} и {'bar':'a', 'baz':0} разные. Вы можете исключить такие изменения, если baz будет null (целое число).