Document-Centric NoSQL

Document-centric databases such as Couchbase or MongoDB take a completely different approach. Instead of structured tables, these databases save information with keys and values. In principle, each document could use its own keys. These NoSQL databases focus on the dataset itself and are therefore considered document-centric, not table-centric. Index keys allow the database to find the stored data again. With simple calculated hash values, MongoDB and Couchbase can very easily distribute their documents across multiple nodes to achieve redundancy.

This solution basically works like GlusterFS or Ceph. Document databases use the vendor's API instead of a standardized query language. Cases in which application developers with an existing SQL connection convert their application to NoSQL are accordingly rare. The approaches are simply too different.

On the other hand, developers of modern web applications can handle this type of data storage quite quickly and easily. Simple function libraries exist for every modern programming language to simplify the handling of document databases greatly and eliminate the tedious process of elaborating a data table and variable structure up front.

Nevertheless, the lack of a unified query language for document-centric NoSQL databases is certainly one of the reasons these technologies have been slow to establish themselves as generic databases for off-the-shelf applications. If you want to take a closer look at these tools, you don't have to look far. Couchbase has a prebuilt Helm chart that makes installation on Kubernetes a breeze [5].

Special Services

NoSQL databases for general use are joined by a few modern scale-out databases for special applications, including Elasticsearch, which has a document structure similar to MongoDB and can be operated quite simply across several nodes. Elasticsearch, as the name suggests, provides a strong search function, which is why it is often used where comparatively unstructured data (e.g., logfiles) need to be searched for specific information.

Users are increasingly replacing databases with simple key-value stores in applications with low data volumes or simple datasets. Redis is certainly one of the most popular at the moment. Many scale-out applications use this data structure store as a communications hub, allowing pods to exchange data and configuration information. Redis runs in-memory but can also dump data to persistent storage at predetermined intervals to reload inventory data after a pod restart.

Conclusions

With concepts such as Kubernetes' StatefulSet, classic databases such as MariaDB, MS SQL, or PostgreSQL can be nicely accommodated in a container environment. Kubernetes delivers good, if not better, database availability than an elaborate active-passive failover construct with Pacemaker. However, this setup requires a reliable storage back end. NoSQL databases promise better integration in scale-out environments, especially for applications with large but not necessarily contiguous datasets. Migrating existing SQL applications to NoSQL would seem to be, with the possible exception of Cassandra, too expensive in most cases, because the data structures differ greatly.