Glossary

Principal terms and their meanings.

The following glossary introduces the principal terms used in descriptions of Couchbase Server-technology. Use the links to locate the full descriptions of each.

  • Server: An instance of Couchbase Server — an open source, distributed, NoSQL document-oriented engagement database, specialized to provide low-latency data management for large-scale interactive web, mobile, and other applications. Each instance runs on its own physical or virtual machine.

  • Cluster: One or more instances of Couchbase Server, each running on an independent node; but cooperating with any and all others, so as to form a unified system; whereby resources are shared, and a single interface provided for data-access and management.

  • Bucket: A logical, user-named entity that groups items; allowing them to be accessed, indexed, replicated, and access-controlled. There are three types:

    • Couchbase: Retains data both in memory and on disk.

    • Ephemeral: Retains data in memory only.

    • Memcached: Designed to be used in the context of other database platforms, such as ones employing relational database technology, in order to provide a managed memory-cache for frequently-used data.

  • Memory: An automatically managed caching layer, supporting high-speed data-access.

  • Storage: The persistent retention of items on disk, in compressed form, with high-speed threaded access.

  • Data: Items, each of which consists of a key by which the item is referenced; and an associated value, which must be either binary or a JSON document.

    • Access: The creation, update, and deletion of items, as supported by the Couchbase Web Console UI and the Couchbase SDK.

    • Model: A lightweight, flexible schema; which can be progressively evolved by applications over time, and allows information to be stored in the form of items.

  • Node: A computer (potentially, a virtual machine) running an instance of Couchbase Server.

    • Addition: The ability to add a Couchbase Cluster of one node to another existing cluster, so that a single, combined cluster is produced. Following addition, rebalance ensures that data and indexes are optimally distributed across all available nodes.

    • Failover: The ability to allow healthy nodes to continue functioning as a cluster, potentially without data-loss, when one node has gone offline. Rebalance ensures that data and indexes are optimally distributed across all available nodes. Failover can be automated.

    • Removal: The ability to remove a node from a cluster. Following removal, rebalance ensures that data and indexes are optimally distributed across all available nodes.

  • Rebalance: The process of redistributing data and indexes optimally among the available nodes of a cluster. This should be performed whenever a cluster-configuration has changed.

  • Availability: The preservation of data from system-failure, by the following means:

    • Backup and Restore: The storing in archive-repositories of the current state of data, indexes, and bucket configurations; and the restoration of such state to a running cluster.

    • Cross Datacenter Replication (XDCR): The replication of data between clusters, to ensure the least chance of data-loss in the event of data-center failure, and to provide high-performance data-access for globally distributed applications.

    • cli:cbcli/couchbase-cli-recovery.adoc: The restoration of current data to a node that is recovered from failure: either by updating data still held locally, or by substituting current data from other nodes.

    • Intra-Cluster Replication: The maintenance and continuous update of data-copies, distributed across the nodes of a cluster, to ensure the least chance of data-loss in the event of single-node failure.

  • Deployment: The installation of a single instance of Couchbase Server, subsequent to the appropriate resourcing and configuration of an underlying platform.

    • Cloud: Couchbase Server runs on a pre-established cloud-configuration.

    • Container: Couchbase Server runs within a software container or virtual machine.

    • Native: Couchbase Server runs on an individual, physical machine.

  • Initialization: The configuration of a new instance of Couchbase Server, either as the first node in a new cluster, or as an additional node for an existing cluster.

  • Security: Couchbase-Server Authentication, Authorization, Auditing, and Encryption.

    • Authentication: To access Couchbase Server, administrators and applications must be authenticated. Authentication is a process for identifying a user who is attempting to access a system. Authentication can be attempted by passing credentials, or by means of certificates.

    • Authorization: Role-Based Access Control (RBAC), whereby access-privileges are assigned to fixed roles that are assigned to administrators and applications.

    • Auditing: The detailed, automated recording of actions performed on Couchbase Server, allowing administrative review; in order to ensure that system-management tasks are being appropriately performed.

  • Services: Couchbase Server-facilities that support different forms of data-access:

    • Analytics: Supports join, set, aggregation, and grouping operations that are expected to be large, long-running, and highly consumptive of memory and CPU resources.

    • Data: Supports the storing, setting, and retrieving of data-items, specified by key.

    • Eventing: Supports near real-time handling of changes to data: code can be executed both in response to document-mutations, and as scheduled by timers.

    • Index: Creates indexes, for use by the Query and Analytics services.

    • Query: Parses input specified in the N1QL query-language, executes queries, and returns results. The Query Service interacts with both the Data and Index services.

    • Search: Creates indexes specially purposed for Full Text Search. This supports language-aware searching; allowing users to search for, say, the word beauties, and additionally obtain results for beauty and beautiful.

  • Scaling: The optional allocation of services to cluster-nodes in accordance with workload-requirements. For example, if a particular service is expected to handle a heavy workload, it can be allocated a large memory quota, and might be deployed as the only service on its node, to ensure optimal availability of CPU cycles.

  • Tools: Provided by Couchbase Server to support cluster-management:

    • CLI: Command-line-based management.

    • Couchbase Web Console: UI-based management.

    • REST API: RESTful management. Note that the REST API, as well as being directly available to the administrator, also underlies the features of the Couchbase Web Console and CLI.

  • java-sdk::start-using-sdk.adoc: Libraries that support cluster-access for applications written in Java, .NET, C, Go, PHP, Python, and NodeJs.