Couchbase Tutorial

What is Couchbase?

Couchbase is a distributed NoSQL database that automatically distributes data across commodity servers or virtual machines. It does not require schema creation before inserting data and stores data in key-value format, opaque binary object, or JSON object format.

Couchbase is easy to develop applications with professional Couchbase SDKs and client libraries available for popular languages and application development frameworks.

One unique attribute of Couchbase is its Memcached protocol compatibility, which allows existing applications to transition to Couchbase Server without changing production code.

Relational Database vs Couchbase

Relational databases have been working for a long time, but they struggled to solve problems introduced by the creation of applications for millions of users, the increase of mobile broadband, and the increasing number of devices.

Relational databases organize data as tables, with each row having a specific schema. Simple data types can be represented in a single table, but complex data types like dictionaries, hashes, arrays, and lists cannot be represented in a single table.

Couchbase is a key value store that allows for the storage of simple and binary data types. It also allows for the representation of complex data types in JSON format, which is a special class of string that represents data structures.

This makes it easier to maintain and keep an application online, as well as performing sophisticated things with the data model.

Why to use Couchbase?

Couchbase provides durable disk-based storage for data and includes a built-in data cache derived from Memcached. This ensures predictable, low-latency access for random reads and writes.

Capacity can be added or removed from a live Couchbase cluster with no application downtime. The administrator UI allows any number of servers to be added or removed at once.

Couchbase supports data replication, with configurable replica copies and live rebalancing enabling continuous operations.

A rich set of built-in monitoring and management tools support the constant uptime of a Couchbase cluster.

A management REST interface supports metrics and administration functionality.

Features of Couchbase:

Couchbase is available for Windows, Linux, and Mac

It is multi-model distributed

It is memory first

Highly Scalable

Developer friendly

Database is modular

Multiple backup services.

Couchbase Architecture:

The Couchbase architecture consists of six node clusters with identical sets of services, including cluster manager, data service, index service, query service, search service, manage cache, and storage.

These services support data retrieval, data insertion, view indexes, nickel indexes, full text search indexes, manage cache, and reduce latency.

What is a Key Value Service?

The first service in Couchbase is the data service, also known as a key value service. All data written in Couchbase is stored on the nodes running the data service.

The fastest way to access data is via key value operation, which requires the application or client to provide the key and Couchbase will return the document. A caching layer maintains frequently accessed data in memory, while a persistent layer provides data storage on the disk.

If an application cannot run key value operations and needs to perform secondary lookups, a query service called SQL++ is available.

This service is a SQL for JSON, allowing anyone from a relational database background to use their existing skills and expertise in Couchbase.

What is Indexing Capability?

Indexing capability is also available to support query services and speed up queries. Secondary indexes can be created on attributes or combination of attributes, allowing for faster lookups and faster query performance.

There are two forms of storage available for indexing services: memory optimized indexes (MOI) and standard GSI (plasma index).

MOI requires the entire index to fit in memory, while GSI allows the index to spill over to the disk if there is not enough memory.

What is a Query Service?

The query service determines if there is a supporting index available and uses it to retrieve necessary attributes from the index node.

If there is no covering index, the query service goes to the data node, which has the entire JSON document available.

If a search function is used in the query, the query service calls the full text search service and retrieves the necessary data.

Full Text Search:

Full text search is also supported, eliminating the need for additional technology in text tags and simplifying architecture.

The database change protocol (DCB) is used to keep global secondary indexes and full text search indexes up-to-date.

The full text search service subscribes to the DCB stream, ensuring that mutations are applied to both secondary and full text search indexes as data is created, updated, or deleted.

Couchbase Analytics:

Couch-based analytics offers real-time access to data, eliminating the need for ETL processes and allowing immediate use of data.

The DCB protocol is used to move data from the data service into the analytics node, ensuring that any changes made on the data nodes are immediately applied to the analytics node.

A filter is also available on the DCB stream to filter out data, allowing reporting to only be done on a subset of the data rather than the entire data set.

XCDR (Cross Data Centre Application):

XDCR (cross data center replication) is another service available, enabling data replication from one cluster to another or across multiple clusters.

This can be done unidirectionally, bidirectionally, or multi-direction. A filtering capability is also available in XDCR, allowing only the necessary data to be replicated to the other side.

XDCR offers memory-based replication at network speed, varying latency depending on distance and network speed.

Connectors can be used with Kafka or Spark to replicate data from couch-based to Oracle or relational databases, or vice versa.

These connectors facilitate data movement between clusters, allowing for efficient data transfer between clusters. They are particularly useful for moving data between clusters.

Concept of User ID’s:

It allows for creativity and control by the programmer. They discuss various methods for creating IDs, such as using an email address or username as a key, incrementing accounts, and creating a lookup for the email address.

They also mention using custom mechanisms like UUID, GUID, or Snowflake to retrieve user documents. They also mention the use of social logins, such as Facebook, where one social login does not require a lookup.

They store the user’s Facebook ID directly when reauthenticating with Facebook. If a lookup is used with a Facebook ID, a lookup document is created to log in with the email address.