Do you have a New OLTP problem
Mike Stonebraker is right when he says in his recent article that the NewSQL market exists to solve the New OLTP problem, however that leaves us with two questions to answer.
- First, are you facing a New OLTP problem? And if so,
- Which NewSQL vendor’s approach is likely to address your specific requirements.
Let’s examine the market drivers behind this problem to better understand how to make those decisions.
You have a New OLTP problem if:
- You need transactions
- You’re facing an explosion of data in terms of velocity or volume
- You’d like real-time analysis of that data
- You’re considering a project to combine NoSQL and map/reduce
The baseline solution to a New OLTP problem includes:
- A scale-out database with
- Support for ACID transactions and
- A standards-based query language, SQL
Because you would rather avoid:
- Re-implementing consistency management in the application (or managing consequences of eventual consistency)
- Relearning how to query your data with a new language
- Rewriting your software or buying new tools
In addition your ideal solution would include:
- Adaptability to changing conditions (elasticity)
- Multi-tenancy, utility/SLA based solutions (DBaaS)
- An easy way to utilize hosted resources as well as internal infrastructure (multi-cloud)
This then becomes the new entry level for a modern OLTP database. When you have a New OLTP problem you require an ability to process extremely high transaction volumes while at the same time remaining responsive to business critical analytic query processing. NoSQL may have solve a small portion of the problem however the work required to adapt system to their lower standards simply pushes the hard work (consistency, query processing) into your application code, but it didn’t eliminate the need. The traditional (OldSQL) vendor, regardless of the specialized hardware, does not have what it takes to manage this deluge of data while providing up to the second analysis.
With NewSQL there is no reason to require an existing solution to be rewritten, no reason to retrain or rethink applications at all. You should be free to ask your programmers already familiar with SQL, JDBC, ODBC and other database standards to use the tools they are comfortable with, to incorporate existing open source and packaged SQL-based solutions, apply commonly used SQL techniques, etc. and benefit from the new database infrastructure. As an application programmer there should be no need to change your approach, simply to change your expectations of the database.
Regardless of what you are building, something entirely new or an improvement to an existing solution, if you are facing a New OLTP problem you can now find NewSQL solutions.