Choosing an In-Memory Database

In a previous post on In-Memory Databases (IMDBs), Bobby Coates, Product Marketer at SingleStore, discussed what an in-memory database is and why it is useful and fast. In this post Bobby explains what to look for in an in-memory database, and shows how SingleStore fares against those capabilities.

Choosing an In-Memory Database (IMDB)

In-memory databases (IMDBs) are exploding in popularity. Wikipedia lists 42 different choices as of this writing (https://en.wikipedia.org/wiki/List_of_in-memory_databases). This popularity is increasing because IMDBs can significantly speed up a lot of very common tasks. From accelerating applications to providing faster analytics, IMDBs simply outperform traditional databases.

Some of the uses for in-memory databases include:

• Accelerating application performance.
• Using sidecar marts to assist but not replace data warehouses.
• Data warehousing.
• Store and navigate relationships using Graph data.
• Storing and representing Spatial data.

Types of in-memory databases

There are a few ways to categorize in-memory databases. For this post, we’ll focus on primary function.

• Application accelerator. It’s important for applications to be fast. Users may be external customers or internal users, either way they’ve become accustomed to fast applications and poor performance will negatively affect the experience. In this case, the amount of data may be relatively small (when compared to a data warehouse) or very large (for extremely large applications like ERP or CRM). If there is a lot of data, then one of the ways to make the application fast is having the application cache data in use. This can increase the number of application servers needed (cost) as well as making the application more complicated (even more cost). An in-memory database can improve performance and simplify the application.
• Data Warehouse/Hadoop accelerator. In this case, the volumes of data are extremely large with a lot of work done preprocessing the data to make it fast (aggregation, transformations, indexes, etc.) and still the DW can struggle. In this case, what may happen is that the Data Warehouse (DW) may preprocess some commonly used data and then write that data to the in-memory accelerator. When a query is submitted to the DW and it can be served by the accelerator, the accelerator responds (very quickly), this both delivers a quick response and removes some of the load from the DW but is limited in size.
• OLAP. Rather than accelerating part of the data, this type has access to all the data. If there is a large amount of data, the database will require a lot of memory or will need to be able to move data in and out of memory smoothly to address demand but be gentle on memory usage.
• Graph. Graph databases focus on relationships between entities. It is very specialized and can be demanding on the database to identify all the paths between the entities. Graph databases are often used in fraud detection.
• Spatial. This is for storing and querying points, lines and shapes representing places. Some advanced versions can represent geographic topography.
• Multi-Model. These databases are capable of performing two or more of the above capabilities. If a database can perform more than one task, it can offer savings in time and money as moving and duplicating data require skilled resources.

Why Choose SingleStore to be Your In-Memory Database?

At the core of any database, it should be fast. And SingleStore is unequivocally fast. It enriches the user experience and makes customers smile. SingleStore is multi-model and can serve applications, OLAP, as an accelerator to a data warehouse or Hadoop, for geospatial purposes, and more. Along with this rich set of capabilities, SingleStore can often deliver 10-100x performance at ⅓ the price.

Final Thoughts

SingleStore is a database purpose-built for data-intensive applications. It leverages in-memory capabilities in a multi-modal environment to deliver a wide range of capabilities. When choosing an in-memory database, many folks only consider the immediate need, for example supporting a large application, and review only databases that serve that specific purpose. This overlooks the possibility that there may be additional benefit in generating analytics on that data in real time. This is one very common area where SingleStore shines, and shouldn’t be discounted.

If you have questions about how SingleStore helps address In-Memory Database requirements, ask them on our Forum. Development experts and engineers from SingleStore, as well as members of our user community are always happy to help out.

Follow us on Twitter.