The 451 Group has published last week the conclusions of a report detailing the growing set of options in the information management space. In the process they also clarified what they meant by "NewSQL".
“NewSQL” is our shorthand for the various new scalable/high performance SQL database vendors. [...NewSQL vendors] have in common the development of new relational database products and services designed to bring the benefits of the relational model to distributed architectures, or to improve the performance of relational databases to the extent that horizontal scalability is no longer a necessity.
We would include (in no particular order) Clustrix, GenieDB, ScalArc, Schooner, VoltDB, RethinkDB, ScaleDB, Akiban, CodeFutures, ScaleBase, Translattice, and NimbusDB, as well as Drizzle, MySQL Cluster with NDB, and MySQL with HandlerSocket. The latter group includes Tokutek and JustOne DB. The associated “NewSQL-as-a-service” category includes Amazon Relational Database Service, Microsoft SQL Azure, Xeround, Database.com and FathomDB.
For Matthew Aslett, senior analyst at the 451 group, there are currently three trends in the industry:
- the NoSQL databases, designed to meet the scalability requirements of distributed architectures, and/or schemaless data management requirements,
- the NewSQL databases designed to meet the requirements of distributed architectures or to improve performance such that horizontal scalability is no longer needed
- the Data grid/cache products designed to store data in memory to increase application and database performance
The 451 Group presented a classification of the information management market and they conclusion of their report:
The report notes that even though there is a high degree of innovation in the information management space, the market is still largely dominated by relational vendors. They see however an interesting trend related to polyglot programming which is making developers use multiple database products.
The 451 Group explains that NoSQL has emerged both from the availability of commodity of hardware and the lack of response from existing vendors to address the performance, scalability and performance requirements of large scale data processing. Yet, they explained earlier:
In the meantime, we have already noted the beginning for the end of NoSQL, and the lines are blurring to the point where we expect the terms NoSQL and NewSQL will become irrelevant as the focus turns to specific use cases.
They see the emergence of NewSQL providers as a direct response to the increasing need for scalable data management products that take advantage of the distributed server architecture where NewSQL and data-grid products are commonly found. They see this sector of the market increasingly targeted by NoSQL vendors as well.
They also see distributed data-grid/cache products increasingly being positioned as potential alternatives to relational databases as the primary platform for distributed data management, with a relational database relegated to a supporting role.
InfoQ spoke briefly with William Shulman, co-founder of MongoLab, a company that provides a Cloud-based hosted MongoDB solution. He explained:
I think the six key drivers [cited to be behind the adoption of alternative information management solutions Scalability, Performance, Relaxed Consistency, Agility, Intricacy and Necessity] miss something subtle and important, that to me is the reason why MongoDB is the next MySQL. It's a data structure thing. MongoDB may have originally gotten attention because of the "mongo" (i.e. it can scale). But, I think the reason it is beloved by so many, for datasets both big and small, is the fact that it is a JSON object store. Having the ability to store complex data structures that mirror the objects in your code is what everyone has been waiting for for 15 years. Good bye object-relational mapping.
New information management solutions are rapidly being adopted even by large corporations, for instance Nick Tan, from the Commonwealth Bank of Australia, presented last year how the bank adopted Oracle as a Service showing significant hardware, license and operations cost savings. Are you using similar solutions? Do you see the benefits? Where do you see NoSQL fit?
Community comments
Complex data structures
by Matt Aslett,
This trend is picking up, SQL interface is unbeatable,NoSQL can improve it
by Avi Kapuya,
Missing LDAP
by Francois Armand,
Good bye to object-relaional mapping
by Robert Greene,
Picture in Big?
by Stefan Edlich,
NewSQL already used
by Thomas Mueller,
Impedance Mismatch depends on the programming context
by Erick Von Schweber,
Complex data structures
by Matt Aslett,
Your message is awaiting moderation. Thank you for participating in the discussion.
With regards to William's point about the importance of data structures, I agree and we do cover that in the report within the section on Agility and Intricacy.
Thanks for the write-up Jean-Jacques.
Matt
This trend is picking up, SQL interface is unbeatable,NoSQL can improve it
by Avi Kapuya,
Your message is awaiting moderation. Thank you for participating in the discussion.
A post I wrote from some time ago on this, without calling it NewSQL...
Xeround is a SQL database built on top of NoSQL foundations,
this post discusses different aspects of NoSQL, SQL and what's in the middle:
blog.xeround.com/2010/12/nosql-the-sequel
Missing LDAP
by Francois Armand,
Your message is awaiting moderation. Thank you for participating in the discussion.
Why LDAP is always missing in the NoSQL ecosystem ?
It is one the most used NoSQL datastore in the wild (you know, in the sens that you are doing NoSQL even without knowing it with LDAP).
It comes with a normalized protocol and query language, several interoperable and highly performant implementations of server (the two best, OpenLDAP and OpenDS^WOpenDJ being open source). Moreover, it has an interesting semi-structured format (schema based but free DIT), and a natural serialization format (LDIF) which is great to follow and store revision of the content.
Add to that the multi-master replication protocol[1] that can be used to have a normalized externalized trigger system, and you have a proponent that - at least - you should consider.
Not to say that LDAP is free from problem - it hardly is, but it is intersting, even if to see what can/should be done, and what can be avoid.
[1] blog.normation.com/2010/07/18/java-ldap-sdk-for...
Good bye to object-relaional mapping
by Robert Greene,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'm an object database guy, with Versant. We elimiated the need or ORM back in the 90's. Why was this important ... for 2 reasons. Developer productivity and Cost of Computing. The simple key-value (key-JSON) approach to elimination of RM "relational mapping" is not really delivering on these "reasons" for most applications. Using simple key-value moves the responsibility of complex relations into the application developers space, so lots of extra code must be written to manage depth in a model. So, that tosses your developer productivity. Also, storing everything in JSON means you need to de-serialize in the application space and that costs big time on the CPU, it is in essence a kind of mapping ( from Strings to language types ). So, that tosses out Cost of Computing. In the end, people need end to end objects, they need the object database, one with a killer query engine.
Picture in Big?
by Stefan Edlich,
Your message is awaiting moderation. Thank you for participating in the discussion.
Is this picture available in a bigger size? (I don't have 3750 $ at hand)
Would be great for educational purposes.
NewSQL already used
by Thomas Mueller,
Your message is awaiting moderation. Thank you for participating in the discussion.
FYI: the name 'NewSQL' is already in use by an (my) open source project.
Impedance Mismatch depends on the programming context
by Erick Von Schweber,
Your message is awaiting moderation. Thank you for participating in the discussion.
Am I the only reader of this fine post that works outside of the object programming context? I have found great value in moving as much application code as I can out of the object context and into the declarative context, and doing so end to end across all tiers. In SQL systems that means NOT doing OR mappping, but rather developing the app in SQL itself, including the user interface, all while applying MVC. I've been exploring doing the same with XSLT, XQuery and now SPARQL. While I am not at all against others doing objects, it is not the only way to go. I would argue that cost and productivity can be much higher in the declarative context, end to end with no mapping to objects. So the question I have with regard to this posting: from a declarative programming context what is the future of NoSQL and NewSQL?