У вас есть два варианта: разбить полезную нагрузку на несколько записей или сохранить ее вне потока, например, в S3.
Для первого варианта вы можете использовать PartitionKey и SequenceNumberForOrdering ( документ ).Присвойте уникальный ключ раздела (например, UUID) каждой исходной записи.Если вам нужно разбить источник на чанки размером менее 1 МБ, установите порядковый номер для чанков 2..N равным возвращаемому порядковому номеру предыдущего чанка.
Это потребует от клиентов проверки разделаключ для извлеченных записей и при необходимости восстановить исходную запись.Обратите внимание, что им может потребоваться буферизовать несколько фрагментов (для разных исходных записей).
Вывод данных из внешнего вида упростит код как производителя, так и потребителя.Опять же, создайте уникальный идентификатор для каждой исходной записи, но вместо записи записи в поток запишите ее на S3 с этим идентификатором в качестве ключа.Затем запишите ключ в поток.Затем потребитель будет извлекать фактические данные из S3, когда он читает идентификатор из потока.
Этот второй подход требует большего управления: вам нужно добавить правило жизненного цикла в S3, чтобы удалить записи, и выВам нужно будет убедиться, что это правило жизненного цикла позволяет объектам жить как минимум в течение срока хранения потока (я бы, вероятно, установил бы 8-дневный TTL независимо от периода хранения потока, потому что S3 дешев).
Если у вас есть только нечасто большие записи, особенно если у вас много маленьких записей, тогда запись всего в S3 будет неэффективной.В этом случае вы можете принять гибридную модель, в которой вы записываете в поток структуру данных, которая содержит либо фактические данные, либо ссылку на внешнее хранилище.