Hybrid discovery service #network #hyperledger-fabric
|
Joao Antunes
Hi, community,
I couldn't find any data regarding this, but is there a way or is it in the roadmap to have a hybrid discovery service? What I mean by hybrid is; having multiple peers on the same network, some with couchdb and some with leveldb, in a way that we can query only the peers with couchdb when we have a rich query or just query the leveldb peers, when we only query by key.
Thank you, João Antunes |
||||||||||||||||
|
|
||||||||||||||||
|
Yacov
I am not sure anyone tested mixed database types, have you tested it? Does it work?
I'm not sure what happens to a LevelDB backed peer when it receives directions to build indices which only exist in CouchDB.
Regarding discovery, there is no roadmap for this, no.
Having said that, discovery fetches information from the gossip membership module, and it is fairly straightforward to add any type of information about the peer to the information being replicated and returned to the user.
In the code, there is a message called Properties which is simply replicated and is set by the peer:
So if you want, you can extend it yourself and then set its value in a similar manner to how it's done for chaincodes [1], and then you get this information from the discovery query automatically.
From: fabric@... <fabric@...> on behalf of Joao Antunes <joao.antunes@...>
Sent: Wednesday, August 10, 2022 3:25 AM To: fabric@... <fabric@...> Subject: [EXTERNAL] [Hyperledger Fabric] Hybrid discovery service #network #hyperledger-fabric
This Message Is From an External Sender
This message came from outside your organization.
Hi, community,
I couldn't find any data regarding this, but is there a way or is it in the roadmap to have a hybrid discovery service? What I mean by hybrid is; having multiple peers on the same network, some with couchdb and some with leveldb, in a way that we can query only the peers with couchdb when we have a rich query or just query the leveldb peers, when we only query by key.
Thank you, João Antunes |
||||||||||||||||
|
|
||||||||||||||||
|
David Enyeart
You should NOT use a mix of LevelDB and CouchDB based peers on the same channel. Things may work at first, but if you later endorse data on a LevelDB peer that is not compatible with CouchDB, the transaction could eventually get validated and committed on the LevelDB peers but not the CouchDB peers, resulting in different state on the ledger depending on LevelDB versus CouchDB.
From the Fabric documentation:
“You must decide whether to use LevelDB or CouchDB before setting up your network. Switching a peer from using LevelDB to CouchDB is not supported due to data compatibility issues. All peers on the network must use the same database type.”
If you don’t need advanced query on each peer, the recommendation is to use LevelDB database for peer and then use block events to build a downstream queryable data store that is fit-for-purpose based on the query requirements. See the off-chain data sample for more details of this pattern - https://github.com/hyperledger/fabric-samples/tree/main/off_chain_data.
From:
fabric@... <fabric@...> on behalf of Yacov <yacovm@...> I am not sure anyone tested mixed database types, have you tested it? Does it work? I'm not sure what happens to a LevelDB backed peer when it receives directions to build indices which only exist in CouchDB. ZjQcmQRYFpfptBannerStart
ZjQcmQRYFpfptBannerEnd
I am not sure anyone tested mixed database types, have you tested it? Does it work?
I'm not sure what happens to a LevelDB backed peer when it receives directions to build indices which only exist in CouchDB.
Regarding discovery, there is no roadmap for this, no.
Having said that, discovery fetches information from the gossip membership module, and it is fairly straightforward to add any type of information about the peer to the information being replicated and returned to the user.
In the code, there is a message called Properties which is simply replicated and is set by the peer:
}
So if you want, you can extend it yourself and then set its value in a similar manner to how it's done for chaincodes [1], and then you get this information from the discovery query automatically.
From: fabric@... <fabric@...> on behalf of Joao Antunes <joao.antunes@...>
Sent: Wednesday, August 10, 2022 3:25 AM To: fabric@... <fabric@...> Subject: [EXTERNAL] [Hyperledger Fabric] Hybrid discovery service #network #hyperledger-fabric
Hi, community, I couldn't find any data regarding this, but is there a way or is it in the roadmap to have a hybrid discovery service? What I mean by hybrid is; having multiple peers on the same network, some with couchdb and some with leveldb, ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd Hi, community,
I couldn't find any data regarding this, but is there a way or is it in the roadmap to have a hybrid discovery service? What I mean by hybrid is; having multiple peers on the same network, some with couchdb and some with leveldb, in a way that we can query only the peers with couchdb when we have a rich query or just query the leveldb peers, when we only query by key.
Thank you, João Antunes |
||||||||||||||||
|
|