State Database options(狀態數據庫選項)
狀態數據庫選項包括LevelDB和CouchDB(默認庫是leveldb)。 LevelDB是嵌入在peer進程中的默認鍵值狀態數據庫。 CouchDB是可選的替代外部狀態數據庫。與LevelDB鍵值存儲一樣，CouchDB可以存儲以鏈代碼建模的任何二進制數據（CouchDB附屬功能在內部用於非JSON二進制數據）。但作為JSON文檔存儲，當鏈代碼值（例如資產）被建模為JSON數據時，CouchDB還能夠對鏈代碼數據進行豐富的查詢。
LevelDB和CouchDB都支持核心鏈代碼操作，例如獲取和設置密鑰/鍵值/keys（資產）以及基於密鑰/鍵值/keys查詢。可以按范圍查詢密鑰/鍵值/keys，並且可以對復合密鑰建模以啟用針對多個參數的等效查詢。例如，所有者的復合鍵，asset_id可用於查詢某個實體擁有的所有資產。這些基於密鑰的查詢可用於針對分類帳的只讀查詢，以及更新分類帳的事務。
如果您將資產建模為JSON並使用CouchDB，您還可以使用鏈代碼中的CouchDB JSON查詢語言對鏈代碼數據值執行復雜的富查詢。這些類型的查詢對於理解分類賬上的內容非常有用。針對這些類型的查詢的提議響應通常對客戶端應用程序有用，但通常不作為事務提交給orderer服務。實際上，無法保證結果集在鏈代碼執行和富查詢的提交時間之間是穩定的，因此豐富的查詢不適合在更新事務中使用，除非應用程序能夠保證鏈碼執行時間和提交時間之間的結果集是穩定的，或者可以處理后續事務中的潛在更改。例如，如果您對Alice擁有的所有資產執行富查詢並將其傳輸給Bob，則可能會在鏈代碼執行時間和提交時間之間通過另一個事務將新資產分配給Alice，您將錯過此“幻像”項。
CouchDB作為一個獨立的數據庫進程與peer一起運行，因此在設置，管理和操作方面還有其他考慮因素。您可以考慮從默認的嵌入式LevelDB開始，如果需要其他復雜的富查詢，請轉到CouchDB。將鏈碼資產數據建模為JSON是一種很好的做法，因此您可以選擇在將來需要時執行復雜的富查詢。
JSON文檔不能在頂層使用以下字段名。這些是供內部使用的。
_deleted_id_rev~version
Using CouchDB from Chaincode（使用鏈碼的couchdb)
大多數鏈碼填充程序API可以與LevelDB或CouchDB狀態數據庫一起使用，例如， GetState，PutState，GetStateByRange，GetStateByPartialCompositeKey。此外，當您在鏈碼中使用CouchDB作為狀態數據庫，並將資產建模為JSON時，您可以通過使用GetQueryResult API並傳遞CouchDB查詢字符串對狀態數據庫中的JSON執行富查詢。查詢字符串遵循CouchDB JSON查詢語法。
marbles02 fabric示例演示了使用來自鏈碼的CouchDB查詢。它包含一個queryMarblesByOwner()函數，該函數通過將所有者id傳遞到鏈碼來演示參數化查詢。 然后，它使用JSON查詢語法查詢狀態數據以查找與“marble”的docType和所有者id匹配的JSON文檔的狀態數據。
{"selector":{"docType":"marble","owner":<OWNER_ID>}
為了提高JSON查詢的效率，CouchDB中的索引是必需的，對於任何具有排序的JSON查詢都是必需的。索引可以與鏈碼一起打包在/META-INF/statedb/couchdb/ Indexes目錄中。每個索引必須在其擴展名為*.json的文本文件中定義。索引定義采用JSON格式，遵循CouchDB索引JSON語法。例如，為了支持上述marble查詢，提供了docType和owner字段的示例索引:
{"index":{"fields":["docType","owner"]},"ddoc":"indexOwnerDoc", "name":"indexOwner","type":"json"}
鏈代碼的META-INF / statedb / couchdb / indexes目錄中的任何索引都將與用於部署的鏈代碼打包在一起。當鏈代碼安裝在peer上並在peer的一個通道上實例化時，索引將自動部署到peer的通道和鏈代碼特定的狀態數據庫（如果它已配置為使用CouchDB）。如果首先安裝鏈代碼然后在通道上實例化鏈代碼，則索引將在鏈代碼實例化時進行部署。如果鏈代碼已在通道上實例化，並且您稍后在peer上安裝鏈代碼，則索引將在鏈代碼安裝時部署。
部署后，鏈代碼查詢將自動使用索引。 CouchDB可以根據查詢中使用的字段自動確定要使用的索引。或者，在選擇器查詢中，可以使用use_index關鍵字指定索引。
在安裝的鏈碼的后續版本中可能存在相同的索引。要更改索引，請使用相同的索引名稱，但要更改索引定義。在安裝/實例化時，索引定義將重新部署到peer的狀態數據庫。
如果您已經有了大量的數據，並且稍后安裝了鏈代碼，那么在安裝時創建索引可能需要一些時間。類似地，如果您已經有大量數據並實例化了鏈碼的后續版本，那么創建索引可能需要一些時間。避免調用查詢狀態數據庫的鏈碼函數，因為在初始化索引時，鏈碼查詢可能超時。在事務處理期間，當塊提交到分類帳時，索引將自動刷新。
CouchDB Configuration(couchdb 配置)
通過將狀態數據庫配置選項從goleveldb更改為CouchDB，可以將CouchDB作為狀態數據庫啟用。 此外，couchDBAddress需要配置為指向peer使用的CouchDB。 如果CouchDB配置了用戶名和密碼，則應使用admin用戶名和密碼填充用戶名和密碼屬性。 couchDBConfig部分提供了其他選項，並記錄在案。 對core.yaml的更改將在重新啟動peer后立即生效。
您還可以傳入docker環境變量來覆蓋core.yaml值，例如CORE_LEDGER_STATE_STATEDATABASE和CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS。
以下是core.yaml的stateDatabase部分：
state: # stateDatabase - options are "goleveldb", "CouchDB" # goleveldb - default state database stored in goleveldb. # CouchDB - store state database in CouchDB stateDatabase: goleveldb couchDBConfig: # It is recommended to run CouchDB on the same server as the peer, and # not 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 have read and write authority on CouchDB username: # The password is recommended to pass as an environment variable # during start up (e.g. LEDGER_COUCHDBCONFIG_PASSWORD). # If it is stored here, the file must be access control protected # to prevent unintended users from discovering the password. 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
托管在Hyperledger Fabric提供的docker容器中的CouchDB能夠使用Docker Compose腳本使用COUCHDB_USER和COUCHDB_PASSWORD環境變量傳入環境變量來設置CouchDB用戶名和密碼。
對於Fabric提供的docker鏡像之外的CouchDB安裝，必須編輯該安裝的local.ini文件以設置admin用戶名和密碼。
Docker編寫腳本僅在創建容器時設置用戶名和密碼。 如果要在創建容器后更改用戶名或密碼，則必須編輯local.ini文件。
在每個peer節點啟動時讀取CouchDB peer選項