vania-janet/multiturn-rag-retrieval-data huggingface dataset:
"query" : 50,
"read" : 1000,
"write" : 500
}
}
}





 Default JMESPath 

A JMESPath query is applied to the output of this command by default. The default JMESPath is:

current.throughput

If a custom JMESPath query is provided, it will replace the default JMESPath.







 ibmcloud cloudant capacity-update 

Sets the target provisioned throughput capacity for an IBM Cloudant instance. When target capacity is changed, the current capacity asynchronously changes to meet the target capacity.

ibmcloud cloudant capacity-update --blocks BLOCKS



 Command options 

--blocks (int64)
: A number of blocks of throughput units. A block consists of 100 reads/sec, 50 writes/sec, and 5 global queries/sec of provisioned throughput capacity. Required.

The minimum value is 0.





 Example 

Example request

ibmcloud cloudant capacity-update --blocks 10





 Example default output 

Example CapacityThroughputInformation response.

blocks	10
query	50
read	1000
write	500





 Example full output 

Example CapacityThroughputInformation response.

{
"current" : {
"throughput" : {
"blocks" : 5,
"query" : 25,
"read" : 500,
"write" : 250
}
},
"target" : {
"throughput" : {
"blocks" : 10,
"query" : 50,
"read" : 1000,
"write" : 500
}
}
}





 Default JMESPath 

A JMESPath query is applied to the output of this command by default. The default JMESPath is:

target.throughput

If a custom JMESPath query is provided, it will replace the default JMESPath.









 Monitoring 

Commands for Monitoring resource.



 ibmcloud cloudant events-config
In summary, you must ensure that your application can handle a [429](https://cloud.ibm.com/apidocs/cloudantlist-of-http-codes) response correctly.



 Consumption of read operations by partitioned queries 

Partitioned query requests use a variable number of read operations that depend on the results returned. Consumption is based on two axes:



1. The number of rows that are read from the index that is involved in the query.
2. The number of documents read from the database, if any, during the execution of the query.





 View queries, search queries, and _all_docs 

Each block of 100 rows that are read from the index uses one read operation. In addition, each document that is read from the database during execution of a query uses one read unit.

The number of rows that are read from the index is the same as the number of results returned. Documents are only read from the database when include_docs=true is passed as a query string parameter during the query request.

You can see example costs in the following table:



Table 1. Example costs

 Number of results Include documents Total Read consumption Consumption for rows read Consumption for documents read 

 199 No 2 2 0 
 199 Yes 201 2 199 
 301 No 4 4 0 
 301 Yes 305 4 301 



Reducing use of include_docs=true is key for reducing read consumption for partitioned _all_docs, view, and search queries.





 IBM Cloudant Query 

For IBM Cloudant Query requests, the number of read operations used for index rows read relates to the rows read from the underlying index. The rows are read before filtering occurs based on parts of the selector that can't be satisfied by the index. Therefore, these results mean that the rows read value, and consumed read units, can be higher than the number of eventual results you receive.

In addition, IBM Cloudant Query must read the document for every row that is returned by the underlying index. This way, it can run further filtering that is required by the selector and passed to the query.



Table 2. Read consumption

 Number of results Number of rows returned by index Total Read consumption Consumption for rows read Consumption for documents read
GET /{db}/_design/{ddoc}/_view/{view} <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantgetview), [CouchDB](https://docs.couchdb.org/en/latest/api/ddoc/views.htmlget--db-_design-ddoc-_view-view) Execute the view function from the specified design document. <br>CouchDB documentation references more query parameters (conflicts, end_key, end_key_doc_id, attachments, att_encoding_info, sorted, start_key, start_key_doc_id, update_seq). 
 POST /{db}/_design/{ddoc}/_view/{view} <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantpostview), [CouchDB](https://docs.couchdb.org/en/latest/api/ddoc/views.htmlpost--db-_design-ddoc-_view-view) Execute the view function from the specified design document. <br>CouchDB documentation references more query parameters (conflicts, end_key, end_key_doc_id, attachments, att_encoding_info, sorted, start_key, start_key_doc_id, update_seq). 
 HEAD /{db}/_design/{ddoc}/{attname} <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantheaddesigndocumentattachment), [CouchDB](https://docs.couchdb.org/en/latest/api/ddoc/common.htmlhead--db-_design-ddoc-attname) Retrieve the HTTP headers that contain a minimal amount of information about the specified attachment. For IBM Cloudant, use {attachment_name} instead of {attname}.
HEAD /_scheduler/jobs/{job_id} <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantheadschedulerjob) Retrieve the HTTP headers of a single replication task based on its replication ID. 
 POST /_search_analyze <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantpostsearchanalyze), [CouchDB](https://docs.couchdb.org/en/latest/api/server/common.htmlsearch-analyze) Retrieve the results of analyzer tokenization of the provided sample text. 
 GET /_session <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantgetsessioninformation), [CouchDB](https://docs.couchdb.org/en/latest/api/server/authn.html?highlight=_sessionget--_session) Retrieve information about the authenticated user. <br>CouchDB documentation references a query parameter (basic). 
 POST /_session <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantpostsession), [CouchDB](https://docs.couchdb.org/en/latest/api/server/authn.html?highlight=_sessionpost--_session) Start a new session for the specified user credentials. Cookie-based user login. <br>CouchDB documentation references an extra query parameter (next). 
 DELETE /_session <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantdeletesession), [CouchDB](https://docs.couchdb.org/en/latest/api/server/authn.html?highlight=_sessiondelete--_session) Retrieve a response that instructs the HTTP client to clear the cookie. 
 GET /_utils <br>[CouchDB](https://docs.couchdb.org/en/latest/api/server/common.htmlutils) Access the built-in Fauxton administration interface.
GET /_all_dbs <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantgetalldbs), [CouchDB](https://docs.couchdb.org/en/latest/api/server/common.htmlall-dbs) Query a list of all database names in the instance. 
 POST /_api/v2/api_keys <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantpostapikeys) Generate an API key. 
 GET /_api/v2/db/{db}/_security <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantgetcloudantsecurity) Retrieve database permissions information. 
 PUT /_api/v2/db/{db}/_security <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantputcloudantsecurity) Modify only Cloudant related permissions to database. 
 GET /_api/v2/monitoring <br>[Cloudant](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-monitoring-an-ibm-cloudant-clustermonitoring-metrics-overview) Monitor a specific cluster aspect. 
 GET /_api/v2/user/config/cors <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantgetcorsinformation) Retrieve CORS configuration information. 
 PUT /_api/v2/user/config/cors <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantputcorsconfiguration) Modify the CORS configuration. 
 GET /_db_updates <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantgetdbupdates), [CouchDB](https://docs.couchdb.org/en/latest/api/server/common.htmldb-updates) List all database events in the instance.
DELETE /{db}/_design/{ddoc}/{attname} <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantdeletedesigndocumentattachment), [CouchDB](https://docs.couchdb.org/en/latest/api/ddoc/common.htmldelete--db-_design-ddoc-attname) Delete the attachment of the specified design document. 
 POST /{db}/_ensure_full_commit <br>[CouchDB](https://docs.couchdb.org/en/latest/api/database/compact.htmlpost--db-_ensure_full_commit) Commit any recent changes to the specified database to disk. 
 POST /{db}/_explain <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantpostexplain), [CouchDB](https://docs.couchdb.org/en/latest/api/database/find.htmlpost--db-_explain) Identify which index is being used by a particular query. 
 POST /{db}/_find <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantpostfind), [CouchDB](https://docs.couchdb.org/en/latest/api/database/find.htmlpost--db-_find) Find documents that use a declarative JSON querying syntax. <br>IBM Cloudant documentation references more request body fields (r, bookmark). 
 GET /{db}/_index <br>[Cloudant](https://cloud.ibm.com/apidocs/cloudantgetindexesinformation), [CouchDB](https://docs.couchdb.org/en/latest/api/database/find.htmlget--db-_index) List indexes.
Or you can stop views from auto-updating by adding one of the following options to a design document. You can stop all index types from indexing if you set "autoupdate": false.

See the following examples:

{
"_id": "_design/lookup",
"autoupdate": false,
"views": {
"view": {
"map": "function(doc)..."
}
}
}

{
"_id": "_design/lookup",
"autoupdate": {"views": false},
"views": {
"view": {
"map": "function(doc)..."
}
}
}





 View freshness 

By default, all index results reflect the current state of the database. IBM Cloudant builds its indexes automatically and asynchronously in the background. This practice usually means that the index is fully up to date when you query it. If not, by default, IBM Cloudant applies the remaining updates at query time.

IBM Cloudant provides a few parameters, described next to alter this behavior. We recommend against using them as the side-effects typically outweigh their benefit.



 Parameters 

The update option indicates whether you're prepared to accept view results without waiting for the view to be updated. The default value is true, meaning that the view is updated before results are returned. The lazy value means that the results are returned before the view is updated, but that the view must then be updated anyway.

While IBM Cloudant strives to keep indexes updated in the background, no guarantee exists about how out-of-date the view is when queried with update=false or update=lazy.

The stable option indicates whether you would prefer to get results from a single, consistent set of shards. The false value means that all available shard replicas are queried and IBM Cloudant uses the fastest response. By contrast, setting stable=true forces the database to use just one replica of the index.
The resolver sends the request to the Cloudant database for the requested DNS record, and determines whether the VPC can access the requested DNS zone.
4. If the DNS zone information is not part of the user's configuration, the DNS query is forwarded to a public resolver.







 DNS Services deployment model 

DNS Services is a multitenant solution. Control plane is accessed by all customer environments through public endpoints behind IBM Cloud® Internet Services. Public networks are not used for accessing the data plane of the service. Both the control and data plane of the service are shared across tenants. The service uses a Cloudant database that is accessed securely by sending requests over a public network. This data is encrypted in transit using SSL. Data is also encrypted at rest in Cloudant.
Therefore, these results mean that the rows read value, and consumed read units, can be higher than the number of eventual results you receive.

In addition, IBM Cloudant Query must read the document for every row that is returned by the underlying index. This way, it can run further filtering that is required by the selector and passed to the query.



Table 2. Read consumption

 Number of results Number of rows returned by index Total Read consumption Consumption for rows read Consumption for documents read 

 5 199 201 2 199 
 199 199 201 2 199 
 5 301 305 4 301 
 301 301 305 4 301 



Using appropriate indexes is key for reducing read consumption for partitioned IBM Cloudant Query queries.







 Consumption of read and write operations by replication 

[Replication](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-replication-guide) between two databases uses read capacity on the source database and write capacity on the target database. The replicator is aware of the rate limits in IBM Cloudant and employs staggered retry logic when encountering 429 responses associated with reaching the provisioned throughput capacity limits set for the instance.

You can use the default parameters and replicate a database with a large backlog of documents. In that case, a single replication job uses close to 2500 - 3000 reads per second on the source database and a few writes per second on the target database. Users can reduce the approximate read throughput that is used by a replication job by adjusting the [performance-related options](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-advanced-replicationperformance-related-options) that are associated with [tuning replication speed](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-replication-guidetuning-replication-speed). The following table provides recommended options for users who want to reduce the read capacity used on the source database:



Table 3. Reduce read capacity

 http_connections worker_processes Approximate reads per second on source database 

 2 1 200 
 6 2 1000 
 12 3 2000 
 20 4 3000 (This value is the default.) 







 Viewing and changing capacity
To return the readings for a specific device from a partition, you can use an IBM Cloudant Query index. For this document, use POST to _index with an index definition that includes the partitioned field set to true.

For Query index definitions, the partitioned field isn't nested inside an options object.

For these queries, you need two partitioned indexes:



1. By timestamp
2. By device ID and timestamp





 Uploading partitioned index by timestamp 

Upload the index by timestamp to the database by using this command:



* Curl
* Java
* Node
* Python
* Go



curl -X POST "$SERVICE_URL/readings/_index" -H 'Content-Type: application/json' --data '{
"index": {
"fields": [
{"ts": "asc"}
]
},
"name": "timestamped-readings",
"type": "json",
"partitioned": true
}'

import com.ibm.cloud.cloudant.v1.Cloudant;
import com.ibm.cloud.cloudant.v1.model.IndexDefinition;
import com.ibm.cloud.cloudant.v1.model.IndexField;
import com.ibm.cloud.cloudant.v1.model.IndexResult;
import com.ibm.cloud.cloudant.v1.model.PostIndexOptions;

Cloudant service = Cloudant.newInstance();

IndexField indexField = new IndexField.Builder()
.add("ts", "asc")
.build();

IndexDefinition index = new IndexDefinition.Builder()
.addFields(indexField)
.build();

PostIndexOptions indexOptions = new PostIndexOptions.Builder()
.db("readings")
.index(index)
.name("timestamped-readings")
.type("json")
See [PR](https://github.com/apache/couchdb/pull/1195).

_design_docs handler
: Fix a bug with total row count in the _design_docs handler. See [PR](https://github.com/apache/couchdb/pull/1744).

Replication filters
: Optimizations to the _doc_id and _design_docs replication filters. See [issue](https://github.com/apache/couchdb/issues/1737).

Index jobs
: Fix a regression where long-running index jobs can fail.







 November 2018 



 4 November 18 

The following changes were made in build 7410:

Improvements
: Internal changes and bug fixes.





 1 November 2018 

The following changes were made in build 7426:

Improvements
: Internal bug fixes to data compression, search, and core database components.

Audit logs
: Include [CRN](https://cloud.ibm.com/docs/account?topic=account-crn) in audit logs.

Replicator
: Replicator stability improvements.

q parameter
: Improve validation of q parameter on database creation. See [COUCHDB-1582](https://issues.apache.org/jira/browse/COUCHDB-1582).

_bulk_get endpoint
: Fix error in _bulk_get endpoint for the _users database. See [COUCHDB-1650](https://issues.apache.org/jira/browse/COUCHDB-1650).

JavaScript URL rewrites
: Fix JavaScript URL rewrites hanging on POST or PUT requests. See [COUCHDB-1612](https://issues.apache.org/jira/browse/COUCHDB-1612).

IBM Cloudant Query and invalid reduce functions
: Fix invalid reduce functions in IBM Cloudant Query indexes that prevent indexing. See [COUCHDB-1666](https://issues.apache.org/jira/browse/COUCHDB-1666).







 October 2018 



 11 October 2018
: Number of provisioned throughput capacity blocks, where block is 100 reads/sec, 50 writes/sec, and 5 global queries/sec.

throughput
: A breakdown of the specific number of reads/sec, writes/sec, and global queries/sec.

See the following example JSON response with the target capacity set:

{
"current": {
"throughput": {
"read": 500,
"write": 250,
"blocks": 5,
"query": 25
}
},
"target": {
"throughput": {
"read": 1000,
"write": 500,
"blocks": 10,
"query": 50
}
}
}
Show more





 View the current consumption of provisioned throughput capacity used 

Use a GET method to the /_api/v2/user/current/throughput endpoint to see the current consumption of provisioned throughput capacity for an IBM Cloudant instance. The current consumption shows the quantities of reads, writes, and global queries conducted against the instance for a given second. When you use this endpoint, it is a best practice to aggregate this data continuously over time to get a more comprehensive view of a IBM Cloudant instance's throughput consumption patterns.

Method
: GET

Path
: /_api/v2/user/current/throughput

Response
: The current consumption of provisioned throughput capacity used, broken down by the number of reads, writes, and global queries.

See the following example request to retrieve the current consumption of capacity by using HTTP:

GET $SERVICE_URL/_api/v2/user/current/throughput

See the following example request to retrieve the current consumption of capacity:



* Curl
* Java
* Node
* Python
* Go



curl "$SERVICE_URL/_api/v2/user/current/throughput"

import com.ibm.cloud.cloudant.v1.Cloudant;
import com.ibm.cloud.cloudant.v1.model.CurrentThroughputInformation;
This type of database can be less complex to work with since no partitioning scheme needs to be defined, but you can create only global secondary indexes.

IBM Cloudant strongly encourages you to use a partitioned database for best long-term database performance where the data model allows for logical partitioning of documents.

The partitioning type of a database is set at database creation time. When you create a database, use the partitioned query string parameter to set whether the database is partitioned. The default for partitioned is false, maintaining compatibility with an earlier version.

The partitioning type can't be changed for an existing database.

For more information, see [Database partitioning](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-database-partitioning).
"baz": 5
}
}







 Changes feed 

IBM Cloudant publishes the adds, edits, and deletes affecting a database through a single HTTP feed from the [_changes endpoint](https://cloud.ibm.com/apidocs/cloudantpostchanges-databases). This feed can be used by your application to trigger events. You can access the feed by using HTTP or curl, as shown in the examples. Using the feed=continuous option means that the stream provides you with every change that is necessary to get the most recent version of every document in the database.

For more information, see [Using the IBM Cloudant changes feed FAQ](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-faq-using-changes-feed&code=javascript).

See the following example that uses HTTP to query the changes feed:

GET /$DATABASE/_changes?feed=continuous HTTP/1.1
Host: $SERVICE_URL
Authorization: ...

See the following example that uses the command line to query the changes feed:

curl "$SERVICE_URL/$DATABASE/_changes?feed=continuous"

The changes are described by using one line per change. Each change consists of:



1. A string that contains a sequence number (seq).
2. A string that contains the ID of the document that was changed.
3. An array of changes.



To see the document body itself, append &include_docs=true to the curl command.

Each change is described by using the format that is shown in the following (abbreviated) example.

See the following example _changes feed:

{
"seq":"11-g1A...c1Q",
"id":"6f8ab9fa52c117eb76240daa1a55827f",
"changes":[
{
"rev":"1-619d7981d7027274a4b88810d318a7b1"
}
]
}
When a DNS query for a particular DNS zone is received by the resolver, it identifies the VPC where the DNS query originated and validates that it can access the DNS zone of the DNS query. If the VPC doesn't have access to the DNS zone, the DNS query is forwarded to a public resolver.

The public resolver that is used for forwarding is also in the IBM Cloud private underlay. A public resolver means that it resolves public DNS zones, although it is instantiated in the IBM Cloud private network. The public or private resolvers are not accessible from the internet.

Access to the multitenant control plane and data plane infrastructure is strictly controlled and restricted on an as-needed basis to a small number of operations personnel for administrative and troubleshooting purposes.

Zoom

![Architecture diagram](https://cloud.ibm.com/docs-content/v1/content/d56dbd8ab7d14086029681ee71679e14aea53723/dns-svcs/images/data-isolation.png)

Figure 1. Architectural diagram of control plane and data plane.



1. Customer A and Customer B create DNS configuration records through the multitenant control plane infrastructure. Records get saved in the database as separate documents. Configuration information of different users gets saved in the database.
2. A data plane DNS request from Customer A and Customer B's VPCs gets routed to the DNS resolvers 161.26.0.7 and 161.26.0.8 through the multitenant data plane infrastructure.
3. The resolver sends the request to the Cloudant database for the requested DNS record, and determines whether the VPC can access the requested DNS zone.
4. If the DNS zone information is not part of the user's configuration, the DNS query is forwarded to a public resolver.







 DNS Services deployment model 

DNS Services is a multitenant solution. Control plane is accessed by all customer environments through public endpoints behind IBM Cloud® Internet Services. Public networks are not used for accessing the data plane of the service.
Configuring IBM Cloudant for cross-region disaster recovery 

The [IBM Cloudant disaster recovery guide](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-disaster-recovery-and-backupdisaster-recovery-and-backup) explains that one way to enable disaster recovery is to use IBM Cloudant replication to create redundancy across regions.

For more information, see how to [retrieve replication scheduler documents](https://cloud.ibm.com/apidocs/cloudantgetschedulerdocs) and monitor replication status.

You can configure replication in IBM® Cloudant® for IBM Cloud® by using an "active-active" or "active-passive" topology across data centers.

The following diagram shows a typical configuration that uses two IBM Cloudant accounts, one in each region:

Zoom

![This diagram contains a customer, global load balancer/DNS, and two data centers. The data centers contain a load balancer, three app servers, and a database, which replicates between each database.](https://cloud.ibm.com/docs-content/v1/content/522c6f62358b063f921283400a601c3f9bc66f08/Cloudant/images/active-active.svg)

Figure 1. Example active-active architecture

Remember these important facts:



* Within each data center, IBM Cloudant already offers high availability by storing data in triplicate across three servers.
* Replication occurs at the database rather than account level and must be explicitly configured.
* IBM Cloudant doesn't provide any Service Level Agreements (SLAs) or certainties about replication latency. IBM Cloudant doesn't monitor individual replications. Your own strategy for detecting failed replications and restarting them is advisable.





 Before you begin an active-active deployment