New SQL: An Alternative to NoSQL and Old SQL for New OLTP Apps

1. New SQL: An Alternative to NoSQL and Old SQL for New OLTP Apps An Article by Mike StoneBraker June 16, 2011, http://cacm.acm.org/ Group 18 AsmaaElBadrawy Sundaram T R

2. Motivation • Old OLTP requirements: • Historically, OLTP was performed by customers submitting traditional transactions to a relational DBMS. • Enterprises used ETL products to convert OLTP data to a common format and load into data warehouse for performing business analysis. • Data warehouse activity rarely shared machine resources with OLTP because of lock contention in the DBMS and because business intelligence (BI) queries were so resource-heavy that they got in the way of timely responses to transactions.

3. Motivation • New OLTP requirements: • The transactions are increasing day by day. Good throughput has to be maintained even with the increase in transactions (e.g web and smart phones) • Need for real-time analytics. (e.g a Web property wants to know the no. of current users playing its game) Picture from VoltDB.com

4. New OLTP Deployment • Deployment Options: • Three different Query languages: • Traditional SQL • NoSQL • NewSQL

5. New OLTP Deployment (cont’d) • Traditional SQL: • The workload experienced by New OLTP may exceed the capabilities of Old SQL solutions. • Data warehouses are typically stale by tens of minutes to hours. So real-time analytics very difficult with old SQL.  Not ideal for New OLTP requirements.

6. New OLTP Deployment (cont’d) • NoSQL: • Overcomes workload problems in old SQL • Provides Scalability and high performance • Achieved through relaxing or eliminating transaction support and moving back to a low-level DBMS interface. • Downside: • Pushes ACID properties to applications where they are far harder to solve. • The absence of SQL makes queries a lot of work.

7. New OLTP Deployment (cont’d) • NewSQL: • SQL-like, but not SQL. • Implemented such that it is easy to use. • Not so complex as SQL • SQL not standardized or simplified. • It is considered that object databases are not the future. • Available Converters to migrate SQL based applications to NewSQL. So old applications based on SQL are not affected. • Has java-like data types which are easier for developers. • Supports advanced data types like arrays.

8. New OLTP Deployment (cont’d) • NewSQL: • Compared to the earlier options: • Preserves SQL features • Offers high performance and scalability • Preserves the traditional ACID properties for transactions.   • Capabilities these systems should support: • Should be equally capable of high throughput as the NoSQL solutions, without the need for application-level consistency code. • Should preserve the high-level language query capabilities of SQL.

9. A Comparison of old and NewSQL

10. NewSQL Commercial Use • Clustrix • Distributed systems-based database solutions. • NimbusDB • Provides very fast transactional database solutions • VoltDB • Provides a “blazingly fast” relational database system. • real-time feeds, sensor-driven data streams, micro-transactions, low-latency trading systems

11. Relevance to course • Chapter 21: • OLTP • Chapter 29: • Data warehouses

12. References • “New SQL: An Alternative to NoSQL and Old SQL for New OLTP Apps”, Michael Stonebraker, June 16, 2011, http://cacm.acm.org/browse-by-subject/data-storage-and-retrieval/109710-new-sql-an-alternative-to-nosql-and-old-sql-for-new-oltp-apps/fulltext. • “NewSQL Project”, Source Forge, http://newsql.sourceforge.net/ • “'NewSQL' Could Combine the Best of SQL and NoSQL”, JoabJackson, IDG News, PCWorld, http://www.pcworld.com/businesscenter/article/238728/newsql_could_combine_the_best_of_sql_and_nosql.html • “The NewSQL Database You'll Never Outgrow”, VoltDB, http://voltdb.com/our-story/about-voltdb