MapR-DB is an enterprise-grade, high performance, NoSQL (“Not Only SQL”) database management system. It is used to add
real-time, operational analytics capabilities to big data applications. As a multi-model NoSQL database, it supports both
JSON document models and wide column data models.

Since MapR-DB tables are created in volumes, when you restrict the volume, you also restrict the table data. If a volume
is restricted to a subset of a cluster's nodes, then it allows you order to isolate sensitive data or applications, and
even use heterogeneous hardware in the cluster for specific workloads.

MapR-DB is an enterprise-grade, high performance, NoSQL (“Not Only SQL”) database management system. It is used to add
real-time, operational analytics capabilities to big data applications. As a multi-model NoSQL database, it supports both
JSON document models and wide column data models.

This topic describes how MapR-DB tables are implemented directly in the MapR file system (MapR-FS) which allows MapR-DB
to leverages the same architecture as the rest of the MapR platform which provides minimal additional management.

Information about and location of tables (and files) is not tracked directly, but through MapR-FS containers by the
CLDB. Because this architecture keeps the CLDB size small, it becomes practical to store 10s of exabytes in a MapR cluster,
regardless of the number of tables and files.

Due to the architecture of how updates to table regions (also called tablets) are applied and and replicated, data in
table regions are instantly available. Tables and table regions are part of abstract entities called containers which provide the automatic replication of table regions (with a default of three) across the nodes of a cluster.

Since MapR-DB tables are created in volumes, when you restrict the volume, you also restrict the table data. If a volume
is restricted to a subset of a cluster's nodes, then it allows you order to isolate sensitive data or applications, and
even use heterogeneous hardware in the cluster for specific workloads.

Since MapR-DB tables are created in volumes, mirroring of volumes lets you automatically replicate differential data
in real-time across clusters. You might want mirror volumes to create disaster recovery solutions for databases or to
provide read-only access to data from multiple locations.

MapR-DB can be used as both a document database and a wide-column database. As a document database, OJAI documents are
stored in MapR-DB JSON table. As a wide-column database, binary files are in stored MapR-DB binary tables.

Data in one table can be replicated to another table that is in the same cluster or in a separate cluster. This type of
replication is in addition to the automatic replication that occurs with table regions within a volume.

The MapR Sandbox for Hadoop is a fully-functional single-node cluster that gently introduces business analysts, current
and aspiring Hadoop developers, and administrators (database, system, and Hadoop) to the big data promises of Hadoop and
its ecosystem.

These release notes contain information about Version 5.2 of the MapR Converged Data Platform.

Multi-Tenancy

Since MapR-DB tables are created in volumes, when you restrict the volume, you also
restrict the table data. If a volume is restricted to a subset of a cluster's nodes, then it
allows you order to isolate sensitive data or applications, and even use heterogeneous hardware
in the cluster for specific workloads.

For example, you can use data placement to keep personally identifiable information
on nodes that have encrypted drives, or to keep MapR-DB tables on nodes that have SSDs. You
can also isolate work environments for different database users or applications and place
MapR-DB tables on specific hardware for better performance or load isolation

Isolation of work environments for different database users or applications lets you
set policies, quotas, and access privileges at for specific users and volumes. You can run
multiple jobs with different requirements without conflict.

As an example, the diagram below depicts a MapR cluster storing table and file data.
The cluster has three separate volumes mounted at directories /user/john,
/user/dave, and /project/ads. As shown, each directory
contains both file data and table data, grouped together logically. Because each of these
directories maps to a different volume, data in each directory can have different policy. For
example, /user/john has a disk-usage quota, while /user/dave
is on a snapshot schedule. Furthermore, two directories, /user/john and
/project/ads are mirrored to locations outside the cluster, providing
read-only access to high-traffic data, including the tables in those volumes.

Example: Restricting table storage with quotas and physical topology

This example creates a table with disk usage quota of 100GB restricted to certain
data nodes in the cluster. First, we create a volume named
project-tables-vol, specifying the quota and restricting storage to nodes in
the /data/rack1 topology, and mounting it in the local namespace. Next, we
use the HBase shell to create a new table named datastore, specifying a path
inside the project-tables-vol
volume.