Тем не менее, возможны оптимизации, и мы постараемся реализовать их в будущих версиях Corda. Например, один из вариантов - отрезать схему, если вы знаете, что у вашего контрагента она уже есть.
ажется, что текущая версия Corda (3.1) хранит (подписанную) транзакцию через BLOB как сериализованный байтовый массив класса JavaSignedTransaction, (TheSignedTransaction этоWireTransactionто есть содержит байтовый массив, представляющий сериализованную транзакцию).
Для некоторых проектов такой подход может представлять проблему, так как он кажется сравнительно бесполезным в отношении памяти и, следовательно, пропускной способности.
Это стандартный способ, которым Corda будет сериализовать транзакции? Какие существуют варианты, чтобы изменить сериализацию, чтобы уменьшить требования к памяти?
пример
ПытаясьПример CordApp «IOU» имея простойIOUState и простая транзакция, одна транзакция создает одну запись в таблицеNODE_TRANSACTIONS где размерTRANSACTION_VALUE сообщаетselect length(TRANSACTION_VALUE) from NODE_TRANSACTIONS составляет 11 килобайт. Похоже, что эти 11 килобайт состоят из 9 килобайт для сериализованногоWireTransaction и 2 килобайта для подписей. IOUState содержит один двойной (и информация о двух экземплярах).
Использование BlobInspector для десериализации двоичного формата TRANSACTION_VALUE позволяет обнаружить файл JSON всего 2 кБайта - намного меньше, чем 11 кБайт двоичного BLOB, но при этом все равно иметь данные, которые могут быть значительно сокращены при хранении в другой модели.
Учитывая 170 транзакций в секунду (цифра указана для Corda), простой пример ввода-вывода потребует 50 терабайт в год (365 дней, 24 часа) в каждом (участвующем) узле.
Также обратите внимание: то, что размер большого двоичного объекта намного больше, чем десериализованный JSON (по крайней мере, фактор 5), противоречит интуиции. Может я тут что то не так сделал ...