Download New SQL: An Alternative to NoSQL and Old SQL for New

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Database wikipedia , lookup

Expense and cost recovery system (ECRS) wikipedia , lookup

Clusterpoint wikipedia , lookup

Database model wikipedia , lookup

Microsoft SQL Server wikipedia , lookup

Relational model wikipedia , lookup

Open Database Connectivity wikipedia , lookup

SQL wikipedia , lookup

PL/SQL wikipedia , lookup

Transcript
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
Asmaa ElBadrawy
Sundaram T R
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.
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
New OLTP Deployment
• Deployment Options:
▫ Three different Query languages:
 Traditional SQL
 NoSQL
 NewSQL
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.
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.
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.
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.
A Comparison of old and NewSQL
SQL
NewSQL 'Jdb'
NewSQL 'S2'
CREATE TABLE TEST(
ID INT PRIMARY KEY,
NAME VARCHAR(255)
)
test=new table(
int id,
string name,
key(id)
)
create table test(
id int,
name string,
primary key(id)
)
INSERT INTO TEST
VALUES(1,'Hello')
test.add(1,"Hello")
insert test (1,'Hello')
SELECT * FROM TEST
test.get()
select test
SELECT T1.ID,T2.NAME FROM
TEST T1, TEST T2
WHERE T.ID=T2.ID
t1=test; t2=test;
t1.join(t2[t1.id==t2.id]).get(t1.id,t2.na
me)
select t1:test join t2:test on
t1.id==t2.id get t1.id, t2.name
UPDATE TEST SET NAME='Hi'
WHERE ID=1
test[id==1].set(name="Hi")
update test set id=1 where
name=='Hi'
DELETE FROM TEST WHERE ID=1
test[id==1].delete()
delete test where id==1
DROP TABLE TEST
test.drop()
drop test
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
Relevance to course
• Chapter 21:
▫ OLTP
• Chapter 29:
▫ Data warehouses
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-andretrieval/109710-new-sql-an-alternative-to-nosql-and-oldsql-for-new-oltp-apps/fulltext .
• “NewSQL Project”, Source Forge,
http://newsql.sourceforge.net/
• “'NewSQL' Could Combine the Best of SQL and NoSQL”, Joab
Jackson, IDG News, PCWorld,
http://www.pcworld.com/businesscenter/article/238728/ne
wsql_could_combine_the_best_of_sql_and_nosql.html
• “The NewSQL Database You'll Never Outgrow”, VoltDB,
http://voltdb.com/our-story/about-voltdb