IERS is Built for Elasticity

If you stop to think about it, the relational database (RDBMS) is a pretty remarkable piece of technology. Can you name another product category that has remained essentially unchanged since it was first introduced roughly 40 years ago?

However, in 2014 the RDBMS is no longer the “be all and end all” of database technology. An RDBMS can’t meet the demands placed on it by big data and cloud computing. Data entry has changed dramatically also. Instead of a requirement to scale with the number of data processing employees, there is now a requirement to scale with the number of customers, or to give a more dramatic example, to scale with the number of devices or sensors in a machine-to-machine (M2M) or Internet of Things (IoT) scenario. Many enterprises have outgrown their RDBMS, as have most telecommunications providers.

All up and down the application stack we can see the ability to scale out and in quite easily. By definition, big data requires an elastic database that can scale across multiple storage and compute nodes. Other technology that was created to be elastic, such as NoSQL and NewSQL, are more appropriate for big data environments.

How to Know if You Need Elasticity

Not every project requires an elastic database. When one does, things go much more smoothly if you can figure that out in advance and plan accordingly. It’s much easier if you make the effort to plan for an elastic architecture from the beginning. Look at your planned load and your projected growth and ask yourself whether it will exceed the capacity of your current hardware/software architecture. Will your database requirements fluctuate in demand? Will there be daily, weekly, monthly, and/or seasonal changes in the number of servers required? For example, if you have an analytics application that requires eight database nodes 24×7, yet peaks at 14 nodes for four hours every night, then elasticity is important.

NoSQL, NewSQL, and Elasticity

When NoSQL systems were initially being designed, emphasis was placed on scalability. In many cases, this meant eliminating many of the features that had been added to RDBMSs over time: powerful query languages, database consistency guarantees, durability, atomic operations – and just about everything else. At this point we had lots of elastically scalable databases that offered little else, whereby making them unusable except for very specific use cases.

NewSQL goes beyond NoSQL and stipulates that elasticity isn’t the only thing that matters and is instead a baseline requirement. Many of the things that we gave up (such as SQL) in our quest for elasticity are important. NoSQL required many of these things to be built into applications (increasing complexity and cost) and now we want them back in the database layer where they belong.

IERS is Built for Elasticity

In addition to having elasticity in its name, NEC’s InfoFrame Elastic Relational Store (IERS) was designed from the very beginning to provide a high-performance elastically scalable database with full ACID capabilities. IERS’ scale-out architecture expands your system without downtime as demand and data volume increases. This allows you to start small, save on unnecessary resource investments and then scale out easily based on demand. Minimal to no application modification is required to scale out or in.

IERS can scale out easily and quickly. System resource can be added while the system is live and in production, enabling the system to be reconfigured on-the-fly without downtime. Also, as the system scales out, automatic rebalancing of the data takes place. This process does not impact user operations. IERS sports an easy to use web based GUI that allows administrators to scale-in/scale-out with a few clicks from anywhere in the globe. Process once initiated requires no further human intervention.

To learn more about NEC’s IERS solution visit:

Matt Sarrel *Matt Sarrel is a leading tech analyst and writer providing guest content for NEC.

IERS Combines the Best of NewSQL and Key Value Stores

In my last blog post I provided a general introduction to key value stores (KVS). In this post I’m going to explain how InfoFrame Elastic Relational Store (IERS) takes the basic concepts of the KVS and improves upon them to build a database with strong business oriented features.

The main improvement is that IERS is built to process high-speed transactions with full ACID capabilities. As a quick refresher, ACID stands for Atomicity, Consistency, Isolation, Durability and refers to the set of properties that deliver reliable processing of database transactions. Atomicity preserves transaction integrity by only allowing complete transactions to be committed, not just parts of transactions. Consistency allows for well-defined rules to control and validate the data before it is written to the database. Isolation verifies that concurrent execution of transactions still results in complete transactions being committed; this is where conflict resolution takes places. Durability means that once a transaction has been committed it will remain intact even in the event of power loss, crashes, or other system errors. IERS offers full ACID support and thus meets the requirements for a business environment processing transactions, which many KVS fail to meet.

Most KVS cannot guarantee the constraints that developers need to place on data in order to preserve consistency. Consistency needs to be handled by the application, which pushes this critical function further away from the database engine and makes it more cumbersome to design the application as the application must now include features the database should handle. On the other hand, IERS provides consistency at the database layer, preserving the high performance of KVS.

Whereas most KVS require database-specific code to be written, IERS uses an industry standard SQL interface. Most KVS platforms don’t support SQL, hence the name NoSQL being used as a term to describe them. Over time, NoSQL as a term has expanded to include next-generation databases with a SQL interface by rebranding itself as “Not Only SQL.” Some industry analysts refer to next-generation databases with a SQL interface as NewSQL. However, the most commonly used database programming language is SQL and many business environments already have a significant investment in SQL. For these reasons, SQL support is one of the most important and most used features of IERS. Using another KVS might require developers to learn a custom API, thus delaying the development process. IERS, with its SQL support, allows developers to get up and running as fast as possible.

Database security is also a requirement in a business environment. IERS provides the same user authentication and table level access management as an RDBMS. In contrast, the typical KVS will push this up to the application layer. IERS also offers full support for user activity logging and can be integrated with a solution like IBM Guardium to provide complete audit trails.

IERS also fully supports range queries, a common database operation that retrieves all records where some value is between an upper and lower boundary. For example, list all customers between ages 8 and 18. A typical KVS cannot support a range query. In fact, a typical KVS only supports queries on the key.

As you can see, IERS contains many enhancements that are typically not found in a KVS. When the database layer lacks such functionality, then it must be implemented in the application layer. This requires the application layer to manage transactions, security, data constraints and consistency. It’s much easier to simply use a database that contains this functionality such as IERS. By including the functionality described in this posting, IERS demonstrates that it is more applicable for use in solving business problems than a typical key value store. The most important of these enhancements is full support for ACID transactions; without ACID there cannot be transactions. Businesses evaluating NoSQL and NewSQL key value stores for a high-speed transaction driven environment will find that IERS more than meets their needs.

To learn more about NEC’s IERS solution visit:

Matt Sarrel *Matt Sarrel is a leading tech analyst and writer providing guest content for NEC.