Hyperledger Fabric CouchDB as the state database--use CouchDB

Using COUCHDB as the state database

State database Options

The state database includes LEVELDB and COUCHDB. LEVELDB is the default key/value state database embedded in the peer process, andCouchdb is an optional external state database. as with the LEVELDB key/value store, COUCHDB can store any binary data modeled as Chaincode (the COUCHDB attachment function is used internally for non-JSON binary data). However, when Chaincode values (for example, assets) are modeled as JSON data, stored as JSON documents, COUCHDB supports rich querying of chaincode data.

Both LEVELDB and COUCHDB support core chaincode operations, such as getting and setting a key (asset) and querying based on the key. A key can be queried by a range, and a composite key can be modeled to support an equivalent query against multiple parameters. For example, the asset ID can be used to query all assets owned by an entity as a key combination of the owner. these key-based queries can be used for read-only queries against the ledger, and for transactions that update the general ledger.

If you model the asset as JSON and use COUCHDB, you can use the Couchdb JSON query language in Chaincode to perform complex rich queries on the Chaincode data values, which are useful for understanding the contents of the ledger. For these types of queries, transactional protocol responses are typically useful to client applications, but are typically not submitted as transactions to the sort service. In fact, there is no guarantee that the result set will be stable between chaincode execution and rich query commit time, so it is not appropriate to use the results of rich queries to perform the final transaction update operation, unless you can guarantee the stability of the result set between the Chaincode execution time and the commit time. Or you can deal with potential changes in subsequent transactions. For example, if you perform a rich query on all of Alice's assets and transfer it to Bob, a new asset may be assigned to Alice by another transaction, which is another transaction between the Chaincode execution time and the commit time, which may miss this "virtual value" during this process.

COUCHDB is run as a standalone database process with peer, so there are additional considerations for setup, management, and operation. We can consider starting with the default embedded Leveldb, which can be transferred to COUCHDB if additional complex rich queries are required. modeling Chaincode Asset data as JSON is a good practice so that we can execute the complex rich queries we need in the future.

Using the CouchDB in Chaincode

Most Chaincode APIs can use LEVELDB or COUCHDB state databases, such as GetState, Putstate, Getstatebyrange, and Getstatebypartialcompositekey. You can use the Getqueryresult API and pass a COUCHDB query string to perform rich queries on the JSON in the state database only when using COUCHDB as the state database and the model asset as JSON in Chaincode. The query string follows the COUCHDB JSON query syntax.

The MARBLES02 example in a fabric project demonstrates the use of COUCHDB queries from Chaincode. It includes a getmarblesbyowner () function that demonstrates a parameterized query by passing an owner ID to Chaincode, and then queries the state data of the JSON document that matches the "marble" doctype, and the owner The ID uses the JSON query syntax:

{
"Selector": {
"DocType": "Marble",
"Owner":<owner_id>
}
}

To make the JSON query more efficient, and for any JSON query with sorting, you need to use the index in COUCHDB. The index can be packaged with the Chaincode/meta-inf/statedb/couchdb/indexes directory. Each index must be expanded in its own text file by *. JSON is defined, where the index is defined in JSON format and references the COUCHDB index JSON syntax, for example, to support the above marble query, provides a sample index of DOCTYPE and owner fields:

{
"Index": {
"Fields": [
"Data.doctype",
"Data.owner"
]
},

"Name": "Indexowner",
' type ': ' JSON '
}

The sample index can be found here.

Note: In 1.1 alpha, you must specify the data wrapper for each field referenced in the index definition. in subsequent releases, the requirement to specify the data wrapper might be canceled.

Any index in the Chaincode meta-inf/statedb/couchdb/indexes directory will be packaged and installed on peer together with Chaincode. When Chaincode is installed on a peer and then instantiated on the channel of peer, the index is automatically deployed to the peer's Channel state database (if configured to use COUCHDB). If Chaincode is installed before the Chaincode is instantiated on the channel, then the index will be deployed when the Chaincode is instantiated. If Chaincode is already instantiated on a channel and then installs the Chaincode on a peer, the index will be deployed when the Chaincode is instantiated.

At deployment time, the index is automatically exploited by the Chaincode query. COUCHDB can automatically determine which index to use based on the fields used in the query. or, in a selector query, you can use the Use_index keyword to specify the index.

The same index may exist in subsequent versions of the installed Chaincode. to change the index, use the same index name, but change the index definition. Upon installation/instantiation, the index definition is redeployed to the peer's state database.

If the Channle already has a large amount of data and then Chaincode is installed, the creation of the index may take some time to instantiate. Similarly, if the channel already has a large amount of data and instantiates subsequent versions of Chaincode, it may take some time to create the index. It is therefore necessary to avoid invoking the Chaincode function of the query state database during these time periods, because the Chaincode query may time out when the index is initialized. The index is automatically refreshed during transaction processing because the block is submitted to the ledger ledger.

COUCHDB Configuration

You can enable COUCHDB as a state database by changing the state database configuration option from Goleveldb to COUCHDB. Additionally, the couchdbaddress needs to be configured to point to the couchdb used by the peer. If you configure COUCHDB with a user name and password, the user name and password attributes should contain the administrator user name and password. More options are available in the Couchdbconfig, and records are made where appropriate. After restarting the peer, the modified core. Yaml will take effect immediately.

Of course, you can also overwrite the core with the Docker environment variable. Yaml values, such as Core_ledger_state_statedatabase and core_ledger_state_couchdbconfig_couchdbaddress.

The following are the state database options from Core.yaml:

State : # statedatabase-options is"Goleveldb", "CouchDB"# goleveldb-default state database stored in GOLEVELDB. # Couchdb-store state database in CouchDB statedatabase:goleveldb couchdbconfig: # It's recommended to run couch     DB on the same server as the peer, and # No map the CouchDB container port to a server port in Docker-compose.     # Otherwise Proper security must be provided on the connection between # CouchDB client (on the peer) and server. COUCHDBADDRESS:COUCHDB:5984# This username must has read and write authority on CouchDB username: # The password was recommended to     Pass as an environment variable # during start up (e.g. Ledger_couchdbconfig_password). # If It is stored here, the file must was access control protected # to prevent unintended users from discovering the P     Assword. Password: # Number of retries for CouchDB errors maxretries:3# Number of retries for CouchDB errors during peer startup Maxretriesonstartup:10# CouchDB Request Timeout (unit:duration, e.g. 20s) requesttimeout:35s # Limit on the number of records To return per query Querylimit:10000

COUCHDB is hosted in a Docker container by using a Docker compose script that uses Hyperledger fabric to set COUCHDB username and password capabilities through existing environment variable settings, That is, Couchdb_user and Couchdb_password environment variables.

For COUCHDB installations outside of the Docker image provided with fabric, install locally. You must edit the INI file to set the Admin user name and password.

The Docker compose script only sets the user name and password when the container is created. If you want to change the user name or password after the container is created, you must edit the local. ini file.

Note: The peer option for COUCHDB is read at each peer startup.

Add

In Hyperledger Fabric 1.0 from scratch (ix)--fabric Multi-node cluster production startup has set the peer and CLI boot configuration, which did not join the COUCHDB, here to add a new peer authoring method, I hope to help you.

Subsequent writes to the CA will also include the CA boot section.

# Copyright IBM Corp. All rights reserved.## spdx-license-identifier:apache-2.0#version:' 2 'services:couchdb:container_name:couchdb IMAGE:HYPERLEDGER/FABRIC-COUCHDB # comment/uncomment the port Ma pping if want to hide/expose the CouchDB service, # For example maps it to utilize Fauxton User Interface in Dev env    Ironments. Ports:-"5,984:5,984"peer0.xxx.example.com:container_name:peer0.xxx.example.com Image:hyperledger/fabric-peer Environment: -Core_ledger_state_statedatabase=couchdb-core_ledger_state_couchdbconfig_couchdbaddress=couchdb:5984-Core_peer_id=peer0.xxx.example.com-core_peer_networkid=anti-core_peer_address=peer0.xxx.example. com:7051-core_peer_chaincodelistenaddress=peer0.xxx.example.com:7052-core_peer_gossip_externalendpoint=peer0.xxx.example.com:7051-Core_peer_localmspid=xxxmsp-core_vm_endpoint=unix:///Host/var/run/docker.sock# The following setting starts Chaincode containers on the same # Bridge network as the peers # https: docs.docker.com/compose/networking/-Core_vm_docker_hostconfig_networkmode=anti_default-core_logging_level=error #-CORE_LOGGING_LEVEL =debug-core_peer_gossip_skiphandshake=true-core_peer_gossip_useleaderelection=true-core_peer_gossip_o rgleader=false-core_peer_profile_enabled=false-core_peer_tls_enabled=false-core_peer_tls_cert_file=/e Tc/hyperledger/fabric/tls/server.crt-core_peer_tls_key_file=/etc/hyperledger/fabric/tls/server.key-core_peer _TLS_ROOTCERT_FILE=/ETC/HYPERLEDGER/FABRIC/TLS/CA.CRT volumes:-/var/run/:/host/var/run/-./crypto-conf Ig/peerorganizations/xxx.example.com/peers/peer0.xxx.example.com/msp:/etc/hyperledger/fabric/msp-./    Crypto-config/peerorganizations/xxx.example.com/peers/peer0.xxx.example.com/tls:/etc/hyperledger/fabric/tls Working_dir:/opt/gopath/src/github.com/hyperledger/fabric/peer command:peer node Start ports:-7,051:7,051      - 7,052:7,052      - 7,053:7,053depends_on:-couchdb networks:default:aliases:-Anti extra_hosts:-"Orderer0.example.com:x.x.x.41"     - "Orderer1.example.com:x.x.x.42"     - "Orderer2.example.com:x.x.x.43"cli:container_name:cli image:hyperledger/fabric-tools tty:true Environment:-Gopath=/opt/gopat H-core_vm_endpoint=unix:///Host/var/run/docker.sock-Core_logging_level=error #-Core_logging_level=debug-core_peer_id=cli-core_peer_address=pe Er0.xxx.example.com:7051      -Core_peer_localmspid=xxxmsp-core_peer_tls_enabled=false-core_peer_tls_cert_file=/opt/gopath/src/gith ub.com/hyperledger/fabric/peer/crypto/peerorganizations/xxx.example.com/peers/peer0.xxx.example.com/tls/ server.crt-core_peer_tls_key_file=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerorganizations/ xxx.example.com/peers/peer0.xxx.example.com/tls/server.key-core_peer_tls_rootcert_file=/opt/gopath/src/ github.com/hyperledger/fabric/peer/crypto/peerorganizations/xxx.example.com/peers/peer0.xxx.example.com/tls/ ca.crt-core_peer_mspconfigpath=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerorganizations/    Xxx.example.com/users/[email protected]/msp Working_dir:/opt/gopath/src/github.com/hyperledger/fabric/peer Volumes:-/var/run/:/host/var/run/-./chaincode/go/:/opt/gopath/src/github.com/hyperledger/fabric/antimoth /anti/chaincode/go-./crypto-config:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/-./scripts:/opt/gopath/src/github.com/hyperledger/fabric/peer/scripts/-./channel-artif Acts:/opt/gopath/src/github.com/hyperledger/fabric/peer/channel-artifacts depends_on:-peer0.xxx.example.com E  Xtra_hosts:-"Orderer0.example.com:x.x.x.41"     - "Orderer1.example.com:x.x.x.42"     - "Orderer2.example.com:x.x.x.43"     - "peer0.xxxx.example.com:x.x.xx.251"

Hyperledger Fabric CouchDB as the state database--use CouchDB