<p>We use at the moment one protobuffer file which gets persisted to disk (PersistableNetworkPayloadMap) for storing data which arrived from the P2P network and are from payload type PersistableNetworkPayload.<br>
There are 2 use cases for those data: Account age witness and trade statistics.<br>
Both are persisted in an append-only style as there is no use case for removing that data. This allows us to only use the hash of the payload as key in a map. For removal of the data we would need to support a signature and store a public key with the data which increases the data size quite a lot (specially for account age witness data we want to keep it as small as possible).</p>
<p>We will have new use cases from the DAO: Proposals and BlindVotes which are essential data for constructing the vote result need to be persisted as well.<br>
We could use a custom data structure inside the DAO domain but then we would need to re-implement already existing features from the p2p network like the delta handling for requests.<br>
At the moment the 2 payload types (account age witness and trade statistics) are stored in the same data structure/file (PersistableNetworkPayloadMap).<br>
For the DAO we would like to have our consensus critical data more explicitly controlled and defined.<br>
We suggest to use domain specific storage implementations and merge the data from different sources for the P2PDataStorage as the p2p network domain is not aware of the other domains.<br>
That will also gives us more flexibility about the way how the data are persisted (maybe use a high performance DB for those payload types which creates a lot of disk IO) and make it easier to implement solutions for better scalability (e.g. pruning of old trade statistics, or move them to a data provider for on-demand requests once the data gets too much).</p>
<p>I am working on an implementation for that cahnges at <a href="https://github.com/ManfredKarrer/bisq-p2p/commits/storage-provider">https://github.com/ManfredKarrer/bisq-p2p/commits/storage-provider</a> and would like to ask for feedback (still not complete but basics are in place).</p>
<p>My suggestion uses the AppendOnlyDataStoreService class which maintains a list of storageServices.<br>
Any domain can add a storage service and the AppendOnlyDataStoreService takes care of merging those data sources for the domain agnostic P2PDataStorage.<br>
We can transition from the current data store to the new system by copying over the existing data entries to the new files and then having 2 new storage files: AccountAgeWitnessMap and TradeStatisticsMap (not impl. yet).<br>
With the DAO there will be 2 more: ProposalMap and BlindVoteMap.</p>
<p>We added also support for data which can be removed, which would require the public key and use different data types.<br>
Those are handled in PersistedEntryMapService. As there is currently no use case I have not implemented the support for multiple services but it would follow the same concept as in AppendOnlyDataStoreService. I could be probably consolidated to one implementation with a bit more generics support (thought it would get a bit complicate, so I prefer to have a bit duplicated code rather then very obscure generics).<br>
There might be use cases from the DAO for that PersistedEntryMapService but that is still not 100% clear. If there will be no use case we can remove that as well.</p>
<p><a class="user-mention" data-hovercard-user-id="1070734" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/freimair">@freimair</a> <a class="user-mention" data-hovercard-user-id="23560607" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/sqrrm">@sqrrm</a> <a class="user-mention" data-hovercard-user-id="301810" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/cbeams">@cbeams</a><br>
What do you think about it?</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/bisq-p2p/issues/8">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AkpZtv4rZL_e-R8XTS9a31rQBYxqgVVHks5ts01cgaJpZM4TqtDa">mute the thread</a>.<img src="https://github.com/notifications/beacon/AkpZtj9-oPCfKE3r0OuO8ddBST2Q8anKks5ts01cgaJpZM4TqtDa.gif" height="1" width="1" alt="" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/bisq-network/bisq-p2p/issues/8"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/bisq-network/bisq-p2p","title":"bisq-network/bisq-p2p","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/bisq-network/bisq-p2p"}},"updates":{"snippets":[{"icon":"DESCRIPTION","message":"Change data persitence  (#8)"}],"action":{"name":"View Issue","url":"https://github.com/bisq-network/bisq-p2p/issues/8"}}}</script>