NoSQL databases are becoming increasingly popular with developers for mobile and web applications as they provide flexibility, scalability, and performance as required by most of the next generation applications.
There are several categories of NoSQL databases:
- Document stores such as MongoDB, Couchbase and BaseX. These types of databases allow data to be stored as JSON documents.
- Key/Value pair NoSQL database such as Riak, Redis and Cassandra, which store data as key/value pairs.
- Graph databases such as Neo4j and DEX.
CumuLogic’s NoSQL database service provides a quick and easy way to access fully managed NoSQL database instances on any cloud, including private clouds. CumuLogic’s platform currently supports MongoDB database service. Users can launch a dedicated MongoDB service and optimize it for their particular workload if needed. CumuLogic platform manages the database instances from provisioning and monitoring, to replication and sharding automatically, and backup/restore. Each instance of MongoDB is optimized for a given size of the database node, so users get the highest price/performance value. MongoDB instances can be scaled on-demand by adding new replica nodes without having to shutdown the database.
CumuLogic platform users have visibility into key metrics so developers can take appropriate actions to fine tune NoSQL database performance. In addition the platform performs automated backups at defined frequencies and supports point-in-time restore for faster recovery from failures.
CumuLogic NoSQL database service automates the provisioning, configuration, performance optimization, management, failover, backups, updates and patching and security and access control, eliminating over 75% of administration tasks required to manage database servers.
- Fully managed instances of MongoDB database servers. Provision on-demand a single node or multi-node replica sets.
- Eliminate over 75% of administrative tasks with automated provisioning, configuration, performance optimization, scaling, failover, backups, updates and patching, and more
- Use single pane console or CLI tools to manage both SQL and NoSQL database instances
- Supports uses cases, such as Web Application Hosting, Big Data Analysis, Dev/Test/QA environments and more
- Easy to integrate with existing billing, monitoring, metering systems and network operations for Cloud Providers
Below are the features supported by CumuLogic MongoDB-as-a-Service:
- Provisioning – Single click or single API call to provision the desired database instance: size with configuration and performance parameters, single or multi-node replica set, backup settings, size of storage volumes and rules for auto update and patches.
- Monitoring and Self-Healing – MongoDB databases are fully monitored and provide visibility into performance of the database via real time charts on the User Dashboard. No additional monitoring tools are required to monitor MongoDB instances. In case of failure, the system will try to restore the replica set nodes or sharded cluster. Alert notifications are sent to the user’s email address regarding any performance degradation, failures and recovery process.
- Backup and Restore – CumuLogic database service uses persistent storage for datastore and initiates full database snapshot once every 24 hours. CumuLogic also backups the opslog (transaction log file) file periodically and hence it’s possible to do a point-in-time restore. In case of a single node database instance, the database backup will impact the performance of the database, therefore, it’s recommended to customize the time of the day suitable for backup operations. In case of replica sets, a secondary node is used for backup purposes to minimize the performance impact on the primary node. The backup retention period can be changed from the one day default.
- Database Snapshots – Users can initiate database snapshots at any time on a running database instance – as well as restore a database snapshot, or launch a new database instance with an existing snapshot. User initiated snapshots are retained permanently until deleted by the user. It is also possible to recover/restore snapshots in other availability zones, enabling users to migrate a database from one availability zone to another.
- Scaling – It’s possible to launch a single node of MongoDB and add additional nodes to convert the single node to a replica set as you scale your application. You can also remove nodes and scale down the replica set.
- Replication – MongoDB is a highly scalable database and has built-in high availability and data redundancy. A MongoDB single instance can be used for small experimental projects or can be used as multi-node replica set for data durability. For smaller applications or development experimentation, it is sufficient to use a single MongoDB instance and co-locate the application on the same instance.
- Automated Software Patching – CumuLogic database service provides an optional feature to apply minor updates and patches to the database engine. Users can choose when the updates are to be implemented and schedule the implementation. The database service does not apply patches to the operating system.
- Optimization – MongoDB database instances are optimized for the target cloud (IaaS cloud, virtualized environment or bare metal), which means out-of-the-box performance of each instance will be optimized to deliver the highest possible IOPS and lowest latency based on the size of the database instance. MongoDB internal processes perform disk I/O and are configured for better performance. Most of these parameters can be changed to suit a particular workload by creating Parameter Groups. Parameter Groups are a set of configuration parameters that impact the performance of the database and must be tweaked for optimal operations.
- Security and Access Control – MongoDB database instances are secured and protected by applying Security Groups or iptable configuration on the VM nodes. To access the database instance, you must first allow ingress from your application server’s IP address on a defined port. To enable access, you can create an Access Group and apply that Access Group to the running instance of MongoDB. Access groups work like firewall settings to open ports for ingress IP address range.
Get A Free Trial with a Cloud Provider Partner
CumuLogic NoSQL Database-as-a-Service eliminates over 75% of the database management tasks for developers and administrators while providing the flexibility to control the scalability and performance of the database instances.
- Instant Provisioning– Easy to spin up new database instances whether for development, QA/Testing or production purposes. Database instances can be provisioned using CumuLogic Console or with an API call. The deployment and lifecycle control of the database instances can be easily automated by using command line tools.
- Low Cost of Operation – The database instances are fully managed and monitored, eliminating the need for manual installation, configuration, backups, patching, scaling and replication. The built-in monitoring of database metrics allows users to analyze performance and availability.
- On-Demand Scalability – CumuLogic MongoDB can scale from a single instance for smaller applications all the way to production quality via Replica Sets and Sharded Cluster architectures.
- Reliable – Reliability is achieved by providing options to deploy multi-node replica sets. Multi-node database instances are replica sets or nodes of a sharded cluster and not only provide reliability, but also enhance the scalability of applications. Reliability of database instances can also be improved by using multiple replicas of the master database instance. In the event of a failure of the master database, replicas can be promoted as primary database servers.
- Secure – Database instances are secured using the firewall settings and security groups of IaaS clouds that allow users to control remote access to the database instances.
- Cost Effective – CumuLogic NoSQL database service is scalable on-demand so you can start using the size of instances which can handle a minimal workload and only scale the database out when needed. This eliminates costly over provisioning of resources and management cost of database service.
- Integrated with PaaS – Applications deployed on CumuLogic’s platform can easily be configured to connect to the database instances managed by the database service. In fact, only a single datasource for the applications is required to run on the platform in order to connect to the database instances. This allows users to build highly fault-tolerant application architectures.
- Supported on Multiple IaaS Clouds – CumuLogic abstracts the underlying APIs of the various IaaS clouds such as Apache CloudStack, Citrix CloudPlatform, OpenStack, VMware vCloud, vSphere, XenServer, KVM, Eucalyptus and many others. This enables users to deploy CumuLogic’s platform and database services on any of the supported private and public clouds.
CumuLogic NoSQL Database-as-a-Service supports the MongoDB database engine, providing a quick way for developers and system administrators to provision fully managed instances of MongoDB database server on any cloud. With a single click or a single API command, users can provision a fault-tolerant, multi-node MySQL cluster, or a single node instance of the standard version of MySQL server.
When provisioning the MySQL database engine, users can tweak the performance parameters to optimize the database service for their applications and workload types.
Once provisioned, the database instances are fully monitored and managed by CumuLogic database service, including:
- Monitoring and reporting any instance failures
- Self-healing from some possible failures like process crash
- Periodically backing up the database to an alternate storage, most commonly object storage if available
- Configuring security and access controls by using firewall settings, security groups on IaaS clouds and using master user names and encrypted passwords
- Scheduling patching and applying minor updates to the running instances
Users can override the default time intervals of the scheduled automated backups, define the backup data retention policies, change the maintenance time windows, configure security and access credentials and override any updates and patching policies of the running instances.
CumuLogic DBaaS users can also create multiple read-only replicas of a master database instance to scale out their applications. Ready-only replicas are synchronously replicated and can be used in the event of master database failures.
CumuLogic NoSQL database service can be easily deployed with CumuLogic In-Memory Caching (Memcached) service to enhance the application performance.
Working with CumuLogic NoSQL Database Service
CumuLogic database service can be used to launch database instances using the User Console or a simple set of API. Users can launch database instances, create read replicas, take snapshots, create and apply parameter groups.
MongoDB-as-a-Service for Private Clouds – To run MongoDB service inside your datacenter, you can download CumuLogic Installer. To run the CumuLogic platform, you only need access to a single VM (or you can install it on bare metal as well) with at least 16GB RAM and 50GB disk space. The CumuLogic platform integrates with Citrix CloudPlatform, Apache CloudStack, OpenStack, Eucalyptus, and VMware vSphere and vCloud environments. Performance of MongoDB and other CumuLogic services depend on the environment type and block storage available.
Launching a Database Instance – Select the MongoDB database engine and size of the instance, and launch your database. Optionally, you can configure the database parameters and customize the preferences for backup and update maintenance time windows. Once you have launched the database instance you can get credentials and access point so you can use them to configure the datasource for your application to connect to the database instance. You can also use your preferred database management tools such as MySQL Workbench to create schema and import data into the database instance.
Creating and Applying a New Database Parameter Group – Database parameter groups allow users to optimize the performance of the database for specific workloads. You can easily create a new parameter group from a parameter family group of the engine, modify the selected parameters, and apply that parameter group to your database instance. You can apply a database parameter group to running instances with requiring a restart of the instance or start a new database instance with new parameter group.
Scaling out the Database Instance – For smaller applications or development experimentation, it’s sufficient to use a single MongoDB instance and co-locate the application on the same instance. However, for production purposes, there are two possible architectures: Replica Sets and Sharded Cluster (with or without Replica Set), both supported by CumuLogic’s platform. Please refer to our “MongoDB-as-a-Service” white paper for more details.
Taking a Snapshot – We recommend taking full database snapshots at regular intervals or at critical points where you are making major database or application code changes. In the event of a recovery, you may restore the database to in-point snapshots from the full database snapshots.
Monitoring and Optimizing – You can use monitoring metrics and charts to identify any potential issues with your database instance. As needed, you can edit the desired performance parameters by using database parameters and/or by using the in-memory caching service to scale out your database performance.
Users can also deploy applications using CumuLogic platform services and connect applications using a standard JDBC connection string.
The database tier is a key architecture component for any application. Applications may use relational databases such as MySQL, or NoSQL datastore such as MongoDB based on the application type, the data type and the size of the data to be stored. With CumuLogic DBaaS, developers, DevOps and Ops teams can quickly launch the desired type of the database, the size of the database nodes with a single API call or a single click on the UI. This eliminates the need for installing or provisioning, configuring and managing the databases completely.
Big Data Analysis
In modern applications, the data tends to be unstructured and in high volume. Such data can be generated by social applications or machines such as log files from web servers or debug data from large number of applications. Such data is usually required to be analyzed for further action by the applications. For example, analyzing web server log files to identify the demographics of the site visitors. Because of the unstructured nature of the data and its volume, developers prefer to use NoSQL daatabases such as MongoDB. Unlike relational databases such as MySQL, MongoDB can store unstructured data in form of collections of JSON files. These files can then be analyzed by commonly available tools.
CumuLogic SQL database service makes it easy and cost effective to architect a Disaster Recovery (DR) architecture and a plan for mission critical applications. Typically, enterprises are required to maintain one standby deployment environment to failover to in case of any downtime. With CumuLogic database service, it’s possible to launch a full functioning database server on the cloud or on different clouds within minutes, and a replica of a database server on an alternate cloud or alternate availability zone on the same cloud. The replicas are fully synchronized and in case of downtime, applications can quickly use the replica database servers nodes. If applications are deployed on CumuLogic PaaS, the platform will provision the applications on the alternate availability zone in case of failover. Database service eliminates the need of highly expensive standby environments and lowers the overall cost of maintaing and implementing a DR plan.