How the Cloud Complements In-Memory Databases
How the Cloud Complements In-Memory Databases
It's always a bonus when two promising, up-and-coming technologies fit well together. An example is the use of Redis to create a low-level cache that improves the performance of Rails models.
Join the DZone community and get the full member experience.Join For Free
In-memory databases and cloud-hosted apps are finding favor for their speed and convenience, particularly when used in tandem.
The outlook is rosy for in-memory databases, although they won't make their disk-based counterparts obsolete anytime soon. Eventually, however, DRAM prices will drop low enough to make in-memory databases suitable for bread-and-butter applications, not just the forecasting and planning apps that benefit most from in-memory's high performance.
Companies already use a mix of fixed-disk, solid-state, flash, and cloud storage. The ability to find just the right combination of storage options for your changing data loads is the key to keeping performance high and costs low. When it comes to speed, in-memory databases and cloud services have a distinct advantage over in-house fixed-disk servers.
In a recent interview, Oracle's Rich Clayton disparaged in-house IT, claiming it is too slow for planning and forecasting applications. Clayton is quoted by Diginomica's Phil Wainewright in a February 17, 2015, article as saying that within two years, up to 80 percent of planning and forecasting apps will be running in the cloud, although operational financials will remain the province of in-house systems.
The need for speed is also what's driving adoption of in-memory databases, which will generate $95 billion in annual revenue by the end of 2018, according to Gartner. Information Age's Ben Rossi reports on the in-memory database forecast in a February 27, 2015, article.
Analysts claim the biggest shortcoming of in-memory databases is their reliance on volatile memory. Gartner analyst Donald Frieberg points out that it's much more difficult to configure and manage a high-availability server for in-memory databases than it is for databases stored on fixed disks. Frieberg is quoted by Computing's Graeme Burton in a September 22, 2014, article.
One solution for protecting against data loss in in-memory databases is to implement remote direct memory access (RDMA), which allows the database to write to a second server. While doing so introduces some latency, Friebeg claims RDMA doesn't affect database performance.
Remote direct memory access allows an in-memory database to write to two servers simultaneously. Source: IBM.
One of the most practical uses of an in-memory database is to create a low-level cache to improve database performance. In a January 15, 2015, post on Sitepoint, Vasu K explains how to cache Rails models with Redis. While the primary source of Rails bottlenecks is in the View layer, a model-layer cache can boost database speed considerably.
Redis is particularly handy for this task because it is simple to set up and manage. Start by moving into the Redis app directory and executing the commands below:
Creating a low-level cache for Rails models starts by executing these commands from the Redis app directory. Source: Vasa K via Sitepoint.
Once you've created your models and category listing page with category descriptions and tags, you start your browser and go to /category to view the mini-profiler that benchmarks execution times of actions performed at the backend. Next, use the Ruby client for Redis built into Rails to direct the database to use Redis as the cache store.
The Ruby client for Redis lets you instruct Rails to designate Redis as its cache store. Source: Vasa K via Sitepoint.
One option for writing objects to Redis is to iterate over each property in the object, and then save the properties as a hash. However, it's faster and simpler to save them as a JSON encoded string using JSON.load. This necessitates updating the views to use the hash syntax to display the categories.
The simplest way to manage in-memory databases along with SQL and NoSQL databases is by using Morpheus. With the Morpheus database-as-a-service (DBaaS) you can provision, deploy, and monitor your MongoDB, Redis, MySQL, and ElasticSearch databases from a single point-and-click console. Morpheus lets you work with SQL, NoSQL, and in-memory databases across public, private, and hybrid clouds in just minutes. Each database instance you create includes a free full replica set for built-in fault tolerance and fail over.
In addition, the service allows you to migrate existing databases from a private cloud to the public cloud, or from public to private. A new instance of the same database type is created in the other cloud, and real-time replication keeps the two databases in sync. Visit the Morpheus site to register an account or sign up for a Morpheus demo.
Published at DZone with permission of Darren Perucci , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.