Features of Cloudant NoSQL Database

IBM® Cloudant™ NoSQL DB for Bluemix™ is a NoSQL database as a service (DBaaS) that scales globally, runs nonstop, and handles a wide variety of data types such as JSON, full-text, and geospatial. Cloudant NoSQL Database is an operational data store that is optimized to handle concurrent reads and writes, and provides high availability and data durability.

Cloudant provides a RESTful API to create, read, update, and delete documents.

Reading a document

The Cloudant RESTful API makes every document in your Cloudant database accessible as JSON through a URL, which makes Cloudant so powerful for web applications.

Each document in Cloudant has a unique _id field that can be used to retrieve that document.

To retrieve a document by using the API, simply append the document’s ID to the URL of the database. For example, for a document of _id foo in the mydb database, the GET URL to retrieve the document will look like this:

GET https://[username].cloudant.com/mydb/foo

Inserting a document

Documents can be inserted into Cloudant individually or in bulk.

To insert documents, you can provide a unique value for the _id .field. If the document to be inserted doesn’t define an _id value, a value is assigned to it during the insertion.

If you initially define an _id for your document, you must ensure that the _id isn’t already being used. If it is, the insertion will fail.

Inserting by using cURL

Command:

curl -d '{"season": "summer", "weather": "usually warm and sunny"}' -X POST https://[username].cloudant.com/crud/ -H "Content-Type:application/json"

Response:

{"ok":true,"id":"590e2bca76c09882e37dea534b000be3","rev":"1-0af5e64fe24d262db237b9f14046f490"}

If you want to set the _id when you insert, you can do it in two ways: POST and PUT.

Updating and deleting documents

The _rev field is added to your documents by the server when you insert or modify them, and is included in the server response when you make changes or read a document. The _rev value is built from a crude counter and a hash of the document and is used to determine what needs to be replicated between servers, and whether a client is trying to modify the latest version of a document. For this reason, updates need to send the _rev token to be able to modify a document.

Important: The _rev field should not be used to build a version control system. It’s an internal value that is used by the server and older revisions are transient and removed regularly.
The code or command line to update a document is the same as to insert. Be sure to include the _rev field in the document body.

As you might expect, deletions are done by using the DELETE HTTP method. In some cases, firing a DELETE might not be possible, so you can also delete a document by adding _deleted to the document and update it. This is especially useful for bulk operations where many documents might be created, updated, or deleted in a single HTTP operation. Because you’ll be removing the document, you can delete the rest of its contents, apart from the _id_rev, and _deleted fields. If you leave other fields, they will be in the document’s “tombstone.” Leaving these fields can be useful when replicating or validating document edits.

Cloudant allows the creation of indexes by using MapReduce

Secondary indexes, or views, are defined in a map function, which pulls out data from your documents and an optional reduce function that aggregates the data emitted by the map.

These functions are written in JavaScript and held in “design documents that are special documents that the database knows contain these and other functions. Design documents are special documents that define secondary indexes.

Sample design document with MapReduce functions

{
  "_id": "_design/name",
  "views": {
    "view1": {
      "map":"function(doc){emit(doc.field, 1)}",
      "reduce": "function(key, value, rereduce){return sum(values)}"
    }
  }
}

The naming convention for design documents is such that the name follows _design/ in the _id. This code defines view1 for the design document name. Design documents can contain multiple views; each is added to the view’s object.

Cloudant Query provides a declarative way to define and query indexes

Cloudant Query is a declarative JSON querying syntax for Cloudant databases. Indexes can be of two different types: JSON or text. If you know exactly what data you want to look for or you want to keep storage and processing requirements to a minimum, you can specify how the index is created by making it of type JSON. For maximum possible flexibility when looking for data, you would typically create an index of type text. Indexes of type text have a simple mechanism for automatically indexing all the fields in the documents.

Here’s a sample JSON document to create a query index:

{
  "index": {
    "fields": ["make"]
  },
  "name": "make-index",
  "type": "json"
}

After the query index is created, the index can be searched by using a selector that is also written as a JSON document. Selectors are conceptually similar to an SQL statement’s WHERE clause.

Here’s an example selector to return documents with the make VW and with a model year of 2000 or later:

{
  "selector": {
    "make": "VW",
    "year": {"$ge": 2000}
  }
}

Cloudant Query provides two API endpoints: _index and _find. These are used to manage indexes and perform queries against them by using selectors.

Cloudant Sync simplifies large-scale mobile development

Cloudant Sync enables you to push database access to the farthest edge of the network: mobile devices, remote facilities, sensors, and Internet-enabled goods, so that you can:

  • Scale bigger
  • Enable client apps to continue running offline

Cloudant Sync allows mobile and distributed apps to scale by replicating and syncing data between multiple readable, writeable copies of the data in other data centers, and even on mobile iOS and Android devices. This is much easier and more cost efficient than growing a single, central database to handle all data collection.

Cloudant Sync allows you to create a single database for every user: you simply replicate and sync the copy of the database in Cloudant with a local copy on a user’s phone or tablet (or vehicle, sensor, appliance, and so on). This syncing can reduce round-trip database requests with the server. If there’s no network connection, the app runs from the database on the device; when the network connection is restored, Cloudant resyncs the device and server.