What is NoSQL and what are database operators?

In the previous blog, SQL vs NoSQL Database, we discussed the difference between two major database categories. In a nutshell, the main difference between NoSQL and SQL is that NoSQL adopts a ‘right tool for the job’ approach, whilst SQL adopts a ‘one tool for all the jobs’.

While SQL remains a standard in organisations worldwide, many other database systems have recently emerged. This is mainly due to the rising volume of highly varied data, scalability, changing storage requirements, the need for high processing power, low latency, and evolving requirements in analytics that database applications have to cater to. NoSQL is a class of newer database systems that offer alternatives to traditional RDBMS so it can cater for one or more of these specialised needs.

Sponsored

class="wp-block-image">

What does NoSQL mean?

NoSQL stands for “not only SQL” rather than “no SQL”. NoSQL databases aim to build flexible schemas and specific data models. Typically, these databases are built for the web or for scenarios where traditional relational databases can have limitations. NoSQL databases can be quicker to develop applications with, can offer more flexibility and scale; and they often offer excellent performance due to their specialised nature.

Why use NoSQL?

NoSQL databases are widely recognised for their ease of development, functionality, and performance at scale. Multiple NoSQL databases have different characteristics and purposes. However, they share fundamental elements:

• Developer friendliness
• Can store various data types (structured, unstructured and semi-structured)
• Can update schemas and fields easily
• Specialised to solve specific use cases
• Can scale horizontally in some databases such as MongoDB, OpenSearch, etc.
• Some NoSQL communities benefit from open systems and concerted commitment to onboarding users.
• There are also multiple proprietary NoSQL services that organisations can use.

NoSQL database examples

There are multiple types of NoSQL databases, such as document databases, key-value stores, wide-column databases, and graph databases.

• Document databases are primarily built for storing information like documents, including JSON. Examples are MongoDB and Couchbase. ElasticSearch, and OpenSearch.
• Databases store data in a “key-value” format and optimise it for reading and writing—for example, Redis.
• Wide-column databases that use the tabular format of relational databases, allowing a wide variance in how data is named and formatted in each row – even on the same table. For instance, Cassandra.
• Graph databases that use graph structures to define the relationships between stored data points, such as Neo4j.

What are database operators

The databases mentioned in the previous section must be managed and operated in the production environment. This means that database administrators and analysts who run workloads in various infrastructures should be able to automate tasks to take care of repeatable operational work. An operator can be used to manage the database applications.

An operator is an application that contains code that takes over automated tasks to manage a database. Below is the list of features that an operator should enable so databases can be managed and operated appropriately in any environment. 

Operators for database high availability

The database should be highly available, as this is usually pretty important for the organisation’s continuity. High Availability (HA) is a system characteristic that aims to ensure an agreed level of operational performance, typically uptime, during a standard period.

Operators ensure that the Recovery Point Objective (RPO) and  Recovery Time Objective (RTO) defined are achieved. The strategy should include automatic failover without data loss – with switching traffic from old primary to new primary, automation of a one-member and full-cluster crash recovery, cross-region and/or cross-cluster replication, health and readiness checks, etc.

Security set-up enabled by operators

A database can hold confidential, sensitive, or protected information, making it a prime target for cyberattacks. Therefore, operators should implement basic security requirements such as user authentication and authorisation is essential and should be enabled by default. In addition, semi-automatic updates, network security, encryption in transit and encryption at rest can be implemented.

Operators for deployment

Deployment readiness is also vital for databases in production. An  automated setup for deployment done by Operators helps organisations improve the customer experience and mitigate operational risks. There are multiple considerations here: schema setup, vertical and horizontal scalability, the ability to deploy air gapped, database plugins, customisation and configuration of the database, multiple database version support, multiple storage system support and many more.

Backup  and restore implementation

Here is the list to consider of what operators should do to enable backup and restore

• Backup to another region
• Backup compression
• Backup encryption with external encryption key storing
• Partial restoration
• Consistent backup of multi-shard clusters
• Point-in-Time Recovery – the possibility to make recovery to any transaction

Operators enables monitoring

A production database should be monitored appropriately. This can be implemented by having logs, query analytics, host and database metrics. In addition, appropriate alerting rules and notification channels must be in place. An operator can simplify and automate enabling these monitoring capabilities for databases.

Canonical Charmed NoSQL database operator

Canonical has developed its own database operators, known as charms. Charms are application packages with all the operational knowledge required to install, maintain and upgrade an application. Charms can integrate with other applications and charms. 

Charmhub.io has published multiple database charms that can run in Kubernetes, Virtual Machines (VMs), public, private and hybrid clouds. Explore the available NoSQL open source charms below:

Deploy Redis using Charmhub – The Open Operator Collection

Deploy Cassandra using Charmhub – The Open Operator Collection

Deploy MongoDB using Charmhub – The Open Operator Collectio

Conclusion

Building and running massively interactive applications has created new technology requirements. This includes requirements on agility, real-time data management, and data variability. Unfortunately, SQL cannot meet these new requirements. Enterprises need to turn to NoSQL database technology.

NoSQL technologies have various data types: document, wide column, graph, and a key-value store. This makes this database more suitable to address multiple use cases.

These databases need to be managed and operated in the production environment, and an operator is an excellent tool to automate tasks for analysts, administrators and engineers.