Performance tests: disk space distribution in mc folder

+1 vote

At the moment we are running some performance tests:

- 4 Nodes

- write random key-values in root stream.


Now the disk usage is at 8 GB and I am interested in an explanation of the following information:

5.3M    ./permissions.db
4.1G    ./wallet/txs.db
7.1G    ./wallet
480K    ./entities.db
272K    ./database
208K    ./chainstate
183M    ./blocks/index
1.9G    ./blocks
8.9G    .
8.9G    total


I would assume to find the most data in /blocks but obviously it is in wallet / wallet.tx.

Can you explain what exactly is stored there and why it takes that much space compared to the /blocks folder?



asked Nov 24, 2017 by Alexoid

1 Answer

+1 vote
Best answer
There are two reasons why a particular node will use up space in its wallet for a stream item – either because it created the item, or because it is subscribed to the stream. Nodes for which neither of these conditions are fulfilled will only have the stream item in the blockchain.
answered Nov 24, 2017 by MultiChain
selected Apr 26, 2018 by Alexoid
Thanks. So at the moment our "reasonable default" was to subscribe to all stream. But aren't you at least automatically subscribed to the root stream?

Thanks for the information
Yes, a node is subscribed to the root stream by default, but it can always unsubscribe from it.

Need to bring this up again:
Why does the node that created the item need that much more information?

I am evaluating a use case with a huge amount of data in the blockchain and it is a problem here, that the wallet folder needs 4 times the space of the blocks folder.
In the long term we expect to add more options to reduce per-node storage requirements of this nature.

In the shorter term, here's a possible workaround: Combine many events together into a single stream item. Any stream item payloads above 256 bytes in size are not replicated inside the wallet database, but rather only pointed to by the wallet database. So if you have large stream items, the wallet will grow much more slowly relative to the blockchain on disk. Can that help?
Hi. The problem is we need the mapping and the lookup via key-value in a stream.
The data layout is key 64Byte, value 64Byte.
But being aware of this helps, yes.

But I have to correct myself in one point. Wallet folder is not 4 times the size, but 2 times of the blocks folder.

Assuming the node is subscribed to the stream, then this index from the stream key -> item will always take up space, and it cannot be avoided. It may be that in this case you want to consider using an external database for indexing.