For any queries/reporting beyond simple JSON queries, the recommendation is to use a downstream purpose-built data service. Chaincode is optimized for transactions, not large queries. See an example of a downstream data service based on block events here:
https://github.com/hyperledger/fabric-samples/tree/master/off_chain_data


Dave Enyeart

samyakj---01/07/2021 08:20:06 AM---Hi Community, We are trying to model the traceability of an asset in hyperledger fabric.

From: samyakj@...
To: fabric@...
Date: 01/07/2021 08:20 AM
Subject: [EXTERNAL] [Hyperledger Fabric] Assistance for planning design of a chaincode #couchdb #fabric #hyperledger-fabric
Sent by: fabric@...

We are trying to model the traceability of an asset in hyperledger fabric. We've come up with several ideas but are unsure which one would be most efficient in terms of retrieving traceability for a given product.

The product can go through multiple stages in its lifecycle, and multiple products can be aggregated to produce a combined output, in which case the output should be able to trace back to the origins of each input used.

We faced the following limitations:

• Fabric's ~100MB MAX transaction payload limit (don't know if this is still applicable in v2.2) see reference: If we try to embed the trace data in the product asset itself, it will be an unbounded growth, and for bigger aggregations, like 10000 products getting aggregated into a storage for ex. it might exceed that max size.
• Query performance using lookups: If we try to lookup the independent trace of each input batch, query performance will take a hit (involving 10000 lookups using the same ex.). We are looking for very efficient query speeds as the traceability will be shown to customers that they will reach by scanning a QR code.

Thanks & Regards, Samyak Jain