Пройдя по Главной книге - PullRequest
       6

Пройдя по Главной книге

0 голосов
/ 15 октября 2018

У меня есть настроенное приложение, которое загружает вложение с каждой транзакцией.Вложение представляет собой сжатый файл со списком уникальных идентификаторов, связанных с TX.Я пытаюсь реализовать логику, которая запрещает повторное появление того же уникального идентификатора в следующей транзакции.Допустим, у меня есть начальная передача с списком вложений A, B, C, D, E, и она проходит.Тогда у меня есть Tx 2a с вложением F, G, H и Tx 2b с вложением C, F, G, H.Я хотел бы, чтобы 2a было принято, но 2b было бы отклонено.

Я пытаюсь найти лучший способ хранить и запрашивать историю идентификаторов.Я знаю, что вложение будет сохранено в истории передачи, но просмотр книги и открытие / чтение всех вложений, чтобы убедиться, что нет дубликатов, кажется чрезвычайно интенсивным при масштабировании (вложения, скорее всего, содержат тысячи уникальных идентификаторов, а не 5).).

Является ли практичным создание таблицы в БД - возможно, даже в части хранилища вне книги - которая просто содержит все использованные идентификаторы?Узел, отвечающий за проверку избыточности, может прочитать входящее вложение, запросить таблицу, проверить избыточность, подписать tx, а затем вставить новые идентификаторы в таблицу?Или есть что-то лучшее, что мы можем сделать, что включает в себя фактический просмотр бухгалтерской книги?

Спасибо

1 Ответ

0 голосов
/ 16 октября 2018

Предполагая, что не существует миллионов идентификаторов, и если вы не возражаете против того, что все прошлые идентификаторы находятся в текущей версии состояния, то вы можете накопить их внутри состояния, внутри Set?Set обеспечит отсутствие дупликов.Преимущество этого подхода заключается в том, что вы можете выполнить логику проверки внутри контракта.

Если вам не нужны эти проверки внутри контракта, вы можете воспользоваться одним из предложенных вами подходов:

  • "обход бухгалтерской книги" на самом деле просто выполняет несколько неэффективных запросов к базе данных, как вы правильно заметили
  • , другой предложенный вами подход кажется хорошей идеей.Держите таблицу БД вне регистра с идентификаторами. В настоящее время работаем над функцией, чтобы сделать это намного проще.Тем временем вы можете использовать ServiceHub.jdbcConnection для выполнения запросов к БД.

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

Одна вещь, которую вы могли бы сделатьпопробуйте сохранить фильтр Блума внутри вашего объекта состояния.Таким образом, вы получаете компактную структуру данных и быстрые проверки членства.Вам придется обновлять фильтр каждый раз, когда добавляется идентификатор.Может быть на что посмотреть.

Приветствия

...