Как обрабатывать большие размеры хранилища в Корде? - PullRequest
0 голосов
/ 29 мая 2018

Данные в нашем хранилище управляемы.Со временем мы накопим большой объем.Невозможно сохранить такие большие данные для ежедневных транзакций.Мы бы хотели периодически архивировать или хранить данные, чтобы поддерживать производительность запросов.

Могу ли я узнать, задумывались ли вы о работе с крупномасштабными наборами данных и что бы вы посоветовали.

1 Ответ

0 голосов
/ 05 июня 2018

Из списка рассылки corda-dev:

Да, нам следует поработать над этим.Как вы заметили, сейчас это не актуальная проблема, но может стать таковой в будущем.

Наша текущая реализация фактически предназначена для хранения данных, даже если они больше не являются «текущими» в бухгалтерской книге.Таблицы связанного хранилища ORM предпочитают помечать строку как устаревшую, а не фактически удалять данные из базовой базы данных.Кроме того, хранилище транзакций не имеет понятия сбора или удаления мусора, поэтому оно также никогда не удаляет данные.Это имеет явные преимущества с точки зрения понимания истории бухгалтерской книги и того, как она попала в ее текущее состояние, но это также создает операционные проблемы.

Я думаю, что у людей будут разные предпочтения в зависимости от их ресурсов июрисдикции.Давайте рассмотрим два хранилища данных по отдельности:

Сделать удаление данных из реляционно сопоставленных таблиц легко, это всего лишь изменение политики.Вместо того, чтобы пометить строку как ушедшую, мы фактически запускаем вызов SQL DELETE.Хранилище транзакций сложнее.Corda извлекает выгоду из своего блочного дизайна здесь;теоретически мы можем собирать старые транзакции.Дьявол кроется в деталях, потому что для узлов, которые используют SGX, хранилище tx будет зашифровано.Таким образом, нам нужно не только разработать параллельный GC для графа TX, но и запустить его полностью внутри анклавов.Забавная проблема системной инженерии.

Если проблема заключается только в производительности запросов, один очевидный шаг заключается в том, чтобы перенести хранилище tx в масштабируемое хранилище K / V, такое как Cassandra, размещенное на BigTable и т. Д. Нет большой причины хранить хранилище tx.должна быть в той же РСУБД, что и остальные данные, просто удобно иметь одну базу данных для резервного копирования.Масштабируемые K / V-хранилища на самом деле не теряют производительность запросов по мере роста набора данных, поэтому это также хорошее решение.

WRT, такие как GDPR, возможность удаления данных может помочь или может быть неактуальной,Как и во всем, что связано с ВВП, никто не знает, потому что ЕС не удосужился дать какие-либо ответы - аудит распределенной бухгалтерской книги может считаться «законной потребностью» в данных, а может и нет, в зависимости от того, кто судья в деньдело.

Во всяком случае, проблема заключается в том, что личные данные хранятся в бухгалтерской книге, что на сегодня не так часто.

...